JSP2 vs SPDF vs IEC 81001-5-1: Framework Pick

The February 3, 2026 final guidance made this a real question. The 2023 draft treated SPDF as the default. The 2026 final explicitly recognizes JSP2, IEC 81001-5-1, and ISA/IEC 62443-4-1 as acceptable alternatives, provided the manufacturer demonstrates equivalent coverage. That opened a decision that many medtech teams did not previously have to make and are now making poorly.

This post is the framework-selection guide the guidance itself does not provide.

Why This Matters

Framework choice is not a documentation exercise. It determines which artifacts your engineering team produces for the next three to five years, which audits you pass without rework, and which procurement questionnaires you can answer without a translation layer. Picking the wrong spine costs six to twelve months of retrofit work when the first mismatched audit or RFP arrives.

The 2026 final guidance is also more explicit than the draft about equivalence: if you pick a non-SPDF framework, you must map its outputs to the FDA's expected artifacts.[^fda2026] Reviewers do not learn your framework, they check your artifacts. A JSP2 or 81001-5-1 submission that skips the mapping reads as an incomplete SPDF submission and draws the same deficiency letters.

What this post is not

To keep the decision clean, a few things this post is explicitly not about:

• Not ISO 27001 or SOC 2. Enterprise information-security frameworks. Useful for the company, but the FDA does not accept them as substitutes for a product-development framework.
• Not HIPAA. HIPAA governs covered entities and business associates handling PHI, not device development. A HIPAA program does not satisfy Section 524B.
• Not the NIST Cybersecurity Framework (CSF 2.0). CSF is an organizational risk-management framework, not a product-development lifecycle. It complements SPDF or 81001-5-1; it does not replace either.
• Not NIST SSDF (SP 800-218). SSDF is a general secure-software framework and can feed any of the four medtech-specific frameworks below, but on its own it is not one of the four the FDA lists.
• Not a shortcut around the artifacts. Whichever framework you pick, you still owe the same threat model, SBOM with VEX, security risk file, postmarket plan, CVD process, and labeling.

Decision tree

What the FDA actually said in the 2026 final guidance

The final Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions guidance (February 3, 2026) states that manufacturers should implement a secure product development framework and lists the following as acceptable:[^fda2026]

• The FDA's own SPDF, as described in the guidance.
• HSCC's Joint Security Plan v2 (JSP2), published March 2024.[^jsp2]
• 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.[^iec81001]
• ISA/IEC 62443-4-1:2018, Security for industrial automation and control systems, Part 4-1: Secure product development lifecycle requirements.[^iec62443]

The guidance is clear that the choice is the manufacturer's, and that any of the four is acceptable if the resulting submission contains the expected content: security risk management, threat modeling with the required architecture views, SBOM with VEX, interoperability considerations, security testing, labeling, and a postmarket cybersecurity management plan.

The four frameworks at a glance

Quick pick: SPDF vs JSP2 vs IEC 81001-5-1

For the three frameworks most medtech teams actually weigh, use this as the one-line answer:

SPDF: the FDA's default

SPDF is the framework the FDA wrote for itself. It is the least ambiguous mapping to the artifacts reviewers expect, because it is the source of those artifacts. See our companion piece on the SPDF vs SSDLC gap for what SPDF adds over a general secure SDLC.

Pick SPDF when:

• The device is US-first or US-only.
• The team does not already have an established framework running.
• You want the shortest path from artifacts to a clean submission.

SPDF's weakness: it is not recognized as a standard outside the US. EU notified bodies do not evaluate against SPDF, and hospital procurement rarely asks about it by name.

JSP2: the healthcare-industry framework

The Health Sector Coordinating Council's Joint Security Plan v2 (March 2024) is a healthcare-industry-authored total-product-lifecycle framework. It was written by manufacturers, health-delivery organizations, and government partners together, which is why it aligns unusually well with the questions hospital security and procurement teams actually ask.

JSP2 covers the same lifecycle stages as SPDF but adds explicit sections on customer-facing security documentation, procurement enablement (including alignment with the MDS2 disclosure form), and coordinated deployment guidance. Our deep-dive on JSP is here.

Pick JSP2 when:

• Hospital contracts and IDN security reviews drive as much of your roadmap as the FDA does.
• You want a framework that reads naturally to both regulators and customers.
• You already produce MDS2 forms and want the underlying development framework to align with them.

JSP2's weakness: slightly less name recognition inside FDA review divisions than SPDF, so the mapping to expected artifacts must be explicit in the submission.

Picking a security lifecycle framework?

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

IEC 81001-5-1: the international spine

IEC 81001-5-1:2021 is the international standard for security activities in the health-software lifecycle. It is harmonized with IEC 62304 (software lifecycle) and IEC 82304-1 (health software safety), and it is the framework EU notified bodies expect under the MDR and IVDR. For the direct comparison, see IEC 81001-5-1 vs IEC 62304.

See also: IEC 81001-5-1 vs AAMI SW96, AAMI TIR57 vs TIR97 vs SW96, and MedTech Cyber Standards Every Device.

Pick IEC 81001-5-1 when:

• You submit to both the FDA and EU notified bodies.
• The device is regulated in multiple jurisdictions where ISO/IEC standards carry more weight than US-specific frameworks.
• The engineering org already runs IEC 62304 and wants the security framework to sit natively on top of it.

IEC 81001-5-1's weakness: it costs more to adopt cleanly, and the language is denser than SPDF or JSP2. Small teams shipping US-only will find the overhead disproportionate.

Talk to a MedTech cybersecurity expert about framework selection

ISA/IEC 62443-4-1: the industrial option

ISA/IEC 62443-4-1 comes from the industrial automation world. It is the secure development lifecycle standard for control-system vendors, and it is exceptionally rigorous, arguably more rigorous than any of the other three on pure development-process discipline.

Pick 62443-4-1 when:

• The device is genuinely industrial in scale: surgical robotics, large imaging platforms, radiation therapy systems, hospital automation.
• The parent company already runs 62443 across other product lines and wants a single framework.
• The customer base includes non-clinical industrial buyers alongside hospitals.

62443-4-1's weakness: it is overkill for most Class II devices, and its vocabulary (zones, conduits, security levels) does not translate naturally to FDA reviewer expectations without heavy mapping.

Decision matrix: which framework fits which company

How to mix frameworks without confusing reviewers

Real submissions often use more than one framework. A common pattern: IEC 81001-5-1 as the international spine, with SPDF-shaped artifacts (four architecture views, VEX-paired SBOM, FDA-format postmarket plan) presented in the submission. Another: JSP2 as the internal operating framework, with an SPDF-labeled artifact package for the FDA and JSP2-labeled documentation for hospital procurement.

Two rules keep this readable:

1. Name the spine once, in the cybersecurity management plan. Do not describe the device as "SPDF and JSP2 and 81001-5-1 aligned" in a submission cover letter. Pick one, and describe the others as mappings.
2. Produce artifacts in the FDA's expected shape regardless of spine. Reviewers grade the artifacts, not the framework. Threat model with four views, SBOM with VEX, integrated ISO 14971 / AAMI SW96 risk file, postmarket plan, CVD process, labeling. Every framework can produce these; the wrapper is the manufacturer's choice.

How Blue Goat Cyber Approaches This

Blue Goat Cyber runs a framework-selection workshop before the first submission of a device family. The output is a one-page decision memo naming the spine, the mapping to FDA artifacts, and the sequence of internal work needed to stand it up. For teams already committed to a framework, we run gap assessments against the 2026 final guidance and produce a remediation backlog ordered by deficiency-letter likelihood.

Christian Espinosa, our founder, has led cybersecurity submissions on more than 250 FDA-cleared devices under all four frameworks, and sits close enough to HSCC and IEC working groups to catch changes before they land in guidance.

Frequently Asked Questions

Does the FDA prefer SPDF over the others?

The 2026 final guidance treats the four frameworks as equivalent when the resulting artifacts meet the guidance's content expectations. In practice, SPDF is the lowest-friction path because it uses the FDA's own vocabulary.

Which should I choose for a first-ever 510(k)?

SPDF. It is the FDA's own vocabulary and the shortest path from artifacts to a clean submission. Adopt a different framework only if a specific driver (EU submission, existing 62443 program, hospital-procurement pressure) is already on the table.

Which should I choose if my main buyer is a large IDN or hospital system?

JSP2. It was co-authored by health-delivery organizations, so its outputs answer procurement questions in the vocabulary hospital security teams already use, and it aligns natively with the MDS2 disclosure form.

Which should I choose for a connected implantable or infusion pump?

SPDF or IEC 81001-5-1. Both handle the harm-traceability, four-view threat modeling, and postmarket obligations these devices demand. Pick SPDF for US-first, IEC 81001-5-1 for dual FDA/EU.

Which should I choose if we already run ISO 13485 and IEC 62304?

IEC 81001-5-1. It slots onto IEC 62304 directly and reuses the ISO 13485 QMS scaffolding, so adoption cost is low. SPDF is still fine, it just does not benefit from the existing standards investment.

What if I genuinely cannot decide?

Default to SPDF, document the decision in the cybersecurity management plan, and revisit at the next major device version. SPDF is never the wrong answer for an FDA submission; it is only sometimes not the best answer.

CTA

Pick the framework once, correctly, before you build the artifacts. Blue Goat Cyber runs a two-week framework selection and gap workshop that outputs a submission-ready spine, a mapping to FDA artifacts, and a prioritized remediation backlog. Book a discovery session.

Christian Espinosa, Founder, Blue Goat Cyber. CISSP, CCISO, ex-military red team. Has led framework selection and FDA cybersecurity submissions for more than 250 medical devices under SPDF, JSP2, IEC 81001-5-1, and ISA/IEC 62443-4-1. More on the author.

References

Continue the Framework choice series

Dive deeper with these companion articles:

• How SPDF Maps to IEC 81001-5-1 Activities
• IEC 81001-5-1 vs IEC 62304 for Medical Devices
• How JSP2 and MDS2 Fit Together for Medtech
• Medical Device Cybersecurity SPDF vs TPLC
• SPDF vs SSDLC: What Medtech Teams Get
• The Medical Device and Health IT JSP
• MDS2 and HSCC Disclosure for Medical
• SSDLC for Medical Device Cybersecurity
• Post-Exploitation Frameworks in MedTech