Understanding the FDA Secure Product Development Framework (SPDF)

The Secure Product Development Framework is the FDA telling manufacturers it no longer wants security features. It wants a security process. The agency introduced the SPDF in its 2023 premarket cybersecurity guidance and kept it central in the 2025 guidance. It isn't a document you write or a checklist you complete. It's a set of practices that run across the whole product lifecycle, from concept through postmarket maintenance.

The five practice areas

The FDA describes the SPDF as covering:

• Risk management integration: cybersecurity risks evaluated with the same rigor as patient safety risks
• 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
• Maintenance and updates: vulnerability monitoring, patching, and coordinated disclosure
• Documentation: traceable evidence of how security was built in and how risk is managed over time

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

That's 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.

I've watched submissions stall on exactly this point. The testing was competent, but it was framed as an event. Reviewers came back asking about process: who monitors, who decides, where the decision trail lives. The SPDF is that question formalized.

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 of security risk. Different regulators arriving at one conclusion: security is a development discipline, not a feature.

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

Running the SPDF instead of writing it

Teams rarely struggle to agree with the framework. They struggle to produce its evidence continuously without doubling their engineering load. That's the problem we built ELTON around.

ELTON maintains a living record linking vulnerabilities, exploitability, mitigations, and risk assessments across development and postmarket phases. That's lifecycle traceability in the FDA's sense of the term, produced as a byproduct of doing the work rather than as a writing project at the end.

Testing runs continuously for the same reason. Penetration testing, SBOM analysis, and SAST and DAST keep feeding the record after the submission ships. And instead of carrying generic CVSS ratings, each finding gets architecture-adjusted exploitability analysis. That's what makes a remediation decision, or a no-fix decision, defensible in front of a reviewer.

Because the SPDF shares its skeleton with IEC 81001-5-1 and its international siblings, one body of evidence supports submissions in multiple markets. The premarket outputs are FDA-aligned, and the postmarket obligations draw on the same data instead of duplicating the work.

Build security in, don't bolt it on. Every manufacturer nods at the phrase. The SPDF is the FDA operationalizing the nod: if security really was built in, you can show the trace. If it was bolted on, no document written in the last month before submission will hide it.