The FDA's finalisation of the Cybersecurity in Medical Devices guidance in September 2023 marked the most significant change to medical device regulatory requirements in a decade. For the first time, cybersecurity documentation is a mandatory element of every premarket submission — not an optional supplement, not a best practice, but a required component of 510(k), De Novo, and PMA submissions. Devices submitted without compliant cybersecurity documentation will receive a refuse-to-accept notification from FDA.
The guidance applies to cyber devices — any device that contains software, is intended to connect to the internet or another device, and contains a technological characteristic that could be susceptible to cybersecurity threats. This definition covers the vast majority of modern networked medical devices. Understanding what the guidance requires in engineering terms is now a foundational competency for any medical device development programme.
Premarket Submission Requirements: What Must Be in the Technical File
The 2023 guidance specifies the cybersecurity documentation required in premarket submissions. The submission must include: a Software Bill of Materials listing all commercial, open-source, and off-the-shelf software components including version numbers; a cybersecurity risk assessment identifying threats, vulnerabilities, and residual risks; a description of the security architecture including network interfaces, data flows, and security controls; evidence of security testing including penetration testing and SAST/DAST results; and a cybersecurity management plan describing the processes for monitoring, identifying, and remediating vulnerabilities post-market.
The Software Bill of Materials requirement is the most operationally demanding new element. An SBOM must enumerate every software component in the device — including deeply nested open-source dependencies — in a machine-readable format (SPDX or CycloneDX). Generating an accurate SBOM requires integration with the software development build pipeline; manually constructed SBOMs consistently miss transitive dependencies and are rejected by FDA reviewers.
Security Architecture Documentation
The security architecture documentation must describe the device's network interfaces and protocols, authentication mechanisms, encryption implementations, access control design, audit logging capabilities, and update mechanisms. FDA evaluates this documentation against the NIST Cybersecurity Framework and the Medical Device and Health IT Joint Security Plan published by the Healthcare and Public Health Sector Coordinating Council.
Encryption in transit using TLS 1.2 or higher is effectively mandatory for networked medical devices. Encryption at rest for stored patient data is expected for Class II and Class III devices. The use of deprecated cipher suites or deprecated protocol versions in a submission will generate deficiency questions from FDA reviewers. Authentication for remote access must implement multi-factor authentication for administrative access, with documented justification for any deviation based on patient safety trade-offs.
Postmarket Cybersecurity Programme Requirements
The 2023 guidance establishes that manufacturers must have a postmarket cybersecurity management programme in place as a condition of continuing to market the device. This programme must include: continuous monitoring of threat intelligence sources for vulnerabilities in SBOM components; a Coordinated Vulnerability Disclosure policy and process; a process for assessing the severity of identified vulnerabilities and determining whether patient notification or recall is required; and a patch deployment capability that can reach devices in the field.
The CVSS severity framework is the expected tool for vulnerability severity assessment. FDA guidance establishes that Critical severity vulnerabilities (CVSS 9.0–10.0) require expedited response — typically within 30 days — and may require a 522 postmarket study order or recall depending on the device's risk profile. Manufacturers must document their vulnerability triage and remediation processes in a manner that FDA can examine during inspection.
The Software Bill of Materials: Operational Implementation
Maintaining a continuously accurate SBOM throughout the device lifecycle is both an FDA expectation and a practical prerequisite for vulnerability monitoring. When a CVE is published for an open-source component, the manufacturer must be able to query their SBOM database to determine which device versions are affected and the deployment count of affected versions. Manual SBOM maintenance cannot support this operational need.
SBOM tooling integrated with the build pipeline generates SBOMs automatically at each build, enabling version-accurate SBOMs for every device firmware release. The SBOM database must be queryable by CVE identifier and must support comparison between SBOM versions to identify component changes between firmware releases.
Penetration Testing Expectations
FDA expects premarket submissions to include results of penetration testing conducted by qualified parties. For Class II devices, internal penetration testing conducted by a team independent of the development organisation is generally acceptable. For Class III devices or devices with broad network connectivity, FDA may expect third-party penetration testing by a qualified security firm. The penetration testing scope must cover the device, its network interfaces, the backend cloud infrastructure, and the communication protocols between them.
The Algorithm Approach: Medical Device Cybersecurity Engineering
The Algorithm implements cybersecurity engineering for medical device programmes using automated SBOM generation integrated with the development build pipeline, security architecture design aligned to FDA guidance and the Medical Device JSP, and penetration testing programmes scoped to the specific device risk profile. We prepare cybersecurity documentation packages for premarket submission that meet FDA's 2023 guidance requirements and design postmarket vulnerability monitoring programmes that satisfy FDA's ongoing surveillance expectations.
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.