Cybersecurity is not a separate document under MDR. It lives inside the ISO 14971 risk file, anchored to EN IEC 81001-5-1:2022 and interpreted through MDCG 2019-16 Rev.1. A device that is secure at launch can become insecure the moment a SOUP library publishes a CVE, which is why cybersecurity risk management is a lifecycle activity, not a one-time artefact.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • MDR Annex I Sections 17.2 and 17.4 require that software be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management including information security, verification and validation.
  • EN IEC 81001-5-1:2022 is the current state-of-the-art standard for health software security activities in the product life cycle. It aligns with IEC 62443-4-1 concepts and dovetails with EN 62304.
  • MDCG 2019-16 Rev.1 is the authoritative MDR interpretation of cybersecurity requirements. It maps directly to 81001-5-1 and expects cybersecurity risks to be assessed alongside safety risks in the ISO 14971 file.
  • In Tibor's audit experience, the most underestimated aspect of cybersecurity risk management is lifecycle. A device passes its pentest on day one and then a library ships a CVE on day 400.
  • The SBOM is not a new document. It is what the IEC 62304 configuration item list should already contain.
  • Penetration testing is rarely wasted money. It is external proof of responsible development when internal process was weaker than it should have been.

Why this matters (Hook)

A wearable startup ships an NB-approved Class IIa device. A year later a curious security researcher posts a write-up showing that the device's Bluetooth pairing flow accepts any peer without authentication. The clinical consequence is real: a bad actor within Bluetooth range can impersonate the companion app and inject false readings into the patient record. The startup's risk file says nothing about this scenario because cybersecurity was handled in a parallel workstream that never fed back into the ISO 14971 hazard list.

Tibor has seen this pattern repeatedly at notified body engagements. Wearables and smart wearables are growing fast and encryption, data protection, and penetration testing remain under-invested. The failure mode is not usually total negligence. It is structural: cybersecurity lives in a separate tab of a separate spreadsheet, written by a different person on a different day, and never gets reconciled with the safety risk file that the NB actually reads.

Felix has watched the same pattern on the funding side. Founders who pitched a clean MDR submission then had to go back to investors to explain a post-market software change, an NB change notification, and six months of schedule slip because a SOUP library had a CVE nobody was tracking.

What MDR actually says (Surface)

MDR does not use the word "cybersecurity" very often, but the requirements are unambiguous once the right sections are pulled together.

Annex I Section 17.2. For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.

Annex I Section 17.4. Manufacturers shall set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended.

Annex I Section 23.4. The information supplied with the device shall include, where relevant, minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended.

MDCG 2019-16 Rev.1 "Guidance on Cybersecurity for medical devices". The authoritative interpretation of the above. It defines the scope of cybersecurity responsibilities, explicitly ties cybersecurity to the ISO 14971 risk management process, and lays out expectations for threat modelling, security risk assessment, secure development lifecycle, SBOM maintenance, verification, validation, and post-market vulnerability handling.

EN IEC 81001-5-1:2022 "Health software and health IT systems safety, effectiveness and security Part 5-1: Security". The current standard for security activities across the health software product life cycle. It is harmonised under MDR for the relevant GSPRs and is the reference point the notified body will use when assessing whether the state of the art has been met.

Plain language: MDR says the device must be secure in a state-of-the-art way and the risk file must reflect that. MDCG 2019-16 Rev.1 says the state-of-the-art way looks like 81001-5-1. 81001-5-1 says security activities have to be planned, performed, and maintained across the whole product life cycle, and the results have to flow into the ISO 14971 risk file.

A worked example (Test)

A Class IIa continuous glucose monitor with a Bluetooth companion app and a cloud backend. Software Safety Class B under IEC 62304. Primary users are adults with Type 1 diabetes; the app shows live readings and alerts on hypoglycaemia. The startup has four developers, one part-time regulatory lead, and is preparing for its first notified body submission.

Here is what a credible cybersecurity risk management approach looks like.

Threat model first, not a checklist. The team maps the trust boundaries: the sensor, the BLE link, the phone app, the cloud API, the healthcare provider dashboard. Each boundary gets a threat analysis using STRIDE or an equivalent approach. The output is a short document with named threats, not a pass-fail questionnaire.

Every threat lands in the ISO 14971 file as a hazard. "Unauthorised BLE peer injects false glucose reading" is a security threat in the threat model and a clinical hazard in the risk file. Probability, severity, and risk control all get filled in the same way as for mechanical and electrical hazards. This is the step most startups skip and the step Tibor checks hardest in audits.

Risk control follows the same hierarchy as for safety. Inherent security by design first: no BLE pairing without a device-specific code displayed on the sensor housing. Protective measures second: cryptographic authentication of every reading payload, rate limiting on the cloud API, anomaly detection on the dashboard. Security by information last: the IFU and the IT security baseline statement required by Annex I Section 17.4 and Section 23.4.

SBOM is the IEC 62304 configuration item list, done properly. Every library, every SOUP component, every version, tracked in the same place the development team already tracks configuration items. When a CVE lands against libexampleSSL 1.4.2, the SBOM tells the team within minutes whether they are exposed. If the SBOM lives in a spreadsheet nobody opens, the team finds out weeks later, which is the situation Tibor has seen play out at several post-market audits.

Verification and validation include security test cases. Unit tests for crypto primitives. Integration tests for the pairing flow. A system-level penetration test before submission. The pentest is not a replacement for secure development: it is the external proof that the internal process worked. Tibor's experience is that even startups that missed 81001-5-1 during development can still produce a credible pentest result that gives the NB evidence of responsible engineering.

Post-market vulnerability response is a documented procedure with a clock on it. A named owner. A monitoring feed for CVEs against the SBOM. A triage protocol that maps severity to response time. A change control path that loops back into the ISO 14971 file and, when significant, into a notified body change notification. Tibor has investigated cases where the window between public disclosure of a library vulnerability and the manufacturer noticing was several weeks. No patient harm in those cases, but the window was long enough that something could have happened.

GDPR is not a separate workstream. Personal data is data worth protecting in the cybersecurity risk file. MDCG 2019-16 Rev.1 treats data protection as part of the security scope. Tibor sees manufacturers who design software that processes PII and forget GDPR applies. The fix is awareness, not legal complexity: PII becomes an asset in the threat model, the same way glucose readings are an asset.

The Subtract to Ship playbook (Ship)

Fewer cybersecurity documents, more integration. The goal is one risk file that a reviewer can read end to end and understand both the clinical and the security story.

  1. One risk file. Cybersecurity risks are rows in the same ISO 14971 file as clinical risks. Tag them with a category so they are filterable, but do not start a parallel file. Parallel files diverge.
  2. Threat model as a standing document. Not a one-time artefact. Reviewed on every architecturally relevant change. Dated. Version-controlled.
  3. SBOM inside IEC 62304 configuration management. If the configuration item list is credible, the SBOM is a view over it. If the SBOM is a separate Excel file, the configuration management is probably not credible.
  4. Wire a CVE feed to the SBOM. Free tooling exists. The point is not sophistication. The point is knowing within 24 hours of a public disclosure whether the device is exposed.
  5. Name a vulnerability response owner. Not a committee. One person with a documented deputy. Tibor's rule: if nobody's name is on the procedure, nobody owns it, and nothing happens until the NB notices.
  6. Pentest before submission, even if not strictly required for your class. External evidence of responsible development is one of the cheapest ways to earn NB trust, particularly for startups whose internal 81001-5-1 process was thinner than ideal.
  7. Close the loop from PMS into the security branch of the risk file. Field data is not only about usability and mechanical failure. Failed login attempts, anomalous API traffic, and reported app misbehaviour are inputs to the security risk probability estimates.
  8. Never accept a known exploitable vulnerability. Tibor's absolute rule: if a real vulnerability is known and would harm the patient when exploited, there is no acceptance case. Zero tolerance. Patch it or pull it.

Reality Check

  1. Is there one ISO 14971 risk file containing both clinical and cybersecurity hazards, or are they in separate documents that never reconcile?
  2. Can the team name the person who owns post-market vulnerability response, and the named deputy?
  3. Does the SBOM live inside IEC 62304 configuration management, or is it a parallel spreadsheet?
  4. Is there a CVE monitoring feed wired to the SBOM, and what is the documented time from disclosure to internal triage?
  5. Has the device ever been pentested by someone who did not write the code?
  6. Does the threat model cover every trust boundary, including the cloud backend and healthcare provider interface?
  7. Are GDPR-relevant data assets identified in the security risk file?
  8. When did the security risk file last get updated from PMS field data, and was it less than a year ago?
  9. If a SOUP library publishes a critical CVE tomorrow, how long until the team knows and triages it?

Frequently Asked Questions

We are not connected to anything. Do we still need cybersecurity risk management? Only if the device has truly zero wireless capability whatsoever. If the microcontroller supports Bluetooth or Wi-Fi even in a disabled configuration, the risk file has to include evidence that the radio cannot be re-enabled maliciously. Tibor treats "it is not connected" as a claim that needs proof, not a statement of fact.

Is EN IEC 81001-5-1:2022 mandatory under MDR? It is not mandated by name in the MDR text. It is the harmonised state of the art that MDCG 2019-16 Rev.1 points to for MDR Annex I Section 17.2 cybersecurity expectations. Meeting 81001-5-1 gives presumption of conformity for the relevant aspects. Not meeting it puts the burden of proving equivalent compliance onto the manufacturer.

How does MDCG 2019-16 Rev.1 differ from FDA cybersecurity guidance? MDCG 2019-16 Rev.1 is the EU side. FDA cybersecurity expectations now flow from Section 524B of the FD&C Act and its guidance. The technical content is substantially aligned at the engineering level: threat modelling, SBOM, vulnerability response, secure development. The regulatory mechanics differ. A startup selling in both markets can maintain one cybersecurity risk file if it is built against 81001-5-1 and cross-mapped to the FDA expectations.

Is a penetration test required for Class IIa software? MDR does not mandate a specific pentest. MDCG 2019-16 Rev.1 expects security verification and validation, and a credible pentest is one of the most widely accepted forms of that evidence. For startups whose internal 81001-5-1 process was thin, Tibor considers a pentest close to essential as pre-submission evidence.

Does our QMS need a separate cybersecurity SOP? Not as a separate system. Cybersecurity belongs inside the existing procedures for risk management, software lifecycle, configuration management, CAPA, and post-market surveillance. Adding a parallel SOP creates two sources of truth and guarantees drift. Adding cybersecurity sections to the existing SOPs is the cleaner move.

What counts as a significant change for cybersecurity purposes? A change that alters the attack surface or the effectiveness of security controls. Adding a new API endpoint is significant. Upgrading a TLS library to patch a CVE may or may not be significant depending on the nature of the change. The decision lives in the change control procedure and in the ISO 14971 update. Felix's coaching experience: founders who document these decisions contemporaneously never lose them; founders who do not, always do.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I Sections 17.2, 17.4, 23.4.
  2. MDCG 2019-16 Rev.1: Guidance on Cybersecurity for medical devices (December 2019, Rev.1 July 2020).
  3. EN IEC 81001-5-1:2022: Health software and health IT systems safety, effectiveness and security Part 5-1: Security Activities in the product life cycle.
  4. EN ISO 14971:2019+A11:2021: Medical devices, application of risk management to medical devices.
  5. EN 62304:2006+A1:2015: Medical device software, software life cycle processes.