MDR Annex II does not have a chapter titled "cybersecurity". Notified bodies still expect a complete cybersecurity dossier inside the technical file. The expected contents are a security plan, a threat model, a security risk assessment integrated with EN ISO 14971, security requirements traced to implementation, verification and validation evidence, an SBOM, a vulnerability management plan and a cybersecurity section inside the IFU. The anchor standards are EN IEC 81001-5-1:2022 and MDCG 2019-16 Rev.1.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • MDR Annex II is the structural spine of the technical documentation. Cybersecurity evidence is distributed across several Annex II sections, not concentrated in one chapter.
  • MDR Annex I Section 17.2 and 17.4 are the GSPRs that require cybersecurity evidence in the first place. Annex I Section 23.4 carries the instructions-for-use requirements.
  • EN IEC 81001-5-1:2022 is the health software security lifecycle standard. MDCG 2019-16 Rev.1 is the EU interpretation.
  • The eight deliverables auditors expect are: security plan, threat model, security risk assessment, security requirements, design and implementation records, V and V evidence, SBOM and vulnerability management plan, and IFU security section.
  • The SBOM is not a separate artefact. It flows from the EN 62304 configuration item list.
  • Every cybersecurity document must trace back to a specific Annex II section so the notified body reviewer can find it.

Why founders get this wrong

In Tibor's experience, the most common cybersecurity finding at a first notified body submission is not that the device is insecure. It is that the technical file does not tell the reviewer where to look. The security plan exists on a Confluence page. The threat model is a diagram in a slide deck. The SBOM lives in the build system. The pentest report is in an email attachment.

None of this is wrong engineering. It is wrong filing. Annex II is an index, and if the index does not point at the evidence, the reviewer cannot grant presumption of conformity. The fix is to produce a single cybersecurity dossier that cross-references Annex II sections and lives inside the technical documentation folder.

Felix coaches startups on this the same way every time. Do not reinvent your cybersecurity process. Just put the outputs in the right drawer. The drawer is Annex II.

What MDR actually says

MDR Annex II defines the contents of the technical documentation. The relevant sections for cybersecurity are:

  • Annex II Section 1, device description and specification, including variants and accessories. The scope of cybersecurity controls is established here.
  • Annex II Section 2, information to be supplied by the manufacturer. This is where the IFU cybersecurity section lives.
  • Annex II Section 3, design and manufacturing information. The security development lifecycle outputs are cross-referenced here.
  • Annex II Section 4, general safety and performance requirements. This is the GSPR checklist where every cybersecurity GSPR, specifically Annex I Section 17.2, 17.4 and 23.4, is ticked with a citation to the underlying evidence.
  • Annex II Section 5, benefit-risk analysis and risk management. The EN ISO 14971 file goes here, and the cybersecurity risk assessment is integrated into it.
  • Annex II Section 6, product verification and validation. Cybersecurity V and V evidence goes here: static analysis results, penetration test report, fuzz testing records and SBOM vulnerability scans.

MDR Annex I Section 17.2 requires software development according to the state of the art, including IT security. Annex I Section 17.4 requires minimum IT security measures, including protection against unauthorised access. Annex I Section 23.4 is the instructions-for-use clause that requires the IFU to contain information relevant to safe use, which MDCG 2019-16 Rev.1 interprets as including cybersecurity information for users and operators.

The eight deliverables a notified body expects

1. Security plan. The top-level document. States the scope, the security objectives, the lifecycle model applied, the roles and responsibilities and the links to the other documents. Anchored to EN IEC 81001-5-1:2022. Referenced from Annex II Section 3.

2. Threat model. Describes the assets, the trust boundaries, the threat actors, the attack surfaces and the threats. A diagram plus a table. Should follow an established method such as STRIDE or a comparable structured technique, and should name it. Referenced from Annex II Section 5 alongside the risk file.

3. Security risk assessment. Integrated with the EN ISO 14971 risk file. Each threat from the threat model becomes an entry in the risk file with hazard, sequence of events, harm, severity, probability, control measures and residual risk. Separate cybersecurity-only risk files are a classic auditor finding. Referenced from Annex II Section 5.

4. Security requirements. Derived from the threat model and the risk assessment. Traceable forward to design, implementation and test cases, and backwards to the Annex I GSPRs. These are the security equivalent of software requirements under EN 62304 clause 5.2. Referenced from Annex II Section 3 and Section 4.

5. Design and implementation records. Architecture documentation that shows the security controls in the design, configuration of cryptographic libraries, authentication flows, key management and secure boot where applicable. Referenced from Annex II Section 3.

6. Verification and validation evidence. The most visible output and often the least complete. Expected artefacts: static application security testing report, dynamic testing, fuzz testing, penetration test report by an independent party where feasible, known-vulnerability scan of all SBOM components. Each artefact carries a date, a tester, a scope and a result. Referenced from Annex II Section 6.

7. SBOM and vulnerability management plan. The SBOM lists every component, library and SOUP item with version, supplier and licence. In Tibor's experience, a good SBOM follows naturally from the EN 62304 configuration item list. The vulnerability management plan defines how CVE feeds are monitored, how severity is triaged, how patches are validated and how changes flow into change control. Referenced from Annex II Section 3 and Section 6.

8. IFU security section. The user-facing cybersecurity information. Intended operating environment, required network configuration, user account management, patch responsibilities, incident reporting contact. MDCG 2019-16 Rev.1 gives the content list. Anchored to MDR Annex I Section 23.4. Referenced from Annex II Section 2.

A worked example: a Class IIa connected infusion pump

A startup is preparing a first submission for a Class IIa connected infusion pump. The device has a Bluetooth Low Energy link to a bedside tablet and a cloud sync for PMS telemetry. The technical file exists but the cybersecurity content is scattered.

The remediation is a single cybersecurity dossier folder that sits alongside the risk management file inside the technical documentation. Inside the folder:

  • 01-security-plan.pdf cross-references EN IEC 81001-5-1:2022 clause by clause.
  • 02-threat-model.pdf diagrams the BLE boundary, the tablet trust boundary and the cloud boundary, with STRIDE tables.
  • 03-security-risk-assessment.pdf is an extract from the main ISO 14971 risk file that shows the cybersecurity entries. The full risk file stays intact.
  • 04-security-requirements.xlsx traces every requirement to the test case and to Annex I Section 17.4.
  • 05-design-records/ contains the BLE pairing flow, the key management document and the cryptographic library configuration.
  • 06-vv-evidence/ contains the SAST report, the pentest report, the fuzz test output and the SBOM scan.
  • 07-sbom.json is a CycloneDX file generated from the build system, with a date and a hash.
  • 08-vulnerability-management-plan.pdf names the CVE feeds, the triage cadence and the patch process.
  • 09-ifu-security-section.pdf is the text block that appears in the user IFU.

Annex II Section 4, the GSPR checklist, cites each file by its name. The notified body reviewer opens the checklist, sees the citation, opens the file and finds the evidence. This is the only structure that survives contact with a lead auditor.

The Subtract to Ship playbook

Step 1. Build the folder before the documents. Create the nine-file structure above, even if most files are stubs. The empty folder forces the team to see the gaps.

Step 2. Start with the GSPR checklist. Open the Annex II Section 4 checklist and fill in the citations for Annex I Section 17.2, 17.4 and 23.4. If the citation is to be completed, that is a task. If the citation is see main risk file, it is not specific enough.

Step 3. Derive the SBOM from the build system, not from a spreadsheet. A CycloneDX or SPDX file generated on every release is always current. A hand-maintained spreadsheet is stale within a week.

Step 4. Integrate the security risk assessment into the EN ISO 14971 risk file. If there are two risk files, merge them. One file, one owner, one review cadence.

Step 5. Make the IFU section a real section, not a sentence. The IFU cybersecurity section is a full subsection with operating environment, user responsibilities, patch model and contact information.

Step 6. Write the vulnerability management plan before the first vulnerability. The plan names the CVE feeds, the triage cadence, the severity thresholds and the change control trigger. If the plan is written after the first CVE, the first CVE always wins.

Reality Check

  1. Can you name the Annex II section that cites each of your cybersecurity documents, without looking.
  2. Does your GSPR checklist cite specific files for Annex I Section 17.2, 17.4 and 23.4.
  3. Is your SBOM generated from the build system on every release, or maintained by hand.
  4. Is your cybersecurity risk assessment inside the EN ISO 14971 risk file, or in a separate document.
  5. Does your IFU contain a cybersecurity section with operating environment, user responsibilities and a contact for incident reporting.
  6. Do you have a written vulnerability management plan that names specific CVE feeds and a triage cadence.
  7. When was the last penetration test, who performed it and is the report in Annex II Section 6.
  8. Can a new team member find the cybersecurity dossier in under two minutes.

Frequently Asked Questions

Is there a single MDR clause that requires a cybersecurity technical file chapter. No. The requirement is distributed across Annex I Sections 17.2, 17.4 and 23.4, and the evidence is distributed across Annex II Sections 1 to 6. MDCG 2019-16 Rev.1 is the document that pulls them together.

Does the SBOM need to be in a specific format. MDR does not name a format. CycloneDX and SPDX are the two common standards. Notified bodies accept either. The key expectation is that it is machine-readable and current.

Do we need an independent penetration test. MDR does not mandate independence. In Tibor's audit practice, an independent pentest carries significantly more weight than an internal one, especially for Class IIa and above.

How often should the cybersecurity dossier be updated. On every release that affects any security-relevant component, and on every new CVE that affects an SBOM component. The vulnerability management plan defines the trigger.

Is the IFU cybersecurity section the same as the full security documentation. No. The IFU section is a short user-facing text. The full documentation stays inside the technical file. MDCG 2019-16 Rev.1 gives examples of both.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex II; Annex I Sections 17.2, 17.4, 23.4.
  2. 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.
  3. MDCG 2019-16 Rev.1, Guidance on cybersecurity for medical devices, July 2020.
  4. EN 62304:2006+A1:2015, Medical device software, software life cycle processes.