SPDF vs SSDLC: What Medtech Teams Get

Part of our medtech cybersecurity framework choice series (SPDF, JSP2, IEC 81001-5-1). For the full overview, start with JSP2 vs SPDF vs IEC 81001-5-1: Framework Pick.

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 encourages a Secure Product Development Framework (SPDF). Section 524B separately establishes cybersecurity obligations for applicable cyber-device submissions; it does not mandate a framework by name.

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.

Why This Matters

The FDA's Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions final guidance (February 3, 2026) encourages an SPDF and describes supporting cybersecurity evidence. Its Section IV.A states that other approaches might also satisfy the QMSR. Section 524B, effective March 29, 2023, separately requires specified cybersecurity information and processes for applicable cyber-device submissions.

Reviewers assess the submitted cybersecurity evidence: security risk management, threat modeling and architecture views, SBOM and component vulnerability assessment, testing, and postmarket plans. AAMI SW96 is a useful risk-management reference; VEX can communicate vulnerability status but is optional. Existing lifecycle records can support this evidence when their scope and traceability are adequate.

Practical review targets include safety-related risk traceability, postmarket plans, component vulnerability assessments, and device-specific threat models. These are checks against the guidance, not a ranking from a published FDA deficiency-frequency dataset.

Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); NIST SP 800-218, Secure Software Development Framework; FDA, Content of Premarket Submissions for Device Software Functions; NIST Cybersecurity Framework.

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.

A general SSDLC does not automatically establish device-specific safety risk connections or regulatory evidence. It can include maintenance and coordinated vulnerability disclosure: NIST SSDF practice RV.1 addresses ongoing vulnerability identification and disclosure. Check the implemented process rather than assuming those activities are absent.

What SPDF adds on top of SSDLC

The following five areas help assess whether existing secure development practices support the device and its submission. They are not an exhaustive list of statutory obligations.

1. ISO 14971 patient-harm traceability

Assess whether each security risk could affect safety or effectiveness. A spoofed sensor reading may contribute to a wrong-therapy scenario, depending on the architecture and clinical use. Connect safety-related risks to the ISO 14971 analysis; do not invent patient harm for risks limited to other security impacts.

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 implementations can include maintenance and response; coverage depends on the framework and its implementation.

4. SBOM and component vulnerability assessment

Section 524B requires an SBOM for applicable cyber-device submissions. The guidance recommends machine-readable documentation; SPDX and CycloneDX are common options, not the only legally permitted formats. An evidence-backed VEX document can communicate component vulnerability status, but is not required by name. Dependency scanning supports, but does not replace, device-specific assessment.

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. Section 524B(b)(1) requires a plan that includes coordinated vulnerability disclosure and related procedures for applicable submissions. General secure development frameworks can also address disclosure; confirm device-specific coverage.

Side-by-side: SPDF vs SSDLC

Talk to a MedTech cybersecurity expert about your SPDF gap analysis

Moving from a general SSDLC to the SPDF?

Blue Goat Cyber is a medical-device-only cybersecurity firm. Our team runs the threat modeling, penetration testing, and FDA-facing documentation MedTech submissions live or die on. → Secure MedTech product design consulting

Where SSDLC teams most often fall short

See also: What Is MedTech? MedTech vs Medical Device vs Life Sciences, 8 FDA Cybersecurity Documentation Gaps to Review, and CVSS Score for Medical Devices: How to Calculate and Use It.

Check these four potential gaps against the actual device evidence and the guidance:

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 without a device-specific vulnerability assessment. Explain whether identified vulnerabilities affect the device and what evidence supports that conclusion. VEX is one optional communication format. 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. Provide a usable vulnerability-reporting route. A security.txt file or dedicated page can help discovery; neither is universally required by name.

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 an accurate SBOM and assess identified component vulnerabilities; use VEX where it helps communicate evidence-backed status.
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 evidence gaps and dependencies. Blue Goat track record: 275+ FDA submissions supported, zero cybersecurity rejections.

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 a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed.

Related reading: Total Product Lifecycle Security: A 2026 Playbook for MedTech Leaders.

Frequently Asked Questions

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

SSDLC describes practices that build security into software development and can include maintenance and response. The FDA encourages an SPDF covering the product lifecycle, including support and decommissioning. Medical-device work must connect security risks to safety where relevant and provide appropriate submission evidence and postmarket processes. An existing SSDLC may support that work; its name alone does not establish coverage.

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

It can provide a foundation, but adequacy depends on its actual scope, implementation, and evidence. Map existing records to the device risks, applicable requirements, and guidance recommendations. There is no authoritative 60/40 split or universal completion percentage.

Is SPDF required by law or only by FDA guidance?

Section 524B establishes binding cybersecurity obligations for applicable cyber-device submissions, but does not mandate SPDF by name. The February 3, 2026 guidance contains nonbinding recommendations and encourages an SPDF. It expressly permits alternative approaches that satisfy applicable statutes and regulations.

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

Yes, as long as you map it to SPDF artifacts. Reviewers assess device-specific cybersecurity evidence, not a vendor framework label. Map the process to applicable requirements and guidance recommendations, including risk management, architecture, testing, SBOM and vulnerability assessment, and postmarket plans. VEX is optional, and SW96 is a useful reference rather than a universal legal mandate. Use whatever upstream framework you prefer; produce the SPDF artifacts on top.

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

The timeline depends on existing procedures, evidence quality, device architecture, and remediation needs. Assess those gaps before committing to a schedule; neither the FDA guidance nor Section 524B establishes a universal implementation duration.

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

The guidance addresses devices with cybersecurity considerations, including relevant SaMD. Section 524B applies when the device meets all three cyber-device criteria: sponsor-authorized software, ability to connect to the internet, and sponsor-authorized technological characteristics vulnerable to cybersecurity threats. Determine applicability and evidence scope for the actual product.

CTA

Run an SPDF gap assessment against your existing SSDLC before the next submission window. We scope a gap report and remediation backlog around your existing process and device. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. Book a discovery session.

Christian Espinosa, Founder, Blue Goat Cyber. Christian has red-team and DoD cyberwarfare experience. Blue Goat track record: 275+ FDA submissions supported, zero cybersecurity rejections. More on the author.

Related SPDF reading

• Pillar guide: Medical Device Cybersecurity SPDF Playbook
• CI/CD Security Gates for Medical Devices: SPDF in Practice
• SPDF Cybersecurity Documentation: What FDA Reviewers Expect
• SPDF and IEC 62304 Mapping for Medical Device Cybersecurity
• SPDF vs TPLC in Medical Device Cybersecurity

---

More on this topic

• GET vs POST: When to Use Each HTTP Method