FDA premarket cybersecurity guidance, mapped clause by clause

Section IV.A.1

Quality management system inclusive of cybersecurity

FDA guidance: Device manufacturers must establish and follow quality management systems to help ensure that their products consistently meet applicable requirements and specifications. The quality management systems requirements are found in the QMSR in 21 CFR Part 820, which incorporates by reference ISO 13485.

Medcrypt solution: Medcrypt provides a template and model implementation for folding cybersecurity procedures into an existing quality management system and its design controls.

Section IV.A.1

Secure Product Development Framework

FDA expects cybersecurity to be built in through a secure product development framework (SPDF) that covers the whole product lifecycle, not added just before submission. The submission should show which SPDF processes you use and how they produced the evidence in the rest of the file.

FDA guidance: An SPDF is a set of processes that help identify and reduce the number and severity of vulnerabilities in products. An SPDF encompasses all aspects of a product's lifecycle, including design, development, release, support, and decommission.

What answers it: SPDF procedures and templates aligned with the guidance, mapped to the outputs reviewers look for.

Section IV.B

Design for Security: Authenticity, including integrity

FDA wants evidence that the device can verify that its software, data, and commands are authentic and haven't been altered. This is usually shown through cryptographic signing and verification.

FDA guidance: When reviewing premarket submissions, FDA intends to assess device cybersecurity based on a number of factors, including, but not limited to, the device's ability to provide and implement the security objectives below throughout the device architecture. Premarket submissions should include information that describes how the above security objectives are addressed by and integrated into the device design.

What answers it: cryptographic integrity and authenticity controls in the device, documented against the guidance.

Section IV.B

Design for Security: Confidentiality

The design should ensure the confidentiality of data whose disclosure could lead to patient harm, for example through unauthorized use of credentials, lack of encryption, or exposure of cryptographic keys.

What answers it: cryptographic confidentiality controls in the device, documented against the guidance.

Section IV.B

Design for Security: Secure and timely updatability and patchability

The design should support an end-to-end process to deploy software updates and patches to devices securely and in a timely way.

What answers it: cryptographic controls to ensure code authenticity and integrity, plus a documented update and patch delivery process.

Section IV.C

Transparency

Cybersecurity information necessary to integrate and maintain the device

FDA expects users to get enough information to manage the device's cybersecurity in their environment. That means the SBOM, the security features, and how vulnerabilities and updates are communicated.

FDA guidance: A lack of cybersecurity information, such as information necessary to integrate the device into the use environment, as well as information needed by users to maintain the medical device system's cybersecurity over the device lifecycle, has the potential to affect the safety and effectiveness of a device.

What answers it: customer-facing security documentation and SBOM sharing built from the same source as the submission.

Section IV.D

Submission documentation

Design and documentation are expected to scale with the cybersecurity risk

Risk analysis should reflect how and where the device is really used, including hospital networks, home use, connected systems and third-party infrastructure. Cybersecurity information included in submissions should be based on the level of cybersecurity risk.

FDA guidance: Device cybersecurity design and documentation are expected to scale with the cybersecurity risk of that device. Manufacturers should take into account the larger system in which the device may be used.

What answers it: threat model and risk assessment that capture the real deployment environment.

Section V.A

Security risk management

FDA expects a security risk management process that is separate from, but connected to, safety risk management. It should assess exploitability rather than probability, and feed its results into the safety risk file.

FDA guidance: To fully account for cybersecurity risks in medical device systems, the safety and security risks of each device should be assessed within the context of the larger system in which the device operates.

What answers it: a security risk management process and report structured the way FDA reviews it.

Section V.A.1

Threat modeling

Threat models should identify system risks and mitigations across the whole system, including interfaces and the update path. They should be detailed enough for a reviewer to trace each threat to a control and a test.

FDA guidance: As part of the risk assessment, FDA recommends threat modeling be performed throughout the design process and be inclusive of all medical device system elements.

What answers it: Medcrypt threat modeling plus expert review of the model before you file.

Section V.A.2

Cybersecurity risk assessment

The risk assessment should score each threat for exploitability and patient-harm severity, justify acceptance criteria, and show residual risk after controls.

FDA guidance: Vulnerabilities identified in CISA's Known Exploited Vulnerabilities Catalog should be designed out of the device, as they are already being exploited and expose the medical device system and users to the risk.

What answers it: risk assessment templates and scoring tied to the threat model.

Section V.A.3

Interoperability considerations

Where the device connects to other devices or systems, FDA expects the risks at those interfaces to be assessed and controlled. This includes risks the device introduces and risks it inherits.

FDA guidance: When common technology and communication protocols are used to enable interoperability (e.g., Bluetooth, Bluetooth Low Energy, network protocols), device manufacturers should assess whether added security controls beneath such communication are needed to ensure the safety and effectiveness of the device (e.g., added security controls beneath Bluetooth Low Energy to protect against risks if vulnerabilities in the Bluetooth Low Energy protocol or supporting technology are discovered).

What answers it: expert review of interface risks, which usually takes judgment rather than a tool.

Section V.A.4

Third party software components

Every third-party and open-source component is part of the device's attack surface. FDA expects you to assess and manage each component's risk across the lifecycle.

FDA guidance: As part of demonstrating compliance with design and development under Subclause 7.3 of ISO 13485, and to support supply chain risk management processes, all software, including those developed by the device manufacturer (“proprietary software”) or obtained from third parties, should be assessed for cybersecurity risk. Device manufacturers should document all software components of a device and address or otherwise mitigate risks associated with these software components.

What answers it: SBOM and vulnerability management that tracks components and their vulnerabilities continuously.

Section V.A.4.a

Software Bill of Materials (SBOM)

A machine-readable SBOM is required for cyber devices under Section 524B. It covers commercial, open-source and off-the-shelf components, along with their support level and end-of-support dates.

FDA guidance: A robust SBOM includes both the device manufacturer-developed components and third-party components, including purchased/licensed software and open-source software, and the upstream software dependencies that are required/depended upon by proprietary, purchased/licensed, and open-source software.

What answers it: SBOM generation and management kept current release to release.

Section V.A.4.b

Documentation supporting SBOM

An SBOM alone isn't enough. FDA wants the known vulnerabilities in listed components, an assessment of their impact, and justification for any left unresolved. VEX is a common way to document that.

FDA guidance: In addition to the minimum elements identified by NTIA, for each software component contained within the SBOM, manufacturers should include in the premarket submission: The software level of support provided through monitoring and maintenance from the software component manufacturer (e.g., the software is actively maintained, no longer maintained, abandoned); and The software component's end-of-support date.

What answers it: vulnerability triage with documented VEX-style justifications.

Section V.A.5

Security assessment of unresolved anomalies

Software anomalies left open at release should be assessed for security impact, not just functional impact. FDA expects a justification for each one.

FDA guidance: FDA's Premarket Software Guidance recommends that device manufacturers provide a list of software anomalies that exist in a product at the time of submission. Some anomalies discovered during development or testing may have security implications and may also be considered vulnerabilities.

What answers it: security review of the anomaly list as part of release readiness.

Section V.A.6

TPLC security risk management

Security risk management doesn't stop at clearance. FDA expects the risk file to be kept current across the total product lifecycle (TPLC) as new vulnerabilities appear, with metrics that show the process is working.

FDA guidance: At a minimum, FDA recommends tracking the following measures and metrics, or those that provide equivalent information: Percentage of identified vulnerabilities that are updated or patched (defect density); Duration from vulnerability identification to when it is updated or patched; and Duration from when an update or patch is available to complete implementation in devices deployed in the field, to the extent known.

What answers it: continuous vulnerability monitoring linked back to the risk file.

Section V.B

Security architecture

FDA expects a documented security architecture that shows how the device and its connected systems implement security controls, and where the trust boundaries are.

FDA guidance: A security architecture, like a system architecture, defines the system and all end-to-end connections into and/or out of the system.

What answers it: architecture documentation structured to the guidance.

Section V.B.1

Implementation of security controls

For each security control category in Appendix 1, the submission should show how it is implemented and how it was verified.

FDA guidance: Effective cybersecurity relies upon security being “built in” to a device, and not “bolted on” after the device is designed. FDA recommends that device manufacturers' design processes include design and development inputs for cybersecurity controls.

What answers it: a control-by-control traceability matrix from requirement to test.

Section V.B.2, Appendix 2.A to 2.B

Security architecture views

Reviewers expect specific views: global system, multi-patient harm, updatability and patchability, and security use cases. Missing views are a common source of deficiency letters.

FDA guidance: FDA recommends providing, at minimum, the following types of views in premarket submissions: Global System View; Multi-Patient Harm View; Updateability/Patchability View; and Security Use Case View(s). Documenting these views in premarket submissions should include both diagrams and explanatory text.

What answers it: view templates plus expert review against what reviewers ask for.

Section V.C

Cybersecurity testing

FDA expects evidence that the controls work. That covers security requirements testing, threat-mitigation testing, vulnerability testing (including fuzzing and scanning), and penetration testing by testers independent of the development team.

FDA guidance: While software development and cybersecurity are closely related disciplines, cybersecurity controls require testing beyond standard software verification and validation activities to demonstrate the effectiveness of the controls in a proper security context to therefore demonstrate that the device has a reasonable assurance of safety and effectiveness.

What answers it: medical device penetration testing and test evidence traced to the threat model and risk assessment.

Section VI.A

Labeling recommendations

Labeling should tell users what they need to operate the device securely: recommended controls, network requirements, how updates are delivered, and the SBOM or how to get it.

FDA guidance: FDA regulates device labeling in several ways. For example, section 502(f) of the FD&C Act requires that labeling include adequate directions for use. Under section 502(a)(1) of the FD&C Act, a medical device is deemed misbranded if its labeling is false or misleading in any particular.

What answers it: cybersecurity labeling content drafted from the submission's own documentation.

Section VI.B

Cybersecurity management plans

Section 524B requires a plan to monitor, identify and address postmarket vulnerabilities, including coordinated vulnerability disclosure and timelines for updates and patches.

FDA guidance: Recognizing that cybersecurity risks evolve as technology evolves throughout a device's TPLC, FDA recommends that manufacturers establish a plan for how they will identify and communicate to the relevant parties the vulnerabilities that are identified after releasing the device in accordance with Subclause 8.4 and Subclause 8.5 of ISO 13485, and 21 CFR Part 806, as appropriate.

What answers it: a postmarket cybersecurity management plan backed by ongoing vulnerability monitoring, including SBOM.

Section VII.D

Modifications

When you change a cleared device, FDA expects the cybersecurity impact of the change to be assessed and documented. Changes trigger updated SBOM and risk documentation even when no new submission is needed.

FDA guidance: A manufacturer required to submit an application or submission under one of the enumerated pathways for a device modification would also need to comply with the requirements in section 524B of the FD&C Act. The information we recommend that manufacturers of cyber devices provide will generally differ based on the type of change and whether such change impacts the cybersecurity of the device.

What answers it: change impact assessment tied to the SBOM and risk file.

Appendix 1.A

Authentication

The device should verify the identity of users, devices and systems before trusting them, with strength matched to the risk of each interface.

FDA guidance: There are generally two types of authentication controls—information and entities—and a properly-secured system is able to prove the existence of both. Authentication of information exists where the device and the system in which it operates are able to prove that information originated at a known and trusted source, and that the information has not been altered in transit between the original source and the point at which authenticity is verified.

What answers it: device and user authentication built on proven cryptography.

Appendix 1.B

Authorization

Access should follow least privilege principles. Each user, role or connected system gets only the access its function needs, and privileged functions are protected.

FDA guidance: For the purposes of this guidance, authorization is the right or a permission that is granted to a system entity (e.g., a device, server, or software function) to access a system resource. More specifically, as a defensive measure, an authorization scheme enforces privileges (i.e., “rights” associated with authenticated sessions, identities and/or roles).

What answers it: authorization design reviewed against the device's actual use.

Appendix 1.C

Cryptography

FDA expects industry-standard algorithms and protocols, sound key management, and a plan for algorithm changes over the device's life, including post-quantum transitions.

FDA guidance: Cryptographic algorithms and protocols are recommended to be implemented to achieve the secure by design objectives outlined in Section IV. While high-quality, standardized cryptographic algorithms and protocols are readily available, several commercial products that include cryptographic protections have been shown to have exploitable vulnerabilities due to improper configurations and/or implementations.

What answers it: cryptographic libraries and key management built for medical devices.

Appendix 1.D

Code, data, and execution integrity

The device should detect and prevent unauthorized changes to its code, data and execution state, for example through secure boot and signed software.

FDA guidance: Many cyber incidents are caused, at their root, by the violation of some form of device integrity. This includes the violation of stored code, stored and operational data, or execution state.

What answers it: integrity verification from boot through runtime.

Appendix 1.E

Confidentiality

Sensitive data, including patient data, but also credentials and keys, should be protected at rest and in transit where disclosure could cause harm.

FDA guidance: Manufacturers should ensure support for the confidentiality of any/all data whose disclosure could lead to patient harm (e.g., through the unauthorized use of otherwise valid credentials, lack of encryption). Lack of encryption to protect sensitive information and or data at rest and in transit can expose this information to misuse that can lead to patient harm.

What answers it: encryption and key protection matched to each data flow.

Appendix 1.F

Event detection and logging

The device should record security-relevant events and support detecting attacks, so incidents can be investigated and responded to.

FDA guidance: Event detection and logging are critical capabilities that should be present in a device and the larger system in which it operates in order to ensure that suspected and successful attempts to compromise a medical device may be identified and tracked. These event detection capabilities and logs should include storage capabilities, if possible, so that forensic discovery may later be performed.

What answers it: security logging requirements defined in the architecture and verified in testing.

Appendix 1.G

Resiliency and recovery

The device should keep essential performance during an attack and recover to a known-good state afterwards.

FDA guidance: Devices should be designed to be resilient to possible cyber incident scenarios (also known as “cyber-resiliency”) and maintain availability. Cyber-resiliency capabilities are important for medical devices because they provide a safety margin against unknown future vulnerabilities.

What answers it: resilience requirements traced to failure modes.

Appendix 1.H

Firmware and software updates

Devices must be updatable and patchable. Updates should be authenticated and integrity-checked, and delivered on a timely cycle, as Section 524B requires.

FDA guidance: Devices should be capable of being updated in a secure and timely manner to maintain safety and effectiveness throughout the product's lifecycle. FDA recommends that manufacturers should not only build in the ability for devices to be updated, but that manufacturers also plan for the rapid testing, evaluation, and patching of devices deployed in the field.

What answers it: signed, verified update delivery and an update cadence documented in the management plan.