The record has no cybersecurity field
Since March 2023, a 510(k), PMA, or De Novo for a device FDA calls a "cyber device" cannot even be accepted without a software bill of materials and a vulnerability-management plan. The public clearance record that comes back afterward — FDA's own, and FDA Radar's copy of it — carries neither one.
By Connor Griggs — Regulatory & Quality Strategist
Since March 29, 2023, a device that meets FDA’s definition of a “cyber device” cannot clear, get approved, or get a De Novo grant without a submission that includes a software bill of materials and a plan for handling vulnerabilities discovered after it ships. Search the public clearance record for either one afterward, and neither is there.
What Section 524B actually requires
Section 524B of the FD&C Act — 21 U.S.C. § 360n-2, added by the Consolidated Appropriations Act, 2023, and in effect since March 29, 2023— applies to any “cyber device”: one that includes software, can connect to the internet, and has technological characteristics that could be vulnerable to a cybersecurity threat. A 510(k), PMA, product development protocol, De Novo request, or humanitarian device exemption for a device meeting that definition has to include a plan to monitor and address postmarket vulnerabilities, a coordinated vulnerability-disclosure process, evidence the device can be patched and updated, and a software bill of materials — every commercial, open-source, and off-the-shelf component in it. Since October 1, 2023, FDA can refuse to even accept a submission missing any of it.
None of that content is a field. It is an attachment FDA reviewed once, before the number ever cleared — and the number is the only part of the story the public record keeps.
The record that comes back has none of it
openFDA’s 510(k) endpoint — the one FDA Radar’s own pipeline reads daily — publishes a K-number, applicant, device name, product code, decision date, decision code, advisory-committee panel, and a third-party-review flag. FDA Radar’s adapter carries exactly those fields and nothing else, because the endpoint has nothing else to carry: no cyber-device flag, no SBOM, no record of which vulnerability-disclosure commitment a specific K-number made. A device cleared under Section 524B and a device cleared before the section existed produce, today, an identical shape of public record.
The practice
A predicate search or a competitive read on a connected device can confirm a clearance happened, and when — not whether the underlying SBOM was current, or what the vulnerability plan actually committed the applicant to. That content sits inside the submission FDA reviewed, handled like any other confidential commercial information in the file, not the public 510(k) summary. Reading “cleared” as a cybersecurity judgment about a device is a mistake the record itself doesn’t support — FDA’s own guidance on the section is the primary document for what a submission had to contain, and it was never written to describe what the clearance record discloses afterward. This is regulatory intelligence about what a public record can and can’t show, never regulatory advice about a specific device’s cybersecurity posture — that determination belongs to whoever holds the file. FDA Radar ingests this same K-number record daily, on the schedule the sources page states; the gap described here sits upstream of ingestion, not a limitation this pipeline could close by reading more often.
Primary sources
- Federal Register — Cybersecurity in Medical Devices: Refuse To Accept Policy for Cyber Devices Under Section 524B (guidance availability)
- FDA — Cybersecurity in Medical Devices (Digital Health Center of Excellence)
- openFDA — Device 510(k) field reference
- FDA Radar — what we monitor and how often
Regulatory intelligence, not regulatory advice. This post describes method and published FDA records as of its date; decisions about a specific device belong with your regulatory professional.