top of page

FDA Premarket Cybersecurity Under Section 524B: What Reviewers Expect in 2026

Writer: Sharmila Bhatt
Sharmila Bhatt
Sep 22
9 min read

Few areas of device regulation have moved as quickly as cybersecurity. In the span of three years, FDA gained statutory authority to require cybersecurity information in premarket submissions, finalized a comprehensive premarket guidance, updated it in June 2025 to address that statutory authority directly, and reissued it again in February 2026 to align with the Quality Management System Regulation (QMSR). For regulatory affairs professionals, the result is a mature, enforceable framework, and one where deficiencies in cybersecurity documentation are now a routine reason for additional information requests and, in some cases, refusal to accept a submission.

This article explains what Section 524B of the Federal Food, Drug, and Cosmetic Act (FD&C Act) requires, which devices it covers, what FDA expects to see in a premarket submission, and how to build cybersecurity documentation that moves through review without avoidable delays.

The Legal Foundation: Section 524B

The Consolidated Appropriations Act, 2023, signed on 29 December 2022, added Section 524B, "Ensuring Cybersecurity of Devices," to the FD&C Act. It took effect on 29 March 2023. For any premarket submission for a "cyber device," the sponsor must:

  1. Submit a plan to monitor, identify and address postmarket cybersecurity vulnerabilities and exploits in a reasonable time, including coordinated vulnerability disclosure and related procedures.

  2. Design, develop and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure, and make available postmarket updates and patches to the device and related systems to address known unacceptable vulnerabilities on a reasonably justified regular cycle, and critical vulnerabilities that could cause uncontrolled risks as soon as possible out of cycle.

  3. Provide a software bill of materials (SBOM), including commercial, open-source and off-the-shelf software components.

  4. Comply with other requirements FDA may establish through regulation to demonstrate reasonable assurance that the device and related systems are cybersecure.

Section 524B applies to 510(k), De Novo, PMA, PMA supplement, Humanitarian Device Exemption and Product Development Protocol submissions. It also made failure to comply with 524B a prohibited act under Section 301(q) of the FD&C Act.

What Is a "Cyber Device"?

Under Section 524B(c), a cyber device is a device that:

  • includes software validated, installed or authorized by the sponsor as a device or in a device;

  • has the ability to connect to the internet; and

  • contains any such technological characteristics validated, installed or authorized by the sponsor that could be vulnerable to cybersecurity threats.

FDA's guidance interprets "ability to connect to the internet" broadly. It includes devices that connect through Wi-Fi, cellular, Bluetooth or Bluetooth Low Energy, radio frequency, inductive communications, network ports, USB and serial ports, or any other means that could, directly or indirectly, connect to the internet. In practice, FDA's position is that a device with any of these capabilities is likely a cyber device, even if the intended use does not involve internet access. Sponsors that conclude their device is not a cyber device should document that reasoning carefully, because reviewers will test it.

The Guidance Timeline

  • 27 September 2023: FDA finalized "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions," superseding the 2014 premarket guidance.

  • 1 October 2023: FDA's transition period ended and it began refusing to accept premarket submissions for cyber devices that lacked the information required by Section 524B.

  • 27 June 2025: FDA issued an updated final guidance adding a dedicated section on Section 524B, clarifying which devices are cyber devices, what documentation satisfies each statutory requirement, and how 524B applies to modifications of previously authorized devices.

  • February 2026: FDA reissued the guidance, retitled to reference quality management system considerations, replacing references to the old Quality System Regulation (for example, 21 CFR 820.30 design controls) with references to ISO 13485:2016 clauses as incorporated by the QMSR. FDA described this as a Level 2 update with minor changes; the substantive premarket expectations did not change.

What FDA Expects in a Premarket Submission

The guidance organizes cybersecurity expectations around a Secure Product Development Framework (SPDF): a set of processes that reduce the number and severity of vulnerabilities throughout the product lifecycle. FDA does not mandate a specific framework, but it recognizes that frameworks such as IEC 81001-5-1 (health software security lifecycle) and the AAMI TIR57 and SW96 series can help satisfy QMS expectations. The submission should show the outputs of that framework. The key documentation elements are:

1. Security risk management report

A summary of the security risk management process and its results, distinct from, but linked to, the safety risk management file under ISO 14971. FDA emphasizes that security risk assessment should consider exploitability rather than probability of occurrence, because the likelihood of a deliberate attack cannot be estimated statistically in the way that random failures can.

2. Threat model

A threat model covering the device and the system in which it operates, including communication interfaces, update pathways, cloud services, companion apps and the healthcare delivery organization's network. FDA expects threat models to identify threats, attack surfaces and mitigations, and to be updated across the lifecycle.

3. Cybersecurity risk assessment

An assessment of each identified threat and vulnerability, with pre- and post-mitigation risk, and justification for residual risk acceptability.

4. Software bill of materials and component support information

A machine-readable SBOM in a recognized format (such as SPDX or CycloneDX), plus, for each component, the level of support provided by the component manufacturer and the end-of-support date. FDA also expects an assessment of known vulnerabilities in SBOM components, for example against CISA's Known Exploited Vulnerabilities catalog and the NIST National Vulnerability Database, with a justification for each unresolved vulnerability.

5. Unresolved anomalies

An assessment of unresolved software anomalies for their potential security impact.

6. Security architecture views

Architecture documentation showing how the device implements security controls. The guidance describes four view types: global system view, multi-patient harm view, updatability and patchability view, and security use case views. Reviewers use these to understand trust boundaries and data flows.

7. Security controls

Documentation of how the device addresses the control categories described in the guidance's appendix: authentication, authorization, cryptography, code, data and execution integrity, confidentiality, event detection and logging, resiliency and recovery, and updatability and patchability.

8. Cybersecurity testing

Evidence that controls were tested, including security requirement verification, threat mitigation testing, vulnerability testing (such as fuzz testing and static and dynamic code analysis), and penetration testing. FDA expects penetration testing reports to include independence of testers, scope, duration, methods and findings, with a disposition for each finding.

9. Cybersecurity labeling

Labeling that gives users the information they need to operate the device securely, including recommended security controls for the use environment, a description of backup and restore features, instructions for downloading updates, an SBOM or instructions for obtaining it, and information about the end of cybersecurity support.

10. Cybersecurity management plan

The postmarket plan required by Section 524B(b)(1): how the manufacturer will monitor for vulnerabilities, how it will assess and remediate them, the timeline for routine and critical patches, the coordinated vulnerability disclosure process, and how it will communicate with users.

11. Cybersecurity metrics

FDA recommends tracking metrics such as the percentage of identified vulnerabilities that are updated or patched, the time from vulnerability identification to patch, and the time from patch availability to deployment in the field.

Modifications to Previously Authorized Devices

The June 2025 update clarified an issue that had caused confusion: when a manufacturer submits a premarket submission for a modification to a cyber device that was authorized before 524B took effect, the 524B requirements apply to the new submission. FDA's expectations for documentation depend on whether the change could affect cybersecurity. For changes that do not affect cybersecurity, sponsors can provide a more limited set of information, but they must still address 524B's statutory elements, including the SBOM and postmarket plan. Changes that do affect cybersecurity require documentation proportional to the change and the device's overall risk.

This has a practical consequence for portfolio planning. A minor hardware change to an older connected device can bring the entire device's cybersecurity posture under review. RA teams should assess legacy connected devices before planning their next submission, not after receiving an additional information request.

Where Submissions Typically Fall Short

Based on common additional information themes, these are the areas most likely to delay review:

  • Threat models that stop at the device boundary. Omitting cloud services, mobile apps, update servers or third-party integrations is a frequent deficiency.

  • SBOMs without vulnerability assessment. An SBOM is necessary but not sufficient. Reviewers expect known vulnerabilities to be identified and dispositioned.

  • Missing end-of-support information. Components with no documented support status, or components already at end of life, draw questions about how vulnerabilities will be addressed.

  • Penetration testing without independence or scope detail. Reports that do not state who performed the testing, what was in scope and how long testing took are likely to be questioned.

  • Probability-based security risk scoring. Using the same probability scales as safety risk management, rather than exploitability, is a common source of deficiency.

  • Vague patch timelines. The postmarket plan must commit to reasonably justified timelines for routine and critical updates, not simply state that patches will be released "as needed."

  • Architecture views that do not match the threat model. Inconsistencies between documents signal that the security process was not integrated.

Connecting Cybersecurity to the QMSR

With the QMSR in force since 2 February 2026, cybersecurity sits inside the design and development requirements of ISO 13485 clause 7.3, the risk management requirement of clause 7.1, purchasing controls in clause 7.4 (relevant to software suppliers and open-source components), and feedback and CAPA processes in clause 8. FDA investigators can now inspect how the SPDF is implemented within the QMS, and the February 2026 guidance update makes those links explicit.

For quality and RA teams, the practical implications include:

  • Treating third-party software components as purchased product, with supplier evaluation and ongoing monitoring.

  • Routing vulnerability reports through complaint handling and CAPA where they indicate a potential nonconformity.

  • Assessing whether a vulnerability that could cause patient harm triggers medical device reporting (21 CFR Part 803) or correction and removal reporting (21 CFR Part 806). FDA's 2016 postmarket cybersecurity guidance explains when routine cybersecurity updates are exempt from Part 806 reporting.

A Submission-Readiness Checklist

  1. Document the cyber device determination with reference to each element of Section 524B(c).

  2. Confirm the threat model covers the full system, including cloud and mobile components.

  3. Generate a machine-readable SBOM with support status and end-of-support dates for every component.

  4. Run a known-vulnerability assessment against the SBOM and document dispositions.

  5. Provide all four security architecture view types.

  6. Map security controls to the guidance's control categories.

  7. Include independent penetration testing with full scope and methods.

  8. Draft cybersecurity labeling for users and healthcare delivery organizations.

  9. Finalize a postmarket cybersecurity management plan with committed timelines and a coordinated vulnerability disclosure policy.

  10. Cross-reference security risks to the ISO 14971 safety risk file where security issues could lead to patient harm.

After Clearance: Postmarket Expectations

Section 524B is triggered by a premarket submission, but most of what it requires plays out after authorization. The plan and processes described in the submission become commitments that FDA can evaluate through inspection and, if necessary, enforcement.

  • Vulnerability monitoring. Manufacturers should monitor sources such as CISA advisories, the National Vulnerability Database, component supplier notifications and security researcher reports, and assess each relevant vulnerability against the device's SBOM and threat model.

  • Coordinated vulnerability disclosure. A published policy that tells researchers how to report vulnerabilities, what they can expect in response, and how the manufacturer will coordinate disclosure. Many manufacturers align with ISO/IEC 29147 and ISO/IEC 30111.

  • Patch delivery. The timelines committed in the premarket plan for routine and critical updates should be tracked and reported internally. Missing them without documented justification undermines the reasonable assurance of cybersecurity that 524B requires.

  • Customer communication. Healthcare delivery organizations rely on manufacturer disclosures, including the Manufacturer Disclosure Statement for Medical Device Security (MDS2), to manage devices on their networks. Keeping these current is part of a credible postmarket program.

Under FDA's 2016 postmarket cybersecurity guidance, a cybersecurity routine update or patch that addresses a vulnerability with controlled risk is generally not reportable under 21 CFR Part 806. Where a vulnerability presents uncontrolled risk of patient harm, the manufacturer must assess whether a correction or removal report is required, although FDA has indicated that it does not intend to enforce reporting requirements under Part 806 for certain actions if specific conditions are met, including timely communication to customers and participation in an Information Sharing and Analysis Organization (ISAO).

Legacy Connected Devices

Many manufacturers have connected devices on the market that were authorized before 524B took effect. Section 524B does not apply retroactively to those authorizations, but it will apply to the next premarket submission for a modification. In addition, the QMSR's design and risk management requirements apply to all devices in production. Practical steps for legacy portfolios include:

  1. Generating SBOMs for legacy devices, even if not yet required for a submission, to understand exposure to known vulnerabilities.

  2. Identifying components at or near end of support and planning replacements.

  3. Assessing whether devices can receive updates in the field and, if not, what compensating controls customers need.

  4. Prioritizing legacy devices for cybersecurity upgrades based on connectivity, clinical criticality and installed base.

  5. Planning which legacy devices will require a new submission in the next two to three years, and preparing 524B documentation in advance.

The Bottom Line

Cybersecurity is no longer a specialist appendix to a device submission; it is a statutory requirement with its own documentation set, embedded in the QMS and reviewed with the same rigor as clinical and performance data. The most efficient submissions treat security as a design discipline with traceable outputs rather than a testing exercise at the end. For RA professionals, the most useful action is to align engineering, quality and regulatory teams around the eleven documentation elements FDA expects, and to start that work at design input rather than submission assembly.

Sources

  • FD&C Act Section 524B, added by Section 3305 of the Consolidated Appropriations Act, 2023

  • FDA, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions": fda.gov

  • Federal Register notice of availability, 27 June 2025: govinfo.gov

  • DLA Piper, "FDA issues revised cybersecurity premarket submission guidance to align with quality management system regulation" (February 2026): dlapiper.com

  • FDA, Cybersecurity resources: fda.gov

  • FDA, "Postmarket Management of Cybersecurity in Medical Devices" (December 2016)

  • IEC 81001-5-1:2021, Health software and health IT systems safety, effectiveness and security – Part 5-1: Security – Activities in the product life cycle

Comments


bottom of page