FDA Cybersecurity in Medical Devices Guidance

Cybersecurity is part of device safety and effectiveness

FDA's guidance applies to devices with cybersecurity risk and addresses design, labelling and recommended premarket-submission content. It treats cybersecurity as a lifecycle engineering responsibility rather than a final penetration test or a document prepared only for the regulator.

The guidance is relevant whenever compromise of a device, its software, data, interfaces or supporting environment could affect safety, effectiveness, confidentiality, integrity or availability. The depth of work should be proportionate to the device, its architecture, intended connections, threat exposure and possible consequences.

Begin with MTL-108 — Medical-device Cybersecurity for the general lifecycle framework and MTL-213 — Cybersecurity Engineers in Medical-device Development for role-specific responsibilities.

Section 524B creates specific duties for cyber devices

Section 524B of the Federal Food, Drug, and Cosmetic Act applies to a defined category of cyber devices. For relevant premarket submissions, manufacturers must provide plans and procedures for monitoring, identifying and addressing post-market cybersecurity vulnerabilities and exploits; design, develop and maintain processes and procedures to provide reasonable assurance that the device and related systems are cybersecure; and provide a software bill of materials.

The statutory definition and required submission content must be assessed for the actual product. Do not assume that a device is outside scope because it has no internet-facing user interface: indirect connections, service paths, update mechanisms, cloud dependencies and networked components may still be relevant.

MTL-320 — US FDA Medical-device Regulations — 21 CFR Overview explains how guidance, statutory requirements and regulatory controls fit together.

Use a secure product-development framework

A secure product-development framework embeds security activities into product planning, requirements, architecture, implementation, verification, release and support. It should connect engineering work with design controls, quality processes and management decisions.

The framework can use established industry practices, but it must be implemented in a way that produces device-specific evidence. A policy statement or generic software-development process is not enough.

Threat modelling complements safety risk management

Cybersecurity risk analysis should identify assets, threat actors, attack surfaces, trust boundaries, credible attack paths and the effects of compromise. Safety risk management then considers how cybersecurity events could contribute to hazardous situations and harm.

Keep the analyses connected without forcing them into one scoring system. Security risk frequently changes with attacker capability, exposure and exploit maturity, while safety analysis addresses the severity and probability of harm. Document the translation between a security event, the resulting system state and any safety consequence.

• Define protected assets and security objectives.
• Model the device, external systems, users, service tools and data flows.
• Identify threats, misuse cases and attack paths.
• Assess exploitability and possible technical or clinical impact.
• Derive security requirements and verify risk controls.
• Evaluate residual risk and the effect of security assumptions.

Use MTL-302 — ISO 14971 Risk Management for the safety framework and MTL-112 — Systems Engineering, Architecture and Interfaces for system-boundary discipline.

Architecture evidence should explain how protection works

Reviewers need more than a component diagram. Security architecture should show boundaries, interfaces, data flows, privileges, identities, trust relationships, external dependencies, update paths, cryptographic functions, logging, recovery and the allocation of controls.

Use several focused views where one diagram would become unreadable. Each security claim should be traceable to an architectural mechanism, implemented requirement and verification result. Assumptions about hospital networks, users or external platforms should be explicit and realistic.

Controls should form a defensible security design

Security controls should not introduce unacceptable usability or safety risks. For connected products, MTL-121 — Data, Connectivity and Interoperability and MTL-129 — Privacy and Data Protection by Design provide complementary design considerations.

The SBOM must support vulnerability management

A software bill of materials identifies the software components contained in the device. Its operational value depends on accurate component identity, version, provenance, relationships and linkage to released configurations.

Establish processes to generate, verify, approve and maintain the SBOM; monitor relevant sources for vulnerabilities; determine applicability; assess exploitability and impact; and connect decisions to affected devices and customers. Unknown, unsupported or end-of-life components require deliberate treatment, not omission.

An SBOM is an input to analysis. It does not establish that a device is secure, and a scanner result does not replace product-specific investigation.

Security testing should challenge the risk-control story

Combine complementary methods such as code review, static and dynamic analysis, software-composition analysis, interface testing, misuse-case testing, fuzzing, vulnerability scanning and penetration testing. Select depth and independence according to risk and architecture.

Testing should cover the production-equivalent device, relevant external components, configuration, update and recovery paths. Record tools, versions, scope, environment, assumptions, findings, remediation, retesting and residual conclusions. Explain why the coverage is sufficient rather than submitting an unexplained tool report.

Premarket evidence should tell one connected story

The submission should allow FDA to follow cybersecurity from product context through risk analysis, requirements, architecture, implementation, testing, unresolved anomalies, labelling and post-market plans.

• Define the device, connectivity and cybersecurity scope.
• Explain the secure-development process and supporting quality controls.
• Provide threat-modelling and cybersecurity-risk evidence.
• Show security architecture and control implementation.
• Provide traceability from threats and requirements to verification.
• Include the SBOM and known-vulnerability assessment.
• Explain updateability, patching, support period and end-of-support arrangements.
• Provide security-relevant labelling and customer responsibilities.

Evidence should match the submitted software and hardware configuration. Use MTL-104 — Design Controls and Technical Documentation to organise the wider evidence chain.

Release begins the operational security lifecycle

Manufacturers need defined sources, responsibilities and decision criteria for vulnerability intake, monitoring, triage, investigation, risk assessment, remediation, disclosure and regulatory evaluation. Plans should address third-party components, coordinated vulnerability disclosure, customer communication and urgent response.

Design updateability before release. An update mechanism needs authenticity, integrity, compatibility, failure recovery, configuration control and evidence that the update does not create unacceptable safety or performance risk. Support-period and end-of-support decisions should be visible to management and users.

MTL-111 — Post-market Support and MTL-127 — Configuration and Change Management explain the wider lifecycle processes.

Make cybersecurity part of product governance

Cybersecurity cannot be delegated entirely to a specialist or a penetration-test supplier. Product management defines supported use and lifecycle commitments; systems and software teams implement controls; quality ensures controlled processes and records; regulatory establishes market expectations; service and post-market teams detect field signals; and management provides resources and accepts significant residual risk.

Use common identifiers across requirements, threat models, safety analysis, tests, vulnerabilities, SBOM records and released configurations. This makes the evidence reviewable and makes post-market decisions faster when a new vulnerability appears.

Common misconceptions

Practical readiness checklist

• Is the device's section 524B status documented?
• Are security roles, plans and lifecycle deliverables defined?
• Does threat modelling cover the full system and realistic environment?
• Are security and safety risk analyses explicitly connected?
• Can every important control be traced through architecture, implementation and test?
• Does the SBOM identify the released configuration and support monitoring?
• Have known vulnerabilities and unresolved anomalies been assessed?
• Can updates be delivered securely and recovered safely?
• Do labels explain secure deployment, operation and support?
• Can the organisation receive, assess and remediate post-market vulnerabilities within defined timescales?