On this page
Published:
Key Takeaways
- The February 3, 2026 FDA guidance does not mention VEX or require any of its four statuses.
- VEX can communicate vulnerability assessment results but cannot replace the underlying security risk assessment and test evidence.
- Not affected needs a product-specific explanation; fixed applies only to versions containing the fix.
- Affected and under investigation are not manufacturer risk acceptance decisions.
- Section 524B obligations and CISA VEX statement requirements have different legal and technical roles.
How do the four VEX statuses map to FDA cybersecurity guidance?
The four VEX statuses map to vulnerability assessment, risk management, security testing, and lifecycle evidence recommended in the FDA's February 3, 2026 premarket cybersecurity guidance. They are not four FDA-required dispositions. The guidance does not mention VEX. Use this crosswalk to connect optional status statements to device-specific evidence, not to claim that a VEX label satisfies a regulatory requirement.
The guidance's full title is Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. This page maps assessment results to that guidance; the VEX document guide explains statement formats and authoring.
Read the legal and technical layers separately
Section 524B of the FD&C Act is a binding statute for covered cyber devices and marketing submissions. The FDA premarket cybersecurity guidance is nonbinding, but is the operative interpretation the FDA applies when reviewing a submission against Section 524B. Its scope also includes devices with cybersecurity considerations beyond that statutory subset.
CISA's VEX minimum requirements describe a communication specification. A MUST in that specification is not an FDA statutory duty. Neither Section 524B nor the February 3, 2026 guidance requires a VEX document, a VEX status, or an FDA-specific VEX format. Section 524B(b)(4) authorizes additional requirements through regulation; this guidance is not that rulemaking.
Four-status evidence crosswalk
The evidence below is a practical implementation mapping, not a quotation of FDA-required VEX fields. Identify the exact device version and configuration in every row. All statuses remain subject to manufacturer review and the broader security risk assessment.
| VEX status | What the statement means | Connection to FDA guidance | Supporting evidence and manufacturer decision |
|---|---|---|---|
not_affected | The identified product is not affected by the vulnerability | V.A.2, Cybersecurity Risk Assessment; V.A.4(b), Documentation Supporting SBOM. Explain why the finding does not apply to this product rather than silently removing it from the assessment | Product/build identification, component inventory, applicable justification or impact statement, and evidence such as build records, code reachability analysis, or control tests. Manufacturer reviews the conclusion and its assumptions |
affected | The vulnerability affects the identified product | V.A.2; V.A.4(b); V.C, Cybersecurity Testing. Assess exploitability and security risk, connect device/system impacts to safety where relevant, and document controls, remediation, and control-effectiveness tests | Vulnerability analysis, threat/safety links where applicable, control and test references, and an action statement. Manufacturer determines remediation, interim controls, residual risk, and any reporting or communication duties separately |
fixed | The identified product version contains the fix | V.C; V.A.6, TPLC Security Risk Management; VI.B, Cybersecurity Management Plans; VII.C.1. Demonstrate remediation and security control effectiveness, with consistent inventory, risk records, and update information | Fixed device/software version, change record, updated component inventory or SBOM, and security test results. Manufacturer confirms which released versions contain the fix; older vulnerable versions remain separately assessed |
under_investigation | It is not yet known whether the product is affected | V.A.2; V.A.6; VI.B; VII.C.1. Keep the vulnerability visible in the assessment, explain uncertainty and outstanding work, and connect investigation to vulnerability management rather than treating an unresolved finding as safe. V.A.5 also applies where an unresolved software anomaly has security implications; not every investigation is such an anomaly | Known facts, affected-version candidates, missing evidence, investigation owner, and next review trigger. Manufacturer evaluates interim precautions and submission readiness without inventing a final disposition |
Section references above use the February 3, 2026 document. V.A.2 begins on printed page 13; V.A.4 covers pages 15-17; V.A.5 and V.A.6 begin on page 18; V.C begins on page 25; VI.B begins on page 30; and VII.C.1 covers pages 32-33. These are the page numbers printed in the guidance, not the PDF viewer's sheet counter.
V.A.4(b) recommends assessing all known vulnerabilities, including CISA Known Exploited Vulnerabilities (KEV) Catalog entries, and documenting discovery methods, safety/security risks, and controls. V.A.2 says KEV vulnerabilities should be designed out of the device. Do not reinterpret that recommendation as permission to leave a KEV vulnerability in place solely because its CVSS score is low or a VEX statement exists.
What each status needs in the VEX statement
These are CISA status-specific minimums, not the complete document schema and not a list of FDA requirements.
| Status | CISA statement rule | What the rule does not establish |
|---|---|---|
not_affected | A justification SHOULD be given. If none is given, an impact statement MUST explain why the product is not affected | A scanner's absence of findings does not prove nonapplicability. A status is not a general safety determination |
affected | An action statement MUST be provided | The statement does not itself approve residual risk or decide regulatory reportability |
fixed | No additional status-specific statement is mandated by the minimum requirements | An upstream patch release does not prove that the deployed device version contains the fix |
under_investigation | No additional status-specific statement is mandated by the minimum requirements | An unresolved finding is not a not-affected conclusion or a promise of submission acceptance |
CISA lists five not_affected justifications: component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary, and inline_mitigations_already_exist. Select one only when evidence supports its meaning. A hospital firewall or a user-configurable setting does not automatically qualify as an inline mitigation that fully prevents exploitation.
How Section 524B fits behind the assessment
The same statutory duties apply regardless of the status label. For a covered cyber device:
| Statutory anchor | Actual duty | How VEX can help, without replacing it |
|---|---|---|
| Section 524B(b)(1); guidance VII.C.1 | Submit a plan to monitor, identify, and address postmarket vulnerabilities and exploits in a reasonable time, including coordinated vulnerability disclosure and related procedures | Versioned statements can communicate changing assessments and link to the monitoring and disclosure records |
| Section 524B(b)(2); guidance VII.C.1-2 | Design, develop, and maintain processes and procedures providing reasonable assurance that the device and related systems are cybersecure, and make postmarket updates and patches available as specified in the statute | An affected-to-fixed history can reference remediation and released updates; it does not replace the processes, patch availability, or evidence |
| Section 524B(b)(3); guidance VII.C.3 | Provide an SBOM including commercial, open-source, and off-the-shelf software components | Product and component identifiers can connect vulnerability statements to the inventory; VEX is not an SBOM |
Section 524B(b)(2) distinguishes regular-cycle updates for known unacceptable vulnerabilities from updates as soon as possible out of cycle for critical vulnerabilities that could cause uncontrolled risks. A VEX status alone does not determine either category. Do not turn internal investigation targets into universal FDA deadlines.
Worked example: one finding across device versions
This is fictional, not a client case or an accepted submission. A connected patient monitor uses a library with a disclosed vulnerability. Engineering first needs to confirm whether its affected function is present and reachable in each released build.
| Product scope | Assessment record | VEX communication | Evidence that stays in the controlled file |
|---|---|---|---|
| Version 2.0, applicability still unknown | Manufacturer opens investigation; exposure and clinical consequences remain under assessment | under_investigation | Investigation ticket, build inventory, unknowns, owner, and interim-control decision |
| Version 2.0, vulnerable path confirmed | Manufacturer documents the affected configuration and decides the response | affected, with an action statement | Exploitability analysis, security risk assessment, safety links where relevant, remediation plan, and control evidence |
| Version 2.1, fix incorporated and tested | Manufacturer confirms the fix is in this released version | fixed for 2.1, not retroactively for 2.0 | Change record, versioned SBOM, fix verification, security test results, and deployment instructions |
| Separate version 1.5, vulnerable function absent | Manufacturer confirms that this build excludes the vulnerable code | not_affected, with vulnerable_code_not_present justification | Reproducible build/configuration evidence and analysis identifying the excluded code |
These are different version-scoped statements, not a mandatory four-step lifecycle. Newly discovered evidence can change an earlier conclusion. A fixed release does not mean every installed device has received it.
Build a reviewable evidence chain
- Identify the vulnerability/advisory and exact product versions, builds, components, and configurations.
- Link the finding to the software inventory and document applicability analysis, including known exploited vulnerabilities where relevant.
- Record exploitability, device effects, and safety consequences where relevant in the security risk assessment. CVSS alone is not a clinical risk assessment.
- Connect controls, security requirements, and test results to the finding. Keep uncertainty and test limitations visible.
- Have the manufacturer review the status and separately approve its risk and response decisions.
- If VEX is used, issue a schema-valid statement with its author, identifiers, timestamp, status, and required accompanying statement. Retain revision history.
- Reassess when product composition, exposure, vulnerability knowledge, fix deployment, or mitigation effectiveness changes. Connect postmarket response to disclosure, communication, and applicable reporting procedures.
Record artifact IDs, revisions, controlled locations, approvers, and open gaps. A useful crosswalk lets a reviewer follow the conclusion to evidence without exposing confidential vulnerability details in public labeling.
VI.A, Labeling Recommendations for Devices with Cybersecurity Risks, covers information users may need about security, updates, and responses to vulnerabilities or incidents. If VEX is shared with customers, keep its product scope and advice consistent with controlled labeling and communications. A public VEX file does not replace device-specific labeling.
Common mapping errors
- Calling VEX a required February 2026 deliverable or assuming a particular VEX format is FDA-approved.
- Marking an affected product
not_affectedmerely because the manufacturer accepts its residual risk. - Marking a deployed product
fixedbecause a supplier has published a patch that is not yet integrated. - Treating
under_investigationas adequate closure of an unresolved submission question. - Equating low CVSS severity with low device or patient risk, or ignoring known exploited vulnerabilities.
- Applying one status to all product versions without checking build and configuration differences.
Frequently asked questions
Does the FDA require these four VEX statuses?
No. They are CISA VEX status terms. The February 3, 2026 guidance does not mention VEX; it recommends the underlying vulnerability, risk, control, and testing evidence. This page maps optional communication to that evidence, not to an invented VEX mandate.
Can an affected vulnerability be accepted rather than fixed?
An affected statement describes applicability, not a risk decision. The manufacturer must assess risk, controls, statutory patch duties where applicable, and regulatory consequences. Accepting residual risk does not change applicability to not_affected, and this page does not approve risk acceptance for any device.
Can I submit a device with under-investigation statements?
The label alone cannot answer submission readiness. Explain open questions, risk implications, evidence, and planned work. The FDA assesses the actual submission; an unresolved status neither guarantees refusal nor assures acceptance.
Does the VEX worksheet produce submission-ready VEX?
The VEX assessment worksheet records an evidence-backed assessment and produces a printable worksheet. It is not a machine-readable VEX export or a substitute for manufacturer review.
Related VEX and FDA resources
- VEX document guide
- VEX resource collection
- VEX mistakes and FDA deficiencies
- SBOM vs VEX
- February 2026 FDA cybersecurity guidance
- SBOM vulnerability management
- Coordinated vulnerability disclosure
How Blue Goat Cyber helps
We connect component inventories, threat models, vulnerability assessments, security test evidence, and documented response decisions. The manufacturer retains approval of product-specific VEX conclusions, risk decisions, and regulatory actions. Explore postmarket SBOM and VEX monitoring or FDA premarket cybersecurity support.
Sources and primary references
- FDA: Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, February 3, 2026
- 21 U.S.C. 360n-2: FD&C Act Section 524B
- CISA: Minimum Requirements for Vulnerability Exploitability eXchange, April 2023
- CISA: VEX Status Justifications
- CISA: When to Issue VEX Information, November 2023
Sources & references
Primary sources cited in this article. Links open in a new tab.
- FDA: Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, February 3, 2026- U.S. FDA
- CISA: Minimum Requirements for Vulnerability Exploitability eXchange, April 2023- CISA
- CISA: VEX Status Justifications- CISA
- CISA: When to Issue VEX Information, November 2023- CISA
