FDA Cybersecurity Guidance: What Software Teams Need to Know

If I build software for a U.S. medical device, FDA cybersecurity rules now affect design, testing, submission, and patching after release.

Here’s the short version: since March 29, 2023, many “cyber devices” must include three things in premarket submissions: an SBOM, a postmarket cybersecurity plan, and proof that security is built into the development process. If those pieces are missing, FDA can refuse to accept the submission.

What I take from this article is simple:

• Cybersecurity is now part of product and regulatory work, not just IT
• Traceability is the main job: threats must link to requirements, controls, tests, and labeling
• The SBOM must be usable, not just attached as a file
• Postmarket handling must be defined before launch, including intake, triage, fixes, and disclosure
• Patient safety is part of the risk story: ransomware has been linked to 34%–38% higher in-hospital mortality for admitted patients during an attack, and 67% of healthcare groups reported ransomware in 2024

In other words: I can’t treat FDA cybersecurity guidance as a last-minute document task. I need a workflow that produces records as the product moves from requirements to release and then through support.

What matters most is connected evidence. The article keeps coming back to the same point: if my threat model, SBOM, testing, risk file, and labeling do not line up, review gets harder and launch can slip.

A few takeaways stand out:

• Threat models should map back to design inputs
• Security tests should support release decisions, not sit outside the main process
• Labeling should state setup limits, network assumptions, update needs, and residual risk
• Vulnerability procedures should name owners and escalation rules before shipment

My bottom line: this is a workflow problem as much as a compliance problem. Teams that connect engineering, quality, regulatory, and security work are in much better shape than teams stitching files together at the end.

Case Study: Why FDA Cybersecurity Expectations Are Really QMS Expectations

sbb-itb-535baee

What the FDA Expects in Premarket Cybersecurity Submissions

FDA reviewers want cybersecurity built into the quality system and risk management process, with traceable evidence in the DHF and risk files. In plain English: they want to see that security wasn't bolted on at the last minute. It needs to show up throughout development, and that trail tends to appear in three main submission artifacts.

The 3 core submission elements teams should plan for

For cyber devices, FDA expects three recurring elements in a premarket submission package: a postmarket cybersecurity plan, documented secure product development and maintenance processes, and a software bill of materials (SBOM).^{[1][5][7][3][6][8]}

The postmarket plan should spell out how the team will monitor threat intelligence, triage vulnerabilities, assess patient-safety impact, decide patch timing, and handle coordinated disclosure roles.

The SPDF should show that security requirements, threat modeling, architecture, and verification are part of the normal development process and design controls. FDA treats this as part of design controls under 21 CFR 820.30, so it should sit inside your quality system, not off to the side as a separate exercise.

The SBOM should be machine-readable and include commercial, open-source, and off-the-shelf components, plus support status and end-of-support dates for each one. That level of detail matters. A GAO report found an average of 6.2 vulnerabilities per medical device,^[10] which helps explain why component transparency matters so much. The SBOM also needs to connect each component to known vulnerabilities and the risk controls tied to them.

How design controls, risk management, and labeling connect

FDA guidance draws a straight line from cybersecurity hazards to design inputs, risk controls, verification tests, and labeling. If your device faces a threat like unauthorized remote access or network spoofing, that threat should show up in the hazard analysis, lead to a specific security requirement, map to a design element, and link to a matching test case. Every step should be traceable.

Labeling is another area teams often shortchange. But labeling should reflect the same hazard analysis and residual-risk decisions documented in the risk file. It should state secure configuration requirements, network assumptions, update expectations, and residual cyber risk. It should also call out prohibited configurations, such as direct internet exposure.

These submission artifacts work best when the development workflow produces them as work moves forward, not in a scramble at the end.

How Software Teams Can Build an FDA-Aligned Secure Development Workflow

To satisfy FDA review, teams need a workflow that produces traceable evidence at every stage, not a last-minute scramble to assemble documents.

Map threats, controls, and evidence from requirements through release

Start with architecture-based threat modeling. The goal is simple: identify assets, entry points, trust boundaries, and critical medical device security risks. Then map threats across each data flow, including spoofing, tampering, denial of service, and elevation of privilege.

From there, build a traceability matrix that links each threat to a specific security requirement, the control put in place, and the verification result. That link matters. If the threat model flags unauthorized remote access, the matrix should show the authentication requirement, the access control, and the test evidence showing failed login attempts. This gives FDA a clean line from risk to verification.^[9][12]

Update the model after architecture changes, new CVEs, and major releases.

That same traceability also tells the team what must be tested before release. It’s not just paperwork. It shapes the release gate.

Use testing methods that support security and submission readiness

Use layered testing so security work fits into the normal development process instead of becoming a separate track.

SCA should run automatically in CI and scan open-source and third-party components against known CVEs. Static analysis (SAST) should catch insecure coding patterns, such as improper cryptography use, buffer overflows, and injection flaws, on every major commit or on a nightly basis. Teams also need defined severity thresholds that must be met before release, plus a report that supports the DHF and the submission package.^[7][12]

Fuzz testing should focus on externally exposed interfaces. Penetration testing should cover the full system: device, app, and cloud backend. It should happen at least once per major release, with documented scope, methodology, acceptance criteria, and a summary report that can be referenced directly in a premarket submission.^[8][12]

Those results should feed the vulnerability-response process defined before launch.

Set up postmarket vulnerability handling before launch

Before launch, define how vulnerabilities will be taken in, triaged, escalated, and remediated. Set intake channels, assign triage ownership, establish risk-based remediation timelines, and document escalation triggers ahead of release.

Be specific about when an issue moves beyond engineering to senior leadership or a clinical safety committee. For example, escalation may be required when a vulnerability is remotely exploitable without authentication, when there is evidence of active exploitation, or when the affected installed base is large.^[9][11]

Document those criteria in a vulnerability SOP, add a RACI, and retain issue logs.^[9][4]

What to Document for FDA Review and Internal Risk Operations

Once the workflow is in place, the next step is simple: turn those outputs into an evidence set the FDA can review. Some of that material goes into the submission package. Some of it stays inside your day-to-day risk operations. The key is making sure the two line up.

The minimum documentation set engineering and regulatory teams should assemble

For cyber devices, the FDA submission package should include:

• A security risk management plan and report that brings cybersecurity hazards into the main risk file, with likelihood and impact scoring tied to patient safety outcomes
• A threat model that covers assets, attack vectors, trust boundaries, and threat actors across the full device lifecycle, including manufacturing, deployment, maintenance, and decommissioning
• Security architecture diagrams that show data flows, trust boundaries, protocols, encryption methods, and authentication mechanisms at each interface
• A machine-readable SBOM in SPDX or CycloneDX format that lists components with version, supplier, and support status, along with vulnerability data and related risk controls in machine-readable format where possible ^[7][13]
• Security control traceability that links each identified risk to a specific control and its verification result
• Verification and validation evidence covering authentication, encryption, secure update mechanisms, fuzz testing, and penetration testing results
• Vulnerability monitoring and update procedures that explain how the team will monitor new vulnerabilities, assess impact, and ship patches or updates over the product's life ^[14][15]

Submission artifacts versus internal controls

The submission package is the part built for regulators. Internal controls are the working processes behind it - the stuff your team uses to produce, support, and keep that evidence current over time.

Here’s how each submission artifact maps to the internal control that supports it:

Where Censinet fits in ongoing healthcare cyber risk management

FDA documentation doesn’t stop at clearance. Postmarket cybersecurity is an operational job that continues across the device lifecycle.

Censinet RiskOps™ helps healthcare organizations and device manufacturers track device risk, vendor documentation, and vulnerability handling over time.

These artifacts become the basis for the 30- to 90-day checklist in the next section.

Conclusion: An FDA Cybersecurity Checklist for Software Teams

At this point, the plan is set. The workflow is mapped, the documents are defined, and the postmarket path is clear. What comes next is the part that matters most: execution.

FDA cybersecurity compliance is not a one-time task you finish before launch. It runs across the full product lifecycle. It starts with requirements, carries through development and submission, and keeps going after release. Teams that do this well treat cybersecurity the same way they treat quality: built into the product, documented, and owned by specific people.

That means a few things need to happen early. Secure development should line up with quality and risk processes. Submission artifacts should be prepared well before filing. And postmarket ownership should be assigned before launch, not after.

The most important first step is confirming whether your product meets the cyber device definition under FD&C Act Section 524B.^[2] If your device has network connectivity, software-dependent functions, update mechanisms, or external interfaces, use a simple test: could an exploit affect device function, data integrity, availability, or patient safety? If the answer is yes, cybersecurity is not optional. It is a core regulatory requirement.

Over the next 30 to 90 days, the focus should be on closing the gaps that are still open:

That 30-to-90-day window should also show whether the team can keep monitoring, updating, and fixing issues after launch. In plain terms, it’s not enough to have documents in place. The team needs to show it can keep the process running when the product is live.

Engineering, regulatory, and security should work from the same traceability records and the same review milestones. If those groups are working from different versions of the truth, things can fall apart fast.

FAQs

How do I know if my product is a cyber device?

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

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

If your product meets those criteria, it must follow FDA cybersecurity requirements. That includes providing a Software Bill of Materials and having a postmarket vulnerability management plan.

What should be in an FDA-ready SBOM?

An FDA-ready Software Bill of Materials should be machine-readable and formatted as CycloneDX or SPDX.

It also needs to include a complete inventory of software components, not just the obvious ones. That means listing:

• Proprietary code
• Open-source libraries
• Commercial off-the-shelf software
• Transitive dependencies

For each component, include the supplier, name, version, and identifiers such as PURL or CPE. You should also list dependencies, hashes, license information, author, creation timestamp, and lifecycle metadata such as support status and end-of-support dates.

What records should we create before launch?

Before launch, build and maintain a cybersecurity evidence set that lines up with FDA Section 524B.

This isn’t just paperwork. It’s the record that shows how your device was reviewed, tested, and prepared for use in the field.

That evidence set should include:

• a threat model, including risks that show up during the decommissioning phase
• a cybersecurity risk assessment, plus a clear explanation of any residual risk you decided to accept
• a security risk management plan stored in your QMS records
• a machine-readable SBOM
• security architecture evidence, traceability, testing and verification records, and postmarket documentation for disclosure, patching, updates, and SBOM maintenance

Think of it as your cybersecurity paper trail. If someone asks, “How did you assess this risk?” or “How will you handle fixes after release?” you should be able to point to clear records instead of scrambling to piece them together later.

Related Blog Posts

• FDA Cybersecurity Guidance: Key Updates for 2025
• FDA Cybersecurity Design Controls: Key Requirements
• FDA Secure Design vs. Traditional Cybersecurity Approaches
• How to Meet FDA Cybersecurity Requirements