EU MDR cybersecurity is part of device safety - not a separate certification. My starting point: confirm whether your product falls under MDR, then connect each applicable Annex I requirement to security controls, test results, and risk records. FDA compliance alone does not satisfy EU requirements.
I focus on five tasks:
- Confirm scope and responsibilities: Use intended purpose and medical device class - not connectivity - to determine requirements and the conformity assessment route.
- Build security into the lifecycle: Assess threats, test controls, plan updates, and define support and retirement steps.
- Keep records linked: Connect technical documentation, deployment instructions, release decisions, and post-market records.
- Plan vulnerability response: Separate routine security fixes from reportable incidents. The general serious-incident reporting limit is 15 days, with shorter deadlines for certain urgent cases.
- Check the current rules: Review MDR law, guidance, standards, and device changes before closing your 2026 assessment. Treat GDPR and other cybersecurity duties separately.
My rule of thumb: <u>tools can help coordinate the work, but they do not transfer the manufacturer’s legal responsibility</u>. The goal is safe device use backed by current records, from design through retirement.
EU MDR Cybersecurity: Lifecycle Compliance Map
Annex I Requirements for Secure Design
Annex I Sections and Required Records
Build a requirements traceability matrix that connects each applicable provision to a design decision, implemented control, test result, and user instruction. Record the responsible owner, affected software version, review date, and unresolved findings.[8][9] Make this matrix the backbone of the technical file.
| Annex I provision | Design focus | Supporting records |
|---|---|---|
| 14.2 | Risks from the intended environment, connected equipment, and software–IT interactions | Environment assumptions, interface diagrams, integration tests, and failure-mode or resilience tests |
| 17.2 | State-of-the-art software lifecycle, risk management, information security, and verification and validation | Development plan, threat-modeling method, security requirements, code-review records, and verification and validation reports |
| 17.4 | Minimum hardware, network, and IT-security requirements, including protection against unauthorized access, for intended operation | Supported configurations, access controls, required ports and protocols, and installation and deployment documentation |
| 23.4, especially 23.4(ab) | User information, including minimum hardware, network, and IT-security requirements needed to operate the software as intended | Installation instructions, configuration steps, security precautions, maintenance procedures, and update and decommissioning instructions |
Keep the matrix, deployment instructions, and test evidence aligned. A standard alone does not prove MDR conformity. Document the clauses used, device-specific adaptations, justified exclusions, and evidence of conformity with applicable Annex I requirements.[8][5][12]
Threat Modeling and Patient Safety Risks
Define the intended use, clinical setting, users, assets, interfaces, data flows, and trust boundaries. Assess threats from data manipulation, service disruption, malware, unauthorized access, and insecure updates.
Link each threat to a hazardous situation, clinical harm, control, test evidence, residual risk, and benefit-risk justification. Include foreseeable misuse and usability risks that affect security. Access controls must not delay clinical care.[8][6][10]
Security Controls from Development to Retirement
Choose authentication, role-based access, least privilege, protected communications, and encryption to match device risk and deployment conditions. Define key and certificate management, security-event logging, behavior during outages, tested recovery, and authenticated, integrity-protected updates. Test controls under abnormal conditions and verify that they do not undermine clinical availability.[8][11]
Review code and third-party components during development. Protect build environments and signing keys in production, verify secure defaults at deployment, and reassess vulnerabilities during maintenance.
For retirement, define end-of-support dates and actions for data export and deletion, credential revocation, certificate invalidation, and network removal. Use after support ends requires a documented risk decision and compensating controls.[8][9][13] These records feed the technical documentation and release decision.
sbb-itb-535baee
Module 2 Regulatory Framework FDA 524B and EU MDR
Technical Documentation and Conformity Assessment
Once secure design is in place, the technical file must demonstrate conformity and keep post-market evidence up to date. Annex II documents conformity; Annex III documents post-market control. Build both under the Article 10 QMS. The level of detail depends on device class, risk, and the Article 52 route - not connectivity. Class I devices can generally use manufacturer self-declaration. Class IIa, IIb, and III devices require notified-body involvement. For Class I sterile, measuring, and reusable surgical devices, that involvement covers only specified aspects.[14][15][19][20]
Cybersecurity Documentation Map
Keep Annex II documentation controlled and easy to search. Required evidence should include the applicable GSPR checklist, design and manufacturing information, risk-management and benefit–risk records, software and system specifications, information supplied by the manufacturer, verification and validation results, and post-market surveillance documentation required by Annexes II and III.
Map each control to its Annex I requirement, threat, test, evidence, and residual risk. Identify requirements that do not apply and explain why. Cross-reference controlled records rather than making disconnected copies.[16][17]
Use this map to connect each cybersecurity artifact to its purpose as MDR evidence.
| MDR evidence category | Responsible function | Artifact | Review point | Cybersecurity objective |
|---|---|---|---|---|
| Device and system description | Engineering / regulatory | Architecture, interfaces, dependencies, data flows, operating environment | Design baseline and major change | Define the assessed system and supported environment |
| GSPR conformity | Regulatory / quality | Applicable GSPR checklist and applicability rationale | Technical-file review | Show that each applicable requirement is addressed |
| Risk management | Risk management / clinical safety | Threat model, risk analysis, control decisions, residual-risk assessment | Design review and release | Link threats to patient and user safety |
| Software lifecycle | Software engineering / quality | Lifecycle plan, requirements, change records, defect records | Each development phase and release | Control security throughout development and maintenance |
| Component information | Engineering / cybersecurity | Component inventory and, where appropriate, SBOM | Build, release, and vulnerability review | Identify vulnerable third-party and open-source components |
| Verification and validation | Test engineering / cybersecurity | Security, interoperability, usability, regression, and performance results | Test completion and release | Show that controls work in intended and foreseeable use |
| Vulnerability testing | Cybersecurity / quality | Vulnerability scans, manual assessment, penetration-test rationale and report | Pre-release and risk-triggered reassessment | Identify exploitable weaknesses and document how they are addressed |
| Labeling and instructions | Regulatory / human factors | Installation, configuration, access, credential, update, warning, unsupported configuration, and residual-risk information | Labeling approval and change review | Enable secure use without overstating user responsibility |
| Post-market surveillance and vigilance | Post-market / regulatory | PMS plan, incident records, trend analysis, corrective-action records, PSUR or PMS report as applicable | Periodic and event-driven review | Detect, investigate, and control emerging vulnerabilities |
| Quality-system procedures | Quality / regulatory | Secure development, change control, supplier and vendor risk, vulnerability-response, CAPA, and record-retention procedures | Internal audit and management review | Make cybersecurity activities repeatable and auditable |
Security Testing and Release Approval
Carry traceability through the test case, result, defect, corrective action, and acceptance. Record the tested build, environment, scope, methods, findings, exploitability, safety effects, fixes, retest results, and residual risks. Testing should cover interoperability, update behavior, supported configurations, and regression. Add manual analysis to automated vulnerability testing where needed. Use penetration testing when exposure and risk justify it. Otherwise, document the rationale and alternative evidence.[17]
Release and patch approval should involve engineering, cybersecurity, quality, regulatory affairs, and clinical or safety specialists where needed. Final approval remains with the manufacturer. Change control must assess effects on intended purpose, performance, interfaces, labeling, validated configurations, and continued conformity.
Even a third-party component patch may need review if it affects security behavior, performance, interfaces, or validated configurations. Before implementation, regulatory affairs should determine whether the change affects technical documentation, labeling, certification, or the conformity route.[14][15][18]
Include the approval record in the technical file and release rationale.
User Instructions and Secure Deployment
Publish instructions that match validated configurations. Cover supported configurations, network requirements, ports and protocols, access roles, credential requirements, account provisioning, logging, backup and recovery expectations, update procedures, unsupported configurations, warnings, and residual risks.
Healthcare teams are responsible for limiting administrative access, training users, and applying manufacturer-approved updates. Specify the manufacturer’s responsibilities for maintenance support, vulnerability evaluation, and safety incident notices.
Healthcare teams secure the environment; manufacturers remain accountable for conformity and corrective action. Vendors maintain conformity records, while healthcare teams own deployment and operational records.[5][8][19]
Post-Market Monitoring and Team Workflows
After release, MDR compliance moves from design evidence to surveillance, triage, and documented escalation.
Vulnerability Response and MDR Reporting
Under Article 83, manufacturers must maintain a risk-based post-market surveillance (PMS) system. For as long as the device is supported, monitor its use, advisories, supplier notices, vulnerability databases, service records, and provider feedback. Link each finding to the original threat model, affected version, and deployed configuration.
Product security should assess exploitability with input from engineering and clinical safety. Healthcare teams should supply logs, exposure details, and constraints on device use. Coordinate disclosure so customers receive clear mitigation instructions. This evidence supports the workflow owners listed below.[4][7][23]
Not every vulnerability is a reportable serious incident. Regulatory affairs should assess Article 87 reporting thresholds separately and determine whether remediation qualifies as a field safety corrective action (FSCA). A field patch or configuration change becomes an FSCA when it aims to prevent or reduce the risk of a serious incident - not just because it improves security.
Report qualifying serious incidents without delay, generally no later than 15 days after the manufacturer becomes aware of the incident and has established or reasonably suspects a causal link to the device. Certain urgent categories have shorter reporting periods. Don’t wait for a completed investigation: preserve evidence and document the reporting decision.[4][22][24]
Track each finding from assessment through closure. Feed the results into the original risk records and threat model, CAPA, and the applicable PMS report or periodic safety update report (PSUR). Assess recurring events against Article 88 trend-reporting criteria rather than assuming every vulnerability count is reportable. When corrective action is needed, keep authority and notified-body reporting separate from routine customer notices.[4][21][23]
Task Owners, Reviews, and Escalation
Assign named owners while keeping manufacturer approval for product-risk decisions. Define approval authority within each organization’s remit: manufacturer teams validate updates and accept product residual risk; healthcare teams verify safe local deployment and approve local exceptions.
Temporary controls need testing evidence and an expiration or review date, plus clinical review when care could be affected. Set risk-based review intervals unless a law or contract specifies a deadline.[8][25]
Use this workflow to assign actions, evidence, review timing, and escalation.
| Lifecycle task | Accountable party | Supporting evidence | Review frequency | Escalation trigger |
|---|---|---|---|---|
| Vulnerability triage and patch decision | Manufacturer product security and quality; regulatory affairs for reporting classification | Disclosure record, affected versions, exploitability, safety assessment, reporting rationale | Continuous intake; risk-based triage | Active exploitation, possible serious harm, ineffective mitigation |
| Update testing and release | Manufacturer engineering, quality, and clinical safety; healthcare teams for local deployment checks | Regression results, release approval, deployment checks | Each release; risk-based reassessment | Unsafe update path, failed tests, care disruption |
| Vendor and component support | Manufacturer supplier management, supported by component vendors | Component records, advisories, support commitments, fix evidence | Risk-based and contractually scheduled | Missing remediation, inadequate evidence, support ending |
| Healthcare inventory and segmentation | Healthcare clinical engineering, IT, and security | Version and support inventory, network rules, control-test records | Risk-based; after relevant changes | Unknown versions, exposed devices, failed isolation |
| Procurement review | Healthcare procurement, security, clinical engineering, and privacy | Supplier evidence, support terms, approved risk decision | Before purchase; risk-based renewal | Unsupported device, missing evidence, unacceptable risk |
| Incident investigation | Manufacturer and healthcare incident leads within their respective remit | Logs, timeline, clinical impact, containment and communications | Immediately; through closure | Possible serious incident, exposure across many devices or sites, loss of care availability |
| Compensating controls and exceptions | Local system owner and risk approver; manufacturer for product mitigations | Tested controls, expiration date, residual-risk acceptance | Risk-based; by exception expiration | Control failure, changed threat, risk above approved tolerance |
| End-of-support and retirement decision | Manufacturer for product support; healthcare organization for continued use or retirement | Support notice, migration plan, clinical fallback, risk decision | Lifecycle milestones; risk-based review | No secure upgrade path or unacceptable remaining risk |
Risk Assessment Coordination with Censinet RiskOps™
Censinet RiskOps™ can help healthcare organizations and vendors organize third-party and enterprise risk assessments. Teams can use it to track device and supplier reviews, remediation owners, due dates, and open risks.
The platform supports MDR-related post-market coordination. It does not replace manufacturer technical documentation, PMS records, conformity assessment, vigilance judgment, competent-authority reporting, or legal accountability.
Conclusion: Confirm Scope and Keep Records Current
Confirm device scope based on intended purpose, software function, class, risk profile, and conformity route - not connectivity. Document the decision and its rationale in the technical file.[8][26]
Keep the Annex I requirements-to-evidence matrix current. Map each applicable GSPR to controls, tests, residual-risk approvals, and documented exclusions.[8]
After mapping the technical file, review the external rules that govern it. Before closing the 2026 file, recheck current EU MDR law, Commission materials, nonbinding MDCG guidance, applicable standards, and notified-body expectations. Log the review date, sources, reviewer, and resulting actions.[3]
Handle MDR, GDPR, and other cybersecurity obligations separately. Give each gap an owner, a due date, and acceptance criteria. Trigger reviews and evidence updates when threats, device changes, or post-market findings emerge, so the compliance file stays aligned with changes to the device, threat landscape, and support status.[8][27]
FAQs
How do I prioritize cybersecurity gaps for MDR compliance?
Integrate cybersecurity into your ISO 14971 risk management framework. Under EU MDR Annex I, prioritize vulnerabilities that could affect clinical performance or patient safety. Assess clinical impact alongside severity scores, such as CVSS, to separate issues that need immediate action from those that need monitoring.
Keep a clear record linking each vulnerability to its controls, verification evidence, and residual risk decisions. Connect your SBOM, threat model, and testing records, and use vulnerability feeds to automate monitoring.
What evidence should I request from medical device vendors?
During procurement, ask the manufacturer for a machine-readable SBOM in CycloneDX or SPDX format, with updates throughout the device’s lifecycle. Also request a VEX file that identifies whether known vulnerabilities can be exploited in the device’s configuration.
Ask for the manufacturer’s coordinated vulnerability disclosure policy, including contact details, response timelines, and procedures for notifying customers.
Request the device’s support status, end-of-support dates, and security testing evidence. This should include penetration test reports and vulnerability scan results that show security controls work on the shipped build.
How do I assess whether a security patch affects MDR conformity?
Use structured change control to assess whether a patch changes the design or intended purpose enough to require further review. Check its effects on intended use, performance, risk, and compliance to determine whether it needs Notified Body review, an updated clinical evaluation, or a new conformity assessment [1].
Update technical documentation with patch details, risk assessments, and verification evidence [1][2][3]. Link patches to PMS and PSURs, and follow vigilance reporting and Field Safety Notice requirements for FSCAs [1].
