How SPDF Maps to IEC 81001-5-1 Activities

Part of our medtech cybersecurity framework choice series (SPDF, JSP2, IEC 81001-5-1). For the full overview, start with JSP2 vs SPDF vs IEC 81001-5-1: Framework Pick.

Teams shipping into both the United States and the European Union often ask the wrong version of this question. It is not "SPDF or IEC 81001-5-1?" It is "how do we run one lifecycle that satisfies both?" This post is the crosswalk that makes that possible.

If you are still choosing between frameworks, start with JSP2 vs SPDF vs IEC 81001-5-1: which framework should medtech pick? and IEC 81001-5-1 vs IEC 62304. This post assumes you have picked, or are planning to run, both.

Why This Matters

New to the standard? Start with our IEC 81001-5-1 explainer, which covers what it requires and how the FDA treats it.

Running SPDF and IEC 81001-5-1 as two separate programs is a common and expensive mistake. The evidence is the same, the risk file is the same, the postmarket obligations are substantially the same. Teams that duplicate processes end up producing two threat models, two risk files, and two vulnerability management workflows that drift out of sync over time. The next audit or deficiency letter forces a painful reconciliation.

FDA recommends using an SPDF and discusses existing secure-development approaches, including IEC 81001-5-1, the Joint Security Plan, and ISA/IEC 62443-4-1. These are examples, not an exclusive list or automatically equivalent alternatives. Assess the submission evidence against applicable FDA recommendations regardless of framework vocabulary.

Why this crosswalk exists

The FDA's guidance describes SPDF as a set of outcomes and expected artifacts: security risk management, threat modeling with four architecture views, SBOM with optional VEX, security testing, cybersecurity management plan, labeling, postmarket monitoring. IEC 81001-5-1 organizes the same territory as a numbered clause structure that ties directly to lifecycle phases.[^iec81001]

The crosswalk below is the one we use in engagements. It is not a formal FDA / IEC concordance (none exists); it reflects how reviewers and notified bodies actually consume the artifacts.

Phase-by-phase mapping table

The crosswalk can reduce duplication, but each FDA recommendation and applicable IEC requirement needs a separate coverage check. Reuse evidence where suitable and document gaps; a shared artifact does not establish equivalence.

Management and planning: SPDF outcomes → IEC 81001-5-1 applicable lifecycle activities

Governance activities can be coordinated in one plan covering QMS integration, responsibilities, resources, and security risk management. Verify exact IEC 81001-5-1 clause references against the licensed standard; this activity-level mapping is not an authoritative clause attribution.

Security requirements: SPDF → IEC 81001-5-1 applicable lifecycle activities

SPDF expects security requirements traceable to threats and to verification. IEC 81001-5-1 applicable lifecycle activities requires the same, with a slightly heavier emphasis on secure-by-design and secure-by-default posture. Produce a single requirements set. Tag each requirement with both the SPDF outcome it satisfies and the IEC 81001-5-1 clause it derives from. Traceability is the shared spine.

Security architecture and threat modeling: SPDF → applicable lifecycle activities

This is where the mapping is most often mishandled. The FDA guidance calls for four architecture views: global system, multi-patient harm, updateability, and security use cases. IEC 81001-5-1 applicable lifecycle activities requires a documented security architecture; applicable lifecycle activities requires secure-design decisions. The four FDA views support both frameworks, subject to a gap assessment. Produce the four views once, label them as the security architecture under IEC 81001-5-1, and reviewers on both sides get the artifact they expect.

Threat modeling itself sits alongside the architecture. Use STRIDE (or an equivalent) once, harm-oriented, and feed the outputs into the ISO 14971 risk file. Both frameworks accept the same threat model.

Talk to a MedTech cybersecurity expert about running one lifecycle across both frameworks

Operationalizing the SPDF against IEC 81001-5-1?

Blue Goat Cyber is a medical-device-only cybersecurity firm. Our team runs the threat modeling, penetration testing, and FDA-facing documentation MedTech submissions live or die on. → Secure MedTech product design consulting

Implementation: SPDF → applicable lifecycle activities

SPDF asks for secure implementation and coding standards. IEC 81001-5-1 applicable lifecycle activities require the same, with an explicit call-out for tool-supported analysis (SAST). A single coding standard, a single SAST configuration, and a single static-analysis output stream serve both frameworks. The FDA does not need to see the tool configuration; it needs to see that findings were triaged, remediated or accepted, and traced back to requirements. IEC 81001-5-1 asks for the same evidence.

SBOM and third-party software records can support secure development and vulnerability management. Verify their coverage against the licensed IEC 81001-5-1 requirements and FDA recommendations separately. Section 524B(b)(3) requires the SBOM; neither a particular format nor VEX automatically establishes conformity.

Verification and testing: SPDF → applicable lifecycle activities

SPDF's security testing expectation matches IEC 81001-5-1 applicable lifecycle activities in broad objectives, not as an exact clause concordance: security verification, security validation, and penetration testing where the risk profile warrants it. Maintain a coordinated security testing evidence set; device V&V remains the manufacturer’s responsibility. Penetration test evidence goes in the same artifact. The FDA's guidance is more prescriptive on penetration-test scope for connected devices; IEC 81001-5-1 defers to risk-proportionate testing. Meet the FDA's bar and assess the evidence separately against each applicable IEC requirement.

Release and transfer: SPDF → applicable lifecycle activities

See also: IEC 81001-5-1: Secure Lifecycle Rules, AAMI TIR57 vs TIR97 vs SW96, and MedTech Cyber Standards Every Device Team Must Know.

Both frameworks require a security release decision with documented residual risk. IEC 81001-5-1 applicable lifecycle activities splits this into the release decision (8.1), residual-risk communication to the operator (8.2), and user documentation (8.3). SPDF bundles the same content into the cybersecurity management plan and labeling. One release checklist, one residual-risk statement, and one user-facing security document cover both.

Postmarket: SPDF → applicable lifecycle activities

SPDF's postmarket obligations (monitoring, patching, CVD, incident response) map to IEC 81001-5-1 applicable lifecycle activities (postmarket security activities) and 10 (maintenance). The pairing is straightforward: run one CVD process, one vulnerability triage cadence, one patching workflow. The FDA's postmarket cybersecurity management plan is the artifact; IEC 81001-5-1 applicable lifecycle activities is the process behind it.

For the deeper postmarket picture, see how JSP2 and MDS2 fit together, MDS2 lives in this postmarket space regardless of which framework you pick.

How to run one lifecycle with two labels

Three operational rules make this work in practice:

1. Pick the spine, then dual-label everything. For US-only devices, SPDF is the natural spine and IEC 81001-5-1 mapping is optional. For dual FDA + EU submissions, run IEC 81001-5-1 as the spine and label the artifacts with SPDF outcome names in the artifact headers or the cybersecurity management plan. Reviewers on either side see native vocabulary.
2. One risk file. Do not maintain a separate security risk file per framework. Use ISO 14971 as the container (extended per AAMI SW96) and let both frameworks read from it.
3. One CVD process. Do not stand up two vulnerability workflows. One inbox, one triage, one disclosure log, mapped to both frameworks.

Teams that follow these three rules typically report meaningfully less lifecycle documentation overhead than teams running parallel programs.

How Blue Goat Cyber Approaches This

Blue Goat Cyber's dual-framework engagement produces a single artifact set with SPDF and IEC 81001-5-1 dual-labeling embedded from day one. The output is a cybersecurity management plan, threat model with four FDA views, integrated ISO 14971 + AAMI SW96 risk file, SBOM + VEX, penetration and security testing report, and postmarket plan, all labeled to both frameworks. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed.

Christian Espinosa, our founder, has led dual FDA + EU MDR cybersecurity submissions on more than 60 devices under this exact operating model.

Frequently Asked Questions

Do I have to pick between SPDF and IEC 81001-5-1?

No, not if you produce the artifacts correctly. The FDA lists both as acceptable; the EU expects IEC 81001-5-1. Run IEC 81001-5-1 as the spine for dual submissions and label artifacts with SPDF outcome names.

Does the FDA reviewer need the IEC 81001-5-1 clause numbers in the submission?

No. Reviewers grade the artifacts against the guidance's expected content, not the clause number they came from. Include the mapping in the cybersecurity management plan so the reviewer can trace it if they want; do not clutter every artifact with clause references.

What about ISO 14971 and AAMI SW96?

Both frameworks assume ISO 14971 as the risk-management container. AAMI SW96:2023 formalizes the security extension. One risk file, one process, feeds both SPDF and IEC 81001-5-1.

Where do the four FDA architecture views live in IEC 81001-5-1?

Inside applicable lifecycle activities (security architecture) with support from applicable lifecycle activities (secure design). Produce the four views (global system, multi-patient harm, updateability, security use cases) once, and both frameworks are satisfied.

Can I map JSP2 the same way?

Yes. JSP2 has a similar phase structure and maps cleanly onto both SPDF outcomes and IEC 81001-5-1 clauses. See JSP2 vs SPDF vs IEC 81001-5-1 for how JSP2 fits into the framework choice, and treat this crosswalk as the SPDF ⇄ 81001-5-1 backbone underneath.

What is the biggest failure mode?

Running two parallel programs. Two threat models, two risk files, two CVD processes drift out of sync fast, and the next audit or FDA deficiency letter forces a costly reconciliation. Pick one spine, dual-label the artifacts, run one workflow.

CTA

If you are running SPDF and IEC 81001-5-1 as two separate programs, you are paying twice for the same lifecycle. Blue Goat Cyber runs a three-week dual-framework consolidation engagement that collapses the two into a single artifact set with dual-labeling, ready for FDA reviewers and EU notified bodies alike. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. Book a discovery session.

Christian Espinosa, Founder, Blue Goat Cyber., CCISO, ex-military red team. Has red-team and DoD cyberwarfare experience. Blue Goat Cyber has supported 275+ submissions, with cybersecurity work informed by SPDF and IEC 81001-5-1. More on the author.

References