SPDF vs IEC 62304: Avoid Costly Documentation Mistakes

FDA's Secure Product Development Framework (SPDF) runs inside your IEC 62304 lifecycle. It doesn't replace it. The catch is documentation: FDA reviews software and cybersecurity as two separate packages, so an integrated process still has to produce two sets of deliverables. This post shows where the frameworks overlap, where they split, and how to plan the work once instead of twice.

Two frameworks, one development team

Your software team already runs IEC 62304. Planning, requirements, architecture, verification, and maintenance follow a documented lifecycle, and the FDA software reviewer knows what to expect.

Then cybersecurity arrived with its own vocabulary: threat models, SBOMs, architecture views, penetration tests. Teams ask a fair question. Is SPDF a second lifecycle, or a layer on the one we have?

It's a layer. FDA's February 2026 premarket cybersecurity guidance describes an SPDF as "a set of processes that reduces the number and severity of vulnerabilities in products throughout the device lifecycle." The same guidance says manufacturers "may use other existing frameworks that satisfy the QMSR and align with FDA's recommendations for using an SPDF," and it names the Joint Security Plan (JSP2) and IEC 81001-5-1 as examples. Our book chapter on key standards and their roles maps how these documents relate.

One nuance matters here. IEC 62304 is a software lifecycle standard. It doesn't contain security activities. IEC 81001-5-1 is the standard written to add them, and it's built to sit on top of IEC 62304. When FDA says an SPDF can live inside your existing framework, that's the shape it has in mind: IEC 62304 process plus security activities at each stage.

What an SPDF adds at each IEC 62304 stage

The February 2026 guidance organizes SPDF work into security risk management (Section V.A), security architecture (Section V.B), and cybersecurity testing (Section V.C). Each one maps to an IEC 62304 activity you already run.

Planning (IEC 62304 Clause 5.1)

Your Software Development Plan gains security content:

• Security risk management activities alongside software risk management
• Security requirements for tools, coding standards, and third-party components
• Security verification planned with software verification
• Security-relevant change control inside your existing configuration management

FDA also expects a separate Cybersecurity Management Plan (Section VI.B). This is the postmarket companion to your development plan. It covers vulnerability monitoring, coordinated vulnerability disclosure, patch timelines, and customer communication. More on that below.

Requirements (Clause 5.2)

Security requirements join the Software Requirements Specification. FDA frames them around five security objectives:

• Authenticity, which includes integrity
• Authorization
• Availability
• Confidentiality
• Secure and timely updatability and patchability

IEC 62304 hazard analysis asks what could go wrong with the software. Threat modeling asks how an attacker could make it go wrong. Both feed requirements, and both need traceability. See threat modeling for cloud-connected devices for the method.

Architecture (Clause 5.3)

Your software architecture document can carry security domains, trust boundaries, control placement, and data flows. That serves the software reviewer.

The cybersecurity reviewer wants more. Section V.B.2 asks for dedicated security architecture views: a global system view, a multi-patient harm view, an updatability and patchability view, and security use case views. They build on your software architecture but answer security questions the software package doesn't ask. Our post on the architecture security view walks through each one.

Verification and testing (Clauses 5.5 to 5.7)

Unit, integration, and system tests can verify security controls the same way they verify functional requirements. Add the security requirements to your traceability matrix and you've covered the software side.

The cybersecurity side is where FDA draws a hard line. The guidance states that "cybersecurity controls require testing beyond standard software verification and validation activities." Section V.C lists what it expects to see:

• Evidence that each security requirement was implemented
• Threat mitigation testing against each architecture view
• Vulnerability testing: abuse and misuse cases, fuzz testing, attack surface analysis, vulnerability chaining, known-vulnerability scanning, software composition analysis of binaries, and static and dynamic code analysis
• Penetration testing, with a report that states tester independence and expertise, scope, duration, methods, and results

If you're planning the test campaign, start with how to conduct medical device penetration testing and what FDA looks for in the report.

Maintenance (Clause 6)

Your problem resolution and change control processes extend to security: triage vulnerabilities as anomalies, assess security impact on every change, and manage patches through configuration control. The secure software update process is the IEC 62304 maintenance loop with security acceptance criteria added.

Two documentation packages

This is the part teams miss. The process is integrated. The submission isn't.

The software package

FDA's June 2023 guidance, Content of Premarket Submissions for Device Software Functions, lists ten documentation elements:

1. Documentation Level Evaluation
2. Software Description
3. Risk Management File
4. Software Requirements Specification
5. System and Software Architecture Design
6. Software Design Specification (Enhanced level only)
7. Software Development, Configuration Management, and Maintenance Practices
8. Software Testing as part of Verification and Validation
9. Software Version History
10. Unresolved Software Anomalies

Basic level submissions provide nine of them. Enhanced adds the Software Design Specification plus complete configuration management and maintenance plans and unit and integration test protocols. For element 7, FDA accepts a Declaration of Conformity to IEC 62304 in place of the summaries. See how IEC 62304 maps to the eSTAR for the clause-by-clause view.

The cybersecurity package

Appendix 4 of the February 2026 cybersecurity guidance lists six documentation types broken into fourteen elements:

• Cybersecurity Risk Management Report, which contains the threat model, cybersecurity risk assessment, SBOM, vulnerability assessment and software support, unresolved anomalies assessment, and traceability
• Measures and Metrics for the SPDF processes
• Architecture Views, with the security requirements and the four view types
• Testing
• Labeling
• Cybersecurity Management Plans

FDA says the breadth of this documentation "will naturally scale with the level of cybersecurity risk," and that scaling shows up most in the threat model and the architecture views. A device with a single USB port needs one of each view. A networked device with cloud connectivity and a commercial operating system needs several. The FDA cybersecurity requirements post covers each element in more depth.

Where one activity feeds both packages

The efficient path is to plan security activities once and write them up twice:

Activity	Software package	Cybersecurity package
Risk analysis	Risk Management File (ISO 14971)	Cybersecurity Risk Assessment and threat model
Architecture design	System and Software Architecture Design	Architecture Views
Requirements	SRS, including security requirements	Security requirements with traceability to controls
Testing	V&V summary and protocols	Security requirements, threat mitigation, vulnerability, and penetration test evidence
Anomalies	Unresolved Software Anomalies	Unresolved Anomalies Assessment with CWE review
Maintenance	Configuration management and maintenance practices	Cybersecurity Management Plan

Each row is one body of work with two deliverables. The mistake is to produce the left column and assume the right column follows. It doesn't. The cybersecurity reviewer reads the cybersecurity section of the eSTAR, and a pointer to the software section won't satisfy it.

Safety classes and Documentation Levels are separate decisions

Teams often map IEC 62304 Class A, B, and C onto FDA's Basic and Enhanced Documentation Levels. They're related but not the same decision.

IEC 62304 classifies by the injury a software failure could cause: Class A, no injury or damage to health; Class B, non-serious injury; Class C, death or serious injury.

FDA's Documentation Level is Enhanced when a software failure "could present a hazardous situation with a probable risk of death or serious injury." FDA also recommends Enhanced for combination products, Class III devices, and devices that test blood donations or determine donor and recipient compatibility.

Cybersecurity doesn't change the Documentation Level. It scales the cybersecurity package on its own axis, based on connectivity and attack surface. A Class A standalone app and a Class A connected device get the same software package and very different cybersecurity packages.

Document both decisions on their own terms. A reviewer who sees "Class B, therefore Basic" without the FDA rationale will ask for it.

Requirements with no IEC 62304 counterpart

Three parts of the cybersecurity package have nothing to borrow from the software lifecycle.

Cybersecurity Management Plan

Section VI.B lists the elements FDA expects:

• Personnel responsible
• Sources, methods, and frequency for monitoring vulnerabilities
• How you identify and address vulnerabilities in CISA's Known Exploited Vulnerabilities catalog
• Periodic security testing
• Timeline to develop and release patches
• Update processes and patching capability
• Your coordinated vulnerability disclosure process
• How you'll communicate remediations to customers

For cyber devices under Section 524B, this plan is a statutory requirement, not a recommendation. See FDA Section 524B requirements.

Labeling

Section VI.A lists security information FDA expects users to receive: recommended security controls for the use environment, network ports and interfaces, infrastructure requirements, the SBOM, how to obtain authorized updates, how the device responds to security events, backup and restore, secure configuration, forensic log access, end of support, and secure decommissioning. None of this comes from your IEC 62304 file.

Interoperability

Section V.A.3 asks you to assess cybersecurity risks from every interface: other devices, "other functions," healthcare infrastructure, and general-purpose computing platforms. Where you rely on a common protocol such as Bluetooth Low Energy, FDA expects you to consider whether added controls beneath the protocol are needed in case the protocol itself is compromised.

How to plan the work

1. Assess the gap. Audit your IEC 62304 process against Section V of the cybersecurity guidance. Most teams find that planning, requirements, and architecture need additions, while testing needs a separate campaign.
2. Update the plan. Add security activities to the Software Development Plan. Draft the Cybersecurity Management Plan as a separate document from day one.
3. Trace once. Put security requirements, threat model items, controls, and tests into the same traceability tool as the software requirements. One matrix, two filtered exports.
4. Budget the cybersecurity package as its own workstream. Threat modeling, architecture views, SBOM generation, vulnerability assessment, and penetration testing add up. Treat them as a parallel track with its own owner.
5. Book the Q-Submission. FDA recommends using the Q-Submission process to discuss cybersecurity design early. It's cheaper than an Additional Information request.

Integration with clear boundaries

SPDF versus IEC 62304 was never a choice between frameworks. Run security activities inside the lifecycle you already have. Then write two packages, because FDA reads two sections. Teams that plan this way produce one set of evidence and two sets of documents, and they avoid the deficiency letters that come from assuming the software package covers security.

Need help with your cybersecurity or IEC 62304 process and documentation? Email us at info@cybermed.ai.

Sources

• FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance, February 3, 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
• FDA. Content of Premarket Submissions for Device Software Functions. Final guidance, June 14, 2023. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-premarket-submissions-device-software-functions
• IEC 62304:2006 + A1:2015. Medical device software, Software life cycle processes.
• IEC 81001-5-1:2021. Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, Activities in the product life cycle.