FDA Premarket Cybersecurity Guidance for Medical Devices

Cybersecurity can directly affect whether a medical device remains safe and effective. A compromised device may expose information, interrupt treatment, alter clinical data, or prevent essential functions. FDA therefore expects medical device manufacturers to address cybersecurity during design and throughout the device lifecycle.

The current FDA premarket cybersecurity guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, was issued February 3, 2026, superseding the June 27, 2025 final guidance of the same name. It explains FDA's recommendations for designing cybersecure devices, managing cybersecurity risk, communicating security information, and preparing documentation for FDA review.

This guide is for regulatory, quality, engineering, and security teams developing connected medical devices, Software as a Medical Device (SaMD), embedded software, or firmware.

What Does Section 524B Require?

Section 524B of the Federal Food, Drug, and Cosmetic Act establishes statutory cybersecurity requirements for “cyber devices.” A cyber device includes sponsor-authorized software, can connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats.

For applicable 510(k), De Novo, Premarket Approval (PMA), Product Development Protocol, and Humanitarian Device Exemption submissions, sponsors must provide information demonstrating compliance with Section 524B. The central requirements include:

• A plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits within a reasonable time
• Processes and procedures that provide reasonable assurance that the device and related systems are cybersecure
• Postmarket updates and patches for the device and related systems
• A Software Bill of Materials (SBOM) covering commercial, open-source, and off-the-shelf software components

These statutory duties are specific to cyber devices. The FDA guidance has a broader scope and provides recommendations for devices with cybersecurity considerations, including some devices that are not internet-connected or do not require a premarket submission.

What Does FDA Expect in a Premarket Submission?

Documentation should help reviewers understand the device, its use environment, foreseeable cybersecurity risks, controls, and evidence that those controls work. Depending on the device and its cybersecurity risk, a submission may include:

• A security risk management plan and report
• Threat modeling and cybersecurity risk assessments
• Security architecture views and data-flow diagrams
• An SBOM and supporting third-party component information
• Cybersecurity testing, including penetration testing where appropriate
• A cybersecurity management plan for postmarket vulnerabilities
• Secure update, patch, recovery, and rollback information
• Labeling that communicates security requirements, limitations, and user responsibilities

FDA uses a total product lifecycle approach. The submission should show how cybersecurity will be managed from design through deployment, maintenance, and decommissioning.

How Does a Secure Product Development Framework Help?

A Secure Product Development Framework (SPDF) is a set of processes intended to reduce the number and severity of vulnerabilities throughout the product lifecycle. FDA encourages manufacturers to use an SPDF, although other approaches may satisfy applicable requirements.

SPDF evidence can include secure development procedures, security requirements, design reviews, code analysis, vulnerability assessments, change control, testing, and defect management. It should connect to the quality management system and development processes.

The Quality Management System Regulation (QMSR) became effective on February 2, 2026. It amended 21 CFR Part 820 and incorporates ISO 13485:2016 by reference. References to the former design-control provision in 21 CFR 820.30 are now outdated. Under the QMSR, 21 CFR 820.10(c) applies ISO 13485 Clause 7.3 and its subclauses to manufacturers of Class II and Class III devices, as well as Class I devices automated with computer software and certain other listed Class I devices. Cybersecurity documentation can therefore serve as evidence of controlled design, risk management, verification, and validation activities.

Security Risk Management and Threat Modeling

FDA recommends separate but connected security and safety risk assessments. A security event may create a hazardous situation that leads to patient harm, but security risk cannot always be estimated with traditional probability methods because threat actors can deliberately seek exploitable weaknesses.

Threat modeling should begin early and continue as the architecture changes. It should cover the complete medical device system, including hardware, software, cloud services, mobile applications, update servers, data flows, interfaces, trust boundaries, credentials, and third-party dependencies.

Teams may use attack trees, misuse cases, or other structured techniques to describe possible attack paths. Whatever method is selected, the output should identify assets, threats, vulnerabilities, controls, and potential impacts. A traceability matrix can connect each cybersecurity risk to requirements, mitigations, and verification evidence.

Security Architecture and the Use Environment

Security architecture documentation should help a reviewer follow data, code, and commands across the device system. Diagrams should identify external interfaces, communication protocols, authentication and authorization steps, encryption, key-management functions, logging, update mechanisms, and trust boundaries.

The analysis should reflect actual use. A hospital-network device may encounter different threats than a home-use product. Manufacturers should consider foreseeable misuse and the least secure expected configuration.

SBOM and Third-Party Software

An SBOM identifies the software components within a device. For cyber devices, Section 524B requires an SBOM that includes commercial, open-source, and off-the-shelf components. FDA recommends a machine-readable, industry-accepted format consistent with NTIA minimum elements. SPDX and CycloneDX are commonly used formats, but FDA does not prescribe one universal syntax.

The SBOM and supporting information should identify component suppliers, names, versions, unique identifiers, dependency relationships, support status, and end-of-support dates. Manufacturers should also identify known vulnerabilities, assess their safety and security effects, and document applicable mitigations or compensating controls.

The SBOM must correspond to the submitted build. Do not omit firmware, mobile applications, cloud components, or relevant upstream dependencies because separate teams manage them.

Vulnerability Management and Secure Updates

For cyber devices, Section 524B requires a plan for monitoring, identifying, and addressing postmarket vulnerabilities and exploits. The plan should define responsible personnel, monitoring sources and frequency, coordinated vulnerability disclosure procedures, security-testing activities, patch timelines, update processes, and customer communications.

Manufacturers should also explain how updates are authenticated, tested, delivered, and verified. The device should recover safely if an update is interrupted or unsuccessful. Rollback and emergency-update procedures should be planned where appropriate, with controls that prevent an attacker from installing unauthorized or vulnerable software.

Cybersecurity Testing Evidence

Testing should demonstrate that security controls perform as intended in the device's environment of use. FDA recommends evidence such as vulnerability testing, abuse or misuse-case testing, attack-surface analysis, fuzz testing, boundary analysis, static and dynamic code analysis, and penetration testing, as appropriate.

A penetration test report should describe scope, methods, tools, qualifications or independence of testers, findings, exploitability, and remediation status. When findings are corrected, include retest evidence. Unresolved anomalies and vulnerabilities should have documented safety and security assessments and a clear rationale for residual-risk acceptability.

Premarket Cybersecurity Submission Checklist

Before filing, confirm that the submission includes, as applicable:

• An assessment of whether the product is a cyber device
• SPDF evidence linked to controlled development records
• A security risk management plan and report
• A current threat model showing assets, attack paths, and trust boundaries
• Security architecture and data-flow diagrams
• A machine-readable SBOM tied to the submitted build
• Known-vulnerability assessments and mitigation rationales
• Cybersecurity test reports and retest evidence
• Postmarket vulnerability-management and disclosure procedures
• Secure update, verification, recovery, and rollback documentation
• Appropriate cybersecurity labeling and instructions for use

Common Submission Gaps

Common problems include incomplete system scope, an SBOM that omits cloud or firmware components, weak traceability between risks and controls, unsupported third-party software, unclear credential or key management, and penetration-test findings without documented resolution.

Another frequent gap is an update process described only at a high level. Reviewers need to understand how updates are authorized, delivered, verified, tested, and recovered if deployment fails. Medical device manufacturers should review these elements before submission rather than waiting for an Additional Information request.

How Does Cybersecurity Fit Into 510(k), De Novo, and PMA?

Cybersecurity evidence should be scaled to the device and its risk, not omitted because of the submission pathway. A 510(k) demonstrates substantial equivalence to a legally marketed predicate. A De Novo request establishes a classification for a novel low- or moderate-risk device without a suitable predicate. FDA premarket approval (PMA) is the pathway used primarily for Class III devices, and it requires valid scientific evidence supporting a reasonable assurance of safety and effectiveness.

Cybersecurity changes to an authorized device may require a new submission when they could significantly affect safety or effectiveness. The decision depends on the change and applicable FDA policy; changes that do not affect cybersecurity generally require different documentation than those that do.

Most Class I devices and some Class II devices are exempt from 510(k), but exemption is determined by the specific classification regulation and product code. Even a 510(k)-exempt device remains subject to applicable regulatory controls, and FDA's cybersecurity recommendations may still be relevant.

How Quality Commercial Consultants Can Help

Preparing cybersecurity content for an FDA submission requires coordination among regulatory, quality, engineering, and security teams. Quality Commercial Consultants helps medical device and SaMD companies organize their existing technical work into clear, traceable documentation aligned with current FDA expectations.

Our support may include cybersecurity risk and threat-modeling summaries, SBOM documentation, testing evidence, postmarket vulnerability-management plans, and responses to FDA Additional Information requests. We tailor each engagement to the device, submission pathway, development stage, and documentation already available.

Contact Quality Commercial Consultants to discuss your device, submission timeline, and cybersecurity documentation needs.