The SPDF Playbook: Secure Product Development Framework

A practical, ungated guide to building a Secure Product Development Framework that the FDA accepts. The eight pillars, the artifacts each one produces, and a pre-submission readiness checklist you can score yourself against this week.

275+ submissions · Zero rejections · 8 SPDF pillars · +8-12w average AI letter delay

Why the SPDF is Now the Center of FDA Cybersecurity Review

Section 524B of the FD&C Act gives FDA the explicit authority to refuse any premarket submission for a cyber device that doesn’t meet cybersecurity requirements. FDA’s February 2026 premarket cybersecurity guidance, AAMI SW96, and IEC 81001-5-1 all converge on the same expectation: a documented, repeatable Secure Product Development Framework integrated with your QMS.

After 275+ FDA submissions, we see the same pattern: teams that pass review do not have eight separate security documents. They have one SPDF, with eight pillars feeding consistent artifacts into the design history file. This playbook is how we build it. If you want senior help setting it up, see our medical device cybersecurity consulting service.

How to Use This Playbook

1. Read each pillar as a self-assessment: do you have the artifact, and is it at the depth FDA expects?
2. Use the checklist at the end to score your submission readiness across all 15 go/no-go criteria.
3. Where you find a gap, the artifact list is concrete enough to start work on Monday.

The Eight Pillars of an FDA-Ready SPDF

FDA · 21 U.S.C. 360n-2 · SPDF

The eight pillars of an FDA-ready SPDF

Each pillar produces a discrete artifact the reviewer opens inside the eSTAR cybersecurity section.

1. 01

   Security risk management

   SRM plan · SRM report

   ANSI/AAMI SW96:2023

2. 02

   Threat modeling

   STRIDE / attack-tree model

   Feeds SRM and SBOM

3. 03

   SBOM

   CycloneDX or SPDX

   §524B(b)(3) mandatory

4. 04

   Security architecture

   Global · multi-patient · updateability views

   IEC 81001-5-1

5. 05

   Penetration testing

   Independent, scoped report

   Objective evidence

6. 06

   Vulnerability management

   CVD policy · CVE triage

   ISO/IEC 29147 · 30111

7. 07

   Postmarket monitoring

   Plan · KPIs · patch cadence

   §524B(b)(2)

8. 08

   Labeling and transparency

   MDS2 · user documentation

   HSCC MDS2 v3

Output

eSTAR cybersecurity section

Traceable requirement → evidence → residual risk.

Each pillar includes a definition, why FDA cares, and the concrete artifacts you need to build a defensible submission package.

SPDF Governance & QMS Integration

What it is. A written Secure Product Development Framework policy that lives inside your ISO 13485 QMS and references IEC 62304 software lifecycle activities. It defines roles, escalation paths, and the security gates that block a release.

Why FDA cares. FDA’s February 2026 premarket cybersecurity guidance and Section 524B treat the SPDF as a process artifact, not a single document. Reviewers look for evidence that security decisions are made by accountable owners and traced through your QMS like every other design control.

Artifacts you need.

• SPDF policy document mapped to QMS procedures
• RACI matrix covering security architect, QA, regulatory, and engineering
• Definition of Done for each design phase including security exit criteria

Security Requirements & Design Inputs

What it is. Cybersecurity requirements derived from intended use, risk, and applicable standards ( FDA 524B, AAMI SW96, IEC 81001-5-1, IEC 62443-4-2). Each requirement is testable and traced to a design output.

Why FDA cares. Without explicit security requirements, there is nothing to verify against. Reviewers commonly flag submissions where security controls appear in implementation but never in requirements, breaking traceability.

Artifacts you need.

• Security requirements specification with unique IDs and rationale
• Traceability from each requirement to threats, controls, tests, and design outputs
• Mapping to applicable standards and regulatory clauses

Threat Modeling & Architecture Views

What it is. Data flow diagrams with trust boundaries, a STRIDE or PASTA threat enumeration, and the four architecture views FDA expects: global system, multi-patient harm, updateability, and security use case views.

Why FDA cares. FDA’s February 2026 guidance is specific about the views required. Submissions with a single block diagram and a generic STRIDE table are routinely held with deficiencies tied to threat model depth and architecture clarity.

Artifacts you need.

• Data flow diagrams covering every interface, trust boundary, and external entity
• Threat register linking each threat to a control, test, or accepted residual risk
• All four architecture views, kept consistent with the threat model

Stuck on threat modeling, architecture views, or risk integration? A 30-minute call with a senior expert can save weeks of rework. Talk to an SPDF expert →

Security Risk Management Integrated with ISO 14971

What it is. A Security Risk Assessment that translates exploitability into probability of harm and lives inside the same risk file as your ISO 14971 hazard analysis, not in a parallel spreadsheet.

Why FDA cares. Section 524B and the premarket guidance are explicit: cybersecurity risk must be evaluated through patient safety. A standalone security risk register without 14971 linkage is one of the most common deficiency triggers.

Artifacts you need.

• Security Risk Assessment with exploitability-to-harm mapping
• Bidirectional traceability between security risks and 14971 hazards
• Residual risk evaluation reflected consistently in both files

Is Your SPDF Ready for FDA Review?

Our experts have guided 275+ FDA submissions without a single cybersecurity rejection. Let us review your SPDF gaps before you submit.

Book a Free 30-Minute Strategy Session →

Secure Implementation, SBOM & SOUP

What it is. Secure coding standards, code review with security checklists, dependency hygiene, and a CycloneDX or SPDX Software Bill of Materials regenerated on every build with a documented lifecycle plan.

Why FDA cares. FDA expects a machine-readable SBOM that supports continuous vulnerability monitoring, plus evidence that third-party and SOUP components are evaluated, not just inventoried.

Artifacts you need.

• Secure coding standard tied to language and toolchain in use
• CycloneDX or SPDX SBOM with transitive dependencies, suppliers, versions, and licenses
• SOUP analysis with vulnerability assessment and rationale for use

Verification: Static Analysis, Fuzzing & Penetration Testing

What it is. A layered test program: SAST and SCA in CI, protocol fuzzing on critical interfaces, and end-to-end penetration testing across every interface (wired, wireless, BLE, cellular, USB, cloud, service ports).

Why FDA cares. Reviewers expect testing scoped to the threat model and performed with medical-device context. Pure automated scans, web-only pen tests, and reports from generalist firms without medical experience are routinely flagged.

Artifacts you need.

• SAST/SCA configuration and results integrated into the design history file
• Penetration test report scoped across all interfaces, written for FDA audience
• Fuzz testing results on protocols handling untrusted input

Want a second set of eyes on your SPDF before you submit? We do a fixed-fee gap analysis in days. Talk to an SPDF expert →

Cybersecurity Labeling & Coordinated Vulnerability Disclosure

What it is. User-facing cybersecurity transparency: a labeling section covering supported configurations, network requirements, end-of-support dates, SBOM access, and a published Coordinated Vulnerability Disclosure (CVD) program with intake and SLAs.

Why FDA cares. Cybersecurity labeling and CVD are explicit submission elements. Reviewers verify that customers, IT departments, and security researchers have what they need to operate the device and report issues.

Artifacts you need.

• Cybersecurity section in IFU/labeling with hardening guidance and EOS dates
• Published CVD policy referencing ISO/IEC 29147 and 30111
• Internal triage workflow with risk-based response SLAs

Post-Market Monitoring, Patching & TPLC

What it is. A Total Product Lifecycle (TPLC) plan that operationalizes the SBOM: continuous monitoring of vulnerabilities via NVD and CISA KEV, risk-based patch timelines, validated update mechanisms, and customer communication.

Why FDA cares. FDA evaluates premarket and post-market cybersecurity together. A strong premarket package with no credible monitoring or patch plan does not stand on its own.

Artifacts you need.

• Vulnerability monitoring sources and triage workflow tied to the SBOM
• Validated update mechanism: signature, integrity, atomic install, rollback
• Customer communication and patch deployment plan with SLAs

Pre-Submission SPDF Readiness Checklist

If you cannot check all fifteen, you have known gaps that FDA is likely to flag.

1. Written SPDF policy integrated with the QMS and IEC 62304 lifecycle
2. Security requirements specification with traceability to threats, controls, and tests
3. Threat model with data flow diagrams and STRIDE/PASTA analysis
4. All four FDA architecture views (global, multi-patient harm, updateability, security use case)
5. Security Risk Assessment integrated with the ISO 14971 risk file
6. CycloneDX or SPDX SBOM with transitive dependencies and lifecycle plan
7. SOUP analysis with vulnerability assessment for each component
8. SAST/SCA in CI with results in the design history file
9. Penetration test covering all interfaces, performed with medical-device context
10. Fuzz testing on protocols handling untrusted input
11. Cybersecurity labeling with hardening guidance, EOS dates, and SBOM access
12. Coordinated Vulnerability Disclosure policy with published intake and SLAs
13. Validated update mechanism with signature, integrity, and rollback testing
14. Post-market monitoring plan with risk-based patch timelines
15. Section 524B documentation set: Risk Management Report, Management Plan, Labeling, Traceability

SPDF Effort, Calibrated

For a moderate-complexity Class II connected device, this is what a complete SPDF build typically looks like when the work is done right the first time. Several pillars run in parallel.

⚠ Timeline Reality: Most teams need 10-14 weeks of focused work for a first SPDF. Rework after an FDA AI letter typically adds 8-12 weeks to clearance.

When to Bring In a Specialist Partner

You don’t need outside help for every submission. You probably do if any of these are true:

• First 510(k), De Novo, or PMA, This is your team’s first submission with cybersecurity in scope.

• AI Letter or RTA Refusal, You’ve received a deficiency response citing cybersecurity or SPDF gaps.

• Limited Bandwidth, Your engineering team owns security alongside firmware and has limited bandwidth.

• Fixed Launch Date, Your launch date is fixed and a cyber deficiency would slip revenue.

• Defensible Threat Model Needed, You need a defensible threat model and pen test from a firm FDA already recognizes.

How Blue Goat Cyber approaches SPDF work

Every FDA package we ship starts with an SPDF gap assessment against the eight pillars above. We do not sell a framework deck. We deliver the artifacts the reviewer opens: the threat model, the security risk assessment, the SBOM, the design and architecture views, the pen test report, the CVD and patch policies, the postmarket monitoring plan, and the labeling section. Each artifact traces to a specific requirement in Section 524B and the February 3, 2026 final premarket cybersecurity guidance.

Our senior team (CISSP, OSCP, and former military red-teamers) authors the package with your engineering and regulatory leads, then defends it through submission. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Track record: 275+ submissions cleared, zero cybersecurity-driven rejections.

For teams already mid-submission, we run a two-week pressure-test on your existing SPDF and hand back a prioritized fix list before you send.

Frequently asked questions

What is the SPDF and does the FDA require it?

The Secure Product Development Framework (SPDF) is the process the FDA's February 3, 2026 final premarket cybersecurity guidance expects manufacturers to follow across a device's lifecycle. Section 524B(b)(2) requires a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits, and the SPDF is how you demonstrate that plan is real. Reviewers look for SPDF evidence embedded in your QMS, not a standalone document.

Do the eight SPDF pillars map to a specific standard?

Yes. The pillars align with AAMI TIR57, ANSI/AAMI SW96:2023, IEC 81001-5-1, and the process expectations in ISO 14971 and IEC 62304. The February 2026 guidance references these standards as the operational interpretation of Section 524B. When we build an SPDF package we map each pillar to the specific clause of the standard so the reviewer can trace requirement, evidence, and residual risk in one path.

How long does it take to stand up an SPDF from scratch?

Ten to fourteen weeks is typical for a first-time submitter, assuming your engineering team is available for interviews and can pull architecture and dependency data. Teams responding to an RTA or AI letter can compress that to six to eight weeks by focusing on the specific pillars the FDA cited. Rebuilding after a rejection almost always takes longer than doing it right the first time.

Can we reuse SPDF artifacts across multiple 510(k) submissions?

Yes, if they were built to be modular. The threat model, SBOM tooling, CVD policy, and postmarket monitoring plan are typically reusable across a product family. Device-specific artifacts (architecture views, pen test report, security risk assessment) have to be regenerated per submission. Teams that structure the SPDF as a shared QMS asset save weeks per subsequent clearance.

What is the difference between SPDF and SSDLC?

SSDLC is a general software security lifecycle used across industries. The SPDF is the medical-device-specific expression of that lifecycle, extended to cover premarket submission evidence, postmarket vulnerability management, and coordinated disclosure. Every SPDF is an SSDLC, but not every SSDLC meets FDA expectations. The 2026 guidance requires SPDF-specific artifacts that a generic SSDLC will not produce.

What happens if the FDA cites SPDF gaps in a deficiency letter?

You get a hold on your submission until you respond. The most common response requires (a) revised SPDF documentation showing the pillar the reviewer cited is now covered, (b) evidence that the process is embedded in your QMS, not a one-off, and (c) an updated postmarket monitoring plan that closes the loop. Ignoring the deficiency or responding without process evidence usually triggers a second deficiency letter.

Want a Senior Expert to Pressure-Test Your SPDF?

Book a free 30-minute strategy session. No sales rep, no obligation. We’ll review where you are, flag the SPDF gaps FDA is most likely to hit, and give you a fixed-fee quote within 24 hours.

275+ submissions · Zero rejections · 8 SPDF pillars

Related SPDF reading

• 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 SSDLC: What Medtech Teams Get Wrong
• SPDF vs TPLC in Medical Device Cybersecurity

Free tools for this

• SPDF Gap Checker - find the gaps between your development process and the SPDF the FDA expects.