The §524B
readiness checklist.
Since March 2023, FDA can refuse a premarket submission for a cyber device that does not meet §524B. These are the twelve things a §524B cybersecurity package needs. Use it to see where you stand before a submission, or a reviewer, tells you.
Twelve items, one coordinated set.
A security risk management plan and report
The process, documented. Security risk assessed with the same rigor as patient-safety risk. FDA expects the two to live in one risk framework.
A threat model
The backbone of the whole package. Your system, its data flows, and its trust boundaries, with the threats against each and how you mitigate them. Reviewers use it to judge whether your controls match your risks.
A cybersecurity risk assessment
Risk, scored and justified. Each threat rated for how exploitable it is and how much patient harm it could cause, paired with the control that reduces it. This is how you show residual risk is acceptable.
A software bill of materials (SBOM)
Non-negotiable. A machine-readable inventory of every software component, including third-party and open-source, with versions and support status. §524B calls out the SBOM by name.
A known-vulnerability assessment
The other half of the SBOM. Your components checked against known vulnerabilities, with a documented handling decision for each. An inventory without this analysis meets only part of the requirement.
Security architecture views
The device, drawn four ways. FDA expects the architecture documented across specific views, including how the device is updated and how it limits harm across patients. These views show how the device defends itself.
Secure product development evidence
Built in, not bolted on. Evidence that security ran through the development lifecycle rather than being added at the end. The guidance is built around a secure product development framework.
Security testing and reports
Proof, on the record. Vulnerability scanning, penetration testing, and SBOM analysis, with the reports and a record of how findings were resolved. Claims without test evidence do not hold.
A coordinated vulnerability disclosure process
A way to hear about problems. A defined process to receive, assess, and act on vulnerability reports after the device ships. §524B requires a plan to monitor and address postmarket cybersecurity.
A postmarket monitoring and patching plan
Defensible for the device's whole supported life. How you will identify, disclose, and deploy security updates, and how quickly. The device has to stay secure over time.
Security labeling
What you tell the operator. The security-relevant information for users: the controls, the required configuration, and the end-of-support date. Labeling is part of the premarket cybersecurity information.
A PCCP, if your AI/ML model updates
The one most AI teams miss. A predetermined change control plan defining which model changes are pre-authorized and how each is validated, so the model can keep improving without a new submission. Without it, every update risks starting over.
This is a readiness checklist. We specify the controls and coordinate the documentation with our regulatory partner. Predicate selection, substantial equivalence, and the 510(k) submission and filing route through that regulatory-affairs network.
Want to know which of the twelve you already have, and which you don't?
Walk it through with us →
or start the free scoping questionnaire at ferendis.com/start