Understanding the FDA Secure Product Development Framework (SPDF): Requirements and 2026 Implementation Guide

A threat model, SBOM, penetration test, and cybersecurity plan can all be part of an FDA submission. None of them, by themselves, is an SPDF.

That distinction matters because the Secure Product Development Framework (SPDF) is much broader. It brings cybersecurity into the processes used to design, develop, release, maintain, and eventually retire a medical device, so security is managed as part of the product lifecycle rather than assembled only for regulatory review.

FDA reinforced this approach in its February 2026 cybersecurity guidance, which replaced the June 27, 2025 version.

In this guide, we explain what FDA expects from an SPDF, how it connects with development and cybersecurity activities, and what medical device manufacturers need to address when implementing it in 2026.

Key Takeaways

• A strong SPDF is built into everyday product decisions instead of being assembled when the submission is nearly complete.
• The framework works best when security ownership, risk analysis, engineering controls, testing, and follow-up remain connected across teams.
• FDA gives manufacturers flexibility in how they organize SPDF activities, but the approach still needs to fit the device’s actual risk and quality processes.
• Evidence matters as much as design intent. Manufacturers need to show how identified risks were addressed and how implemented controls were checked.
• Cybersecurity responsibility continues after launch. New vulnerabilities, aging components, software updates, and eventual product retirement all need ongoing attention.

What Is the FDA Secure Product Development Framework (SPDF)? 

FDA describes a Secure Product Development Framework (SPDF) as a set of processes for identifying and reducing the number and severity of vulnerabilities in a product. It covers the entire lifecycle:

• Design
• Development
• Release
• Support
• Decommissioning

The framework brings structure to how cybersecurity is handled across these stages. Manufacturers define responsibilities, carry out security activities, document the results, and keep that information updated as the device changes.

SPDF is broader than security testing performed before an FDA submission. FDA allows manufacturers to incorporate these activities into existing product development, software development, risk management, and quality processes.

How the FDA SPDF Fits QMSR in 2026 

FDA’s Quality Management System Regulation became effective on February 2, 2026. The revised 21 CFR Part 820 incorporates ISO 13485:2016, bringing FDA device quality requirements closer to the international quality management standard.

FDA updated its cybersecurity guidance the following day to reflect this regulatory change. Under the 2026 guidance, an FDA SPDF does not need a separate cybersecurity quality system. Cybersecurity work can be built into processes manufacturers already use for:

• Design and development planning
• Design inputs and outputs
• Design reviews
• Verification and validation
• Risk management
• Design changes
• Supplier controls
• Document control
• Complaint handling
• CAPA
• Servicing and postmarket activities

The point is to handle security work with the same control applied elsewhere in product development. Decisions are planned, recorded, reviewed, tested, and kept current as the device changes.

FDA specifically states that SPDF processes can be integrated with product development, software development, risk management, and the wider quality management system.

Five Cybersecurity Objectives FDA Expects Device Designs to Address 

1. Authenticity and Integrity

A medical device should be able to tell whether the software or information it receives is genuine and whether anything has been changed without approval. That applies to firmware, software, configuration settings, commands, and clinical information.

Manufacturers can address this through measures such as signed firmware, integrity checks, and trusted communication between connected systems. If the device cannot verify the source or integrity of an update, it should not accept or run it.

2. Authorization

Access to a medical device does not automatically mean access to every function inside it. FDA expects manufacturers to control what different users, services, devices, and processes can view, change, or operate.

Permissions should reflect the task involved. Clinical users, administrators, service personnel, and connected systems can each have different levels of access. As recommended in FDA cybersecurity documentation, roles, privileges, access controls, and service interfaces should help keep higher-risk functions limited to the people or systems that actually need them.

3. Availability

A medical device can lose connectivity or face a system failure without becoming unsafe. FDA expects the design to account for those situations and preserve the functions needed for safe operation.

That includes planning for:

• Resource exhaustion
• Communication loss
• Denial of service conditions
• Partial system failure

The device should continue operating safely where possible and avoid letting one failed or compromised component disrupt critical functions across the wider system.

4. Confidentiality

Confidentiality comes into play anywhere sensitive information can be seen, stored, or shared. For medical device software security, that means looking beyond patient data alone. Credentials, security records, configuration details, and other protected information also need appropriate safeguards.

Manufacturers should account for where this information appears, including:

• Device storage
• Data moving between systems
• System and security logs
• Cloud services
• Device and service interfaces

The controls chosen should limit unauthorized access or disclosure without interfering with the device’s intended clinical use.

5. Secure and Timely Updatability and Patchability

A device needs a safe way to receive security fixes before a serious vulnerability appears in the field. FDA recommends planning that capability during design, including enough storage and processing capacity to support future software and firmware updates.

The update process should account for:

• Authentication and authorization before an update is accepted
• Integrity checks to confirm the update has not been altered
• Version control so the device receives the intended release
• Recovery when an update fails
• Safe handling of interrupted updates or communication loss
• Rollback where the device design and risk assessment support it

FDA also recommends a secure process for delivering validated patches and planning for rapid testing and distribution once a vulnerability needs to be addressed.

Preparing for an FDA 510(k) Submission?

Generate FDA-compliant SBOMs, VEX documentation, and cybersecurity assessments with expert support.

Speak with Our FDA Compliance Team →

Core Processes That Make Up an FDA-Aligned SPDF 

1. Cybersecurity Planning 

Cybersecurity responsibilities need to be clear while the device architecture is still taking shape. Teams should know who owns security reviews, required evidence, supplier security work, testing, vulnerability response, patching, and postmarket follow-up. Approval points also need to be built into development so unresolved issues are caught before the product moves forward.

These responsibilities are also part of a secure software development lifecycle (SSDLC), where security work runs alongside software development instead of being left until final testing. A penetration testing team can find weaknesses before submission, but it cannot replace the planning and ownership needed throughout the product lifecycle.

2. Threat Modeling and Cybersecurity Risk Assessment

Threat modeling shows how an attacker could reach or affect the device. It should cover the full system, including components, interfaces, data flows, trust boundaries, attack paths, weaknesses, controls, and key assumptions. Manufacturing, servicing, updates, supply chain dependencies, and decommissioning also matter when they introduce security exposure.

Cybersecurity risk assessment then looks at what those scenarios could cause. The focus is on exploitability, security impact, possible effects on safety or clinical performance, required controls, and residual risk.

FDA does not treat cybersecurity risk as a simple extension of traditional safety probability calculations. The two processes connect when exploitation can change device behavior or create patient harm.

3. Security Requirements and Architecture

Once a risk is identified, it needs to lead to a clear design requirement. That could mean authenticated updates, encrypted communication, tighter access control, restricted service interfaces, integrity checks, or security logging.

The architecture should then show where those controls sit and how they work across the medical device system. Useful views can include external interfaces, trust boundaries, communication protocols, authentication paths, key management, update mechanisms, logging, and connections to third-party systems.

FDA also expects cybersecurity information to remain traceable. A practical chain looks like this:

Threat → Requirement → Control → Implementation → Verification

This makes it easier to show why a control exists and how its effectiveness was tested.

4. SBOM, Third Party Software, and Supply Chain Security

Most medical devices rely on third-party software such as operating systems, open source packages, SDKs, libraries, firmware, cloud services, or cryptographic components.

An SBOM helps track those dependencies, but it is not the Secure Product Development Framework (SPDF) itself. Manufacturers still need processes for supplier review, component approval, vulnerability monitoring, support status checks, and replacement of unsupported software.

The workflow is straightforward:

Component selected → inventoried → monitored → vulnerability identified → exploitability assessed → product risk evaluated → remediation decision → records updated

Unsupported components can create future risk simply because fixes may no longer be available.

For cyber devices, Section 524B also requires an SBOM covering commercial, open source, and off-the-shelf software components.

5. Secure Implementation

Once security requirements are approved, they have to show up in the product itself. Depending on the device, that can involve secure coding, input validation, secrets management, dependency controls, privilege separation, secure defaults, cryptography, code signing, secure boot, protected debug interfaces, and controlled build processes.

The choice of controls should come from the actual architecture and threat model. FDA recommends applying security controls across the medical device system using risk-based decisions rather than treating every product the same.

6. Cybersecurity Verification, Vulnerability Testing, and Penetration Testing

Security testing is not one activity. FDA’s current guidance refers to methods such as misuse testing, malformed inputs, fuzzing, attack surface analysis, vulnerability chaining, known vulnerability scanning, software composition analysis, static and dynamic code analysis, and penetration testing.

• Verification Testing: Verification checks whether the security requirements defined for the product were implemented correctly and whether the related controls work as intended.
• Vulnerability Testing: Vulnerability testing looks for weaknesses using methods suited to the device and its software environment. A scan can find known issues, but a clean result does not show that realistic attack paths are safe.
• Penetration Testing: Penetration testing attempts to exploit credible attack paths and shows what impact an attacker could actually achieve. It does not replace requirement verification.

Qualysec’s independent medical device penetration testing can support this part of the SPDF by validating exploitable paths and documenting remediation findings. It is still only one part of the wider framework.

7. Postmarket Vulnerability Management and Coordinated Disclosure

After release, the SPDF shifts toward watching for new security issues and responding when they affect the device. That includes threat intelligence, vulnerability intake, exploitability assessment, coordinated disclosure, incident response, customer communication, and updates to the risk record.

For cyber devices, Section 524B requires a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits. Coordinated vulnerability disclosure also forms part of that postmarket process. 

The postmarket cycle can be summarized as:

New vulnerability → assess → remediate → verify → deploy → monitor → update risk records

8. End-of-Life and Secure Decommissioning

Decommissioning is part of the SPDF lifecycle, so security planning should continue through product retirement. FDA guidance also calls for manufacturers to document known or anticipated end-of-support and end-of-life information for devices and their components.

Before support ends, manufacturers should decide:

• How stored patient and device data will be handled
• Whether user and service credentials need to be removed
• Whether certificates or other cryptographic credentials need to be revoked
• Whether retired devices can still connect to cloud or production systems
• How customers will be informed that security support is ending

These decisions also support broader FDA Product Security Requirements by keeping cybersecurity responsibilities clear after active support ends. Devices that remain in clinical use without patches or maintained services can continue to carry security risk long after retirement.

How the SPDF Works in Practice: Connected Infusion Pump Example

Consider a fictional infusion pump that connects to the hospital network, a cloud service, a web or mobile application, a maintenance laptop, and an update server. 

Under an FDA SPDF, security work would follow the product from architecture through postmarket monitoring rather than happen as isolated tasks. FDA’s February 2026 guidance supports this lifecycle approach and recommends threat modeling across the full medical device system.

1. Architecture mapping: The team maps components, interfaces, data flows, communication paths, and trust boundaries.
2. Threat identification: The model considers realistic scenarios such as stolen service credentials, replayed commands, compromised cloud APIs, malicious updates, vulnerable third-party libraries, and unauthorized maintenance access.
3. Security requirements: Those threats are turned into controls such as authenticated commands, signed update packages, restricted maintenance privileges, and encrypted sensitive communications.
4. Implementation and verification: Engineers build the controls, then test authentication, update integrity, interface behavior, failure conditions, and relevant attack paths.
5. Release and monitoring: Software components remain tracked after release so newly reported vulnerabilities can be checked against the deployed configuration.
6. Postmarket response: When a new issue appears, the team determines whether the released device is affected, applies remediation where needed, verifies the fix, and updates the risk records.

One assumption deserves particular attention: the hospital network cannot be treated as automatically trusted. If the threat model shows that compromised surrounding infrastructure could reach the device, the design needs controls that account for that possibility.

How Cybersecurity Traceability Connects the SPDF 

Traceability keeps the SPDF from turning into a folder of separate cybersecurity files. Manufacturers should be able to follow an issue from the original threat through the requirement, control, verification evidence, and final risk decision.

A simple chain is:

Threat → Requirement → Design Control → Verification → Residual Risk

That connection should remain visible across the threat model, cybersecurity risk assessment, architecture, requirements, SBOM, test evidence, vulnerability records, and residual risk documentation.

These are illustrative examples, not controls that fit every device. The value of traceability is that a change in one artifact can be traced to the related evidence that needs review or retesting.

Standards and Frameworks That Can Support an FDA SPDF

FDA does not provide a separate SPDF certification. Manufacturers can use recognized standards and industry frameworks to support specific parts of the process, but they still need to address the risks and design of the actual device.

FDA recognizes IEC 81001-5-1 Edition 1.0 2021-12 under recognition number 13-122. FDA also recognizes ANSI/AAMI SW96:2023 and AAMI TIR57:2016 for medical-device security risk management.

Using one standard does not automatically show that every device-specific cybersecurity risk has been addressed. Manufacturers still need to connect the standards they use to the device architecture, identified risks, development process, QMS, and submission evidence. Conformity with IEC 81001-5-1 should not be presented as automatic FDA SPDF compliance.

How Qualysec Can Support Medical Device SPDF Cybersecurity Testing

For Qualysec, the focus is not simply finding vulnerabilities. The testing looks at how those weaknesses could be reached, combined, and used across a connected medical device environment.

Qualysec can assess APIs, mobile and web applications, cloud services, networks, IoT components, device interfaces, and other exposed parts of the ecosystem. Manual testing is combined with automated techniques so the assessment goes beyond surface-level scanning.

The final report gives your team clear evidence to work with, including severity-rated findings, reproduction details, remediation guidance, and an executive summary. Once fixes are complete, retesting can confirm whether the issues were properly addressed.

Conclusion

The real test of an SPDF is not how polished the submission looks. It is whether the product can absorb change without turning every new vulnerability into a crisis.

FDA gives manufacturers room to shape the framework around their own development and quality processes, but that flexibility only works when security decisions stay connected over time.

A mature Secure Product Development Framework (SPDF) gives teams a clearer path when the device changes, new risks appear, or reviewers ask how a decision was made. The earlier that structure becomes part of development, the less likely a late security issue is to expose a gap that should have been caught months before.

Medical device manufacturers preparing verification evidence before release or submission can work with Qualysec for a focused penetration testing assessment. Contact the team for a consultation or project quote.

Speak Directly With Qualysec’s Certified Security Experts

Discover vulnerabilities before attackers exploit them

Schedule Free Consultation
→

FAQs

1. Is the FDA Secure Product Development Framework mandatory?

Not as a prescribed framework. FDA encourages manufacturers to use an SPDF because it can support QMSR compliance, while acknowledging that other approaches can also work. Separate statutory duties under Section 524B apply to qualifying cyber devices.

2. What is the difference between SPDF and SSDLC?

An SSDLC concentrates mainly on building security into software development. The FDA SPDF reaches further across the medical device lifecycle, bringing in system architecture, risk management, hardware where relevant, suppliers, updates, postmarket support, and eventual decommissioning.

3. Does every medical device need the same SPDF activities?

No. FDA says cybersecurity design and documentation should scale with the device’s actual cybersecurity risk. Architecture, connectivity, use environment, exploitability, and possible patient harm all influence how much security work and supporting evidence are appropriate.

4. Does FDA expect penetration testing as part of medical device cybersecurity testing?

FDA includes penetration testing among the cybersecurity testing methods manufacturers should consider and recommends submitting penetration test reports. It complements threat modeling, vulnerability analysis, risk assessment, and requirement verification rather than replacing those other activities.

5. How does Section 524B relate to the SPDF?

Section 524B sets legal cybersecurity requirements for qualifying cyber devices, including postmarket vulnerability planning, cybersecure development and maintenance processes, updates and patches, and an SBOM. SPDF recommendations can help organize the work supporting those obligations.