ISO certification alone does not establish FDA compliance. I start with two checks: whether Section 524B applies to your device and which FDA duties your organization must meet.
As of October 13, 2026, alignment means linking your quality processes to device-specific records, not just certificates. The QMSR took effect on February 2, 2026, incorporating ISO 13485:2016 into FDA’s quality-system rules.
In this guide, I explain how to:
- Define scope: Separate mandatory FDA requirements from guidance recommendations and check each standard’s recognition limits.
- Assign owners: Connect threats, patient-safety risks, controls, tests, and approval decisions.
- Prepare submission records: Match test reports, risk assessments, and the software bill of materials (SBOM) to the submitted build.
- Manage software components: Track dependencies, vulnerabilities, supplier support, and release changes.
- Plan postmarket response: Set up monitoring, disclosure, patching, and end-of-life processes.
- Coordinate with HDOs: Share mitigation tasks and deployment needs without replacing manufacturer duties.
My rule: <u>give every applicable FDA obligation an owner, a controlled record, and a place in the submission or postmarket file.</u>
FDA Cybersecurity Alignment: From Scope to Lifecycle Evidence
FDA cybersecurity requirements: What is surprising and new in 2026?
As organizations adapt to these changes, measuring cybersecurity performance becomes critical for maintaining patient safety and operational resilience.
sbb-itb-535baee
Set Governance Roles and Build the Cybersecurity Risk File
With scope mapped, build the controlled cyber risk file. The cybersecurity risk file is a controlled set of records - not necessarily one document. Link the risk-management plan, threat model, security architecture, asset and data-flow inventories, requirements and control assessments, verification and validation results, SBOM and supplier records, vulnerability and change assessments, residual-risk decisions, and monitoring plans.
Connect the file to the QMS so reviewers can follow each risk from identification through monitoring. FDA’s current guidance recommends a Security Risk Management Report and threat modeling.[4][6] Once the file structure is clear, assign owners for each record set.
Assign Owners and Approve Security Procedures
Assign owners so ISO-based procedures produce the evidence needed for FDA submissions. Specify named owners, deputies, and approval rights. Leadership should approve policy, resources, risk acceptance, and escalation thresholds. Procedures should address secure development, supplier oversight, coordinated vulnerability disclosure, response-time expectations, required competencies, and escalation routes.
Quality controls procedures, records, deviations, and CAPA. Regulatory affairs owns submission evidence. Privacy reviews personal-data risks, while clinical safety evaluates patient impact. Procurement or supplier quality oversees third-party components.[4][7] These responsibilities connect ISO-style procedures to FDA-ready evidence.
| Activity | Responsible | Accountable | Consulted / evidence |
|---|---|---|---|
| Threat modeling | Systems engineering and product security | Chief engineer or product-security lead | Clinical safety, privacy, quality; approved threat model |
| Cybersecurity risk acceptance | Product security and clinical safety | Design authority or executive risk committee | Quality, regulatory, privacy; signed residual-risk decision |
| Security requirements | Systems and software engineering | Chief engineer | Product security, clinical safety; requirements traceability matrix |
| Security testing | Verification and security testing teams | Quality or engineering manager | Product security, regulatory; approved test report |
| SBOM maintenance | Software configuration management | Product-security or software-quality owner | Suppliers, procurement, vulnerability team; versioned SBOM |
| Vulnerability response | PSIRT or product-security team | Product-security executive | Quality, regulatory, clinical safety, communications; incident and remediation record |
Link Threat Models to Safety Risks and Security Controls
Start with intended use, foreseeable misuse, users, operating environment, assets, data flows, interfaces, trust boundaries, privileges, update and maintenance paths, and dependencies.
For each attack path, assess patient-safety effects. Identify the affected security property - confidentiality, integrity, availability, authenticity, or accountability - and analyze what could happen: incorrect therapy, delayed diagnosis, unavailable alarms, corrupted records, unsafe configuration, or loss of clinician control.
Trace each threat to requirements and controls, such as authentication, authorization, encryption, logging, segmentation, secure updates, recovery, and fail-safe behavior. Give threats, requirements, controls, tests, defects, and approvals unique identifiers with bidirectional links. That makes missing controls and untested requirements visible.[6][7]
Exploitability is not a fixed probability estimate. Attacker tools, credentials, exposure, public disclosure, and timing can change quickly, so historical frequency may mislead. Document access prerequisites, privileges, feasibility, mitigations, and uncertainty. Assess resulting harms and severity separately: cybersecurity analysis connects to ISO 14971 safety-risk management but does not replace it.[8] Trace each threat and control to a documented approval decision.
Document Risk Decisions and Approvals
Record the decision date, device/software version, threat ID, affected assets and functions, assumptions, evidence reviewed, pre- and post-control risk, verification status, limits, approver, and review date.
Link decisions to change control and verification and validation records so reviewers can follow approvals back to supporting tests. Reopen reviews when interfaces, suppliers, components, vulnerabilities, support dates, or deployment assumptions change. If isolation is part of the control strategy, document who maintains it and how it is verified. Keep approvals in controlled records.
| Record area | ISO 14971 record to reuse | Added FDA cybersecurity evidence |
|---|---|---|
| Intended use | Users, operating conditions, foreseeable misuse | Connected-system scope, interfaces, deployment assumptions |
| Hazard analysis | Hazards, harms, severity rationale | Threats, attack paths, exploit prerequisites, security impacts, patient-safety effects |
| Risk controls | Applicable safety controls and verification | Security requirements, architecture, control-to-threat traceability |
| Verification and validation | Relevant control-effectiveness results | Security, vulnerability, penetration, and resilience test evidence |
| Residual risk | Acceptability evaluations and approval process | Cybersecurity rationale, compensating controls, limitations, named approvers |
| Lifecycle monitoring | Complaints, incidents, change history | Vulnerability response, SBOM assessments, support status, update records |
Use only records that still match the device and software version under review.[6][8] Once the file is traceable, record the test evidence that proves each control works.
Prepare Testing Records and FDA Submission Evidence
Once the risk file is approved, separate the evidence FDA needs from the full internal record set. FDA guidance recommends documenting cybersecurity design, risk management, architecture, testing, vulnerability management, and lifecycle processes in applicable premarket submissions.[7][4] Apply quality-system controls, but don’t assume every internal artifact belongs in the submission package.
Test Security Controls and Device Resilience
Test the exact build and environment described in the submission. Base testing on the critical medical device security risks, threat model, interfaces, requirements, and foreseeable misuse. Cover security requirements, threat mitigation, vulnerability testing, and penetration testing. Use static and dynamic analysis, composition analysis, scanning, and fuzzing where appropriate.
Test authentication, authorization, interfaces, and interoperability using the submission’s exact hardware, software, configuration, and network setup. Under clinically relevant workloads, test tampered updates, rollback attempts, backup restoration, interrupted updates, and disrupted connectivity. For penetration testing, document tester qualifications, appropriate independence, scope, and exclusions.
Keep identifiers consistent. Use the requirement IDs, control IDs, and defect IDs from the risk file so test results map directly to the submission package.
Link Test Results to Security Requirements
A “passed” label is not enough. Link each requirement to its test procedure, results, defects, corrections, retest, and acceptance decision.
Preserve build and hardware identifiers, network setup, dependency and tool versions, test data, dates, reviewers, and supporting logs. Retain hashes for tested binaries and key evidence files. Enterprise audits, training records, and supplier assessments support the file, but they don’t prove the device meets its requirements.
Review Evidence Before FDA Submission
Check that the reports, architecture, risk assessment, and SBOM describe the same configuration. Resolve missing approvals, incomplete retesting, and unsupported risk acceptance.
Keep unresolved findings in the package only when they have documented risk decisions and compensating controls. Record exploitability, patient-safety impact, the authorized decision-maker, and remediation or monitoring commitments. Document how known vulnerabilities were identified, including the date and result of each CISA Known Exploited Vulnerabilities (KEV) Catalog review used in the submission.
| FDA requirement or recommendation | ISO-aligned process | Expected record | Record owner | Retention | Submission location |
|---|---|---|---|---|---|
| Demonstrate implementation and testing of security requirements | ISO 13485 verification/validation; ISO 14971 risk controls | Traceability matrix, protocols, results, defects, retests, approvals | Engineering and quality | Controlled design and verification records | Cybersecurity section and verification/validation attachments |
| Verify threat models and security risk controls | ISO 14971 risk management linked to threat modeling | Threat model, assumptions, assets, trust boundaries, attack paths, control mapping, reviews | Security engineering and risk management | Approved risk file and change history | Cybersecurity risk-management documentation |
| Provide security-testing documentation | Risk-based verification and validation | Analysis, scanning, fuzzing, penetration, interface, and resilience reports | Security testing lead and quality | Full reports and objective evidence | Premarket cybersecurity attachments |
| Address known vulnerabilities | Vulnerability-management and supplier-risk processes | Dated KEV reviews, scan results, discovery methods, triage, severity, remediation or acceptance | Product security and software supply-chain owner | Dated assessments tied to component versions | Vulnerability assessment and risk-management sections |
Submit the reports, summaries, and plans needed for FDA review. Retain supporting raw outputs and controlled records internally unless a requirement or FDA request calls for them. Before SBOM review, check that the tested build, component list, and release record match.
Maintain the SBOM and Software Supply Chain Records
Use the approved build as the source of truth for the SBOM. Section 524B(b)(3) requires an SBOM for applicable premarket submissions for FDA-defined cyber devices. Include commercial, open-source, and off-the-shelf components, along with firmware and embedded software. Keep a separate SBOM for each release.[7][9][10]
Define SBOM Fields and Assign Ownership
FDA recommends machine-readable SBOMs that use the NTIA minimum elements: supplier name, component name, version, unique identifiers, dependency links, SBOM author, and creation timestamp. Also include direct or transitive dependency status, licenses, and hashes. SPDX and CycloneDX are format options, not Section 524B mandates. Choose one canonical format and validate its structure and dependencies. If you use both, document the conversion rules.[6][7][11]
Give each team a clear role: engineering generates the composition record, product security validates it, quality or regulatory affairs approves it, and configuration management archives each release. Treat the SBOM as a controlled record in the cybersecurity risk file. Maintain linked records for vulnerability intelligence, supplier support terms, end-of-support dates, and update history. Procurement owns supplier support information; security owns vulnerability intelligence. Preserve superseded SBOMs. Block release if unidentified components or missing dependencies prevent an accurate inventory.[6][7][9]
Assess Component Vulnerabilities and Device Risks
When a supplier notice or new vulnerability arrives, match the component identifier and affected versions to device releases and deployments. Record the discovery date, affected configurations, whether vulnerable code is enabled and reachable, required access or privileges, and existing controls.[6][7]
A component vulnerability does not automatically establish device exploitability or patient harm. Assess device-level clinical impact separately, including incorrect therapy, unavailable monitoring, and delayed diagnosis. Assess privacy loss, too. A component’s CVSS score alone cannot determine device risk.[6][7]
For each advisory or update, identify affected components and releases. Record which components were added, removed, upgraded, downgraded, or reached end of support. Trigger supplier review when support ends, security defects recur, notices disclose newly affected versions, or composition data is unavailable.[9]
In the release history, link each advisory to the component, SBOM version, device release, risk assessment, decision owner, and patch-validation evidence. Retain the approved mitigation or residual-risk decision. These records support postmarket mitigation and patching decisions, show what changed and why, and feed postmarket monitoring and vulnerability response.[9]
Manage Postmarket Monitoring and Vulnerability Response
Monitor and Respond to Vulnerabilities
Use the SBOM, release history, and approved risk decisions from the prior section to guide postmarket monitoring. Section 524B requires a postmarket cybersecurity monitoring and response plan for applicable cyber-device submissions, including coordinated vulnerability disclosure procedures.
The plan should cover intake, triage, testing, mitigation, notification, and closure. Specify intake sources, triage owners, security testing, patch timelines, update delivery, and customer communications. Use ISO/IEC 29147 for disclosure intake and ISO/IEC 30111 for internal handling. Track acknowledgment, validation, patient-safety effects, priority, mitigation, communications, and closure. Link confirmed findings to the cybersecurity risk file. Open change control when software, configurations, or instructions change.[6][5][7]
Once you confirm a vulnerability, base patch timing on clinical and cyber risk - not a fixed deadline. Fix unacceptable vulnerabilities on a justified patch cycle, and address critical vulnerabilities outside that cycle as soon as possible. Document the timing rationale, interim safeguards, target release date, and management approval. Use active exploitation, remote unauthenticated access, and loss of essential clinical function to guide escalation. Assess applicable FDA reporting obligations separately. Having a patch available does not remove that responsibility.[6][7][4]
Plan Patching, Support, and End-of-Life Transitions
Assign named owners for vulnerability analysis, software engineering, clinical safety review, quality, regulatory assessment, customer support, and communications. Before release, validate installation, rollback, interoperability, cybersecurity effectiveness, performance, and clinical safety across supported configurations.
Give healthcare delivery organizations (HDOs) the details they need to deploy the update: affected versions, deployment instructions, prerequisites, expected downtime, backup and rollback steps, support contacts, and a follow-up date. Coordinate maintenance windows with clinical teams to preserve continuity of care.[7]
Track adoption and failed installations. When deployment must wait, provide validated compensating controls. Define support periods and communicate end-of-life plans early.
If patching is no longer feasible or a component loses support, reassess residual risk. Document whether to restrict functionality, isolate the device, replace the component, retire the device, or transition customers to a supported product. Require suppliers to provide fix status, testing evidence, updated SBOM data, and end-of-support information.[6][7]
Coordinate HDO and Vendor Risk Assessments With Censinet
Shared visibility between HDOs and vendors can help track mitigation ownership and unresolved risk. Censinet RiskOps™ can support centralized third-party and enterprise risk assessments, remediation tracking, and shared visibility across medical devices, suppliers, applications, and healthcare operations.[12][13]
Manufacturers provide advisories, affected versions, mitigation guidance, SBOM changes, and remediation status. HDOs provide deployment context, asset inventories, exposure information, compensating controls, and operational constraints.
Use that shared visibility to assign owners and track unresolved risks. It does not replace manufacturer risk files, testing, SBOM records, quality-system controls, or FDA duties.
Conclusion: FDA and ISO Alignment Checklist
Scope and sources: Confirm the device scope and whether Section 524B applies. Document all external connections and interfaces, affected versions, and the submission pathway. Record current FDA premarket and postmarket cybersecurity guidance, Section 524B, applicable QMSR requirements, and device-specific FDA communications.[4][1][2][14]
Owners and traceability: Check that owners and approval authority are named. Link each major threat in the risk file to its safety impact, controls, test results, residual-risk decision, and approver.
Submission and SBOM: Check that the evidence identifies the exact hardware, software build, configuration, and test dates. Match the release-specific approved-build SBOM to the exact build submitted.[6][7][10]
Lifecycle readiness: Verify that coordinated disclosure, patching, support, and end-of-life processes are active. Check that the postmarket monitoring file includes a named postmarket owner, escalation timelines, and closure records for each finding.[2][5]
Mark each check complete, partially complete, not applicable with justification, or requiring remediation. Map every applicable FDA obligation to an owner, a controlled record, and a submission location or postmarket evidence source. ISO alignment does not automatically satisfy FDA obligations.[4][1][5]
FAQs
How do I know if Section 524B applies to my device?
Section 524B applies if your device meets all three criteria: it includes software validated, installed, or authorized by the sponsor; it connects directly or indirectly to the internet or other networks; and it contains technology that may be vulnerable to cybersecurity threats [1].
Connectivity includes wired and wireless interfaces, cloud-linked updates, and companion apps. Standalone devices with firmware or programmable logic may also qualify [2][1]. Document your assessment in an applicability matrix for each device or device family [3].
How can I identify gaps in my ISO-based cybersecurity records?
Map your controls and documentation to FDA premarket and postmarket requirements. Use a traceability matrix to link each cybersecurity hazard to its mitigation, ISO control, and test evidence. Check that your threat models, risk assessments, and software lifecycle records connect.
Regularly audit your SBOM, security test reports, and risk management files. Confirm that they’re under version control and match your current device configurations and quality management system.
When does a cybersecurity update require a new FDA submission?
A new FDA submission is required when a software update or product supplement affects device cybersecurity. This includes adding software or connectivity features.
Manufacturers must analyze the security impact to ensure the changes don’t introduce new vulnerabilities. They must also validate the changes using updated test evidence linked to the revised threat model and security controls.
Manage these changes through the manufacturer’s established quality management system change control and CAPA processes.
