Section 524B of the Federal Food, Drug, and Cosmetic Act changed the shape of a premarket submission for anything that connects. It is short, and the obligations it creates are specific.
It also catches more companies than they expect. Nothing in it requires hardware.
Software-only products are cyber devices
A cyber device is one that includes software validated, installed, or authorized by the sponsor, can connect to the internet, and has technological characteristics that could be vulnerable to cyber threats. Three conditions, and none of them mentions hardware.
FDA reads "software" broadly here: firmware and programmable logic, software inside a device, and Software as a Medical Device. A connected SaMD product going through a 510(k), De Novo, PMA, PDP, or HDE is a cyber device and carries all three obligations below.
Teams building software-only products often assume this section is aimed at infusion pumps and pacemakers. It is aimed at them too, and the reviewer comments arrive in the same language. What changes is which items apply. A web-and-cloud product will never be asked about a Bluetooth pairing model, and will be asked harder questions about tenant data segregation, API authorization on every request, and where its cloud provider's responsibility ends and its own begins.
The three requirements
A submission for a cyber device must include:
- A plan to monitor, identify, and address postmarket vulnerabilities and exploits, including a coordinated vulnerability disclosure process. This is a plan for what happens after clearance, submitted before it.
- Processes and procedures providing a reasonable assurance that the device and related systems are cybersecure, along with making postmarket updates and patches available.
- A software bill of materials, covering commercial, open-source, and off-the-shelf software components.
Three sentences of statute. Each one expands into a body of work that companies consistently underestimate, so they are worth taking one at a time.
The postmarket plan is a commitment, not a document
This is the requirement that looks easiest and ages worst, because you are submitting a promise about how your company will behave for years after clearance.
A plan that survives scrutiny has to say who receives a vulnerability report and how, how quickly it gets triaged, how exploitability is assessed against your specific product rather than in the abstract, how a patch reaches deployed units, and what your timelines are for each. FDA asks about those timelines directly. "As soon as practicable" is not a timeline.
The coordinated disclosure part means a researcher who finds something must have a way to tell you that does not involve guessing at an email address. If your product is connected and you have no published route for that, you have not met this.
The failure mode is not a badly written plan. It is a well-written plan describing a process that requires someone to own it, at a company where nobody does. The plan is then aspirational, and the first real disclosure demonstrates that to everyone at once.
"Reasonable assurance" is the vaguest and largest of the three
This is where most of the actual work lives, and its wording gives you no clue about the volume behind it.
In practice the agency is looking for a chain: threats identified through a structured threat model, risks assessed under a stated methodology with stated acceptance criteria, security controls specified as uniquely identified and testable requirements, and verification evidence traced back to each one. Not principles. Requirements.
The difference decides submissions, and turning a principle into a testable requirement is a specific exercise rather than an editing pass. It is the single conversion that most often decides whether the rest of the package holds together.
On methodology, FDA does not mandate one but expects you to declare yours. CVSS, AAMI TIR57, and ANSI/AAMI SW96 are the usual choices, and the guidance names SW96 alongside TIR57 in its security risk management section. Any of them is defensible. None of them is, if you have not said which you used and what your acceptance criteria are.
Testing sits inside this requirement too, and FDA treats penetration testing as the primary validation that the controls work in the finished product. Automated scans contribute; they are not the test. Each report is expected to establish tester independence and expertise, scope, duration, methods, and results - and what you do with that report becomes evidence in its own right, because every finding needs a disposition you can defend.
The SBOM is the easy half of an SBOM requirement
Generating a bill of materials is a solved tooling problem. Producing it in a machine-readable format, covering transitive dependencies, with component versions, suppliers, and support and end-of-support dates, is a slightly harder solved problem.
None of that is the requirement. The requirement is what the SBOM obliges you to know.
An SBOM that exists is not an SBOM that has been assessed. You are expected to run the inventory against vulnerability sources - NIST's National Vulnerability Database and CISA's Known Exploited Vulnerabilities Catalog are the two named in review correspondence - and produce a safety and security risk assessment of what comes back, with risk controls for what matters and described compensating controls where you are not fixing something.
Do that honestly on a real codebase and roughly half your components have newer versions available and about one in ten carries a published vulnerability. Now you are triaging every one, deciding which are actually reachable in your product, upgrading those, and documenting the reasoning for the rest. Components that are out of support get their own treatment, because "no patch will ever exist for this" is a different conversation from "we are behind."
That is the work. Generating the document took an afternoon.
Refuse to accept is a real gate
These are not supporting detail that a reviewer will chase you for. Since 1 October 2023, FDA has been able to base a refuse-to-accept decision on Section 524B content alone. Before that date it worked through interactive and deficiency review instead.
The distinction matters for planning. A refuse-to-accept decision means the submission never entered substantive review. A deficiency letter means it was accepted, reviewed, and found wanting, which starts a 180-day clock and pauses the review. Missing 524B content risks the first. Inadequate 524B content produces the second.
Check which guidance you are writing to
FDA's current guidance is Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, issued 3 February 2026. It supersedes the 27 June 2025 document of nearly the same name, which in turn replaced the September 2023 one and added the section dealing specifically with how Section 524B applies.
The 2026 revision is not a change of substance. It aligns the guidance to the Quality Management System Regulation, which took effect on 2 February 2026 and incorporates ISO 13485:2016 by reference - so references to subsections of 21 CFR 820 become references to subclauses of the standard. What the agency expects technically is unchanged: secure design, threat modeling, authentication, testing, supply chain, patching.
The churn is the point. Three versions in under three years, and the retitle is easy to miss because only one word moved. A submission that has been in preparation for a while was written against a superseded document, and the reviewer is reading it against the current one. Check what is current on the day you send, not after somebody else does.
Where submissions actually fall down
The SBOM gets the attention because it is concrete. It is rarely the problem.
The problems I see are more mundane:
Security claims that nobody verified. An architecture document asserts a protection the product is supposed to provide. Then someone reads the implementation and finds the claim does not hold. I have never audited a submission's security claims against a shipped product and found zero mismatches. The software-only version is an architecture document asserting that a service is unreachable from the internet, or a field is encrypted at rest, or an endpoint requires authentication - written once, true then, never re-checked. An inaccurate security claim is worse than an absent one, because it misrepresents the product to the person deciding whether it is safe.
A vulnerability monitoring plan with no owner. Covered above, and it remains the single most common gap between a submission and a company.
Attack surface nobody has counted. Legacy API endpoints, debug interfaces, and diagnostic services accumulate. They rarely appear in the architecture document because nobody remembers adding them. They do appear in a penetration test - at which point you discover whether anyone in the building is equipped to close what it finds.
What to do about it
Audit your own claims before a reviewer does. Read the submission documentation against the running system - the firmware, the deployed infrastructure, the actual configuration - and treat every security assertion as something to be evidenced rather than restated. This is unglamorous and it is the highest-value week available to you.
Reduce what you have to defend. Production logs will tell you which interfaces are genuinely in use. Removing the rest is the cheapest security work there is, and it shrinks what testing has to cover and what documentation has to describe.
Name the owner of the postmarket plan before you submit it, and make sure that person knows they own it.
Convert your control descriptions into numbered testable requirements now, while it is your schedule. Doing it later, under a deficiency letter, means doing the same work with less time and an agency waiting.
This is engineering guidance, not legal or regulatory advice. Regulatory strategy for a specific submission belongs with your regulatory lead.