This post describes key requirements for medical device manufacturers to follow when submitting their devices to US FDA for PMA or 510(k) approvals.
The United States Food and Drug Administration (FDA) provides guidance on cybersecurity in medical devices, outlining both recommended activities and documentation for premarket submissions like 510(k)s and Premarket Approval Applications (PMAs). For a specific category of devices known as “cyber devices,” certain documentation is required by statute under Section 524B of the FD&C Act, as updated in December 2022.
FDA published an updated premarket guidance in June 2025 — see our article on the June 2025 guidance update for how it compares to the 2023 version.
This guidance applies to devices with cybersecurity considerations, which includes, but is not limited to, devices with software functions, or that contain software (including firmware) or programmable logic, regardless of whether they are network-enabled or have connected capabilities. It also applies to combination products where the device constituent part presents cybersecurity considerations.
Generally, the cybersecurity design and documentation in a premarket submission are expected to scale with the cybersecurity risk of the device. The recommendations aim to help manufacturers demonstrate a reasonable assurance of safety and effectiveness, which includes adequate device cybersecurity.
Recommended documentation and activities for all devices with cybersecurity risks
The following documentation elements are recommended for all premarket submissions for devices with potential cybersecurity risks, including 510(k)s and PMAs:
- Security Risk Management Report — summarizes risk evaluation methods, residual risk conclusions, risk mitigation activities, and traceability. Includes outputs from:
- Threat model — systematically identifies potential threats, vulnerabilities, and attack pathways across the device’s architecture, including hardware, software, data flows, and network interfaces. The activity should define assets to protect, potential adversaries, their capabilities, and likely attack vectors, then map these against safeguards and mitigations, so cybersecurity risks are addressed proactively throughout the device lifecycle. Should be performed throughout the design process and cover all medical device system elements.
- Cybersecurity risk assessment — assessment of security risks and controls for residual risks, focusing on exploitability, distinct from safety risk management. Captures risks and controls identified from the threat model.
- Software Bill of Materials (SBOM) — a formal, machine-readable inventory of software components and dependencies, including proprietary, purchased/licensed, and open-source software and their upstream dependencies, including support level and end-of-support dates.
- Vulnerability assessment and software support — identification and assessment of all known vulnerabilities (including those in CISA’s Known Exploited Vulnerabilities Catalog), with a safety and security risk assessment and applicable risk controls for each.
- Security assessment of unresolved anomalies — evaluation of the security implications of any software anomalies discovered during development or testing, considering potential security impacts and Common Weakness Enumeration (CWE) categories.
- Traceability — documentation linking the threat model, risk assessment, SBOM, testing documentation, and other cybersecurity risk management documentation.
- Measures and metrics — tracking of measures such as percentage of identified vulnerabilities patched, time from identification to patching, and time from patch availability to deployment.
- Security architecture views — provide security context and trust boundaries for the device system, with diagrams and explanatory text detailed enough to understand how assets function holistically; the number and extent of views depend on the identified attack surface and risk. At minimum, FDA recommends:
- Global System View — describes the overall device system and all internal/external connections, including software update infrastructure, healthcare facility network impacts, and cloud connections.
- Multi-Patient Harm View — addresses how the device and its system defend against or respond to attacks with the potential to harm multiple patients due to connectivity.
- Updatability and Patchability View — describes the end-to-end process for securely and promptly delivering software updates and patches.
- Security Use Case View(s) — covers all device system functionality through which a security compromise could impact device safety or effectiveness.
- Implementation of security controls — documentation demonstrating that controls (authentication, authorization, cryptography, code/data/execution integrity, confidentiality, event detection/logging, resiliency/recovery, updatability/patchability) have been implemented and tested effectively.
- Cybersecurity testing documentation — demonstrates the effectiveness of design controls beyond standard software verification and validation: evidence of security requirements implementation and boundary analysis; threat mitigation testing; vulnerability testing (abuse/misuse cases, fuzz testing, attack surface analysis, vulnerability chaining, closed box testing, software composition analysis, static/dynamic code analysis); and penetration testing reports detailing tester independence and technical expertise, scope, duration, methods, and results.
- Labeling — cybersecurity information understandable to the intended user: device instructions and product specifications for recommended controls; detailed diagrams for implementing controls; a list of network ports and interfaces with data-flow direction; supporting infrastructure requirements and vulnerability-response instructions; SBOM availability in a continuously accessible, machine-readable format; systematic procedures for downloading version-identifiable updates; how the device responds to anomalous conditions, including user notification and logging; features protecting critical functionality, backup/restore procedures, and secure shipped-device configuration; how forensic evidence is captured; and end-of-support/end-of-life information.
- Cybersecurity (Vulnerability) Management Plan — a plan for identifying and communicating postmarket vulnerabilities: responsible personnel; monitoring sources and frequency (e.g. researchers, the NIST National Vulnerability Database, third-party software manufacturers); procedures for CISA KEV Catalog vulnerabilities; periodic security testing; patch timelines and update/patching capability; the coordinated vulnerability disclosure process; and how the manufacturer intends to communicate forthcoming remediations, patches, and updates to customers.
Required documentation for “cyber devices”
For “cyber devices” — defined as devices that (1) include software validated, installed, or authorized by the sponsor as a device or in a device; (2) have the ability to connect to the internet; and (3) contain technological characteristics vulnerable to cybersecurity threats — the following is required by Section 524B of the FD&C Act for 510(k), PMA, PDP, De Novo, or HDE submissions:
- Plans and procedures (§524B(b)(1)) — a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits in a reasonable time, including coordinated vulnerability disclosure, plus a timeline for patches (regular cycle for known unacceptable vulnerabilities; as soon as possible for critical vulnerabilities that could cause uncontrolled risk).
- Processes and procedures for reasonable assurance of cybersecurity (§524B(b)(2)) — documentation that the manufacturer has designed, developed, and maintained processes providing reasonable assurance that the device and related systems are cybersecure.
- Software Bill of Materials (§524B(b)(3)) — an SBOM including commercial, open-source, and off-the-shelf components.
Documentation for device modifications
If a modification to a cyber device requires a new 510(k) or PMA submission, Section 524B requirements still apply:
- Changes that may impact cybersecurity (e.g. authentication/encryption changes, new connectivity features, software update mechanism changes) require the full required and recommended documentation described above.
- Changes unlikely to impact cybersecurity (e.g. material alterations, sterilization method changes, or algorithm changes that don’t affect architecture, software structure, or connectivity) require the §524B(b)(1) plan (or a reference to the prior submission with a change summary), a description of any current critical vulnerabilities and remediation status since the last authorization, and the §524B(b)(3) SBOM.
The FDA evaluates this information as part of its determination of a device’s safety and effectiveness, considering new risks, vulnerabilities, and how the device’s design addresses them.