What a Secure Product Development Framework is, and what FDA expects to see

How-to guide · MedDevice Startups Staff · Updated Sep 6, 2026 · 6 min read

The SPDF is FDA telling manufacturers it no longer wants security features. It wants a security process, with evidence a reviewer can trace from concept to decommission.

FDA introduced the Secure Product Development Framework in its 2023 premarket cybersecurity guidance and kept it central through the 2025 and 2026 revisions. The guidance defines it plainly: "An SPDF is a set of processes that help identify and reduce the number and severity of vulnerabilities in products. An SPDF encompasses all aspects of a product's lifecycle, including design, development, release, support, and decommission."

It is not a document you write or a checklist you complete. It is a way of running the product. FDA says using an SPDF "is one approach to help ensure that the QMSR is met," encourages it, and allows other approaches that satisfy the QMSR.

What the guidance puts inside it

Section V of the guidance is the SPDF in practice. It has three parts, and the submission documentation follows the same shape.

Security risk management. Threat modeling, a cybersecurity risk assessment based on exploitability, interoperability risks, third-party components and the SBOM, a security assessment of unresolved anomalies, and lifecycle risk management with tracked metrics. FDA points to AAMI TIR57 and ANSI/AAMI SW96 for the plan and report.
Security architecture. Controls from eight categories built in rather than bolted on, documented through architecture views that show the system, its trust boundaries and how updates reach the device.
Cybersecurity testing. Security requirements testing, threat mitigation testing, vulnerability testing and penetration testing, submitted as reports, then repeated after release at intervals commensurate with risk.

Five practice areas, one useful way to think about it

One useful way to break the SPDF down is into five practice areas, a frame that helps a small team decide who owns what:

Risk management integration. Cybersecurity risks evaluated with the same rigor as patient safety risks, and fed into the safety risk file.
Secure design. Threat modeling, secure coding and architecture-level risk reduction.
Testing and verification. Penetration testing, fuzzing and code review inside the standard development process, not a gate at the end.
Maintenance and updates. Vulnerability monitoring, patching and coordinated disclosure for the life of the device.
Documentation. Traceable evidence of how security was built in and how risk is managed over time.

Notice where vulnerability work sits. Testing is not a gate you pass on the way to submission, and vulnerability management is not an appendix for the postmarket team. They are two of the five pillars. The framework assumes vulnerabilities will keep appearing for the life of the device and judges you on whether the machinery for handling them exists.

That is the real shift. A pentest report proves you looked once. The SPDF asks what happens the day after the report, and the year after that, and it wants the answer documented with evidence a reviewer can trace. Submissions stall on exactly this point. The testing was competent, but it was framed as an event, and the reviewer came back asking about process: who monitors, who decides, where the decision trail lives.

Frameworks FDA names

You do not have to invent an SPDF. The guidance lists frameworks that can satisfy the QMSR and align with its recommendations: the Medical Device and Health IT Joint Security Plan (JSP2), IEC 81001-5-1, and ANSI/ISA 62443-4-1 from the industrial control world. For design inputs it also points at the OWASP security by design principles, the Hippocratic Oath for Connected Medical Devices, and the Building Code for Medical Device Software Security.

The same idea, worldwide

If the structure sounds familiar, it should. IEC 81001-5-1 embeds cybersecurity activities in the product lifecycle the same way, and Japan adopted it as JIS T 81001-5-1 for networked medical devices. EU MDR and IVDR guidance expects a quality management system with cybersecurity integrated into it. Health Canada takes the same lifecycle view. Different regulators arrived at one conclusion: security is a development discipline, not a feature.

For a company selling into three or four of those markets, the convergence is the good news. You do not need four security programs. You need one process that produces evidence rigorous enough for the strictest reviewer you face.

Questions & Answers

What is the FDA's Secure Product Development Framework?

A set of processes that identify and reduce the number and severity of vulnerabilities across the whole product lifecycle, from design through decommission. FDA introduced it in 2023 and kept it central in the 2025 and 2026 revisions. It is the agency asking for a security process rather than security features.

Is an SPDF required?

The guidance says using an SPDF is one approach to satisfying the QMSR and encourages it, while allowing other approaches. For cyber devices, the underlying obligation to design, develop and maintain processes that give reasonable assurance of cybersecurity is statutory under Section 524B(b)(2).

Which existing frameworks count?

FDA names JSP2, IEC 81001-5-1 and ANSI/ISA 62443-4-1 as frameworks that can satisfy the QMSR and align with the SPDF recommendations.

Why do submissions stall on the SPDF?

Because testing was framed as an event. A pentest report proves you looked once. Reviewers come back asking about process: who monitors, who decides, and where the decision trail lives.

← All how-to guides