SPDF vs SSDLC: What Medtech Teams Get Wrong

A common assumption inside medtech engineering teams is that an existing Secure SDLC ports cleanly to FDA submissions. It does not. The FDA's February 3, 2026 final premarket cybersecurity guidance names the Secure Product Development Framework (SPDF) as the expected lifecycle model, and Section 524B of the FD&C Act gives the agency authority to refuse submissions that do not meet it.

This post draws the line between the two frameworks for medtech teams currently running an SSDLC and trying to figure out the delta before their next 510(k), De Novo, or PMA submission.

Key Takeaways

• SSDLC is a software-engineering practice; SPDF is a regulatory framework built on top of it.
• SPDF requires every SSDLC activity plus four medtech-specific additions: ISO 14971 harm mapping, AAMI SW96 security risk management, postmarket monitoring, and a coordinated vulnerability disclosure process.
• The biggest gap is traceability: SSDLC traces threats to controls; SPDF traces threats to patient harm.
• A team running a mature SSDLC is roughly 60% of the way to SPDF — the missing 40% is what gets cited in deficiency letters.
• The FDA's 2026 final guidance treats SPDF as the default expectation, not one of several acceptable options.

Table of Contents

• Key Takeaways
• Why This Matters
• What SSDLC actually covers
• What SPDF adds on top of SSDLC
• Side-by-side: SPDF vs SSDLC
• Where SSDLC teams most often fall short
• How to upgrade an existing SSDLC into an SPDF
• How Blue Goat Cyber Approaches This
• Frequently Asked Questions
• CTA

Why This Matters

The FDA's Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions final guidance (February 3, 2026) is explicit that manufacturers are expected to implement an SPDF and to document it in the submission. Section 524B of the FD&C Act, in effect since March 29, 2023, makes that an enforcement matter: a cyber device submission lacking SPDF-equivalent evidence can be refused.

Reviewers do not grade your SSDLC. They grade your SPDF artifacts: the security risk file under AAMI SW96, the threat model with four architecture views, the SBOM with VEX, the postmarket cybersecurity plan, and the coordinated vulnerability disclosure (CVD) process. Each one has an SSDLC analogue and a medtech-specific extension.

The most-cited 2025–2026 cybersecurity deficiencies (per FDA's own published data on AI request rates for cyber devices) cluster around four themes: missing patient-harm traceability, incomplete postmarket plans, SBOMs without exploitability context, and threat models that read like IT threat models. All four are SPDF gaps, not SSDLC gaps — a team can have a working SSDLC and still trigger every one of them.

What SSDLC actually covers

SSDLC, as practiced across general enterprise software (Microsoft SDL, OWASP SAMM, NIST SSDF SP 800-218), covers:

• Security requirements gathering during design.
• Threat modeling, typically STRIDE.
• Secure coding standards and developer training.
• Static and dynamic application security testing (SAST/DAST).
• Code review with a security lens.
• Vulnerability remediation before release.
• Some form of dependency scanning.

What it does not require: linking each threat to a patient-harm scenario under ISO 14971, planning postmarket monitoring of vulnerabilities for the operational life of the device, or running a public coordinated vulnerability disclosure program. Those are not failures of SSDLC. They are simply outside its scope.

What SPDF adds on top of SSDLC

SPDF inherits SSDLC and adds five medtech-specific obligations. Each maps to a discrete artifact reviewers look for in the submission.

1. ISO 14971 patient-harm traceability

Every cybersecurity threat must trace to a clinical harm scenario. A spoofed sensor reading is not a CIA-triad incident; it is a wrong-therapy scenario with a severity grade under your ISO 14971 risk file. SSDLC has no concept of this.

2. AAMI TIR57 / SW96 security risk management

ANSI/AAMI SW96:2023 governs security risk management for medical-device software. It defines how the security risk file integrates with the ISO 14971 safety risk file. Reviewers expect this integration explicitly — not a parallel risk register.

3. Postmarket cybersecurity management plan

SPDF requires a documented plan for vulnerability monitoring, patch deployment, and end-of-support communication for the operational life of the device. SSDLC does not extend past release.

4. SBOM with VEX

A Software Bill of Materials in CycloneDX or SPDX format, paired with VEX (Vulnerability Exploitability eXchange) to communicate which listed CVEs actually apply to the device. SSDLC dependency scanning produces inputs to this; it is not a substitute.

5. Coordinated Vulnerability Disclosure (CVD) process

A published, externally reachable path for researchers and operators to report vulnerabilities, plus an internal triage and response process. Required under Section 524B and the 2026 guidance. SSDLC does not address this at all.

Side-by-side: SPDF vs SSDLC

See also: FDA IDE Cybersecurity Requirements: 2026 Submission Guide, MQTT Vulnerabilities in Connected Medical Devices: FDA Risks, Controls, and Deficiency Patterns, and Fuzz Harness Generation for Medical Devices: HL7, DICOM, BLE GATT, MQTT, CoAP, and Proprietary Binary Protocols.

Dimension	SSDLC	SPDF
Origin	Software engineering practice (Microsoft SDL, NIST SSDF, OWASP SAMM)	FDA premarket cybersecurity expectation (Feb 3, 2026 guidance)
Scope	Design through release	Concept through end-of-support (total product lifecycle)
Risk basis	CIA-triad impact	Patient-harm scenarios under ISO 14971
Risk management standard	None mandated	AAMI TIR57 / ANSI/AAMI SW96
Threat model output	Threat list with controls	Threat list + four architecture views + harm traceability matrix
SBOM	Optional, often dependency-scan output	Required, CycloneDX or SPDX, paired with VEX
Postmarket obligations	None	Documented monitoring plan, patch cadence, end-of-support comms
Vulnerability disclosure	Internal	Externally published CVD process
Regulatory consequence of gaps	Internal risk acceptance	Refuse-to-accept, deficiency letter, or hold

Talk to a MedTech cybersecurity expert about your SPDF gap analysis

Where SSDLC teams most often fall short

Across recent FDA cybersecurity deficiency letters our team has resolved, the same four SPDF-vs-SSDLC gaps recur:

1. Threat model without architecture views. STRIDE spreadsheets are common SSDLC output. SPDF wants global, multi-patient harm, updateability, and security use-case views. See the step-by-step threat modeling guide for the structure reviewers expect.
2. Risk register that lives separately from ISO 14971. Security and safety risks tracked in different files with no cross-reference. SW96 requires integration.
3. SBOM with no VEX. Reviewers see hundreds of "open" CVEs in third-party components with no exploitability statement. See SBOM third-party chip firmware for medical devices for the SBOM/VEX pattern.
4. No CVD process or a CVD process buried in a customer-support page. Reviewers look for a discoverable, dedicated security.txt or /security page with a real intake.

How to upgrade an existing SSDLC into an SPDF

The fastest path is additive, not a rewrite:

1. Adopt AAMI SW96 as your security risk management standard and integrate the security risk file into the existing ISO 14971 file.
2. Extend the existing threat model with the four architecture views and add a harm-traceability column linking each threat to a clinical scenario.
3. Produce a CycloneDX or SPDX SBOM from the existing dependency scanner and add a VEX feed.
4. Write a postmarket cybersecurity management plan covering monitoring sources, patch cadence, and end-of-support communication.
5. Publish a CVD policy and security contact at a stable URL.

These five steps close the typical SSDLC-to-SPDF gap without disrupting the working SSDLC underneath.

How Blue Goat Cyber Approaches This

Blue Goat Cyber runs SPDF gap assessments for medtech teams who already have an SSDLC and need to know exactly what reviewers will flag. The engagement maps your existing artifacts to the 2026 final guidance line-by-line and produces a remediation backlog ordered by deficiency-letter likelihood. Christian Espinosa, our founder, has led cybersecurity submissions on more than 250 FDA-cleared devices, including connected implantables, infusion pumps, and IVD analyzers.

For teams further along, our SPDF implementation service builds the missing artifacts directly: SW96 risk files, architecture views, SBOM/VEX pipelines, postmarket plans, and CVD process. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.

Frequently Asked Questions

What is the difference between SPDF and SSDLC for medical devices?

SSDLC is a software-engineering practice that builds security into design, coding, and testing. SPDF is the FDA's medical-device-specific lifecycle framework that includes every SSDLC activity plus ISO 14971 patient-harm traceability, AAMI SW96 security risk management, an SBOM with VEX, a postmarket cybersecurity management plan, and a coordinated vulnerability disclosure process. SSDLC ends at release; SPDF runs through end-of-support.

Does a mature SSDLC satisfy the FDA's SPDF expectation?

No. A mature SSDLC covers roughly 60% of SPDF: the design, coding, testing, and vulnerability remediation activities. The remaining 40% — patient-harm traceability, SW96 integration, postmarket plan, SBOM/VEX, and CVD — is medtech-specific and must be added explicitly. Submissions that present an SSDLC alone routinely receive cybersecurity deficiency letters.

Is SPDF required by law or only by FDA guidance?

Both. Section 524B of the FD&C Act, in effect since March 29, 2023, gives the FDA authority to refuse cyber-device submissions that lack adequate cybersecurity evidence. The February 3, 2026 final premarket cybersecurity guidance names SPDF as the expected framework. The guidance is non-binding in form but is the operational standard reviewers apply.

Can we keep using NIST SSDF or Microsoft SDL terminology in the submission?

Yes, as long as you map it to SPDF artifacts. Reviewers do not require a specific vendor framework, but they do require the SPDF outputs: security risk file under SW96, threat model with the four architecture views, SBOM with VEX, postmarket plan, and CVD process. Use whatever upstream framework you prefer; produce the SPDF artifacts on top.

How long does it take to upgrade an SSDLC into an SPDF?

For a team with a mature SSDLC and a single connected Class II device in scope, the typical timeline is 8–12 weeks of focused work. The pacing items are SW96 risk-file integration and producing the four architecture views; the SBOM/VEX pipeline and CVD policy are usually faster.

Does SPDF apply to SaMD as well as connected hardware devices?

Yes. SPDF applies to any cyber device under Section 524B, which includes Software as a Medical Device (SaMD) that contains software, the ability to connect to the internet, or any technological characteristic that could be vulnerable to a cybersecurity threat. The artifacts are the same; only the architecture views shift in shape.

CTA

Run an SPDF gap assessment against your existing SSDLC before the next submission window. We deliver a reviewer-readable gap report and a remediation backlog in two weeks. If we miss something the FDA later cites, we resolve it at no additional cost. Book a discovery session.

Christian Espinosa, Founder, Blue Goat Cyber. CISSP, CCISO, ex-military red team. Has led SPDF implementations and FDA cybersecurity submissions for more than 250 medical devices, including connected implantables, infusion pumps, IVD analyzers, and SaMD platforms. More on the author.