⚠ KEY DATE — July 2, 2028 FDA’s recognition of FIRST CVSS v4.0 (Recognition No. 13-140) supersedes its recognition of FIRST CVSS v3.1 (Recognition No. 13-142) under FDA’s Recognized Consensus Standards. FDA will accept declarations of conformity to CVSS v3.1 in premarket submissions until July 2, 2028; after that date, declarations of conformity to CVSS v3.1 will not be accepted.

Executive Summary

On May 25, 2026, the U.S. Food and Drug Administration (FDA) formally recognized the Common Vulnerability Scoring System version 4.0 (CVSS v4.0) as a consensus standard for medical devices (Recognition No. 13-140). With this recognition, the FDA set July 2, 2028 as the date by which CVSS v4.0 supersedes its prior recognition of CVSS v3.1 (Recognition No. 13-142). After that date, declarations of conformity to CVSS v3.1 in premarket submissions will no longer be accepted.

This transition is not merely a version upgrade — it represents a fundamental redesign of how vulnerability severity is measured, communicated, and acted upon. For medical device manufacturers (MDMs), the change carries direct implications for premarket submissions, postmarket surveillance programs, Software Bill of Materials (SBOM) management, and Coordinated Vulnerability Disclosure (CVD) processes. CVSS v4.0 scores are not backward-compatible with v3.x; existing vulnerability libraries, risk registers, and submission documentation should be evaluated and updated under the new framework.

This article provides a structured analysis of the regulatory mandate, the technical enhancements introduced by CVSS v4.0, the compliance obligations it creates for manufacturers, and how Aktriva is positioned to support clients through this transition.

Regulatory Background and FDA’s Position

FDA’s Recognition of CVSS as a Consensus Standard

CVSS has long been central to FDA’s cybersecurity expectations for medical devices. In October 2020, the FDA recognized CVSS v3.0 as a Medical Device Development Tool (MDDT) — qualified for use in postmarket vulnerability disclosures through MITRE’s rubric for applying CVSS to medical devices. The FDA’s Premarket Cybersecurity Guidance has consistently cited CVSS as a primary methodology for assessing exploitability and communicating vulnerability severity.

The February 3, 2026 revision of the FDA’s final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, reinforced this position. Cybersecurity risk analysis — including exploitability assessment — is expected as a component of the Security Risk Management Report submitted with premarket applications for “cyber devices” as defined under Section 524B of the FD&C Act. CVSS is a widely accepted methodology for documenting exploitability within that report, though FDA does not prescribe a specific tool.

The July 2028 Sunset of CVSS v3.1

With the formal recognition of CVSS v4.0 (Recognition No. 13-140, entered May 25, 2026), the FDA has set a clear policy trajectory. Both CVSS v3.1 (Recognition No. 13-142) and CVSS v4.0 are currently acceptable for regulatory submissions. However, this dual-acceptance window closes on July 2, 2028. After that date, CVSS v4.0 becomes the sole recognized version for medical device vulnerability assessment purposes. Manufacturers who continue relying on CVSS v3.1 after that transition period should be prepared to provide appropriate justification, as this may not align with the current FDA-recognized consensus standard.

The FDA’s Recognized Consensus Standards Database — accessible at accessdata.fda.gov/scripts/cdrh/cfdocs/cfstandards — is the authoritative source for current recognized standard editions. FDA reviewers may request clarification or justification when superseded standards are cited in premarket submissions, and manufacturers should verify their standard references as part of submission preparation.

What’s New in CVSS v4.0: Key Enhancements

Released by the Forum of Incident Response and Security Teams (FIRST) in November 2023, CVSS v4.0 is the most significant revision to the standard since the introduction of CVSS v3.0 in 2015. The changes are structural, not cosmetic. For MedTech manufacturers, several enhancements are particularly consequential.

1. Restructured Metric Groups

CVSS v4.0 replaces the three-group model (Base, Temporal, Environmental) with a four-group model: Base, Threat, Environmental, and Supplemental. This restructuring improves the precision of each metric domain and reduces the ambiguity that frequently led to scoring inconsistency under v3.x.

2. New Attack Requirements (AT) Metric

One of the most significant additions is the Attack Requirements (AT) metric, which captures prerequisite deployment or environmental conditions that must exist — but are outside the attacker’s direct control — for a vulnerability to be exploited. This metric meaningfully refines the Attack Complexity (AC) dimension, which in v3.x compressed disparate exploit conditions into a binary High/Low value. Under v4.0, vulnerabilities that require a specific non-default configuration to be exploitable receive a higher AT value and consequently a lower Base Score — a more accurate representation of real-world risk.

For medical devices, where clinical deployment environments vary significantly across healthcare delivery organizations (HDOs), this metric provides a more defensible and contextually appropriate basis for risk rating and remediation prioritization.

3. Separated Impact Metrics: Vulnerable System and Subsequent System

The Scope metric of CVSS v3.x — which offered a binary changed/unchanged toggle — has been replaced with a clearer distinction between:

  • Vulnerable System impact — Confidentiality, Integrity, and Availability of the primary component
  • Subsequent System impact — effects on downstream or connected systems

This bifurcation is directly relevant to networked medical devices, where a vulnerability in a device component may propagate to hospital information systems, clinical networks, or other connected devices — each carrying distinct patient safety implications.

4. Supplemental Metric Group: Safety, Automatable, and Recovery

CVSS v4.0 introduces an optional Supplemental Metric Group that does not alter the calculated score but provides critical contextual signals for risk analysts and downstream consumers. For MedTech, the most significant supplemental metrics are:

  • Safety (S: N/P) — Explicitly flags whether exploitation could result in physical harm to individuals. A value of S:P (Present) indicates that the vulnerability could directly or indirectly cause patient injury — a dimension entirely absent from CVSS v3.x and previously addressed only through the MITRE CVSS Medical Device Rubric.
  • Automatable (AU: Y/N) — Indicates whether the full exploit chain can be automated at scale without per-target human interaction — a critical signal for high-volume attack scenarios in hospital settings.
  • Recovery (R) — Describes the degree to which the system can recover autonomously after exploitation, relevant to devices supporting life-critical functions.

These supplemental metrics, while informational rather than score-modifying, directly support the FDA’s expectation that manufacturers assess patient safety impact in connection with cybersecurity risk. Importantly, the Supplemental Safety metric does not replace or substitute for the safety risk analysis required under ISO 14971 and AAMI TIR57; it is a structured signal to flag vulnerabilities warranting that deeper analysis.

5. Threat Metric Group Replaces Temporal Metrics

The Temporal Metric Group of CVSS v3.x has been renamed and restructured as the Threat Metric Group in v4.0, with Exploit Maturity as its primary component. This group captures real-world exploitation evidence — whether a vulnerability has been seen actively exploited, has proof-of-concept code published, or remains unconfirmed. CISA’s Known Exploited Vulnerabilities (KEV) catalog serves as one key input for assessing exploit maturity, strengthening the connection between CVSS scoring and actionable postmarket surveillance intelligence.

6. Not Backward-Compatible

A critical operational constraint is that CVSS v4.0 scores are not mathematically comparable to CVSS v3.x scores for the same vulnerability. The same CVE scored under both versions may yield substantially different numerical values due to the restructured formulas and new metrics. Manufacturers should establish a clear strategy for rescoring active vulnerabilities and any vulnerabilities included in regulatory documentation — there is no direct conversion path from v3.x to v4.0.

Comparison: CVSS v3.1 vs. CVSS v4.0

AttributeCVSS v3.1CVSS v4.0
Standard released2019 (FIRST)November 2023 (FIRST)
FDA recognitionRec. No. 13-142Rec. No. 13-140, entered May 25, 2026
FDA acceptance deadlineJuly 2, 2028 (sunset)Effective from recognition date
Metric groupsBase, Temporal, EnvironmentalBase, Threat, Environmental, Supplemental
Attack complexityAC: High / Low (binary)AC + new Attack Requirements (AT)
Scope / impactScope: Changed / UnchangedVulnerable System + Subsequent System
Patient safety signalNot included (requires MITRE Rubric)Supplemental Safety metric (S:N / S:P)
Exploit intelligenceTemporal: Exploit Code MaturityThreat: Exploit Maturity (aligned to KEV)
Backward compatibilityCompatible with CVSS v3.0Not backward-compatible with v3.x
Score range0.0 – 10.00.0 – 10.0 (different formula)

Why This Transition Is Critical for Medical Device Manufacturers

The CVSS v4.0 transition is not a routine standards update that can be addressed through a one-line revision to a procedure document. It has cascading implications across the device lifecycle and the quality management system (QMS). While July 2028 leaves a reasonable runway, manufacturers who defer action until the deadline approaches will face compressed timelines with significant operational consequences.

Premarket Submission Impact

Under the FDA’s February 2026 premarket guidance, the Security Risk Management Report is expected to clearly define the methodology used for scoring cybersecurity risk pre- and post-mitigation. Submissions citing CVSS v3.1 after July 2, 2028 will reference a superseded standard, and FDA reviewers may request clarification or additional justification. Manufacturers should aim to have their CVSS v4.0 scoring framework operational well ahead of that date, allowing adequate time for risk assessment documentation and internal review across their submission pipeline.

Postmarket Surveillance and Vulnerability Management

Manufacturers maintaining active postmarket vulnerability management programs — as expected under FDA’s postmarket cybersecurity guidance, QSR/QMSR obligations, and correction and removal regulations (21 CFR Parts 806 and 803) — will need to update their internal processes to score newly identified vulnerabilities under CVSS v4.0.

Note: Section 524B of the FD&C Act primarily addresses premarket cyber devices; postmarket obligations derive from FDA’s postmarket guidance, QMS requirements, and MDR regulations.

This includes:

  • Updating PSIRT (Product Security Incident Response Team) intake and triage procedures
  • Revising the scoring methodology section of the Cybersecurity Management Plan (CMP)
  • Re-evaluating whether existing open vulnerabilities — including those in active remediation queues — require re-scoring under v4.0 to maintain accurate risk rankings
  • Aligning CVSS Threat metrics with CISA KEV catalog monitoring to ensure exploit maturity signals are captured systematically

SBOM and Component Vulnerability Tracking

FDA expects cyber device submissions to include a machine-readable SBOM meeting the expectations set out in the February 2026 premarket guidance. These SBOMs feed directly into ongoing vulnerability monitoring workflows. Third-party vulnerability intelligence feeds (NVD, CISA Vulnrichment, Health-ISAC advisories) are progressively adopting CVSS v4.0 scoring. Manufacturers whose SBOM-based monitoring pipelines are calibrated to v3.x thresholds — for example, triggering escalation at CVSS v3.x ≥7.0 — should recalibrate those thresholds under v4.0, as the same vulnerability can yield a materially different numerical score.

QMS Documentation and Controlled Procedures

Standard Operating Procedures (SOPs) governing cybersecurity risk assessment, vulnerability triage, and MDR-reportability decisions will require formal revision through the change control process under 21 CFR Part 820 / ISO 13485. Affected documentation typically includes the cybersecurity risk management procedure, the PSIRT charter, the Cybersecurity Management Plan, and any device-specific risk management files (DHF) that reference CVSS v3.x as the scoring methodology.

CVD and Disclosure Communications

Coordinated Vulnerability Disclosure (CVD) processes — including vulnerability advisories published to the public, HDO customers, and submitted to ICS-CERT / CISA — must reflect the version of CVSS used for scoring. Transitioning to CVSS v4.0 mid-program without a clear communication strategy can create confusion among downstream consumers and may require re-publication of previously issued advisories for high-severity vulnerabilities.

⏱ RISK SIGNAL Manufacturers who wait until close to the July 2028 deadline to begin their CVSS v4.0 transition will face a compressed implementation window. Scoring framework updates, SOP revisions, and staff training require time that QMS change control and submission preparation timelines cannot easily compress.

How CVSS v4.0 Enhances Vulnerability Risk Assessment in MedTech

Beyond regulatory compliance, CVSS v4.0 represents a genuine improvement in the quality of risk intelligence available to medical device manufacturers. Organizations that approach this transition strategically can derive meaningful operational benefits.

More Accurate Prioritization for Constrained Remediation Resources

CVSS v3.x had a well-documented tendency to produce high Base Scores for vulnerabilities that, in practice, were difficult or unlikely to exploit. The introduction of the Attack Requirements (AT) metric and the more granular Subsequent System impact metrics enable manufacturers to more accurately differentiate between vulnerabilities that pose genuine patient risk and those whose Base Score overstates exploitability in the clinical context. This supports more defensible, risk-prioritized remediation decisions — aligning with the FDA’s preference for exploitability-based risk assessment.

Native Safety Signal for Patient Harm Assessment

The Supplemental Safety metric (S:P) provides a built-in flag for vulnerabilities with potential physical safety consequences. While this metric does not replace the safety hazard analysis required under ISO 14971 and AAMI TIR57, it serves as a structured first-pass filter — enabling PSIRT teams to route safety-relevant vulnerabilities to the appropriate cross-functional review process earlier in the triage workflow.

Better Alignment with Threat Intelligence Ecosystems

The Threat Metric Group’s Exploit Maturity dimension maps naturally to intelligence signals from CISA’s KEV catalog — one key input for exploit maturity assessment — Health-ISAC threat advisories, and commercial vulnerability intelligence feeds. This alignment supports the structured, evidence-based escalation framework described in HSCC’s Joint Security Plan v2 (JSP2), where exploitation status is a primary determinant of remediation urgency alongside patient safety impact.

Support for Multi-System Architecture Analysis

The Subsequent System impact metrics directly address the multi-system architecture that characterizes modern connected medical devices — where a vulnerability in a device component may affect hospital networks, cloud-connected backends, or companion apps. This supports the architectural documentation FDA expects in premarket submissions under the February 2026 guidance, including perspectives covering Global System View, Multi-Patient Harm, Updateability/Patchability, and Security Use Cases.

Worked Example: CVSS v3.1 vs. v4.0 for a Connected Infusion Pump

To illustrate the practical scoring difference, consider a hypothetical network-exploitable command injection vulnerability in the wireless update interface of a connected infusion pump. Successful exploitation could allow an unauthenticated remote attacker to modify drug delivery parameters — a scenario with direct patient safety implications.

CVSS v3.1 Vector

Vector: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Base Score: 10.0 (Critical)
  • Attack Vector: Network (AV:N) — exploitable remotely
  • Attack Complexity: Low (AC:L) — no special conditions required
  • Privileges Required / User Interaction: None
  • Scope: Changed (S:C) — exploiting the device could affect the broader hospital network
  • Impact: Critical across Confidentiality, Integrity, and Availability

Under CVSS v3.1, this vulnerability scores Critical (10.0). However, the vector does not capture that the wireless update interface is disabled by default in standard hospital configurations, and exploitation requires the interface to be administratively enabled — a deployment condition outside the attacker’s control. Nor does it surface the patient safety dimension directly.

CVSS v4.0 Vector

Vector: AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/S:P/AU:N
Base Score: 9.3 (Critical)
  • Attack Requirements: Present (AT:P) — the wireless update interface must be enabled, a non-default condition. This appropriately reduces the score compared to v3.1, reflecting the real-world deployment constraint.
  • Vulnerable System Impact (VC/VI/VA): High across all three — the infusion pump itself is fully compromised
  • Subsequent System Impact (SC/SI/SA): High — drug delivery parameter tampering could affect clinical workflows and connected systems
  • Supplemental Safety: Present (S:P) — exploitation could directly cause patient harm through incorrect drug delivery. This flag routes the vulnerability to the safety risk assessment process under ISO 14971.
  • Automatable: No (AU:N) — exploitation requires target-specific knowledge of the device configuration

Key Takeaways

The CVSS v4.0 score (9.3) is marginally lower than the v3.1 score (10.0) because Attack Requirements more accurately captures the non-default enablement condition. More significantly, CVSS v4.0 surfaces the patient safety dimension (S:P) natively and provides downstream system impact detail that better supports the manufacturer’s Security Risk Management Report and cross-functional safety review. The Safety metric here serves as a triage flag — it does not replace the ISO 14971 hazard analysis, but it ensures the vulnerability reaches that analysis promptly.

💡 KEY INSIGHT The v4.0 Attack Requirements metric prevents the scoring inflation that occurs in v3.1 when deployment-specific prerequisites exist. For medical devices — where clinical configurations vary significantly across HDOs — this yields more defensible risk prioritization.

How Aktriva Supports Manufacturers Through This Transition

Aktriva works exclusively with MedTech manufacturers to navigate the intersection of FDA cybersecurity regulation, product security operations, and quality management. We help clients assess their current CVSS posture, update scoring frameworks and QMS documentation, and prepare premarket submissions that hold up under FDA review — ahead of the July 2028 deadline.

Contact Aktriva to schedule a CVSS v4.0 Transition Readiness Assessment.

Conclusion

CVSS v4.0 is more than a compliance checkbox — the added Attack Requirements and Supplemental Safety metrics genuinely improve how manufacturers prioritize and document vulnerability risk. Manufacturers who begin the transition early will be better positioned than those who wait until the July 2028 deadline approaches.

Authoritative References

#Reference
[1]FDA Recognized Consensus Standards — CVSS v4.0. FDA Recognized Consensus Standards Database, Recognition No. 13-140, entered May 25, 2026. https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfStandards/detail.cfm?standard__identification_no=46410
[2]FDA Premarket Cybersecurity Guidance (2026). Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. FDA Final Guidance, February 3, 2026. https://www.fda.gov/media/119933/download
[3]FDA Cybersecurity — Digital Health Center of Excellence. FDA Medical Device Cybersecurity Landing Page. https://www.fda.gov/medical-devices/digital-health-center-excellence/cybersecurity
[4]FDA Recognized Consensus Standards Database. FDA CDRH — Search Recognized Consensus Standards. https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfstandards/search.cfm
[5]CVSS v4.0 Specification Document. Common Vulnerability Scoring System v4.0 Specification. FIRST, November 2023. https://www.first.org/cvss/specification-document
[6]CVSS v4.0 User Guide. FIRST, November 2023. https://www.first.org/cvss/user-guide
[7]MITRE Rubric for Applying CVSS to Medical Devices. MITRE Corporation (under FDA contract). FDA-qualified Medical Device Development Tool (MDDT), October 2020. https://www.mitre.org/sites/default/files/2021-11/pr-18-2208-rubric-for-applying-cvss-to-medical-devices.pdf
[8]HSCC Joint Security Plan v2 (JSP2). Medical Device and Health IT Joint Security Plan, Version 2.0. Health Sector Coordinating Council (HSCC), March 2024. https://healthsectorcouncil.org/wp-content/uploads/2024/03/Medical-Technology-and-Health-IT-Joint-Security-Plan-v2.pdf
[9]Section 524B of the FD&C Act. Ensuring Cybersecurity of Devices — added by the Consolidated Appropriations Act, 2023. 21 U.S.C. § 360n-2. https://www.congress.gov/117/bills/hr2617/BILLS-117hr2617enr.pdf
[10]AAMI TIR57. Principles for medical device security — Risk management. AAMI Technical Information Report TIR57:2016 (R2019). https://webstore.ansi.org/standards/aami/aamitir572016r2019
[11]NIST SP 800-40 Rev. 4. Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology. NIST, April 2022. https://csrc.nist.gov/publications/detail/sp/800-40/rev-4/final
[12]CVSS v4.0 Examples Document. FIRST (Forum of Incident Response and Security Teams). https://www.first.org/cvss/v4-0/cvss-v40-examples.pdf

Disclaimer: This article is prepared by Aktriva LLC for informational and advisory purposes. It does not constitute legal advice. Regulatory requirements are subject to change; manufacturers should consult FDA guidance documents and the Recognized Consensus Standards Database directly for the most current requirements.