Cybersecurity post-market surveillance is not a separate system. It is a data source plugged into the same MDR Articles 83 to 86 PMS plan that already covers complaints, field data, and vigilance. The feeds are CVE databases, vendor advisories, and threat intelligence, and the receiving structure is the one the regulation already demands.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • MDR Article 83 requires a post-market surveillance system proportionate to the risk class and appropriate for the type of device, planned in accordance with Annex III.
  • Annex III §1.1(a) already obliges manufacturers to collect information on serious incidents, field safety corrective actions, and any feedback or complaints, including on usability and on safety, which in a connected device must include cybersecurity.
  • EN IEC 81001-5-1:2022 §9 (post-market plan for security) specifies the ongoing monitoring for new vulnerabilities, the response process, and the communication obligations.
  • A cybersecurity PMS feed is built from three signal sources: CVE databases matched against the SBOM, vendor and component advisories, and broader threat intelligence.
  • The cybersecurity PMS does not need a separate plan. It needs a named section inside the MDR Article 84 PMS plan.
  • Tibor's Round 2 observation: a device that is secure at launch becomes insecure later when a SOUP component publishes a CVE. Security is continuous, not one-time.

Why this matters

In Tibor's Round 2 follow-up interview, the single most-underestimated aspect of cybersecurity for founders was named plainly. Lifecycle. A device can be secure at launch and insecure six months later because a library published a CVE. Cybersecurity is continuous, not one-time. That is the entire case for cybersecurity post-market surveillance in one sentence.

The regulatory consequence is that MDR Articles 83 to 86 are not just about clinical complaints and hardware field failures. They are about any information that could change the benefit-risk balance of the device after it has been placed on the market. A publicly exploited vulnerability in a dependency changes that balance. If the PMS plan does not monitor for such information and does not define a response, the PMS plan is incomplete.

Felix sees the opposite failure mode on the startup side. Teams set up CVE monitoring for engineering reasons, never connect it to the QMS, and then cannot produce documented evidence of their vulnerability response at the surveillance audit. The work was done. The paper trail was not. The notified body cannot give credit for work that is not documented.

What MDR actually says about PMS, applied to cybersecurity

Article 83(1) requires manufacturers to plan, establish, document, implement, maintain, and update a post-market surveillance system in a manner that is proportionate to the risk class and appropriate for the type of device.

Article 83(2) specifies that the system shall actively and systematically gather, record, and analyse relevant data on the quality, performance, and safety of a device throughout its entire lifetime.

Article 83(3) names the uses of the PMS data. Among them: updating the benefit-risk determination, updating the design and manufacturing information, updating the clinical evaluation, updating the summary of safety and clinical performance, identifying needs for preventive, corrective, or field safety corrective action, identifying options to improve usability, performance, and safety, and contributing to the post-market surveillance of other devices.

Article 84 requires the PMS plan to be documented and to form part of the technical documentation set out in Annex II and III.

Annex III §1.1(a) details the contents of the PMS plan. Among them: information concerning serious incidents, information from trend reporting, a list of relevant harmonised standards, information from the scientific and technical literature, and any feedback and complaints provided by users, distributors, and importers.

Article 85 requires Class I manufacturers to prepare a post-market surveillance report. Article 86 requires Class IIa, IIb, and III manufacturers to prepare a periodic safety update report (PSUR) and, for Class III and implantables, to update it annually and submit it through Eudamed.

Annex I §17.2 and §17.4 make cybersecurity an in-scope safety property throughout this whole construction. A newly disclosed vulnerability is relevant data on the safety of the device within the meaning of Article 83(2).

EN IEC 81001-5-1:2022 §9 translates the general PMS obligation into the specific language of security. It requires monitoring for new vulnerabilities, timely response, and communication to operators and users when warranted. MDCG 2019-16 Rev.1 supports the same reading.

The short version: cybersecurity PMS is not a new obligation. It is what the existing PMS obligation looks like when you take the word "safety" in Article 83(2) seriously for connected and software-driven devices.

A worked example: a Class IIa connected glucose monitoring device

Consider a Class IIa continuous glucose monitoring device with a sensor, a small Bluetooth module, and a companion smartphone app that uploads readings to a cloud backend. Dependencies include the embedded RTOS, a commercial Bluetooth stack, a mobile cryptography library, and several cloud-side open-source packages. Total tracked components in the SBOM: roughly 400.

Signal source 1: CVE feeds matched against the SBOM. Dependency-Track or an equivalent scanner reconciles the SBOM against the National Vulnerability Database and the GitHub Advisory Database daily. Hits are filed as software problem reports under EN 62304 §6.2 and tagged as PMS input.

Signal source 2: vendor and component advisories. The embedded RTOS vendor publishes a monthly security bulletin. The Bluetooth stack supplier issues advisories irregularly. Mobile platform vendors (Apple, Google) publish regular security releases relevant to the companion app. The PMS plan lists each vendor, the cadence of their advisories, and the named individual who reviews them. If the review is not named, it does not happen.

Signal source 3: threat intelligence. This is the fuzziest of the three and the one startups most often skip. Low-cost options that work: ENISA advisories relevant to healthcare, ICS-CERT advisories (increasingly relevant because medical devices share components with industrial systems), MedISAO or similar medical-device ISACs where available, and a small set of security mailing lists covering the specific tech stack. A 30-minute weekly review is enough at startup scale.

The receiving structure. All three signal sources flow into one intake queue. A weekly triage meeting (engineering plus quality, under clause 7.3.9 of EN ISO 13485:2016+A11:2021) reviews new entries. Each entry becomes one of four things. Closed with documented rationale if not relevant. Opened as a software problem report under EN 62304 §6.2 if relevant but not urgent. Escalated to the patch management process (see the cybersecurity patch management post in this series) if critical. Or flagged as a potential serious incident or trend if the real-world evidence suggests harm is occurring.

Integration with the PSUR. For this Class IIa device, MDR Article 86 requires a PSUR. The cybersecurity section summarises the CVE hits of the period, the triage decisions, the patches released, the communication sent to users, and the residual risk. It is a named subsection in the PSUR, not a parallel document.

Integration with vigilance. If a vulnerability is exploited in the field and contributes to a serious incident under Article 87, the vigilance timelines kick in. The PMS and vigilance linkage is tight and the PMS plan documents it explicitly.

Volume on a real Class IIa device. Expect roughly 50 to 200 CVE hits per year against a 400-component SBOM, of which maybe 5 to 15 require real action after triage, and 1 to 3 rise to patch-level priority. These numbers vary widely by stack. The startups Felix coaches that track them honestly are rarely surprised at surveillance audits.

The Subtract to Ship playbook for cybersecurity PMS

1. Write cybersecurity into the existing PMS plan, not as a separate document. One plan, one audit trail, one review cycle. Add a named section under Annex III §1.1(a) data sources that lists CVE feeds, vendor advisories, and threat intelligence sources.

2. Name the humans. Every signal source has an owner, a review cadence, and a named backup. "The team monitors CVEs" is not a PMS plan. "Alex reviews the Dependency-Track alerts every Monday and files software problem reports by Wednesday; Priya covers when Alex is out" is a PMS plan.

3. Use the SBOM as the single source of truth for scope. If a component is in the SBOM, it is monitored. If it is not in the SBOM, it is not in the product. That bidirectional rule forces the SBOM to stay honest.

4. Define triage criteria in advance. CVSS score alone is not enough. The criteria should combine CVSS with exploitability-in-context (is the affected function actually used in this product), reachability (is the attack path open), and patient harm plausibility. Document the rule. Apply it consistently. A VEX statement captures the result.

5. Set response-time targets and measure them. Critical: hours to days. High: days to weeks. Routine: next scheduled release. The targets live in the PMS plan. The measurements live in the PMS reports and the PSUR.

6. Wire the PMS output back into risk management. EN ISO 14971:2019+A11:2021 requires production and post-production information to feed the risk management file. A confirmed vulnerability with field evidence updates the security risk file, which in turn may update the benefit-risk determination. That loop is mandatory under Article 83(3)(a).

7. Practice a CVE drill once per quarter. Pick a real recent CVE against one of your dependencies. Run the full loop: detection, triage, risk reassessment, change classification, patch, communication. Measure the elapsed time. File the dry-run evidence as PMS training. The first real incident will then not be the first incident.

Reality Check

  1. Does your PMS plan name cybersecurity vulnerability monitoring as a data source under MDR Annex III §1.1(a)?
  2. Is every component in your SBOM matched automatically against a CVE feed at least daily?
  3. For each vendor of a third-party component, do you know their security advisory cadence and the named person who reviews it?
  4. Do you have documented triage criteria that combine CVSS with exploitability-in-context and patient harm?
  5. Can you produce a log of every CVE raised against your product in the last twelve months, with the triage decision for each?
  6. Is the cybersecurity section of your PSUR a named subsection, or is it spread across the document and easy to miss?
  7. When was the last time you ran a CVE-response drill end-to-end and measured the elapsed time?
  8. If a notified body auditor asked "show me your cybersecurity PMS" tomorrow, how many clicks would it take to demonstrate the full loop?

Frequently Asked Questions

Do we need a separate cybersecurity PMS plan? No. MDR Article 84 requires one PMS plan per device or device family. Add cybersecurity as a named section inside it, covering data sources under Annex III §1.1(a), triage process, response times, and reporting linkage. EN IEC 81001-5-1:2022 §9 provides the content expectations for that section.

How often do we have to review CVE feeds? EN IEC 81001-5-1:2022 §9 requires a timely response but does not name a frequency. Daily automated scanning with weekly human triage is a defensible baseline for most products. Critical alerts should be reviewed within one business day. Document the cadence in the PMS plan.

What counts as a serious incident for a cybersecurity issue? A cybersecurity issue rises to a serious incident under MDR Article 87 when it directly or indirectly leads to death, serious deterioration in health, or serious public health threat. A theoretical vulnerability with no real-world harm is not a serious incident; it is a PMS input that may trigger corrective action. Confirmed exploitation with clinical consequences is.

Do we have to publish security advisories? EN IEC 81001-5-1 §9 and MDCG 2019-16 Rev.1 expect communication to operators and users when an update has security-relevant impact on them. Publishing advisories on a security page is the cleanest way. The advisory should name the CVE (or internal identifier), affected versions, severity, recommended action, and verification steps.

How does cybersecurity PMS interact with the PSUR? For Class IIa, IIb, and III devices, MDR Article 86 requires a PSUR. The cybersecurity section summarises the signals received, the triage decisions, the patches released, the communication sent, and the residual risk. Class III and implantable PSURs are submitted through Eudamed and updated annually.

What about threat intelligence sources beyond CVEs? Vendor advisories, ICS-CERT, ENISA healthcare bulletins, and relevant mailing lists are enough for most startups. The key is to have named sources, named reviewers, and documented cadence. Quality beats breadth.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Articles 83, 84, 85, 86, 87, Annex III §1.1, Annex I §17.2, §17.4.
  2. EN IEC 81001-5-1:2022, Health software and health IT systems safety, effectiveness and security, §9.
  3. EN 62304:2006+A1:2015, Medical device software, software lifecycle processes, §6.2.
  4. EN ISO 13485:2016+A11:2021, Medical devices, Quality management systems, clause 7.3.9, clause 8.2.
  5. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management.
  6. MDCG 2019-16 Rev.1, Guidance on cybersecurity for medical devices.
  7. MDCG 2025-10, Guidance on post-market surveillance.