FDA Premarket Cybersecurity
FDA premarket cybersecurity evidence is broader than a penetration-test report or an SBOM upload. The current final guidance asks sponsors to show how secure development, security risk management, threat modelling, architecture, testing, labelling and post-release management fit together across the device lifecycle.
Current guidance status
FDA issued the current final premarket cybersecurity guidance in February 2026. FDA states that it supersedes the June 2025 final guidance, so local copies of the 2025 guidance should not be treated as the current source unless a legacy submission record specifically depends on that version.
This document supersedes the final guidance “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions,” issued June 27, 2025.
FDA premarket cybersecurity guidance, February 2026
The guidance is not limited to network-enabled products. FDA frames the scope around devices with cybersecurity considerations, including device software functions, firmware and programmable logic. FDA also distinguishes the broader guidance scope from the narrower statutory duties that apply to cyber devices under section 524B of the FD&C Act.
Cyber device under section 524B
Section 524B applies to a person submitting a 510(k), PMA, product development protocol, De Novo request or HDE for a cyber device. FDA's FAQ explains that these requirements became enforceable for cyber-device submissions after the transition period that ended on 1 October 2023.
Software controlled by the sponsor
The device includes software that is validated, installed or authorised by the sponsor as a device or in a device. FDA treats firmware and programmable logic as software for this analysis.
Internet connection capability
The device has the ability to connect to the internet. FDA reads this broadly and includes direct and indirect connection paths, including wireless, wired, cloud, server and peripheral routes.
Cybersecurity-threat exposure
The device contains sponsor-validated, sponsor-installed or sponsor-authorised technological characteristics that could be vulnerable to cybersecurity threats.
The statutory content is also specific. A qualifying cyber-device submission must include cybersecurity plans and processes, a process for accepting and addressing vulnerabilities, coordinated disclosure information, patching and update commitments, and an SBOM covering commercial, open-source and off-the-shelf software components.
Submission content
A coherent FDA submission shows traceability from device architecture to threat model, risk assessment, requirements, testing, labelling and postmarket management. The records should be consistent enough that FDA can see why the selected controls are adequate for the intended use and use environment.
FDA expects manufacturers to use secure product development practices under a quality system. The submission should make the process visible through planning records, requirements, architecture, implementation controls, verification, validation, anomaly handling and maintenance planning.
FDA treats security risk management as related to, but distinct from, safety risk management. A security risk can become a patient-safety issue when a threat exploits a vulnerability in a way that affects clinical performance, availability, integrity, confidentiality or safe operation.
The report should connect system threat modelling, cybersecurity risk assessment, SBOM analysis, unresolved anomalies, component-support information and verification evidence.
FDA expects threat modelling to cover the device system, its environment, interfaces, data flows, external entities, supply-chain assumptions, deployment, interoperability, update paths, maintenance and decommissioning. The security architecture should then show the controls selected to manage those threats.
FDA describes security testing as more than ordinary software verification and validation. The evidence can include security-requirements testing, boundary analysis, threat-mitigation testing, vulnerability testing, software composition analysis, static and dynamic code analysis, fuzz testing, misuse testing and penetration testing.
FDA expects the user-facing information to explain relevant security controls, configuration, update and patching expectations, logs, interfaces, ports, network assumptions, backup and recovery, support periods, decommissioning and security events. The cybersecurity management plan should describe vulnerability intake, monitoring, communication, patch timelines, CISA Known Exploited Vulnerabilities monitoring and update processes.
Common evidence
Architecture views
FDA identifies several security architecture views, including global system context, multi-patient harm, updateability and patchability, and security-use-case views. These views should explain interfaces, protocols, trust boundaries, users, assets, controls and evidence links.
SBOM
The SBOM should cover manufacturer-developed and third-party components, including purchased, licensed, open-source and upstream dependencies. For cyber devices, section 524B makes SBOM content statutory.
Known vulnerabilities
FDA expects known vulnerabilities to be identified and analysed, including vulnerabilities in third-party components and CISA Known Exploited Vulnerabilities that are relevant to the device or related systems.
Traceability
The strongest file links threat-model findings, risk controls, requirements, architecture diagrams, test results, SBOM entries, residual-risk decisions, labelling and postmarket monitoring into one defensible chain.
FDA also discusses security-control categories such as authentication, authorisation, cryptography, integrity, confidentiality, event detection and logging, resiliency, recovery, updateability and patchability. The useful question is not whether each label appears in a checklist, but whether the selected controls fit the device and its environment.
Not only section 524B
Section 524B is important, but it is not the whole premarket cybersecurity framework. FDA guidance can still be relevant for devices outside the statutory cyber-device definition, for investigational and biologics-linked submissions, and for devices that do not connect to the internet but still contain software, update mechanisms, removable media, local ports or operational environments that create cybersecurity considerations.
- Do not treat the 524B cyber-device definition as a reason to ignore security risk management for other software devices.
- Do not treat an SBOM as a replacement for architecture, threat modelling, security testing or labelling evidence.
- Do not import FDA submission content into an EU file without translating it into MDR technical-documentation terms.
- Do not rely on the superseded 2025 FDA premarket guidance as the current source after the February 2026 final guidance.