EU and U.S. rules both require device security across the lifecycle - but they do not ask for the same records. I start with two checks: which rules cover your device, and whether each released version has linked security, component, and patch records.
Here’s what I compare:
- Scope and review: EU MDR and IVDR tie security to device safety and performance through CE marking. U.S. Section 524B adds explicit duties for qualifying cyber devices in applicable FDA submissions.
- Development and testing: Both systems call for risk controls, design records, testing, and controlled changes.
- SBOMs and support: Section 524B requires an SBOM; MDR and IVDR do not expressly require one. I also check component support dates and device support commitments.
- Vulnerabilities and patches: Both require risk-based responses. Section 524B calls for urgent updates as soon as possible when critical vulnerabilities could cause uncontrolled risk.
- After release: I check disclosure plans, patch installation records, surveillance, and reporting decisions - not just whether a patch exists.
Quick Comparison
| Check | EU MDR/IVDR | U.S. Section 524B |
|---|---|---|
| Security review | Part of CE conformity assessment | Part of applicable FDA submissions for cyber devices |
| SBOM | Not expressly required | Required |
| Patch timing | Based on risk and postmarket duties | Regular, justified updates plus urgent fixes |
| Postrelease work | Surveillance, corrective actions, and applicable reporting | Vulnerability monitoring, disclosure, updates, and applicable reporting |
Section 524B took effect on March 29, 2023. The FDA’s updated cybersecurity guidance followed on June 27, 2025, and its Quality Management System Regulation took effect on February 2, 2026.
My takeaway: <u>reuse the records, not the compliance conclusion</u>. Map each record separately to EU and U.S. rules. Before buying a device, ask for SBOM access, support dates, disclosure contacts, and clear responsibility for installing and verifying patches.
EU vs. US Medical Device Cybersecurity Requirements
EU vs. U.S. Secure Development and SBOM Requirements
Lifecycle Security and Design Documentation
Connect legal requirements to evidence reviewers can trace. Keep threats, requirements, controls, and verification results in one record set. Use that evidence as the baseline for later vulnerability triage and patch validation.
EU and U.S. reviewers both expect traceable evidence. The difference is how their legal structures ask for it.
| Evidence area | EU review documentation | U.S. review documentation | Practical evidence |
|---|---|---|---|
| Lifecycle development | Development plan, security procedures, change-control records, and release approvals. | Development plan, security procedures, change-control records, and release approvals. | Controlled development and maintenance records. |
| Design analysis | Threat analysis and architecture records that support security controls. | Threat modeling and security architecture views that support premarket review. | Data-flow diagrams, trust boundaries, attack paths, and control mapping. |
| Risk management | Risk records that support applicable MDR/IVDR requirements, using an ISO 14971-based approach. | Cybersecurity risk assessment and control traceability. | Links from vulnerabilities to device functions, clinical consequences, controls, and residual risk. |
| Verification and validation | Test evidence that supports safety, performance, and security requirements. | Test evidence that supports cybersecurity claims. | Requirements-based tests, vulnerability scans, penetration testing, and open-finding assessments. |
Choose controls based on device risk. Link each threat to its technical effects and patient-safety consequences, including interruptions to clinical workflows. Then connect controls to test results and assessments of remaining risk.
Once you've mapped the design controls, inventory the shipped build.
SBOM Coverage, Formats, and End-of-Support Dates
Treat SBOM format and metadata as guidance, not statute. Compare component coverage, identifiers, and end-of-support data. EU rules do not explicitly name an SBOM, but SBOM-style inventories support state-of-the-art security review.
| SBOM topic | EU requirements and guidance | U.S. requirements and guidance |
|---|---|---|
| Legal basis | Component inventories support MDR/IVDR security assessment; an SBOM is not explicitly required. | Section 524B requires an SBOM for covered cyber devices. |
| Component coverage | inventory enough component detail to assess critical medical device security risks. | Cover commercial, open-source, and off-the-shelf components; dependency details support review. |
| Format and identifiers | MDR/IVDR does not set a universal format; machine-readable inventories support vulnerability matching. | FDA recommends machine-readable formats such as SPDX or CycloneDX; the statute does not specify these formats. |
| Baseline attributes | Maintain identifiable component records for each release. | Recommended: supplier, name, version, unique identifier, dependencies, author, and timestamp. |
| End-of-support data | Record end-of-support limits and their safety impact. | FDA recommends component support level and end-of-support information. |
| Vulnerability assessment | Link component vulnerabilities to device risks and controls. | Link findings to risk assessments and testing; VEX does not replace the SBOM. |
Generate an SBOM for each released version, including transitive dependencies and relevant firmware. Keep it under configuration control.
Record component end-of-support dates separately from device support. Document unknown dates, risks from unsupported components, and replacement plans or mitigating controls. Any VEX nonexploitability claim needs device-specific justification.
Use the same release baseline to evaluate patch impact and vulnerability reports.
sbb-itb-535baee
How to satisfy Cybersecurity for FDA and EU?
EU vs. U.S. Patch and Vulnerability Requirements
Patch timing should follow risk, not a fixed deadline. Section 524B requires a justified update cycle for known unacceptable vulnerabilities. It also requires out-of-cycle updates as soon as possible for critical vulnerabilities that could cause uncontrolled risk. Base the schedule on exploitability and clinical impact. Under EU MDR/IVDR, remediation must feed into postmarket action.[1] Use the released inventory to link each vulnerability to affected versions, exploitability, and patch scope.
| Activity | EU MDR/IVDR | U.S. Section 524B and related FDA expectations |
|---|---|---|
| Release baseline | Use component inventories to identify affected builds and patch scope. | Use the required SBOM to identify affected builds and patch scope. |
| Triage, disclosure, and risk assessment | Monitor vulnerabilities and assess device-specific exploitability, clinical impact, and reporting duties. | Include monitoring and coordinated vulnerability disclosure in the postmarket plan; assess exploitability and clinical impact. |
| Routine and urgent updates | Set risk-based schedules and escalate serious risks for corrective action. | Use justified regular updates for known unacceptable vulnerabilities; address critical vulnerabilities that could cause uncontrolled risk as soon as possible. |
| Patch validation and deployment | Verify continued safety, performance, and security; document installed versions and remaining exposure. | Validate fixes and their effects on safety and performance; document installed versions and remaining exposure. |
| Customer communications and postmarket records | Document affected versions, precautions, corrective actions, and risk decisions. | Document affected versions, mitigations, maintenance guidance, and remediation decisions. |
Vulnerability Reports, Risk Assessment, and Disclosure
Match vulnerability reports to affected versions using the release inventory. Then check sources such as the CISA Known Exploited Vulnerabilities Catalog and the National Vulnerability Database. Map each flaw to the exact build, dependency, and exposure path.
Assess exploitability and clinical impact for the medical devices themselves. Record whether an attacker can reach the vulnerable function, what privileges they need, and whether exploitation could affect patient safety or clinical performance.
Document the remediation decision, owner, target date, interim controls, and any unresolved residual risk. Coordinate disclosure so customers get precautions they can act on - not just a CVE ID. Disclosure and regulatory reporting are separate tasks. Assess EU vigilance and FDA reporting duties independently. This is critical because cyberattacks can disrupt clinical applications and compromise patient care. Section 524B’s disclosure-plan requirement does not mean every vulnerability must be reported to FDA.[1]
Patch Testing and Deployment
Once you’ve set the remediation decision, verify that the fix works without disrupting safety or workflow.
Before deployment, assess effects on device functions, interfaces, and clinical workflows. Document change-control and validation results, regression testing, security retesting, and release criteria. Check that compensating controls remain effective until installation.
Put the patch through QMS change control, update affected configuration records, and give customers clear installation instructions. Assess the regulatory impact of each change.[1]
Patch availability is not installation. Track affected devices, installed versions, failures, and deferrals. When installation is delayed, agree on interim controls and maintenance windows. Escalate when remaining exposure becomes unacceptable, and keep testing, rollout, and communication records ready for review.
Security Evidence for Review and After Release
After vulnerability triage and patch planning, link SBOMs, risk records, test results, and patch evidence to the EU and U.S. review paths and released builds. Binding obligations do not always prescribe a specific artifact or format.
In the EU, the main requirements are MDR Annex I, Section 17.2, and IVDR Annex I, Section 16.2. Both address IT security in accordance with the state of the art.[1]
| Security evidence | EU conformity review | U.S. premarket review | Postrelease maintenance |
|---|---|---|---|
| Lifecycle security and quality-system controls | Binding: Lifecycle and quality-system controls; Guidance: Dedicated security plan | Binding: Applicable quality-system controls and postmarket vulnerability plan for cyber devices; Guidance: Secure-development and governance evidence | Binding: Maintain controlled procedures, change records, and postmarket decision records |
| Threat models and risk records | Binding: Risk management evidence; Guidance: Threat-model format | Binding: Evidence supporting cybersecurity obligations; Guidance: Threat models and cybersecurity risk assessments | Binding: Reassess residual risks; Risk-based: Update assessments as exposure changes |
| Design and requirements records | Binding: Design and technical documentation; Guidance: Supporting documents | Guidance: Premarket evidence supporting the submission pathway; Binding: Section 524B evidence where applicable | Binding: Controlled design changes; risk-based documentation updates |
| Verification, validation, and testing | Binding: Conformity evidence; Risk-based: Test scope and methods | Guidance: Cybersecurity testing documentation; Binding: Applicable design verification and validation | Binding: Validate relevant changes; Risk-based: Additional testing |
| SBOMs and component inventories | Guidance: Component transparency supports conformity; MDR/IVDR do not expressly require SBOMs | Binding: SBOM for Section 524B cyber devices; Guidance: Machine-readable formats such as CycloneDX or SPDX | Guidance: Maintain release-linked inventories under configuration control |
| Support status and end-of-support dates | Guidance: Lifecycle and maintenance evidence | Guidance: Component support status and end-of-support information | Guidance: Update support data as components change |
| Vulnerability procedures and disclosure | Binding: Lifecycle risk controls; Guidance: Vulnerability monitoring evidence | Binding: Postmarket vulnerability plan, including coordinated vulnerability disclosure; Guidance: Supporting procedures | Binding: Implement applicable processes; Risk-based: Vulnerability assessment updates |
| Patch validation and corrective actions | Binding: Change-control and corrective-action evidence | Binding: Update processes and applicable quality-system controls | Binding: Validation, risk decisions, and corrective-action records |
| Surveillance and incident records | Binding: Postmarket surveillance arrangements | Binding: Postmarket monitoring plan for cyber devices | Binding: Surveillance and applicable reporting |
EU Conformity Review vs. FDA Submission Review
Classification sets the review route; Section 524B applies only to qualifying cyber devices.[1] FDA may request VEX to support exploitability claims. Treat that request as risk-dependent.[1]
| Review element | EU MDR/IVDR | U.S. FDA |
|---|---|---|
| Route and reviewer | Applicable conformity-assessment route; notified-body involvement depends on classification and device characteristics | Applicable premarket pathway, such as 510(k), De Novo, or PMA; FDA reviews the submission |
| Technical documentation | Evidence mapped to applicable general safety and performance requirements | Premarket evidence supporting the pathway, plus Section 524B evidence where applicable |
| Cybersecurity package | Lifecycle security, risk management, and testing evidence | Required SBOM and vulnerability plan, plus cybersecurity evidence for cyber devices; machine-readable SBOM formats are recommended |
| Quality-system records | Controlled records support conformity assessment and applicable quality-system review | Controlled records support quality-system compliance; not every internal record belongs in the submission |
Keep a document index that identifies each artifact’s revision, released build, regulatory requirement, and submission location. For EU files, map the evidence to applicable MDR/IVDR Annex I requirements and the state-of-the-art references used for conformity. These same artifacts must support postrelease surveillance, updates, and reporting.
Security Records After Release
Once a release ships, retention and traceability matter as much as the original submission package.
Keep records linked to each release: vulnerability intake, component updates, customer advisories, patch validation, deployment records, surveillance trends, residual-risk reviews, and corrective actions. Document no-action decisions with the same discipline as remediation.[1]
Record reporting decisions separately from technical triage. Assess EU vigilance, U.S. medical device reporting, and corrective-action duties against their own thresholds. A vulnerability alone is not automatically reportable.[1]
Document who supplies, approves, installs, and verifies updates. If you cannot confirm installation, record the limits of your visibility and the residual exposure.[1]
Conclusion: Map Shared Evidence to EU and U.S. Rules
Once development, SBOM, patch, and postrelease controls are in place, the main task is to map the same evidence to each jurisdiction’s rules.
Both regions require lifecycle security evidence, but that evidence has different legal meanings. EU MDR/IVDR conformity does not establish FDA compliance, and FDA clearance or approval does not establish EU conformity.[1] The same artifact can support both reviews, but it cannot satisfy both on its own.
Maintain Evidence With Separate Regulatory Mappings
Reuse evidence across jurisdictions, not compliance conclusions. Map each artifact separately to the relevant authority, requirement or recommendation, review stage, and postmarket duty. Link component findings to mitigation decisions and test records so every release has a traceable evidence trail.[1] Assign owners for monitoring, remediation, and release approval while keeping manufacturer obligations intact.
Use Device Documentation in Healthcare Risk Assessments
The same release records help healthcare organizations assess operational and replacement risk. Before procurement, request end-of-support dates, SBOM access, disclosure contacts, and patch commitments. Also ask who installs and verifies patches, along with exploitability assessments that distinguish component alerts from device-specific risk.[1]
For HDO risk review, bring these records into a broader third-party assessment workflow. Censinet RiskOps™ supports third-party and enterprise cybersecurity risk assessments for medical devices, clinical applications, supply chains, and patient data.[1]
FAQs
How do I know if my device qualifies as a cyber device?
Under Section 524B of the FD&C Act, a cyber device must meet all three criteria: it contains software or firmware validated, installed, or authorized by the sponsor; it connects directly or indirectly to the internet or another network; and it has features vulnerable to cybersecurity threats.
If your device meets these criteria, FDA cybersecurity documentation and postmarket surveillance requirements apply. Check FDA guidance for current definitions to confirm your device’s status.
When does a security patch require a new regulatory submission?
In the United States, routine patches generally don’t need a new submission if risks are documented and managed. Updates that introduce risks, affect safety or effectiveness, or change intended use typically require a new submission [1][2]. A PCCP may cover pre-approved updates [3].
In the European Union, significant changes to design or intended purpose may require conformity assessment or Notified Body review. Every update needs a documented risk-based rationale and verification evidence [1][4].
What should I do if a device patch cannot be installed safely?
Document your risk-based rationale in your quality management system - for example, in CAPA records or the device history file [1]. Assess how leaving the device unpatched could affect safety and essential performance, including possible system instability or workflow disruptions [1].
Back every decision with documented verification and validation evidence. Clearly communicate the patch status and any required alternative risk mitigations to healthcare delivery organizations [1].
