What Section 524B is
Section 524B, "Ensuring Cybersecurity of Devices," is a section of the Federal Food, Drug, and Cosmetic Act (FD&C Act). Congress added it through section 3305 of the Food and Drug Omnibus Reform Act of 2022 (FDORA), which was enacted on December 29, 2022 as part of the Consolidated Appropriations Act, 2023. The section is codified at 21 U.S.C. 360n-2.
The requirements took effect on March 29, 2023. FDA's FAQ states that the cybersecurity requirements do not apply to an application or submission submitted before that date, and that a later submission for a change to a previously authorized cyber device is covered.
Section 524B has four parts. Subsection (a) says who must submit information. Subsection (b) lists the obligations. Subsection (c) defines "cyber device." Subsection (d) lets FDA exempt devices or categories of devices and requires it to publish that list in the Federal Register. The rulemaking authority sits in subsection (b)(4). This guide walks through each part and then maps the obligations to the documents FDA expects in the eSTAR.
Who must comply
Section 524B(a) places the duty on the person who submits a premarket application or submission. FDA's guidance lists the covered pathways: 510(k), PMA, PDP, De Novo, and HDE. The FAQ adds that this includes Special and Abbreviated 510(k)s and PMA and HDE supplements.
The statute uses "person" in 524B(a) and "sponsor" in 524B(b). FDA's guidance assumes the manufacturer is the submitter and says that whoever submits the application for a cyber device is subject to the requirements. If a contract manufacturer, a distributor, or a specification developer files the submission, the duty follows the filer.
Devices with no premarket submission, such as 510(k)-exempt devices, have no 524B filing. The guidance still applies its cybersecurity recommendations to every device with software, exempt or not, under the quality management system. In practice, that means a 510(k)-exempt connected device should still have a threat model, an SBOM, and a vulnerability plan, even though nothing is filed.
What counts as a cyber device
Section 524B(c) defines a cyber device as a device that meets all three of the following tests:
- It includes software validated, installed, or authorized by the sponsor as a device or in a device.
- It has the ability to connect to the internet.
- It contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.
All three must be true. A device that fails any one test is not a cyber device, although the guidance recommendations may still apply to it.
FDA interprets each test in Section VII.B of the guidance. "Software" includes firmware and programmable logic. "Ability to connect to the internet" covers connections that are intentional or unintentional, through any means, including any point identified in the evaluation of the device's threat surface and environment of use.
Features that give a device the ability to connect
The guidance gives an illustrative, not exhaustive, list of features that FDA considers to provide the ability to connect to the internet:
- Network, server, or cloud service provider connections.
- Radio-frequency communications, such as Wi-Fi, cellular, Bluetooth, and Bluetooth Low Energy.
- Magnetic inductive communications, for example the link between an implant and its external programmer.
- Hardware connectors capable of connecting to the internet, such as USB, ethernet, and serial ports.
The guidance is explicit about the USB case. A device that is serviced through a USB connection has the ability to connect, even if the connection is brief. In CyberMed's experience, the ability test is where most "we are not a cyber device" arguments fail. If the device has any port or radio, plan on being a cyber device and document the determination either way.
The third test in practice
The third test asks whether the device contains characteristics that could be vulnerable to cybersecurity threats. Software with an interface almost always meets it. The useful output of this test is not a yes or no. It is a written determination that names the interfaces, the software, and the threat surface, and that the reviewer can read in the eSTAR. FDA's FAQ says a manufacturer who is unsure can contact the agency, and a Pre-Submission is the formal route to do that.
The three 524B(b) obligations
Section 524B(b) requires the sponsor of a cyber device to do three things. Each has a subsection number that reviewers use, and each maps to a specific set of documents. A fourth subsection, 524B(b)(4), lets FDA add requirements by regulation.
524B(b)(1): a plan for postmarket vulnerabilities
The sponsor must submit "a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures." FDA recommends that this plan contain the elements of the Cybersecurity Management Plan described in Section VI.B of the guidance:
- Personnel responsible.
- Sources, methods, and frequency for monitoring and identifying vulnerabilities, such as researchers, the NIST National Vulnerability Database, and third-party software manufacturers.
- How vulnerabilities in CISA's Known Exploited Vulnerabilities Catalog are identified and addressed.
- Periodic security testing.
- Timeline to develop and release patches.
- Update processes and patching capability, meaning the rate at which an update can reach fielded devices.
- The coordinated vulnerability disclosure process.
- How forthcoming remediations, patches, and updates are communicated to customers.
The guidance adds two specific expectations for cyber devices. First, coordinated vulnerability disclosure covers disclosures from external parties, disclosures of issues the manufacturer finds, and the procedures used to make those disclosures. Second, the plan should state the timeline, with justification, for the updates that 524B(b)(2) requires.
524B(b)(2): processes, procedures, and patches
The sponsor must "design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure," and must make updates and patches available. Subsection (b)(2)(A) requires updates and patches for known unacceptable vulnerabilities on a reasonably justified regular cycle. Subsection (b)(2)(B) requires updates and patches, as soon as possible and out of cycle, for critical vulnerabilities that could cause uncontrolled risks.
"Related systems" is broad. FDA's guidance says it includes manufacturer-controlled elements such as other devices, software that performs "other functions," software and firmware update servers, and connections to healthcare facility networks. The threat model and the security risk assessment have to cover these systems, not only the device.
FDA points to Appendix 4 of the guidance as the documentation that demonstrates 524B(b)(2) compliance. That appendix is the source of the document list in the next section. The stakes are higher for this obligation than for the other two. The guidance notes that failure to comply with any requirement under 524B(b)(2) is a prohibited act under section 301(q) of the FD&C Act.
524B(b)(3): the software bill of materials
The sponsor must provide a software bill of materials (SBOM) that includes commercial, open-source, and off-the-shelf software components. FDA recommends a machine-readable SBOM consistent with the minimum elements in the NTIA's 2021 document The Minimum Elements for a Software Bill of Materials.
FDA asks for two elements beyond the NTIA baseline for each component: the level of support from the component's maintainer (actively maintained, no longer maintained, or abandoned) and the end-of-support date. These can go in the SBOM or in an addendum. The submission should also identify all known vulnerabilities in the device and its components, including any in CISA's Known Exploited Vulnerabilities Catalog, describe how each was found, and provide a safety and security risk assessment and the risk controls for each. If any SBOM information cannot be provided, the guidance asks for a justification.
CyberMed's SBOM requirements guide covers formats and tooling. The obligation in the statute is the SBOM itself. The support status, end-of-support dates, and vulnerability disposition are what turn the SBOM into evidence a reviewer can accept.
524B(b)(4): requirements FDA may add by regulation
Subsection (b)(4) requires cyber device sponsors to comply with any other requirements FDA sets in regulation to demonstrate reasonable assurance of cybersecurity. The guidance notes that FDA is not required to issue a regulation to elaborate on the requirements already in the statute. As of the February 2026 guidance, no such additional regulation applies.
How the obligations map to the eSTAR
Since October 1, 2023, all 510(k) submissions, unless exempted, must be filed using the eSTAR. The eSTAR has a Cybersecurity section with questions and attachment slots, and the software documentation lives in its own section. The eSTAR does not use the words 524B(b)(1), (2), and (3). The reviewer does. The table below connects the two, using the document list in Appendix 4 of FDA's guidance.
| 524B obligation | What the reviewer looks for | Guidance section |
|---|---|---|
| (b)(1) Postmarket plan | Cybersecurity Management Plan with CVD procedure, monitoring sources, patch timelines, and customer communication | VI.B, VII.C.1 |
| (b)(2) Processes and procedures | Threat model, cybersecurity risk assessment, security architecture views, security controls and requirements, unresolved anomaly assessment, traceability, testing evidence, labeling, metrics | V.A, V.B, V.C, VI.A, Appendix 4 |
| (b)(2)(A) and (B) Patches | Update and patch timelines with justification, stated in the management plan, plus the updatability and patchability architecture view | VII.C.1, V.B.2 |
| (b)(3) SBOM | Machine-readable SBOM with NTIA elements, support status, end-of-support dates, and known vulnerability assessment | V.A.4, VII.C.3 |
The documents FDA recommends
Appendix 4, Table 1 of the guidance lists the documentation FDA recommends for premarket submissions. In summary: a Cybersecurity Risk Management Report that contains the threat model, the cybersecurity risk assessment, the SBOM, the vulnerability assessment and software support information, the unresolved anomalies assessment, and traceability; measures and metrics; security architecture views with their requirements; testing; labeling; and the cybersecurity management plan. The book chapter on understanding eSTAR requirements walks through these one by one.
The guidance says documentation is expected to scale with cybersecurity risk, not with the software documentation level from the premarket software guidance. A device with a low software documentation level can still carry a high cybersecurity risk, and the cybersecurity file scales with that risk. This is the point where teams most often under-scope. CyberMed's FDA cybersecurity documentation service exists to write this set against the actual device.
Architecture views
The guidance asks for four security architecture views: global system, multi-patient harm, updatability and patchability, and security use case views. Appendix 4 notes that a simple device, such as a SaMD product with limited connectivity, may need a single view for each of the first three and a small set of use case views. A device with networking, wireless, cloud, or a commercial operating system may need several views of each type. These views are where the "related systems" scope of 524B(b)(2) becomes visible to the reviewer.
Technical screening and refuse to accept
FDA published a refuse to accept (RTA) policy for cyber devices in March 2023. The FAQ states that the policy in that guidance expired on October 1, 2023, and that from that date FDA expects sponsors of cyber devices to have had enough time to prepare submissions that contain the information Section 524B requires.
The screening now happens in the eSTAR. The FAQ states that an eSTAR submission will be put on a Technical Screening hold if it does not contain accurate responses and relevant attachments in the Cybersecurity section. The general Refuse to Accept Policy for 510(k)s guidance describes the acceptance review process that the eSTAR automates.
In practice this means the three 524B(b) items need attachments on the day of submission, not during interactive review. A blank SBOM slot, a management plan that is a paragraph rather than a document, or a "not a cyber device" answer that the rest of the file contradicts will stop the clock before substantive review starts.
What changed in the February 2026 guidance
FDA issued the current guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, on February 3, 2026. The document states that it supersedes the version issued on June 27, 2025. The June 2025 version had replaced the September 2023 final guidance, which was the first to address Section 524B.
The change is in the quality system framing. FDA's Quality Management System Regulation took effect on February 2, 2026, and incorporates ISO 13485:2016 by reference. The guidance now references ISO 13485 subclauses where earlier versions referenced 21 CFR 820 design control provisions. For example, it cites Subclause 7.3.6 for design verification and Subclause 7.3.7 for design validation when it discusses cybersecurity testing, and Subclause 8.4 and 8.5 when it discusses the management plan. The title changed from "Quality System Considerations" to "Quality Management System Considerations" for the same reason.
What did not change: the cyber device definition, the three 524B(b) obligations, the document list in Appendix 4, the four architecture views, the SBOM elements, the testing recommendations, and the labeling recommendations. A submission built to the June 2025 guidance does not need new documents. It needs a check that its quality system references and its secure product development framework are described in QMSR terms. CyberMed's post on the February 2026 update gives a first-read summary.
The guidance history in one place
- 2014: first final premarket cybersecurity guidance, "Content of Premarket Submissions for Management of Cybersecurity in Medical Devices."
- December 28, 2016: Postmarket Management of Cybersecurity in Medical Devices, which the current premarket guidance supplements and cross-references for uncontrolled and controlled risk.
- December 29, 2022: FDORA adds Section 524B to the FD&C Act. Effective March 29, 2023.
- September 2023: final premarket guidance that replaced the 2014 guidance and addressed Section 524B.
- June 27, 2025: revised premarket guidance.
- February 3, 2026: current premarket guidance, aligned with the QMSR.
Modifications to an authorized cyber device
Section VII.D of the guidance covers device changes. Section 524B applies to any submission on one of the listed pathways, so a 510(k) or PMA supplement for a modification to a cyber device carries the full obligations. FDA applies least burdensome principles to what it expects to see.
For changes that may affect cybersecurity, such as changes to authentication or encryption algorithms, new connectivity, or a new software update mechanism, FDA expects the documentation described in Section VII.C, which is the full set.
For changes unlikely to affect cybersecurity, such as materials, sterilization method, or an algorithm change that does not touch architecture, software structure, or connectivity, the guidance describes a lighter package:
- 524B(b)(1): the plan if not previously provided, or a reference to the prior submission with a summary of changes.
- 524B(b)(2): a statement of whether any critical vulnerabilities that could cause uncontrolled risks exist, and whether any uncontrolled-risk vulnerabilities were remediated since the last authorization.
- 524B(b)(3): a current SBOM.
The guidance also says FDA will take known cybersecurity concerns for the device type into account regardless of the change proposed. A modification submission is not a way to avoid a known weakness in the fielded device.
Common deficiency triggers
Reviewers write deficiencies against the guidance sections, not against the statute. The following are the gaps CyberMed sees most often when it reviews cybersecurity files before submission. They are listed with the guidance expectation each one misses. No frequencies are given, because CyberMed does not publish client data.
- No cyber device determination. The eSTAR asks the question. The file should contain the three-test analysis with the interfaces named, even when the answer is no.
- A management plan without timelines. Section VII.C.1 asks for the timeline, with justification, for regular-cycle and out-of-cycle updates. A plan that says "as needed" does not meet it.
- An SBOM without support status or end-of-support dates. Section V.A.4(b) asks for both, for every component.
- Known vulnerabilities listed but not assessed. The guidance asks for a safety and security risk assessment and the risk controls for each known vulnerability, including any in the CISA Known Exploited Vulnerabilities Catalog.
- Missing architecture views. Section V.B.2 describes four views. A single block diagram does not cover multi-patient harm or updatability.
- Testing without independence or scope. Section V.C asks penetration test reports to state the testers' independence and expertise, scope, duration, methods, and results. Internal developer testing alone is a common gap. CyberMed's penetration testing service produces reports written to that list.
- No traceability. Appendix 4 lists traceability across the threat model, risk assessment, controls, and testing. Reviewers ask for it when they cannot follow a threat to its control and its test.
- Labeling that omits cybersecurity. Section VI.A recommends specific cybersecurity labeling content. Its absence is a separate deficiency from the technical file.
The 5 reasons FDA will refuse your 510(k) post covers the same ground from the reviewer's side. A three-minute 524B readiness assessment checks a file against these triggers before submission.
Worked example: a cloud-connected patient monitor
The example is illustrative. It is a Class II, 510(k) patient monitor that streams vital signs to a cloud service over Wi-Fi and pairs with a companion mobile app over Bluetooth Low Energy. Firmware updates arrive from the manufacturer's update server. A USB port is used for factory provisioning and field service.
Cyber device determination. Test one: the monitor runs firmware and an embedded Linux application, and the sponsor validated both. Met. Test two: Wi-Fi, BLE, and USB each appear in the guidance's list of features that provide the ability to connect. Met. Test three: the network stack, the BLE pairing, the update client, and the USB service interface are characteristics that could be vulnerable. Met. The device is a cyber device, and the determination is documented with those interfaces named.
524B(b)(1). The management plan names the product security lead, lists the NVD, CISA KEV, and the Linux distribution's advisories as monitoring sources with a monthly review cadence, describes the CVD intake path and the customer advisory process, and states a quarterly regular update cycle with a 30-day target for out-of-cycle patches to uncontrolled risks. Each timeline carries a justification tied to the risk assessment.
524B(b)(2). The threat model covers the monitor, the app, the cloud service, and the update server as related systems. The four architecture views show the global system, the multi-patient harm path through the cloud tenant, the update chain with signing and rollback, and use cases for pairing, streaming, and service access. Controls trace to requirements, and the test report covers requirement verification, fuzzing of the BLE and network interfaces, and an independent penetration test with scope, duration, and methods stated.
524B(b)(3). The SBOM is generated from the firmware build and the app build in a machine-readable format, includes the embedded Linux packages and the mobile SDKs, and carries support status and end-of-support dates for each component. Known vulnerabilities are listed with a risk assessment and a disposition.
The whole set is attached in the eSTAR Cybersecurity section, with the software documentation in its own section. This is the shape of file that passes technical screening and gives the reviewer a single story to follow.
Statute versus guidance: how to read them together
The statute is short and mandatory. The guidance is long and written with "should." Section 3305(c) of FDORA states that nothing in Section 524B affects FDA's authority to ensure a reasonable assurance of safety and effectiveness, which may include a reasonable assurance of cybersecurity. FDA reads that to mean a reasonable assurance of cybersecurity can be part of its safety and effectiveness determination on every pathway.
The practical result is that a submission which satisfies the three 524B(b) obligations in the narrowest sense can still receive a deficiency, or a not substantially equivalent decision, if the guidance's recommended documentation is missing. The guidance gives the example of a central station alarm that lacks the encryption needed against a recently identified threat. FDA may ask for additional performance data and, if it is inadequate, find the device not substantially equivalent. Treat the guidance as the definition of "reasonable assurance" for review purposes.
Where CyberMed fits
CyberMed writes and tests the cybersecurity file that Section 524B and the guidance describe. The FDA cybersecurity documentation service produces the threat model, risk assessment, architecture views, controls, SBOM analysis, and management plan as one set with one author. Medical device penetration testing delivers the independent test report the guidance asks for. The 30-day Cybersprint combines both for teams with a submission date.
If the question is whether the current file is ready, start with the free FDA 524B readiness assessment. It takes three minutes and returns a gap report against the document list above.