FDA 524B Cybersecurity Requirements: Full Compliance Guide

Manufacturers rarely get tripped up by 524B because they disagree with it. They get tripped up because they treat it as a paperwork exercise bolted onto the end of design, rather than as three interlocking engineering obligations that have to be built into the device and documented from day one. This guide walks through the statute, the definitions that decide whether it applies to you, and the specific artifacts reviewers expect to see for each requirement.

Understanding Section 524B of the FD&C Act

Section 524B is the binding statute: it states what you must do. The February 3, 2026 FDA premarket cybersecurity guidance is the operative interpretation reviewers apply on top of it, describing how you demonstrate compliance. Every obligation below pairs the statutory requirement with the guidance-defined evidence that satisfies it.

Section 524B became law on December 29, 2022, as part of the Consolidated Appropriations Act, 2023 (the FDORA amendments), and took effect 90 days later, on March 29, 2023. The FDA began issuing refuse-to-accept (RTA) decisions on 524B grounds starting October 1, 2023. It is codified at 21 U.S.C. 360n-2, and formal correspondence with the FDA should cite both the FD&C Act section and the U.S. Code reference.

Who counts as a "cyber device"

Under 524B(c), a device is a cyber device if it meets all three prongs: it includes software validated, installed, or authorized by the sponsor; it has the ability to connect to the internet; and it contains technological characteristics that could be vulnerable to cybersecurity threats. All three have to be true at once, but the connectivity prong is interpreted broadly. Wi-Fi, Bluetooth, NFC, a USB service port used for data transfer, a companion mobile app, or a gateway that relays data to a cloud service can all satisfy it, even when the device itself has no persistent network connection.

The statute does not distinguish by device class. A Class II blood glucose meter with Bluetooth pairing and a Class III implantable neurostimulator with an RF programmer are both evaluated against the same three-prong test. If your device has any software and any path to a network, treat 524B applicability as the default assumption and build your rationale for exclusion carefully, because reviewers will ask for it either way.

The three statutory requirements

524B(a) attaches the requirements to marketing submissions filed under 510(k), De Novo (513(f)), PMA (515(c)), PDP, and HDE pathways. IDE submissions under 520(g) are not explicitly enumerated in the statute, though the February 2026 guidance still sets cybersecurity expectations for investigational devices that meet the cyber device definition. Within that scope, 524B(b) creates three concrete obligations.

524B(b)(1): Postmarket vulnerability monitoring plan

You must submit a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and timely patch release. This has to be an operational plan at the time of clearance, not a placeholder promising future process. Reviewers expect:

• A vulnerability monitoring procedure naming specific data sources (NVD, CISA KEV, vendor advisories, your SBOM-driven CVE feed) and a stated review cadence.
• A coordinated vulnerability disclosure (CVD) policy published at a stable URL, with a security contact, an intake channel, and a stated safe harbor for good-faith researchers.
• A triage service-level agreement defining how quickly you assess and score a report, typically using CVSS v3.1 or v4.0.
• A remediation SLA that distinguishes routine patch cadence from an out-of-cycle response to a critical, actively exploited vulnerability.
• A customer communication plan covering field notices, advisories, and CSAF or VEX distribution to downstream users.

See our postmarket cybersecurity readiness plan guide and VDP/CVD workflows guide for the underlying process design.

524B(b)(2): Processes, updates, and patchability

You must design and maintain processes providing reasonable assurance that the device and related systems are cybersecure, and you must make patches and updates available on a reasonably justified regular cycle and, out-of-cycle, for critical vulnerabilities. This is the Secure Product Development Framework (SPDF) requirement expressed in statutory language, and it is where most submission effort concentrates. The evidence set typically includes:

• An SPDF policy mapped to ANSI/AAMI SW96:2023, IEC 81001-5-1, or ISO/IEC 27034.
• A security risk management file under IEC 81001-5-1, cross-referenced to the ISO 14971 safety risk file so security and safety risk are not analyzed in silos.
• A threat model, typically STRIDE or an equivalent method, covering every trust boundary with mitigations traced back to design controls.
• Architecture views: global system view, multi-patient harm view, updateability view, and security use-case view.
• A penetration test report covering vulnerability chaining, boundary analysis, closed-box testing, and manually verified exploitation, not just an automated scan output.
• A cybersecurity testing summary documenting unit-, integration-, and system-level security verification.
• Updateability and patchability evidence: signed updates, rollback protection, a secure boot chain, and a demonstrated update mechanism on the actual device, not a description of one.
• Cybersecurity labeling for end users covering security features, recommended network configurations, and decommissioning guidance.

524B(b)(3): Software Bill of Materials

You must provide an SBOM covering commercial, open-source, and off-the-shelf software components, including the versions of those components. The February 2026 guidance requires the SBOM to be machine-readable, in CycloneDX or SPDX format, and accompanied by a monitoring plan for known vulnerabilities in those components. In practice, reviewers expect:

• A machine-readable SBOM in CycloneDX 1.5+ or SPDX 2.3+ covering firmware, OS, middleware, application code, and third-party libraries.
• Component identifiers, including PURL and CPE wherever both exist, because CVE matching depends on them.
• Cryptographic hashes per component to support integrity verification.
• Supplier and license metadata per component.
• A documented SBOM generation procedure stating whether the SBOM is derived from source, build, or binary analysis, and how often it is regenerated.
• A known-vulnerability summary at the time of submission, with a VEX statement for every open CVE explaining whether it is exploitable in your configuration. See our SBOM vulnerability management guide and VEX documents guide.

524B(b)(4): Additional requirements by regulation

524B(b)(4) authorizes the FDA to add cybersecurity requirements through formal rulemaking, not through guidance. As of mid-2026, no (b)(4) regulation has been issued. The February 2026 guidance is nonbinding and interprets the existing (b)(1) through (b)(3) obligations; it is not the rulemaking contemplated in (b)(4). That distinction matters procedurally, but it does not change practical exposure: reviewers use the guidance as the working standard for what "reasonable assurance" looks like, and deviating from it without a documented rationale is a common source of deficiency letters.

A compliance checklist in statutory order

Work through the requirements in the order the statute presents them, because gaps compound. A weak SBOM undermines your vulnerability monitoring claim, since you cannot monitor components you have not correctly identified, and a weak vulnerability plan undermines the postmarket narrative that ties the whole submission together.

Pathway differences that affect scope

The core 524B obligations are identical across 510(k), De Novo, and PMA, but the depth of evidence reviewers expect scales with pathway. A PMA submission for a Class III device typically requires a more exhaustive security risk management file and a broader penetration test scope than a straightforward Class II 510(k) for a similar architecture. See our pathway-by-pathway cybersecurity differences guide for the specific deltas, and our SPDF playbook for how to build the underlying process once and scale the evidence package to the pathway.

How Blue Goat Cyber approaches 524B compliance

We build 524B compliance into the device development lifecycle rather than assembling it retroactively before submission. For a new engagement, we start by determining cyber device applicability with a documented rationale, then stand up the SPDF artifacts (threat model, security risk management file, architecture views) in parallel with SBOM generation from the build pipeline, so the vulnerability monitoring plan is grounded in a component inventory that is actually correct. Penetration testing is scheduled once the architecture is stable but early enough that findings can still change the design, not just the documentation. We deliver the postmarket vulnerability plan as a working process, with the CVD policy live and the monitoring feed connected, before the submission goes in. Our FDA Premarket Cybersecurity Services and FDA Cybersecurity Deficiency Response engagements cover this end to end, from initial gap assessment through response to any deficiency letter the FDA issues.

FAQ

Does 524B apply to a device with no wireless connectivity?

Possibly. The connectivity prong of the cyber device definition covers any ability to connect to the internet, which includes a USB port used for data transfer, a service laptop connection used to pull logs, or an intermediary gateway that relays data even when the device itself never touches the internet directly. Absence of Wi-Fi or Bluetooth does not settle the question on its own; document the actual data paths and evaluate each one against the three-prong test.

What happens if I omit the SBOM from a 524B submission?

The FDA can issue a refuse-to-accept decision or a deficiency letter citing the missing 524B(b)(3) requirement. Since RTA screening for 524B began October 1, 2023, SBOM omission is one of the most common and most avoidable causes of a hold, because the requirement is unambiguous and the artifact is generative from your build process rather than something you have to reconstruct after the fact.

Is the February 2026 guidance legally binding?

No. It is nonbinding guidance that interprets the binding statutory requirements in 524B(b)(1) through (b)(3). No 524B(b)(4) regulation has been issued as of this writing. In practice, reviewers use the guidance as the working definition of "reasonable assurance," so departing from its recommendations without a documented, defensible rationale carries the same practical risk as noncompliance with a binding rule.

Does 524B apply differently to legacy devices already on the market?

524B applies to new marketing submissions, including certain modifications to legacy devices that require a new submission. A device cleared before 524B took effect is not retroactively subject to it unless you file a new submission that triggers 524B(a) applicability, such as a significant design change. See our guide on legacy medical device cybersecurity for how the postmarket expectations still apply outside the premarket statute.

How does 524B interact with ISO 14971 safety risk management?

524B does not replace ISO 14971; it requires a parallel security risk management process, most commonly built under IEC 81001-5-1, that is cross-referenced to your existing safety risk file. A vulnerability that could cause patient harm needs to appear in both files with a traceable link between them, because reviewers check whether the security risk assessment actually informed the safety risk assessment and not the other way only.

Related guides

• FDA Section 524B Subsections Explained
• FDA Cybersecurity Guidance Summary (2026)
• Medical Device Cybersecurity SPDF Playbook
• SBOM for Medical Devices
• FDA Pathway Cybersecurity Differences

Where to go next

• Cybersecurity for IVD Devices - 524B applied to in vitro diagnostic platforms.

Sources & primary references

• Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (FDA, February 3, 2026 final guidance)
• Consolidated Appropriations Act, 2023, Section 3305 (FDORA)
• Refuse to Accept Policy for Cyber Devices and Related Systems (FDA)
• 21 U.S.C. 360n-2