FDA Cybersecurity Requirements for Medical Devices with Software

The most common conversation I have with a first-time submitter starts the same way: "Our device isn't connected to anything. The FDA cybersecurity stuff doesn't apply to us, right?"

It does. FDA's 2023 premarket cybersecurity guidance applies to any medical device that contains software, connected or not. A standalone analyzer with a USB port, a wearable that only pairs with a phone, even a device whose only "network" is a service-mode interface a tech plugs into once a year — they all need a cybersecurity package. The 2025 update tightened that further.

So if you have software, here is what reviewers expect to see in your submission, and roughly when in development each piece should get built.

The cybersecurity artifacts FDA expects

There are 13 cybersecurity documents that show up across an eSTAR submission for a software-containing device. Different reviewers organize them differently, but the set is stable. The table below is the map I give clients during the first scoping call.

Artifact	When you build it	Where it lives in the submission	Common reviewer pushback
Security Architecture Views	Architecture phase	Cybersecurity section, alongside threat model	Missing trust boundaries; views don't match the system architecture in the software DHF
Threat Model	Architecture phase	Cybersecurity risk management	Threats not tied to specific assets or data flows; no rationale for what was scoped out
Cybersecurity Risk Assessment	Architecture phase, updated through V&V	Cybersecurity risk management	Probability-based scoring instead of exploitability; no acceptance criteria
Cybersecurity Controls	Architecture phase	Cybersecurity controls section	Controls listed without traceability back to threats they mitigate
Cybersecurity Management Plan	Architecture phase	Cybersecurity section	Plan is a template with no specifics about this device
Safety & Security Assessment of Vulnerabilities	Through V&V	Cybersecurity risk management	No mechanism to escalate cyber risks with safety impact into ISO 14971
Software Bill of Materials (SBOM)	Implementation phase, maintained post-market	Software documentation + cybersecurity section	Missing transitive dependencies; no machine-readable format
Assessment of Unresolved Anomalies (cyber-relevant)	After V&V	Software documentation + cybersecurity section	Cyber implications of open anomalies not analyzed
Cybersecurity Testing Report	After V&V	Cybersecurity testing	Penetration test scope unclear; no traceability to controls being tested
Software Level of Support	Implementation phase	Software documentation	Support windows for third-party components not stated
Cybersecurity Metrics	After V&V	Cybersecurity section	Metrics defined but no baseline or threshold
Security Risk Management Report	Final, before submission	Cybersecurity section	Report doesn't roll up the assessments above into a single summary
Cybersecurity Labeling	Final	Labeling	Missing or vague guidance for the user on secure configuration

If you can produce every row of that table and a reviewer can trace each one back to a specific threat and a specific control, you're in good shape. Most deficiency letters I've seen on cybersecurity trace back to a missing or weak entry in one or two specific rows.

How CyberMed splits the work into two phases

The 13 artifacts don't all get built at the same time. Trying to write a Cybersecurity Testing Report before the threat model is locked is wasted effort — the test scope will change. So we split engagements into two phases that mirror development.

Phase 1 — Security architecture

This is where the foundation gets set. The decisions you make here determine whether the rest of the submission is defensible or a scramble.

• System architecture and security views. Identify every component, interface, data flow, and trust boundary. The security views are not a separate diagram — they're the system architecture with the security-relevant elements called out. Components, network surfaces, authentication points, data at rest, data in transit.
• Threat modeling. Map attack surfaces. Identify threat actors and what they could plausibly want. Document attack scenarios against the trust boundaries from the security views. The output is a list of threats traceable back to specific elements of the architecture.
• Risk evaluation. Score each threat. This is where the 2023 and 2025 FDA guidance diverges most sharply from ISO 14971 thinking — cybersecurity risk is scored on exploitability, not probability. I cover this in detail in the risk assessment guide.
• Controls selection. For every threat above the acceptance threshold, select controls that mitigate it. Controls can be technical (signed firmware, mutual TLS) or administrative (a documented patch cadence). Document the rationale for each control selection.
• Security management plan. Roles, responsibilities, processes, and incident response. Avoid the template trap — reviewers can tell when this is generic versus when it reflects how your team actually operates.

Phase 2 — Design, development, and verification

With the architecture locked, this phase is about building, testing, and producing evidence.

• Implementation. Develop the software using the secure coding practices implied by your selected controls. Track which controls are implemented where so you can produce the trace later.
• SBOM generation and analysis. Generate the SBOM (CycloneDX or SPDX, machine-readable). Cross-reference every component against known vulnerability databases. Document anomalies with their cyber implications.
• Cybersecurity testing. Vulnerability scanning, fuzz testing on input interfaces, penetration testing on accessible surfaces. The Cybersecurity Testing Report should trace back to specific controls being verified, not be a generic vulnerability scan output.
• Residual risk. Risks that remain after controls are implemented need to be documented and accepted with rationale. "Acceptable because we ran a pen test" is not rationale. "Acceptable because the residual risk score is below our defined threshold of X and the control was verified by Y" is.

Post-market is not optional

A common misconception is that the cybersecurity work ends at clearance. It doesn't. FDA expects an ongoing program:

• Monitor for new vulnerabilities affecting your SBOM components.
• Patch on a documented cadence. The Cybersecurity Management Plan should specify what that cadence is and how patches are validated before deployment.
• Track and report incidents per the post-market guidance.
• Update the SBOM and the safety and security assessment when components or controls change materially.

If your business model can't sustain post-market cybersecurity work, that's a sign the product isn't ready to be on the market yet. Reviewers know this — the Cybersecurity Management Plan is where they look for it.

At CyberMed we've seen

The single most common pattern I've seen at submission time is a complete cybersecurity package that fails traceability. The threat model exists, the controls exist, the test report exists — but a reviewer can't draw a line from a threat in the model to a control in the controls list to a test case in the report. That's the cybersecurity equivalent of failing a design-controls audit: not a missing document, but a broken chain.

The fix is mechanical but tedious: every threat gets a unique ID; every control references the threats it mitigates; every test case references the controls it verifies. Build the traceability matrix early and update it as the architecture changes. Submitting without it is the fastest way to invite an Additional Information request.

[NEEDS: specific anonymized example of an AI request Jose has worked through, if appropriate to publish]

Where to go next

If you're scoping a submission, the fastest way to gauge where you stand is the FDA 524B Cybersecurity Readiness Assessment — 14 questions, takes about 3 minutes, gives you a tier and a gap report.

If you already know you need help building the package, the 30-day CyberSprint covers all 13 artifacts on a fixed timeline. For a deeper look at the risk-assessment piece specifically, read the 12 essential FDA cybersecurity risk assessment rules.

This post is a framework, not legal or regulatory advice. The specific cybersecurity expectations for your device depend on its risk class, intended use, connectivity, and the FDA pathway you're pursuing. Talk to a regulatory professional who knows your product.