Medical Device Cybersecurity: Required Risk Assessment Docs

If your cybersecurity records don’t connect, your review can stall. For medical devices, I’d check five document groups first: the risk file, architecture and threat model, SBOM and component records, test evidence, and postmarket/labeling files.

Here’s the short version:

• Start with the risk file. It should define scope, owners, threats, controls, residual risk decisions, and traceability.
• Map the system clearly. Reviewers need diagrams, interfaces, data flows, trust boundaries, and use-setting assumptions.
• Keep the SBOM current. It should match the shipped build, list component versions, support status, and end-of-support dates, and link to CVE review.
• Prove controls work. Test plans and reports should tie each check back to a risk, requirement, or control.
• Show your postmarket process. Labeling, disclosure, monitoring, patching, and customer notice records should match the premarket file.

One stat makes the point fast: Claroty found known exploited vulnerabilities in 99% of connected medical devices it reviewed. That’s why regulators look for a single, traceable record set instead of loose files.

A fast check looks like this:

The main idea is simple: every file should point to the next one, from threat to control to test to release and field response.

Webinar: Master Medical Device Cybersecurity: Avoid FDA Delays

sbb-itb-535baee

Security risk management report

The security risk management report is the main record for cybersecurity risk decisions. FDA guidance expects this report in premarket submissions for devices that carry cybersecurity risk.^[12][4][13] Build it under AAMI TIR57 and ANSI/AAMI SW96.^[3][16] Start with the basics: scope, ownership, and review cadence.

Security risk management plan and scope

Before any analysis begins, document the plan, get it approved, and keep it under version control. Define the device’s intended use, system boundaries, what is in scope versus out of scope, and any assumptions about the operating environment. Spell out roles and responsibilities clearly. Who owns security risk decisions? Who speaks for clinical safety? Who signs off from quality and regulatory review? Also document the review cadence and show how the plan fits into the product safety and quality process.^[14][15]

This scope decides what goes into threat analysis, testing, and traceability. Put simply, it sets the baseline for threat analysis and risk scoring.

Threat analysis, risk evaluation, and mitigation rationale

Identify assets, threat actors, attack paths, and exploit conditions with STRIDE or a similar method.^[17][11][10] For each threat, document the possible effect on clinical operations and patient safety. State the patient harm scenario in plain terms.^[1][6][8]

Each threat entry should include:

• Likelihood and severity scoring, using a clear scale
• The control chosen to address the threat
• A short rationale for why that control fits the device architecture and use environment

Document residual risk acceptance with quality-system approval.^[6][8][9]

Traceability from risks to controls and evidence

The traceability matrix is often the quickest way to see whether the risk file is complete. Link each threat or vulnerability to its control, implementation record, verification evidence, and risk decision.^[1][6][8][9] Include unresolved issues and show how each one was handled.

Classify each item as closed, open, or accepted, and give the rationale. This matrix then becomes the baseline for the architecture and threat model documentation that follows.

Threat model and system architecture documentation

This layer of documentation explains how the device is put together and how an attacker might get to it. Put simply, it connects documented risk to the way the system is laid out in practice.

System architecture, interfaces, and data flows

Architecture documentation should cover the entire system: hardware, firmware, software layers, external services, and the deployment setting, including hospital, clinic, and home use.^[19][6][21]

The diagrams should call out major hardware parts, software layers, and outside services such as EHR integrations and cloud platforms. They should also show how the device ties into hospital networks, VLANs, VPNs, firewalls, and security gateways, along with physical, logical, and wireless interfaces like USB, BLE, Wi-Fi, and HL7/FHIR.

Write this for an independent reviewer. In other words, the reviewer should be able to look at the documentation and understand trust boundaries, attack surfaces, and data flows without relying on unwritten team knowledge.

For each interface, document:

• Protocol
• Port
• Authentication method
• Data class

For PHI or clinical data, spell out where the data is created, processed, stored, and transmitted. Also name the encryption and key management in use instead of saying only "secure channel."

Every trust boundary should be marked. At each crossing, document authentication, authorization, confidentiality, logging, and operational ownership. That means being clear about who patches, who monitors, and who can initiate support, so shared duties aren't left fuzzy. This clarity is essential when managing cybersecurity and risk data across complex healthcare networks.

Threat model outputs and use-environment assumptions

Architecture shows how the system is built. Threat modeling shows how it could be attacked. Once the system is mapped, list attack paths for each component, interface, and data flow. A STRIDE-based analysis, or an equivalent method, should produce a catalog of specific threats, such as firmware tampering during over-the-air updates, spoofing of clinician accounts on the web UI, or information disclosure through misconfigured cloud storage.^[18][19]

The table below shows the difference in practice:

Threat model outputs should also make use-environment assumptions explicit. FDA guidance expects manufacturers to treat hospital networks as hostile by default and to assume an adversary may control network traffic, including the ability to alter, drop, or replay packets.^[18][19]

That assumption matters. A device used in a locked-down hospital network does not face the same conditions as one running in a clinic or a patient home. The documentation should explain how hospital, clinic, and home settings change the attacker model and the dependability of network controls.

If the device depends on hospital directory services for authentication, or assumes network segmentation is already in place, say so plainly. Then analyze what happens when those assumptions fail.

Use these outputs to validate the SBOM and the component risk records that come next. The architecture and threat-model outputs should line up with the SBOM and component risk records in the next section.

SBOM and component risk records

Use the threat model and architecture to check the SBOM and component risk records against the actual device build. Start with the component inventory. Then confirm each item is present in the deployed build.

SBOM completeness and component inventory

Document every component running on the device. That includes embedded firmware, operating systems, open-source libraries, commercial off-the-shelf (COTS) SDKs, and cloud services that process or store device data. The FDA requires SBOMs for "cyber devices" in premarket submissions under Section 524B(b)(3) of the FD&C Act, and strongly recommends them for other devices with medical device security risks.^[2][7][30]

Each SBOM entry should include:

• Component name
• Version
• Supplier
• Timestamp
• Unique ID
• Hash
• License
• Type: commercial, open source, off-the-shelf, or internal
• Dependency relationship

Store the SBOM in SPDX or CycloneDX JSON/XML, and attach a CSV export.^{[24][25][26][29][31]}

Two fields should always be included: support status and end of support (EOS) date. For each component, note whether it is supported, in limited support, end-of-life, or unknown. Also record the vendor-published end-of-support date in MM/DD/YYYY format.

An EOS component is not an automatic blocker. But your submission should show the risk assessment, any compensating controls, or the replacement timeline. If a component is unsupported, include a documented risk decision or a replacement plan.

Build SBOM generation into the CI/CD pipeline so it updates at each build and links every released software version to a frozen snapshot tied to the device's Unique Device Identification (UDI). Then run periodic binary composition analysis scans to confirm the deployed image matches the documented inventory.^[31][32]

Once the inventory is done, map each component to current advisories and CVEs.

Third-party vulnerability assessment and remediation tracking

Component risk records show how the SBOM is used to assess exposure. Pair the SBOM with sources such as the NVD, CISA's Known Exploited Vulnerabilities (KEV) catalog, and vendor advisories to find CVEs and track exposure.

For each component, review findings in context. Is the vulnerable version actually in the deployed device? Is the component network-exposed or only internal? Are compensating controls already in place?

Health-ISAC reported 993 vulnerabilities across 966 medical products in 2023, up 59% from 2022; 64% were in software applications.^[27][28] That's a lot to keep up with. Automated SBOM-to-CVE checks help teams stay on top of it.

For each vulnerability, the risk record should document the CVE ID, CVSS score, exploitability context, impact assessment, risk decision - mitigate, remediate, accept, or replace - and the rationale. Every decision should trace to a matching entry in the security risk management report with a unique risk ID.

That traceability - from CVE to risk entry to control to test evidence - is what regulators and hospital security teams look for when they review the file. Tie each open issue to test evidence and the current remediation status.

Cybersecurity testing evidence

After you document component exposure, the next step is proving the controls work on the shipped build. That proof comes from testing. In plain English: your risk file may say a control exists, but testing evidence shows it actually works on the released version. The required record set includes test plans, execution records, and remediation status.

Test plans, methods, and scope

A test plan needs to spell out the claims being tested, the firmware and software version under review, the test environment setup, and the interfaces, data paths, and components in scope. A solid plan links each test to a specific risk or requirement. It should also be repeatable, version-controlled, and tied to the device’s deployment model and known threat model. FDA expects evidence from fuzzing, robustness testing, abuse and misuse cases, vulnerability scanning, SCA, SAST/DAST, and penetration testing.^{[6][34][35][36]}

It also helps to be exact about what was not tested. List every excluded interface, describe the test environment, and note whether the data was real, synthetic, or masked. Record tool names, versions, and configuration settings too. That matters because an unauthenticated vulnerability scan can produce very different results from an authenticated one. The reason for choosing each method - and how deep the testing went - should connect back to the threat model.

Once the scope and methods are set, the report needs to show what the tests actually found.

Results, unresolved findings, and control mapping

The results package should track passed, failed, and open findings. Each finding needs a unique ID, affected component, severity, reproduction steps, and status. Formal reports usually also include the test objective, methodology, pass/fail criteria, observed results, and supporting logs or screenshots when needed. Penetration test reports sent to the FDA should include tester independence and expertise, test scope, duration, methods, tools, and full findings - not just an executive summary.^[6][33][34]

Each test case should map back to the security requirement, risk control, or mitigation it verifies. That lets reviewers check that every cyber control was tested, every failure was tracked, and every open issue has a named owner. For example, if a requirement says software updates must be protected with cryptographic validation, the evidence should show signature verification, rejection of tampered packages, and logging of failed update attempts.^[35][37] IEC 81001-5-1 requires each security mitigation to be tested in three ways: confirm it works as designed, try to defeat it, and check that it did not create new vulnerabilities elsewhere in the design.^[37][38]

The table below sums up the main test types, what they validate, and the records regulators expect to see:

Open findings need a named owner, target fix version, and retest result. Accepted findings need documented rationale, compensating controls, risk-owner approval, and a review date. In practice, only non-exploitable, low-severity findings with documented rationale should be accepted. Retest evidence should show that the fix closed the vulnerability without creating a new one, especially for issues such as insecure update paths, exposed debug interfaces, or authentication bypass.^[6][33][34] These results also feed into labeling and postmarket vulnerability handling.

Labeling, disclosure, and postmarket vulnerability handling

Testing shows what you built and what you checked. Once the device is in the field, a new group of documents matters most: the ones that tell hospitals how to use it safely, and the ones that show regulators how you'll deal with issues after release.

Cybersecurity labeling and secure use instructions

This next document set tells operators how to deploy, harden, and maintain the verified build. Cybersecurity labeling isn't just a user manual. It's part of the risk record. It gives IT administrators, biomedical engineers, and clinical staff the instructions they need to use and maintain the device securely in the approved use environment described in the risk management report.

The labeling package should include a cybersecurity administrator guide, a secure deployment checklist, patch and update procedures, and a known constraints and residual risks summary. Each document should have version control and should be referenced directly in the risk management report and the Instructions for Use (IFU). It also helps to add a Cybersecurity Labeling Index that maps each document to its audience and where it sits in the technical file.

The administrator guide should cover a few core areas:

• Network placement: State the approved network placement and any required network controls.
• Ports and interfaces: List which ports to enable, disable, or monitor, including direction and purpose.
• Initial hardening: Cover changes to default credentials, encryption, time synchronization, and connection to hospital identity systems such as Active Directory or SSO.
• Update procedures: Explain how to install, verify, and roll back updates.
• Logging: List logged events, log format, export method, and SIEM integration. Tie logged events back to the device's threat model so security operations teams know which alerts matter.

The known constraints section should use plain language. If the device can't support MFA, say that plainly. Then point to a compensating control, such as network segmentation or strict physical access. Residual risks should connect to specific steps hospitals can take. They shouldn't sit there as vague warnings.

Coordinated vulnerability disclosure and monitoring plan

After release, the focus shifts from secure use to vulnerability intake and response. FDA requires cyber device submissions to include a plan to monitor, identify, and address postmarket vulnerabilities, including a coordinated vulnerability disclosure (CVD) policy and practice.^[20][45]

A complete CVD program needs a published disclosure policy that references ISO/IEC 29147 and ISO/IEC 30111, a dedicated reporting contact such as a security@ email alias, a web form, or a security.txt file, an acknowledgment SLA of 48 hours or less, and safe-harbor language for good-faith research.^[40][43][44] On the inside, the vulnerability intake and triage procedure should spell out how reports are logged, how severity is classified using CVSS and clinical impact, and when issues get escalated if patient safety or PHI is at risk.^[42]

The postmarket monitoring plan should name the sources the security team watches, such as NVD, vendor advisories, threat intelligence feeds, and security research publications. It should also say how often reviews happen, like weekly CVE scans against the device SBOM.^[39][41] Just as important, it should state who owns triage, remediation decisions, and customer notification through security bulletins or portal updates. That keeps the risk file current after release by linking each new CVE back to the SBOM and vulnerability records already documented in the submission.

For major vulnerabilities, publish formal security advisories that include the CVE identifier, affected device versions, severity rating, recommended interim mitigations, and a patch installation guide with clinical workflow details such as downtime scheduling. Those advisories should link back to the risk management file so the risk can be checked again after remediation.^[45]

To make this work in practice, assign each postmarket task to a named owner in a RACI chart. That chart should define vendor responsibilities such as monitoring, triage, patch delivery, and advisory publication; HDO responsibilities such as local risk assessment, change management, and patch deployment; biomedical engineering tasks such as device inventory and downtime coordination; and clinical leadership responsibilities such as awareness of patient safety implications.

Conclusion: A checklist for complete, review-ready documentation

A review-ready submission is judged on one simple idea: do the risk, architecture, SBOM, test, and postmarket records line up as a single package?

Start with version consistency. The most common problem is a mismatch between records, like a current risk report paired with an outdated SBOM, or test evidence linked to an earlier build. ^[6][1][7]

Then check traceability across the evidence chain. Follow one threat from the model to the mitigation, then to the test, the result, and the residual-risk or labeling statement. If that chain breaks at any point, reviewers will zero in on it. ^[6][47][5]

Last, make sure postmarket controls match the premarket record. Postmarket materials need to reflect the same controls and commitments described in the risk report and labeling. ^[2][48][46]

That’s the standard reviewers expect: one current, traceable, review-ready documentation set.

FAQs

Which cybersecurity document should I build first?

First, confirm whether your product is a cyber device under Section 524B of the FD&C Act. The FDA reads this definition broadly for connected medical devices, so this step decides which documents you’ll need.

Once you know the scope, look at your device’s risk level, start threat modeling before design freeze, and draft your Cybersecurity Management Plan. That plan lays out the scoring, thresholds, and governance that guide the rest of your documentation.

How do I prove my SBOM matches the shipped device?

Integrate automated SBOM generation into your CI/CD pipeline so it’s produced with every build and release. That way, the SBOM matches the software state of the device that actually ships.

Treat the SBOM as a living document linked to your QMS and design controls. This creates traceability between components, risk analyses, and verification evidence, which helps keep the documented inventory in sync with the device’s actual configuration.

What usually causes FDA cybersecurity reviews to stall?

FDA cybersecurity reviews often slow down for a simple reason: the paperwork doesn’t hold together.

A team may have done solid security work, but if the documentation is incomplete, missing, or hard to trace from one artifact to another, review time can stretch out. The same thing happens when the threat model is thin, the SBOM is inaccurate or not machine-readable, or cybersecurity findings aren’t tied back to clinical patient safety impact.

Another common problem is timing. When security documents are written at the end, almost like a box-checking exercise, reviewers can usually tell. FDA expects cybersecurity to be part of the quality system, not something patched in later.

Testing evidence can also become a sticking point. If the record leans only on automated scans, that usually isn’t enough. Reviewers want to see risk-based verification that matches the device, its use, and the harm that could follow if something goes wrong.

Related Blog Posts

• Cybersecurity Testing for 510(k) Submissions: Guide
• FDA Cybersecurity Design Controls: Key Requirements
• Checklist for Pre-Market Medical Device Cybersecurity
• Premarket Cybersecurity: Lessons from Recent Submissions