How JSP2 and MDS2 Fit Together for Medtech

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.

The two acronyms get confused constantly, including in RFPs. This post draws the line clearly and shows how the artifacts chain together across development, submission, procurement, and postmarket.

Key Takeaways

• JSP2 is a total-product-lifecycle framework (HSCC, March 2024). MDS2 is a disclosure form (HSCC, current v3.0).
• JSP2 is one of four development frameworks the FDA lists as acceptable in the February 3, 2026 final guidance.
• MDS2 is not an FDA artifact; it is a hospital-procurement artifact. The FDA does not review it.
• MDS2 answers are much easier to produce, and much more defensible, when JSP2 outputs already exist internally.
• Manufacturers who treat MDS2 as a standalone marketing document usually fail hospital security follow-up questions.

Table of Contents

• Key Takeaways
• Why This Matters
• What JSP2 is
• What MDS2 is
• How the two artifacts chain together
• Which JSP2 outputs populate which MDS2 sections
• Common failure modes when the two are decoupled
• How to run both together without duplicating work
• How Blue Goat Cyber Approaches This
• Frequently Asked Questions
• CTA

Why This Matters

Hospital procurement and internal engineering rarely talk to each other. Engineering picks a development framework (SPDF, JSP2, IEC 81001-5-1, or ISA/IEC 62443-4-1, per the FDA's 2026 framework list) and produces submission artifacts. Sales and clinical affairs receive an MDS2 request from a hospital and scramble to fill it out from whatever documentation exists. The two workflows meet only when a hospital security team asks a follow-up question the sales team cannot answer.

Linking JSP2 and MDS2 explicitly, so the development artifacts populate the disclosure form deterministically, eliminates that class of failure and shortens hospital procurement cycles by weeks.

What JSP2 is

The HSCC Joint Security Plan v2, published March 2024, is a healthcare-industry-authored total-product-lifecycle framework for medical device and health IT cybersecurity. It covers design, development, deployment, operation, and end-of-life. It was written jointly by manufacturers, health-delivery organizations, and government partners.

The FDA's February 3, 2026 final premarket cybersecurity guidance names JSP2 as one of four acceptable lifecycle frameworks alongside SPDF, IEC 81001-5-1, and ISA/IEC 62443-4-1. See the fuller treatment in what is the medical device and health IT Joint Security Plan (JSP).

JSP2 produces the internal artifacts manufacturers use to develop a secure device: threat models, security risk files, SBOMs, postmarket plans, coordinated vulnerability disclosure processes, and customer-facing security documentation.

What MDS2 is

The Manufacturer Disclosure Statement for Medical Device Security is a standardized questionnaire hospital procurement uses to evaluate the security posture of a device before purchase. It is maintained by HSCC and NEMA. The current form is v3.0, with v4.0 in development.

MDS2 covers roughly 250 questions across categories including device description, data at rest and in transit, network configuration, authentication and access controls, patch management, malware protection, audit logging, and end-of-life. The manufacturer fills it out; the hospital security and clinical engineering teams review it as part of vendor risk management.

Detailed walkthrough: MDS2 and HSCC procurement disclosure for medical devices.

MDS2 is not an FDA artifact. Reviewers do not ask for it, and it is not part of the premarket submission. It lives entirely in the procurement conversation.

How the two artifacts chain together

The two fit into the lifecycle at different points and feed each other in both directions.

        JSP2 (development framework)
                 |
                 |  produces
                 v
   Security artifacts: threat model, SBOM+VEX,
   risk file, postmarket plan, CVD process,
   customer security documentation
                 |
                 |  populate
                 v
        MDS2 (procurement disclosure)
                 |
                 |  reviewed by
                 v
   Hospital security + clinical engineering
                 |
                 |  feeds back into
                 v
   JSP2 postmarket + next-version design

JSP2 outputs are the source of truth. MDS2 is a curated, standardized view of those outputs shaped for procurement. Hospital feedback then loops back into the JSP2 postmarket phase, which drives the next-version development cycle.

Assembling JSP2 and MDS2 for a submission?

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. → FDA premarket cybersecurity services

Which JSP2 outputs populate which MDS2 sections

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

MDS2 section	JSP2 output that populates it
Device description, intended use	JSP2 concept phase, intended-use analysis
Data-at-rest protections	JSP2 security requirements, design phase controls
Data-in-transit protections	JSP2 threat model (spoofing, tampering views), design controls
Authentication and access controls	JSP2 security requirements, IEC 62443-inspired role definitions
Network configuration	JSP2 architecture views, deployment guidance
Patch management	JSP2 postmarket cybersecurity management plan
Malware protection	JSP2 design controls, hardened configuration guidance
Audit logging	JSP2 security requirements, forensic-readiness controls
SBOM availability and format	JSP2 SBOM/VEX artifact
End-of-life communication	JSP2 end-of-support plan
Coordinated vulnerability disclosure	JSP2 CVD process definition
Customer security documentation	JSP2 customer security documentation deliverable

Every MDS2 row that hospital security cares most about has a direct JSP2 source. A manufacturer that cannot point to the JSP2 (or equivalent framework) output behind an MDS2 answer is guessing on that row.

Talk to a MedTech cybersecurity expert about aligning JSP2 and MDS2

Common failure modes when the two are decoupled

Across MDS2 forms we review during hospital-side security assessments, the same four decoupling patterns recur:

1. MDS2 answered by sales, not engineering. The form reads as a marketing document. Hospital security asks a follow-up ("show me the CVD policy URL") and the response is a delay of days or weeks.
2. SBOM row marked yes, no SBOM produced. MDS2 checkbox says an SBOM is available in CycloneDX. Procurement asks for it. Engineering does not have one. Cause: no JSP2 SBOM/VEX artifact stood up during development.
3. Patch cadence stated without a postmarket plan. MDS2 promises quarterly security patches. There is no JSP2 postmarket cybersecurity management plan behind it. First high-severity CVE turns the promise into a 90-day scramble.
4. End-of-life row left blank or vague. JSP2 requires an explicit end-of-support plan; MDS2 asks for the communication mechanism. Blank answers are read by hospital security as "we have not thought about this."

Each of these is a JSP2 gap surfaced by an MDS2 question. Fixing the MDS2 answer without fixing the underlying JSP2 gap defers the problem to the next hospital security review.

How to run both together without duplicating work

The pattern that works, for teams already committed to JSP2 (or an equivalent framework, mapped to JSP2):

1. Assign one owner across both artifacts. Usually the security engineering lead or product security manager, not sales.
2. Build the MDS2 form directly from JSP2 outputs. Every MDS2 row cites a JSP2 artifact ID internally. If a row has no artifact citation, that is a JSP2 gap to close, not a row to guess at.
3. Version MDS2 alongside the device. When the JSP2 postmarket phase produces a new SBOM, new threat model update, or new patch cadence, regenerate the MDS2. Stale MDS2 forms are the most common finding in hospital re-assessment.
4. Publish the CVD process at a stable URL. MDS2 asks for it; JSP2 requires it; hospital security verifies it. One URL, one owner, one intake mailbox.
5. Treat hospital feedback as a JSP2 postmarket input. If three hospitals flag the same MDS2 row as insufficient, that is a signal to the JSP2 postmarket cycle, not a sales objection to handle.

How Blue Goat Cyber Approaches This

Blue Goat Cyber runs joint JSP2 / MDS2 alignment engagements for manufacturers who already produce MDS2 forms but keep losing hospital security reviews. The engagement inventories current MDS2 answers, traces each row back to the JSP2 artifact that should support it, flags rows with no underlying artifact, and delivers a remediation backlog that closes the JSP2 gaps and refreshes the MDS2 in one pass.

Christian Espinosa, our founder, has led both submission-side and procurement-side cybersecurity engagements for more than 250 FDA-cleared medical devices, including MDS2 authoring, hospital security response, and JSP2 implementation.

Frequently Asked Questions

Is MDS2 replacing JSP2, or vice versa?

Neither. They cover different parts of the lifecycle. JSP2 is how you build the device; MDS2 is how you disclose what you built to buyers.

Does the FDA look at MDS2?

No. MDS2 is a procurement artifact maintained by HSCC and NEMA. The FDA's premarket review does not include it.

Can I fill out MDS2 without running JSP2?

Yes, but the answers are only as strong as the underlying artifacts. If a competing manufacturer runs JSP2 and cites artifacts row-by-row while you cite marketing copy, hospital security will notice.

What about MDS2 v4.0?

HSCC is developing v4.0 to align more explicitly with the FDA's 2026 guidance expectations (SBOM/VEX, four-view threat models, CVD). Manufacturers with a mature JSP2 program will find v4.0 easier to answer than v3.0, not harder.

Which framework should I pick if hospital procurement is my main driver?

JSP2 is the strongest fit because it was authored jointly by manufacturers and health-delivery organizations. See JSP2 vs SPDF vs IEC 81001-5-1 for the full framework-selection argument.

CTA

Align JSP2 development artifacts to MDS2 procurement answers once, and every future hospital security review gets shorter. Blue Goat Cyber runs joint JSP2 / MDS2 alignment engagements that inventory, remediate, and republish in a single sprint. Book a discovery session.

Christian Espinosa, Founder, Blue Goat Cyber. CISSP, CCISO, ex-military red team. Has led JSP2 implementations, MDS2 authoring, and FDA cybersecurity submissions for more than 250 medical devices. More on the author.