Medical-device cybersecurity: FDA evidence for 2026
Updated 24 September 2026
Source-checked: 24 September 2026.
Build cybersecurity evidence alongside the device, not as a document-gathering exercise at the end. A useful evidence pack explains the system boundary, the security risks considered, the controls selected and how the team checked that those controls work. It must also stay connected to the configuration being submitted.
Scope: US Food and Drug Administration (FDA) premarket submissions. The FDA issued its revised medical-device cybersecurity guidance on 3 February 2026, superseding the June 2025 version. The document contains nonbinding recommendations; statutory duties for qualifying cyber devices arise separately under section 524B of the Federal Food, Drug, and Cosmetic Act. Confirm the applicable pathway and device-specific obligations with the regulatory lead.
Confirm the scope before choosing documents
The FDA’s cybersecurity FAQs explain the statutory cyber-device definition using three elements: sponsor-validated, installed or authorised software; the ability to connect to the internet; and relevant technological characteristics that could be vulnerable to cybersecurity threats. Do not decide applicability merely by checking whether a product has a Wi-Fi logo.
The FAQs also identify requirements involving postmarket vulnerability handling, processes supporting cybersecurity and updates, and a software bill of materials for qualifying cyber-device submissions. Map those obligations separately from the guidance recommendations. Keep the responsible manufacturer and submission owner visible in the plan; an engineering supplier’s deliverable is only part of the overall submission.
Draw the real system boundary
Start with an architecture view that includes the device and the connected systems on which its intended operation depends. Add service interfaces, update paths, mobile applications and remote services where applicable. Identify which interfaces are used in manufacture, clinical operation and servicing. A hidden debug connection still deserves an engineering decision even if it is not part of the normal user interface.
For each boundary, record the asset being protected, who is allowed to cross it and how that permission is enforced. Turn vague statements such as “communications are secure” into questions that can be checked: which endpoint is authenticated, how are credentials provisioned, and what happens when a certificate or credential is no longer acceptable?
Make traceability useful to the reviewer
The February 2026 guidance recommends traceability connecting threat modelling, risk assessment, the software inventory and testing evidence. Use that as a reason to keep one coherent chain rather than several disconnected spreadsheets. The detailed recommendations are in Section V of the FDA guidance.
An illustrative evidence row could contain: an unauthorised update threat; a requirement to reject unauthorised images; the implementation responsible for that decision; a defined negative test; the observed result; and a link to any residual-risk decision. This is an organisational example, not a complete test strategy or a statement that a particular control is sufficient for every device.
Make results reproducible. Identify the hardware revision, firmware image, relevant configuration and test environment. If a security feature depends on an external service, capture the service configuration needed to interpret the result. Record failed tests and their disposition instead of presenting only the final successful run.
Keep the software inventory connected to maintenance
An SBOM, or software bill of materials, should be more than a file attached to a release. Establish how an incoming component advisory reaches the responsible engineer and how that engineer identifies affected device versions. Record a supplier contact and the planned response when a dependency loses support. Test that handover with a controlled example before relying on it in a real incident.
Do not treat a vulnerability identifier as a complete device-risk assessment. Document the relevant exposure, product configuration and risk-control reasoning. Keep engineering findings and regulatory decisions distinguishable so each can be reviewed by the appropriate person without losing their connection.
Integrate the pack with the quality system
The FDA’s Quality Management System Regulation became effective on 2 February 2026 and incorporates ISO 13485:2016 by reference. That context matters when organising design and change records. It does not mean that holding an ISO certificate, completing this checklist or passing a security test grants FDA market authorisation.
Evidence-readiness checklist
- The US submission pathway and applicability assessment have a named owner.
- The system boundary includes relevant connected and service components.
- Risks, requirements, implementations and tests can be followed through one evidence chain.
- The software inventory matches the configuration being submitted.
- Results identify the tested image, hardware and relevant environment.
- Unresolved findings have documented decisions and responsible owners.
- Postmarket vulnerability handling and update responsibilities are assigned.
- The regulatory lead has reviewed the pack against the current product-specific requirements.
DVAR can support the underlying embedded software engineering and product development work. Discuss the intended device, interfaces and evidence responsibilities early; this guide is not a claim of FDA approval, certification or a complete regulatory submission service.