How to Meet FDA Cybersecurity Requirements

If your device uses software and can connect in any way, FDA cybersecurity review now starts before clearance or approval. Since Section 524B took effect, missing items like an SBOM, a risk management plan, or security test records can lead to an intake rejection.

Here’s the short version: I need to show FDA that the device is in scope, map how it connects and moves data, document built-in security controls, prepare a machine-readable SBOM, and back all of it with testing and postmarket plans. That matters because reported data shows 53% of medical devices in surveyed care settings had at least one critical vulnerability.

If I wanted a simple checklist from this article, it would be this:

• Confirm scope: software, firmware, ports, wireless, cloud links, update paths
• Map the device: architecture, connections, trust boundaries, data flows
• Build the file: risk plan, CVD process, secure design records, labeling
• Prepare the SBOM: include third-party, open-source, and off-the-shelf parts
• Prove it works: scanning, analysis, requirements testing, and pen testing when needed
• Tie premarket to postmarket: monitoring, patches, disclosure, and SBOM upkeep

In other words: this is no longer just an IT issue. For many device makers, it is now a direct FDA submission issue tied to safety, effectiveness, and whether the file is accepted for review.

Intro to Medical Device Cybersecurity (Premarket and Postmarket, FDA and EU)

sbb-itb-535baee

Step 1: Confirm Whether Your Device Is in Scope

Start by checking whether FDA premarket cybersecurity rules apply to your device.

Identify Devices and Software Functions That Require Cybersecurity Review

If a device includes software, firmware, programmable logic, or a device software function, it may fall in scope - even if it doesn't look “connected” at first glance.^[4][6] A standalone diagnostic device with embedded firmware can still count.

Under Section 524B, a product is a cyber device if it includes software, can connect directly or indirectly to the internet, and has traits that could leave it open to cyber threats.^[9] FDA takes a broad view of connectivity. That includes Wi-Fi, Bluetooth, BLE, cellular, Ethernet, USB, serial, and inductive communications.^[9]

This is where teams often miss things. Devices with dormant wireless modules, debug ports, service connectors, and cloud-linked update paths can still be in scope. The same goes for update channels and remote servicing features.^[9][10]

Once you've confirmed scope, the next move is simple: write down how the device handles data and where it connects.

Define Intended Use, Connectivity, and Data Flows

Map out how the device works in actual use - who uses it, where it's used, and what the workflow looks like. That gives you a clear picture of the threat surface and the controls FDA will expect to see in the submission.^[9][10]

Create three artifacts early:

• A device architecture summary
• A connectivity inventory
• A data-flow diagram^[10][8]

Then sort data flows into groups such as PHI, device command and control signals, and telemetry or logging data. Mark the trust boundaries wherever data moves into hospital, cloud, or mobile environments.^[10]

You'll use these artifacts again when building the risk management and testing evidence in Step 2 and Step 3.

Step 2: Build the Required Cybersecurity Documentation

Once you’ve mapped scope and data flows, turn that work into cybersecurity documentation you can actually submit.

Create a Cybersecurity Risk Management Plan Tied to Postmarket Action

FDA expects this plan to span the full device lifecycle, including how you monitor, evaluate, and remediate vulnerabilities.^{[4][9][6][16]}

That means spelling out how your team watches advisories and vulnerability feeds, how issues are triaged based on severity and patient impact, what remediation timelines apply, and when a matter gets escalated to engineering, quality, regulatory, or executive leadership.

This plan also needs to connect cybersecurity work to the rest of your quality system. Tie issues to CAPA, design review, change control, verification, and regression testing. SBOM updates should be version-controlled alongside software releases.^[1][6][5][3]

You should also publish a CVD policy that includes safe-harbor language, a dedicated intake channel, acknowledgment timelines, a severity method, and a process for issuing advisories once mitigations are ready.^{[4][15][17][19]} Put the CVD contact in product labeling and on your website. Advisories should clearly list affected versions, compensating controls, and patch steps.^{[4][1][3][17]}

Once the response process is clear, the next job is to show the controls built into the device itself.

Document Secure-by-Design Controls and Labeling

Focus on design-time security controls, not fixes added after the fact. Start with threat modeling, using STRIDE or attack trees to map key assets, trust boundaries, and likely attack paths. Include the diagrams, model files, and mitigation actions in the submission.^{[1][6][3][19]}

Document controls such as:

• Strong authentication
• Role-based access
• Least privilege
• Encryption
• Secure boot
• Integrity checks
• Network segmentation support
• Protected update paths

Your security risk assessment should sum up each threat, its likelihood, its patient safety impact, the mitigation selected, and the reason any residual risk is acceptable.^{[4][1][6][18][19]} It also helps to map those controls to recognized standards such as IEC 62304, IEC 81001-5-1, or UL 2900.^{[1][6][3][19]}

Labeling should be written for the people who will actually use it: clinical users, biomedical engineers, and hospital IT teams. Include ports and protocols, network architecture, firewall rules, default credential handling, patch timelines, logging export, and backup and recovery procedures, along with expected RTO/RPO values.^{[1][6][3][18]} The labeling should also point users to your CVD contact channel and explain how they’ll be told when vulnerabilities and patches are available.^[4][15][17]

After that, you need a clear inventory of the software pieces those controls apply to.

Prepare the SBOM and Supporting Component Records

Section 524B(b)(3) requires a machine-readable SBOM that covers all commercial, open-source, and off-the-shelf components. Use CycloneDX or SPDX in JSON, XML, or tag-value format so the data works with automated vulnerability management tools.^{[4][9][6][12][13][14][16][18]}

At a minimum, each component record should include the supplier name, component name, version, unique identifiers such as PURL or CPE, dependency relationships, hashes, license information, and end-of-support dates.^{[4][12][6][13][14]} End-of-support tracking matters because FDA expects manufacturers to plan for components that reach end of support and the cybersecurity risk that comes with them.^[12][6][14]

One area trips people up all the time: what goes in the SBOM, and what belongs in supporting records. Here’s the split:

Step 3: Validate Controls and Organize Submission Evidence

Once the documentation is in place, the next job is to show the controls work and package the proof so FDA reviewers can follow it without digging.

Run Security Testing That Matches Device Risk

Test depth should match device risk. FDA expects a risk-based verification and validation program tied to intended use, connectivity, and patient safety impact.^[5][1]

For most submissions, that means covering architecture review, security requirements testing, static and dynamic analysis, vulnerability scanning, and, when it fits, penetration testing. Each test should check a control that already appears in the threat model and risk assessment.

Here’s what that looks like in practice:

• Architecture review checks trust boundaries and least-privilege enforcement.
• Requirements testing confirms controls such as encryption, access management, and logging are in place and working as specified.
• Static and dynamic analysis finds coding weaknesses and runtime defects.
• Vulnerability scanning checks known CVEs against the device's OS, libraries, and cloud components.

Penetration testing is expected for networked, wireless, or cloud-connected devices.^[4][1][24] The report should spell out scope across hardware, firmware, companion apps, cloud APIs, and hospital integration points, then map findings back to the threat model.^[21][7][24] If you can't fully remove a vulnerability without affecting therapy, document the compensating controls, monitoring, and labeling that make the residual risk acceptable.^[5][15]

For vulnerability scanning, include the tools used, the CVE databases referenced, the scope covered, and a vulnerability list with CVE IDs, severity scores, and mitigation or acceptance decisions.^[5][20] For static analysis, list the tool name and version, the rulesets used, and a summary of findings with dispositions.

Pull it all together with a security requirements traceability matrix that links each threat in the threat model to a specific requirement, design control, and test case.^[21][22][7] This two-way trace matters. A reviewer should be able to start with a control and trace it back to the risk it addresses, or start with a high-risk threat and see how it was tested and verified.^[5][1][7]

Use a Submission-Readiness Checklist Before Filing

Use the same threat model, SBOM, and control map from Step 2 to organize the test package. Before filing, run a checklist to make sure the package is complete.^{[1][22][23][24]}

Give each item a clear status, such as draft, approved, or pending review, so teams across engineering, quality, regulatory, and IT security can see what’s finished and what still needs sign-off. That connected paper trail matters because FDA reviewers use it to understand the device’s overall cybersecurity posture fast.^[1][23]

Conclusion: Connect Premarket Evidence to Long-Term Cybersecurity Maintenance

Getting through an FDA premarket submission is a big milestone. But it’s not the end of the road.

The work involved in confirming device scope, building a cybersecurity risk management plan, documenting secure-by-design controls, preparing the SBOM, and testing those controls should not sit on a shelf after submission. It should become the postmarket operating model for the device. Put simply: the same artifacts used for premarket review should guide the postmarket cybersecurity program.

Use the submission package as the starting point for postmarket monitoring and remediation. Section 524B requires manufacturers to monitor, identify, and address postmarket vulnerabilities, and to maintain device security through validated updates and patches.^[4][2] The scope, risk, control, SBOM, and test evidence built for submission should feed that process directly. The threat model helps the team decide which patches come first. The SBOM supports component-level CVE mapping. And secure update mechanisms make field patching safer and more controlled.^[4][12]

In practice, this means folding a few core activities into the Quality Management System:

• Continuous monitoring
• Patching
• Coordinated disclosure
• Validated updates

When that happens, premarket artifacts stop being paperwork and start working as a maintenance workflow.

A static SBOM is a common weak spot. If it’s treated as a one-time filing artifact instead of a living inventory, vulnerability response can slow down fast when a new CVE appears in a third-party library. With a current SBOM, the team can check whether the device is affected, review clinical risk, and decide what to do next without wasting time.

Premarket evidence starts the program. Postmarket maintenance keeps it going. Submission evidence gives FDA reviewers confidence that the device was built securely. Postmarket maintenance is what keeps it that way and supports both patient safety and long-term regulatory trust.

FAQs

Does my device count as a cyber device?

Under Section 524B of the FD&C Act, a product is a cyber device if it:

• includes software the manufacturer has validated, installed, or authorized
• connects directly or indirectly to the internet or other networks
• has features that cybersecurity threats could exploit

If it meets those points, it falls under FDA cybersecurity rules, including the need to submit a Software Bill of Materials.

What belongs in the FDA-required SBOM?

To meet FDA pre-market requirements, your Software Bill of Materials (SBOM) needs to be machine-readable and submitted in CycloneDX or SPDX format.

It also needs to include the NTIA minimum elements:

• supplier name
• component name and version
• unique identifiers
• dependency relationships
• SBOM author and creation timestamp

On top of that, the SBOM should include lifecycle metadata, such as support status and end-of-life dates. It should also cover vulnerability assessments for each component, tied to known threats and the related safety and security risk assessments.

When is penetration testing expected?

Penetration testing is expected in both the premarket and postmarket phases.

During development, it helps check whether cybersecurity controls work as intended and supports FDA submission documents. After launch, it should continue across the device lifecycle to spot new vulnerabilities and confirm that controls still work as threats change.

Related Blog Posts

• FDA Cybersecurity Design Controls: Key Requirements
• Checklist for Pre-Market Medical Device Cybersecurity
• Minimum Cybersecurity Standards for Medical Device Suppliers
• FDA IoT Cybersecurity: 2026 Updates Explained