FDA's 2023 cybersecurity premarket guidance: what changed for SaMD teams

In September 2023, FDA finalized the guidance Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions. The previous guidance, from 2014, treated cybersecurity as a recommendation. The new guidance treats it as a documented submission requirement — and the documentation requirements are substantial.

Since the final guidance dropped, we've shipped four SaMD submissions under it. Here's what actually changed, what teams consistently underestimate, and the structure of the cybersecurity portion of the submission package as it looks now.

What actually changed

The biggest change isn't any single requirement. It's that the cybersecurity submission is now an explicit, expected part of the package — with prescribed structure. Pre-2023, you could submit a Class II device with minimal cybersecurity documentation and most reviewers would let it through. Post-2023, that submission gets a deficiency letter.

The four substantive new requirements:

• Software Bill of Materials (SBOM) — required.
• Threat model — required, with explicit consideration of cyber threats.
• Vulnerability response plan — required, with defined update mechanism.
• Secure update mechanism documentation — required.

Each one is meaningful work. None of them are checkbox items.

The SBOM requirement

An SBOM is a machine-readable inventory of every software component in your device. FDA accepts both SPDX and CycloneDX formats.

Sounds simple. Isn't. Three places teams trip up:

First: SBOM has to cover everything, not just your code. Third-party libraries, operating system components, firmware blobs, hardware drivers. If a device runs on Linux, your SBOM has Linux kernel components in it. If you use a library that wraps OpenSSL, OpenSSL is in your SBOM.

Second: SBOM is dynamic. Every time you change a dependency, the SBOM changes. FDA expects the SBOM in the submission to reflect the actual shipping version — which means SBOM generation needs to be part of your release process, not a one-time deliverable.

Third: SBOM has to be analyzable. You can't just hand over a JSON file. You're expected to have analyzed it for known vulnerabilities (CVE matching) and to document the analysis.

The threat model requirement

FDA wants a documented threat model that considers cyber threats specifically — not just safety hazards. They expect you to enumerate threats, model attack paths, and document mitigations.

We typically structure threat models around STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) per system component. For each threat, the document captures: likelihood, impact, current mitigation, residual risk.

What FDA actually evaluates: whether the threat model is comprehensive (did you consider the obvious threats?) and whether the mitigations are real (is there code or documentation for each mitigation, or is the mitigation aspirational?).

Common deficiency: a threat model that lists threats but doesn't trace mitigations back to specific software components or design controls. The traceability is what convinces a reviewer the threat model is operational and not aspirational.

The vulnerability response plan

Once your device is in the field, what happens when a vulnerability is discovered? FDA wants the plan documented.

Specifically, they want:

• How vulnerabilities are received (a documented intake — security@yourcompany.com works, but "call us" doesn't).
• Severity assessment process and timelines.
• Coordination with downstream operators (hospitals, clinics, distributors).
• Patch development and validation process.
• Patch deployment mechanism (this connects to the secure update mechanism, see below).
• Communication plan — to operators, to FDA, to patients if applicable.

The plan doesn't have to be elaborate. It has to be real, written, and verifiable. "We'll figure it out when a vuln drops" is a deficiency.

The secure update mechanism

FDA wants to see how a patch reaches your device, in production, after submission. They expect:

• Cryptographic signature on every update package.
• Validation that the device verifies the signature before applying the update.
• Authenticated channel for update delivery (not just HTTPS — usually mutual TLS with a customer-managed PKI).
• Documented rollback mechanism if an update fails.
• Documented evidence that the update mechanism itself doesn't introduce a new attack vector.

This is the hardest section for software-only SaMD teams that haven't shipped firmware before. The expectation that the device itself does signature verification is sometimes new to teams whose mental model of "updates" is push-a-new-build-to-the-app-store.

What got harder

Three things take meaningfully more work now:

First: SBOM generation as part of CI. Most teams discover during the submission that they need to integrate SBOM generation (e.g., via Syft, CycloneDX-cli, or similar tools) into their build process. If this isn't already done, expect 2-3 weeks of work to set up and validate.

Second: vulnerability monitoring against the SBOM. You can't just generate it and submit it. You need a process for continuously monitoring CVE feeds against your SBOM and triaging matches. We use OSV (Open Source Vulnerabilities) feeds plus custom logic for the device-specific components.

Third: secure update documentation. Software-only teams without firmware experience often need help here. Expect 3-6 weeks of effort to design, document, and validate a secure update flow.

What got easier

One thing actually got easier: FDA now publishes much clearer expectations. Pre-2023, you'd submit cybersecurity content, get a deficiency letter, and have to guess what was expected. Post-2023, the guidance enumerates the expected sections, and review feedback is much more specific. We've found review cycles on cybersecurity content to be shorter under the new guidance than under the old one — once you know the structure.

What most teams miss

The single most common deficiency we see: vulnerability response plan that doesn't address how the patch reaches the device. Teams write a great intake-and-triage section, then trail off when it comes to deployment.

Second most common: SBOM that lists components but doesn't include version pinning. "OpenSSL" isn't a component — "OpenSSL 3.1.4" is. The version is the entire point of the SBOM.

Third most common: threat model written in isolation from the actual codebase. The threat model needs to reference specific software components and design controls. If it reads like a checklist disconnected from your code, reviewers notice.

The submission package structure we use

After four submissions under the new guidance, we structure the cybersecurity section consistently:

• Section 1: Threat model (STRIDE-based, traceable to design controls)
• Section 2: SBOM (CycloneDX format, version-pinned)
• Section 3: Vulnerability assessment against SBOM (CVE matching results, triage decisions)
• Section 4: Vulnerability response plan (intake, triage, patch, communicate)
• Section 5: Secure update mechanism (signature verification, authenticated delivery, rollback)
• Section 6: Security testing summary (penetration test results, fuzzing where applicable)
• Section 7: Operator security documentation (what hospitals need to know to deploy securely)

Each section averages 4-8 pages. The full cybersecurity package on a typical Class II submission runs 30-60 pages. Plan for 6-10 weeks of dedicated work to produce it the first time. Subsequent submissions are faster — most of the structure carries forward.

Closing

The 2023 final guidance moved cybersecurity from optional to integrated. The work is real — but it's also better-defined than it used to be. Teams that engineer cybersecurity into the SDLC from project start produce these submissions in stride. Teams that try to retrofit at submission time discover that the SBOM, threat model, and vulnerability response plan all reflect engineering practices that take months to operationalize.

If you're starting a SaMD project today, build cybersecurity in from day one. Generate the SBOM in CI. Draft the threat model alongside the architecture. Stand up security@yourcompany.com before you ship. The submission becomes a documentation exercise, not a panic.