SPDF and IEC 62304 Mapping: FDA Cyber Guide

Reviewers at the FDA do not treat your SPDF and your IEC 62304 file as separate documents. They expect to open one design history file and trace a single security requirement from the planning record, through architecture and threat model, into code and unit tests, and out to a postmarket monitoring plan. When that trace breaks, you get an Additional Information letter and an 8 to 12 week clearance delay.

This post is the crosswalk. It walks IEC 62304 process by process, shows the SPDF activity that belongs in each one, and flags the three places where 62304 alone is not enough to satisfy the February 3, 2026 premarket cybersecurity guidance or Section 524B.

Key Takeaways

• IEC 62304 defines software lifecycle processes; SPDF adds the cybersecurity layer that reviewers expect inside each one.
• The mapping is concrete: every 62304 clause has a named SPDF artifact that should live in the same design history file.
• IEC 62304 is silent on threat modeling, SBOM, and Coordinated Vulnerability Disclosure - SPDF fills those gaps.
• 62304 software safety classification (A, B, C) does not replace security risk classification under AAMI SW96 and ISO 14971.
• Reviewers want bidirectional traceability between 62304 software items and SPDF threats, controls, and security tests.
• Building the crosswalk once, in your QMS, is faster than rebuilding it for every submission.

Table of Contents

• Why this matters
• How does IEC 62304 actually relate to SPDF?
• Process-by-process crosswalk: 62304 to SPDF
• Where IEC 62304 stops and SPDF takes over
• How do safety class and security risk class interact?
• How Blue Goat Cyber approaches the crosswalk
• SPDF and IEC 62304 FAQs

Why this matters

The FDA's February 3, 2026 final premarket cybersecurity guidance is explicit that cybersecurity must be integrated into the software lifecycle, not bolted on. IEC 62304 is the lifecycle standard the FDA recognizes; the Secure Product Development Framework is how Section 524B's "reasonable assurance of cybersecurity" gets operationalized inside it. When a submission shows SPDF and 62304 as two parallel documents that never reference each other, reviewers read that as a process problem, not a documentation problem.

AAMI SW96 and IEC 81001-5-1 both reinforce the same point: security activities belong inside the controlled software lifecycle, traceable to design inputs and verified against design outputs. Across 250+ submissions, the strongest packages we've produced share one trait - a single integrated lifecycle file where the 62304 process step and the SPDF artifact for that step live side by side.

How does IEC 62304 actually relate to SPDF?

IEC 62304 is process scaffolding. It tells you what software lifecycle activities must exist, who owns them, and what records they produce. It is intentionally silent on cybersecurity content because it predates Section 524B and the 2026 guidance.

SPDF is the cybersecurity content that fills that scaffolding. It does not replace 62304 planning records, requirements, or unit testing - it specifies the security flavor of each. The result is one lifecycle, not two.

Process-by-process crosswalk: 62304 to SPDF

The mapping below covers the eight IEC 62304 processes most submissions touch. Use it as a checklist when you build the design history file.

IEC 62304 process	SPDF activity that lives inside it	Artifact reviewers look for
5.1 Software development planning	SPDF policy + security gates per phase	Plan referencing SPDF policy, security exit criteria per phase
5.2 Software requirements analysis	Security requirements derivation from threats and standards	Security requirements specification, traced to threats and tests
5.3 Software architectural design	Threat modeling, trust boundaries, FDA architecture views	Data flow diagrams, STRIDE register, four FDA architecture views
5.4 Software detailed design	Security design decisions, crypto choices, key handling	Design records identifying security-relevant modules and rationale
5.5 Software unit implementation	Secure coding standard, SAST/SCA in CI, SBOM generation	Coding standard, SAST results, CycloneDX or SPDX SBOM
5.6 Software integration and testing	Integration-level security tests, fuzzing on untrusted inputs	Integration test reports including negative and abuse cases
5.7 Software system testing	Penetration testing across all interfaces	Pen test report scoped to threat model, written for FDA audience
5.8 Software release	Release record including security verification status	Signed release record, residual security risk acceptance
6 Software maintenance	Postmarket monitoring, vulnerability triage, validated patching	Postmarket plan, monitoring sources, patch SLAs
7 Risk management	Security risk integrated with ISO 14971 hazard file	Security Risk Assessment with exploitability-to-harm mapping
8 Configuration management	SBOM as a configuration item, component lifecycle tracking	SBOM regenerated per build, SOUP analysis with CVE evaluation
9 Problem resolution	Coordinated Vulnerability Disclosure intake feeding problem records	Published CVD policy, triage workflow with SLAs

Read every row left to right: the 62304 process is the container, the SPDF activity is the cybersecurity content, and the artifact is what ends up in the design history file. Reviewers should not have to ask where any of these live.

Where IEC 62304 stops and SPDF takes over

Three areas are not covered by IEC 62304 at all. If your only software process standard is 62304, you have known gaps the FDA will flag.

Threat modeling. 62304 requires architectural design records but does not require threat enumeration, trust boundaries, or the four FDA architecture views (global system, multi-patient harm, updateability, security use case). SPDF supplies all four.

SBOM and SOUP cybersecurity evaluation. 62304 requires SOUP identification and anomaly tracking, but not a machine-readable SBOM, supplier metadata, transitive dependencies, or CVE-level vulnerability evaluation. Section 524B and the 2026 guidance require all of it.

Coordinated Vulnerability Disclosure. 62304 problem resolution assumes problems come from internal testing and customer complaints. It does not anticipate external security researchers, ISO/IEC 29147 intake, or risk-based response SLAs. SPDF adds a published CVD program tied into problem resolution.

How do safety class and security risk class interact?

See also: IEC 62304 Classes vs FDA Device Classes: Cybersecurity Impact, 510(k) Cybersecurity Deficiencies That Trigger FDA Holds, and When to Hire a Device Security Consultant vs. Build In-House.

IEC 62304 software safety classes (A, B, C) measure the harm a software failure can cause. They do not measure the harm a cybersecurity exploit can cause. A Class A device with a connected interface can still have a Class C-equivalent security risk if exploitation could affect multiple patients.

Use AAMI SW96 and ISO 14971 to classify security risk independently, then trace each security risk back to the affected 62304 software item. The two classifications can differ for the same component, and that is the point.

How Blue Goat Cyber approaches the crosswalk

We build the SPDF-to-62304 crosswalk once, inside the client's QMS, so every future submission inherits it. Our team brings CISSP, OSCP, and ex-military red team experience to the threat modeling and penetration testing layers, and we sit alongside your software quality lead so the 62304 records and SPDF artifacts are produced together, not reconciled afterwards.

Across 250+ FDA submissions we have not had a cybersecurity rejection. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Most engagements start with a fixed-fee gap analysis against the crosswalk above; you get a scored readiness view and a remediation plan within days, not weeks. See our FDA premarket cybersecurity services for scope and timelines.

Book a 30-minute strategy session →

SPDF and IEC 62304 FAQs

Does SPDF replace IEC 62304?

No. SPDF is a cybersecurity layer that sits inside the IEC 62304 software lifecycle. 62304 tells you what software processes must exist; SPDF tells you what cybersecurity content goes into each process. You need both, integrated in the same design history file, to satisfy the FDA's February 3, 2026 premarket cybersecurity guidance.

Can I use my existing 62304 documentation as my SPDF documentation?

Partially. Your 62304 plans, requirements, architecture, and test records become the containers, but they need security-specific content added: threat model, security requirements, SBOM, security tests, and CVD. The FDA will flag a submission that submits 62304 records alone without the SPDF artifacts the 2026 guidance requires.

How does the IEC 62304 software safety class affect SPDF scope?

Safety class affects the depth of software lifecycle records 62304 requires, but it does not scale SPDF scope. Security risk classification under AAMI SW96 is independent. A Class A device with a wireless interface can still require full SPDF depth because exploitability and patient harm, not safety class, drive security scope.

Where does the SBOM live - in 62304 configuration management or in SPDF?

Both. The SBOM is a configuration item under 62304 Clause 8, and it is also an SPDF postmarket monitoring input. The crosswalk handles this by treating the SBOM as one artifact with two roles - regenerated per build by configuration management, and consumed by the postmarket vulnerability monitoring workflow defined in SPDF.

Is IEC 81001-5-1 a replacement for the SPDF-62304 crosswalk?

IEC 81001-5-1 is closer to a security-specific lifecycle standard and overlaps significantly with SPDF. Many manufacturers adopt 81001-5-1 as the security lifecycle and keep 62304 as the general software lifecycle, then map both into one design history file. The crosswalk principle is the same: one integrated lifecycle, traceable end to end.

What is the fastest way to build the crosswalk if we are mid-development?

Start with the table above and audit each 62304 process for the matching SPDF artifact. Gaps usually cluster in three places: threat model depth, SBOM completeness, and CVD program. Fix those first, then backfill traceability. Most teams need two to four weeks of focused work to retrofit a credible crosswalk on a project already in 62304 execution.

Build the crosswalk before your next submission

If you are preparing a 510(k), De Novo, or PMA and your SPDF and 62304 records currently live in separate files, that gap is fixable in weeks, not months. Book a free 30-minute strategy session and we will walk the crosswalk against your current design history file, flag the gaps the FDA is most likely to hit, and give you a fixed-fee quote within 24 hours. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.

Book your strategy session →

---

Albert Konik, Director of Medical Device Cybersecurity, CISSP, OSCP. Albert has led SPDF and IEC 62304 integration work across 250+ FDA submissions, with a focus on building one design history file that satisfies both software lifecycle and cybersecurity reviewers in a single pass.