FDA Section 524B, explained: what reasonable assurance of cybersecurity requires.
Section 524B lets the FDA refuse to accept a cyber device submission that can't show cybersecurity. This guide maps each obligation to the evidence a submission actually needs.
FD&C Act §524B requires makers of cyber devices to show a reasonable assurance of cybersecurity: a postmarket vulnerability-management plan, secure-design and update processes, and a software bill of materials. The operative premarket guidance was finalized June 27, 2025.[3][7] RankShieldMD produces evidence that supports your submission, not the submission itself, and it is non-device and PHI-free by design.
A cyber device,
defined precisely.
Section 524B applies to a cyber device, defined by a three-part test: it includes device software, it can connect to the internet, and it has a characteristic that could be vulnerable to cybersecurity threats.[7] A device that meets all three is in scope, and its submission carries the §524B obligations. Connectivity is the part most often missed, because peripheral, wireless, and service-network pathways are easy to overlook. RankShieldMD helps a device in scope produce the evidence its submission relies on; the classification decision stays yours and the FDA's.
Three duties.
Three artifacts.
Section 524B(b) names three obligations. (b)(1) a postmarket plan to monitor, identify, and address vulnerabilities with coordinated disclosure; (b)(2) processes for a reasonable assurance the device is cybersecure, with updates and patches; (b)(3) a software bill of materials.[7] RankShieldMD produces each as a signed, verifiable artifact: a postmarket decision feed for (b)(1), post-quantum device identity plus compensating-control containment for (b)(2), and a CycloneDX SBOM for (b)(3), each externally anchored and independently checkable.
A signed
bill of materials.
The §524B(b)(3) SBOM has to cover commercial, open-source, and off-the-shelf components. RankShieldMD emits it in the standard CycloneDX and SPDX formats, machine-readable and human-readable, and seals each to the transparency ledger tied to a specific build.[3] For AI-enabled devices it can also emit a clinical AIBOM describing models, datasets, and lineage. The AIBOM is a voluntary, emerging practice rather than a statutory §524B requirement, and we present it that way, so the SBOM is the signed artifact your reviewer confirms.
Evidenced
continuously.
Section 524B(b)(1) expects a plan to monitor, identify, and address postmarket vulnerabilities within a reasonable time, with coordinated disclosure behind it.[7] RankShieldMD produces a signed decision and integrity feed that records vulnerability identification, triage, and disposition as they happen, sealed to an externally-anchored ledger with a verify recipe. Instead of a one-time attestation, the postmarket obligation becomes a stream a reviewer can inspect and recompute, filing directly into the submission and the quality record rather than being reconstructed later.
The evidence
a reviewer can check.
Below: what a cyber device is, the three §524B(b) obligations, the SBOM formats the FDA accepts, how postmarket monitoring becomes evidence, and how each obligation maps to a signed artifact. Evidence that supports your submission, verifiable, PHI-free, non-device.
What FDA §524B requires, in one paragraph.
FDA §524B requires makers of cyber devices to show a reasonable assurance of cybersecurity through three things: a postmarket vulnerability-management plan with coordinated disclosure, secure-design and update processes, and a software bill of materials, backed by evidence the agency can refuse to accept a submission without. Section 524B was added to the Food, Drug, and Cosmetic Act by the Consolidated Appropriations Act 2023 and took effect March 29, 2023, giving the FDA authority to refuse to accept a premarket submission for a cyber device that lacks adequate cybersecurity information.[7] A cyber device is defined by a three-part test: it includes device software, it can connect to the internet, and it has a characteristic that could be vulnerable to cybersecurity threats. The operative premarket guidance describing how the agency expects a reasonable assurance of cybersecurity to be demonstrated was finalized June 27, 2025.[3] What §524B does not do is hand you a checklist a tool can silently satisfy; it describes obligations you must be able to evidence at the point of submission. That is where RankShieldMD works: it produces evidence that supports your submission, a signed postmarket feed, post-quantum device identity, and a CycloneDX SBOM sealed to an externally-anchored, post-quantum-signed transparency ledger. It never makes your submission, never makes you compliant or cleared, and works on device identity and integrity, never on protected health information.
It puts device makers ahead of where regulation is heading, not past a rule that already exists: the FDA expects crypto-agility and migration planning today and does not mandate post-quantum cryptography, and an AIBOM remains a voluntary practice rather than a §524B requirement.
How do you meet FDA 524B cybersecurity requirements?
You meet §524B by turning each of its three statutory obligations into concrete, inspectable evidence before you file, rather than a narrative you assemble at the last minute.
Section 524B(b) names the obligations precisely: a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits in a reasonable time with a coordinated disclosure process; a design and processes that provide a reasonable assurance the device and the systems it connects to are cybersecure, along with updates and patches; and a software bill of materials covering commercial, open-source, and off-the-shelf software components.[7] The way to meet each one is to produce it as an artifact a reviewer can hold and check. RankShieldMD does exactly that. It generates a signed postmarket decision and integrity feed for (b)(1), a composite post-quantum device identity plus compensating-control containment for (b)(2), and a CycloneDX SBOM for (b)(3), and it seals each to an externally-anchored, post-quantum-signed transparency ledger with a verify recipe. A reviewer, an auditor, or a buyer can then recompute and confirm the artifact without trusting a dashboard. The obligation stays yours; what changes is that the evidence behind it is verifiable rather than asserted. RankShieldMD produces evidence that supports your submission. It never makes your submission, and it never makes you compliant or cleared.
What is a cyber device under §524B?
A cyber device is defined by a three-part test, and a device that meets all three parts is subject to the §524B requirements.
The statute defines a cyber device as one 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 characteristic that could be vulnerable to cybersecurity threats.[7] All three parts must be present. The element most often overlooked is connectivity, because peripheral ports, wireless links, and service-network pathways are easy to miss when a device is assessed as if it lived on an island. A device that genuinely cannot connect to the internet may fall outside the strict definition, but manufacturers should assess connectivity carefully rather than assume it away, because a wrongly excluded device that later proves connected is a refuse-to-accept waiting to happen. Where a device is in scope, its premarket submission, whether a 510(k), a PMA, or a De Novo request, must carry the §524B cybersecurity information. RankShieldMD produces the identity, SBOM, and postmarket evidence an in-scope device relies on. It does not render the classification decision for you; that determination is yours and the FDA's, and RankShieldMD is deliberately non-device so it never pulls you across a regulatory line.
What are the three §524B(b) obligations?
Section 524B(b) names three obligations, and the strongest way to satisfy each is a signed artifact rather than a paragraph of prose.
The first, §524B(b)(1), is a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits, including a coordinated vulnerability disclosure process and related procedures, so that issues found in the field are handled within a reasonable time.[7] The second, §524B(b)(2), is to design, develop, and maintain processes and procedures that provide a reasonable assurance the device and the systems it connects to are cybersecure, and to make available postmarket updates and patches. The third, §524B(b)(3), is to provide a software bill of materials, including commercial, open-source, and off-the-shelf software components. Each obligation is a place a submission can be refused if the evidence is missing or merely narrated. RankShieldMD produces each as a verifiable artifact: a signed postmarket decision feed for (b)(1); post-quantum device identity with compensating-control containment and posture evidence for (b)(2), including devices that cannot be patched; and a CycloneDX or SPDX SBOM for (b)(3), sealed to a transparency ledger and tied to a specific build. It produces evidence that supports these obligations. It does not satisfy them on your behalf, and the FDA remains the deciding authority.
What SBOM formats does the FDA accept?
The FDA expects the §524B(b)(3) software bill of materials in a machine-readable format, and the two widely adopted standards are CycloneDX and SPDX.
A software bill of materials is the ingredient list for a device's software, covering commercial, open-source, and off-the-shelf components, and the premarket guidance the FDA finalized June 27, 2025 expects it in a machine-readable form so a reviewer and a pipeline can both parse it.[3][7] CycloneDX and SPDX are the two standard, widely adopted formats, both machine-readable and both renderable as human-readable views, so the same bill of materials serves an automated dependency check and a human examiner without being maintained twice. RankShieldMD emits the SBOM in CycloneDX and SPDX, produces human-readable views alongside them, and can seal each SBOM to the post-quantum-signed transparency ledger tied to a specific build. That means the exact components running on a given device version are a confirmable fact rather than a document that quietly drifts out of date between releases. For AI-enabled devices, RankShieldMD can also emit a clinical AIBOM, an AI bill of materials describing the models, datasets, and lineage behind the device, the way an SBOM describes software.[5] The AIBOM is a voluntary, emerging practice rather than a §524B statutory requirement, and we present it as strengthening the record, not satisfying a rule. The SBOM becomes a signed, tamper-evident artifact, not a screenshot in a slide deck.
How do you produce postmarket monitoring evidence for FDA?
You produce it as a signed, continuously updated feed rather than a one-time attestation that a program exists.
Section 524B(b)(1) expects a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits within a reasonable time, with a coordinated disclosure process behind it, and the weakest version of that evidence is a policy document that describes an intention.[7] The stronger version is a running record that shows the program actually operating. RankShieldMD produces a signed decision and integrity feed that captures vulnerability identification, triage, and disposition as they happen, and seals each event to an externally-anchored transparency ledger with a verify recipe, so the postmarket program is evidenced continuously rather than attested once. A reviewer or auditor can open the feed, see how a specific vulnerability was handled, and recompute the record to confirm it has not been altered after the fact. Because the evidence is exportable and independently verifiable, it also files as objective evidence in a quality record. The Quality Management System Regulation, which harmonizes the FDA quality-system requirements with ISO 13485, takes effect February 2, 2026 and expects objective evidence that processes were followed and risk decisions justified, and signed postmarket records, SBOMs, and device-identity credentials drop into that record rather than being reconstructed at audit time. It supports your postmarket program; the FDA remains the deciding authority.
Where to go next.
The obligations, produced as evidence
The postmarket, secure-design, and SBOM artifacts a §524B submission relies on, produced as signed evidence for regulatory, quality, and product-security leads.
Explore → UNPATCHABLE DEVICESContain the device you can't patch
Compensating-control segmentation, verifiable posture, and ISO 14971 residual-risk dossiers for unpatchable and end-of-life devices still serving patients.
Explore → AIBOMAn AI bill of materials for clinical AI
What an AIBOM is, how CycloneDX ML-BOM applies to AI-enabled devices, and why it strengthens the record while remaining a voluntary practice, not a mandate.
Explore →What we are careful never to claim.
It supports your submission
RankShieldMD produces evidence that supports your §524B submission. It never makes your submission, never renders an FDA decision, and cannot make an organization compliant or cleared.
The FDA doesn't mandate PQC yet
Today the FDA expects crypto-agility and migration planning. RankShieldMD puts you ahead of where regulation is heading, not past a rule that already exists. Quantum-safe, not quantum-proof.
It's device identity, not PHI
RankShieldMD works on device identities, credentials, SBOMs, and posture evidence. It is non-device and PHI-free by construction, and the AIBOM it can emit is voluntary, not a §524B mandate.
References
- [3] FDA (June 27, 2025, final). Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions. federalregister.gov/documents/2025/06/27/2025-11669
- [5] Frontiers in Computer Science (Jan 2026). AI bill of materials (AIBOM / ML-BOM) definition, Radanliev et al. frontiersin.org/journals/computer-science/…/fcomp.2026.1735919
- [7] FD&C Act §524B (added by the Consolidated Appropriations Act 2023, effective March 29, 2023). fda.gov/medical-devices/…/cybersecurity
- SBOM Standard machine-readable software bill of materials formats referenced above: CycloneDX (cyclonedx.org) and SPDX (spdx.dev).
FDA §524B: questions, answered.
How do you meet FDA 524B cybersecurity requirements?
You meet Section 524B by turning each of its three statutory obligations into concrete, inspectable evidence before you file, rather than a narrative you assemble at the last minute. Section 524B(b) names them: a postmarket plan to monitor, identify, and address vulnerabilities with coordinated disclosure, a design and processes providing a reasonable assurance the device is cybersecure with updates and patches, and a software bill of materials. The operative premarket guidance was finalized June 27, 2025.[3] The way to meet each one is to produce it as an artifact a reviewer can hold and check. RankShieldMD produces evidence that supports your submission, a signed postmarket feed, post-quantum device identity, and a CycloneDX SBOM. It never makes your submission and never makes you compliant or cleared.
What is a cyber device under §524B?
A cyber device is defined by §524B with a three-part test: the device includes software validated, installed, or authorized by the sponsor as a device or in a device; the device has the ability to connect to the internet; and the device contains any such technological characteristic that could be vulnerable to cybersecurity threats.[7] A device that meets all three parts is a cyber device, and its premarket submission is subject to the §524B requirements. A device that genuinely cannot connect to the internet may fall outside the strict definition, but manufacturers should assess connectivity carefully because peripheral, wireless, and service-network pathways are easy to overlook. RankShieldMD helps a cyber device produce the postmarket, secure-design, and SBOM evidence those requirements rely on. It does not render the classification decision for you; that determination is yours and the FDA's.
What are the three §524B(b) obligations?
Section 524B(b) names three obligations for a cyber device submission. (b)(1) is a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits in a reasonable time, including a coordinated vulnerability disclosure process.[7] (b)(2) is a design and processes that provide a reasonable assurance the device and the systems it connects to are cybersecure, together with the processes to make available updates and patches. (b)(3) is a software bill of materials covering commercial, open-source, and off-the-shelf software components. RankShieldMD produces each as a signed, verifiable artifact: a postmarket decision feed for (b)(1), post-quantum device identity plus compensating-control containment for (b)(2), and a CycloneDX SBOM for (b)(3). It produces evidence that supports these obligations; it does not satisfy them on your behalf.
What SBOM formats does the FDA accept?
The FDA expects the §524B(b)(3) software bill of materials in a machine-readable format, and the two widely adopted standards are CycloneDX and SPDX.[3][7] Both are machine-readable and can be rendered human-readable, so the same bill of materials serves an automated pipeline and a human reviewer. The SBOM should cover commercial, open-source, and off-the-shelf components. RankShieldMD emits the SBOM in CycloneDX and SPDX, produces human-readable views alongside them, and can seal each SBOM to a post-quantum-signed transparency ledger tied to a specific build, so the exact components running on a given device version are confirmable. The SBOM becomes a signed, tamper-evident artifact rather than a screenshot in a slide deck.
What is an AIBOM and is it required?
An AI bill of materials, or AIBOM, describes the models, datasets, and lineage behind an AI-enabled device the way an SBOM describes software components.[5] For AI-enabled medical devices RankShieldMD can emit a clinical AIBOM alongside the CycloneDX SBOM, so the AI supply chain is documented with the same rigor. An AIBOM is a voluntary, emerging practice rather than a §524B statutory requirement, and we present it that way. It strengthens the record for AI-enabled devices; it is not something the statute currently mandates. Positioning it honestly matters: a device maker adopting an AIBOM is ahead of where practice is heading, not satisfying a rule that already exists.
How do you produce postmarket monitoring evidence for FDA?
You produce it as a signed, continuously updated feed rather than a one-time attestation that a program exists. Section 524B(b)(1) expects a plan to monitor, identify, and address postmarket vulnerabilities and exploits within a reasonable time, with a coordinated disclosure process behind it.[7] RankShieldMD produces a signed decision and integrity feed that records vulnerability identification, triage, and disposition as they happen, sealed to an externally-anchored transparency ledger with a verify recipe. Instead of a narrative reconstructed at submission time, the postmarket obligation becomes a stream a reviewer or auditor can inspect and recompute. The evidence is exportable and independently verifiable, so it files directly into the submission and the quality record. It supports your postmarket program; the FDA remains the deciding authority.
Is RankShieldMD a medical device, and does it touch patient data?
No on both. RankShieldMD is security and quality tooling that helps device manufacturers evidence their §524B obligations. FDA classification turns on intended use, and RankShieldMD attests device identity and integrity; it never renders, drives, or influences a clinical decision, so it stays non-device by design. It also works on device identities, credentials, signed commands, SBOMs, and posture evidence, never on protected health information, so it is PHI-free by construction. The device keeps doing its clinical job through its own systems, and RankShieldMD only proves identity and integrity. It attests; it never renders. And it produces evidence that supports your submission; it does not make you compliant or cleared.
Turn the §524B requirement into evidence you can hand over.
Bring a device or a fleet. We'll show you the §524B obligations produced as signed evidence, an SBOM your reviewer can verify, and residual-risk dossiers for what you can't patch. Evidence that supports your submission, verifiable, PHI-free, non-device.