Key Takeaways
- An SBOM is required, but not enough. FDA 524B requires proof of active software risk control, including vulnerability analysis, remediation decisions, and postmarket monitoring.
- Exploitability analysis is the differentiator. The FDA doesn’t expect zero vulnerabilities, but it does expect documentation of which ones matter and why.
- Submission gaps can lead to FDA Additional Information requests, which can delay clearance if responses are incomplete or late.
- RunSafe supports 524B submissions by providing SBOM generation, CVE analysis, binary-level risk mitigation, and continuous monitoring.
Section 524B of the Federal Food, Drug, and Cosmetic Act changed the compliance calculus for medical device manufacturers. Since its enactment, the FDA has required manufacturers of “cyber devices” to include specific cybersecurity evidence in their pre-market submissions as proof that software risk is understood and controlled throughout the device lifecycle.
The challenge most manufacturers run into is this: 524B compliance is not a documentation exercise. An SBOM alone does not satisfy the FDA. What reviewers look for is evidence that a manufacturer knows what software is in its device, understands the vulnerabilities, has made informed decisions about risk, and has a plan to continue monitoring once the device ships.
Section 524B is a meaningful technical and organizational commitment, and the gap between submitting paperwork and demonstrating genuine control is where submissions get delayed.
What Section 524B Requires
For cyber devices, FDA’s 524B framework calls for cybersecurity information in the premarket submission that covers three broad areas: a software inventory, processes for secure development and vulnerability management, and a postmarket plan to monitor, identify, and address vulnerabilities and exploits. FDA’s more recent guidance also emphasizes threat modeling, secure development practices, and documentation that supports reasonable assurance of cybersecurity.
Several key areas to consider are:
A Software Bill of Materials (SBOM) that inventories all software components in the device, including commercial, open-source, and off-the-shelf components. This is the foundation. Without an accurate SBOM, everything downstream is unreliable.
Security assurance and remediation processes that show the device was developed securely and that the manufacturer can release patches and updates when vulnerabilities emerge. This is where secure development lifecycle (SDL) evidence comes in.
A postmarket monitoring plan demonstrating that vulnerability management continues after FDA clearance and that the manufacturer will identify newly disclosed CVEs affecting their components and act on them in a structured way.
What the FDA does not require is zero vulnerabilities. What they do require is proof that you know about your vulnerabilities, understand their risk in the context of your specific device, and have made defensible decisions about each one.
Where Medical Device Manufacturers Get Stuck
Many manufacturers can generate an SBOM, but struggle to prove that it reflects the software actually present in the finished device. That becomes especially challenging when an inventory is derived only from manifests or declarations rather than from the build output or the delivered binary.
Vulnerability management is even harder. A list of CVEs tied to SBOM components is helpful, but FDA reviewers are also looking for the manufacturer’s risk-based rationale: which issues matter, which are mitigated, which are not exploitable in the device’s actual architecture, and which are being actively monitored or remediated.
Additional Information (AI) requests are the practical consequence of submission gaps. A single AI cycle can add 30 to 90 or more days to clearance. Given that manufacturers have 180 calendar days to respond, a complex AI request about vulnerability management methodology can consume most of that window. The cost of getting this wrong is not abstract.
How RunSafe Security Supports 524B Compliance
RunSafe supports manufacturers with technical evidence that can strengthen FDA cybersecurity submissions, including SBOM generation, vulnerability analysis, binary-level risk reduction, and postmarket software inventory monitoring. These capabilities can help manufacturers document how they identify software components, assess vulnerabilities in context, and maintain a repeatable process for managing cybersecurity risk over time.
SBOM Generation (RunSafe Identify)
RunSafe Identify generates a build-time SBOM for embedded systems during the compilation process. Because it captures what is actually compiled into the binary—not what is declared in a manifest—it produces an inventory that reflects the real device. Output aligns with CycloneDX and the NTIA minimum elements, and is formatted for FDA submission.
This matters because the FDA expects a “live, validated” software inventory. A build-time SBOM provides a defensible answer when reviewers ask how the manufacturer knows the SBOM is accurate.
Vulnerability Analysis (RunSafe Identify)
RunSafe’s Risk Reduction Analysis maps SBOM components to known CVEs and vendor advisories and, critically, assesses exploitability, not just presence. This allows manufacturers to produce structured documentation that explains which vulnerabilities are applicable to the device, which are not exploitable given the device architecture, which are mitigated by existing controls, which require remediation, and which are formally accepted with documented justification.
That distinction matters significantly for FDA review. A static list of CVEs is not a vulnerability management process. An exploitability analysis with risk-based remediation decisions is. RunSafe’s analysis also supports Vulnerability Exploitability eXchange (VEX) documentation, which is increasingly expected as part of a complete submission package.
Risk Mitigation (RunSafe Protect)
When a patch is unavailable — a common situation in embedded medical device development, where vendor timelines and device stability requirements constrain remediation — manufacturers need a way to demonstrate risk reduction. RunSafe Protect makes classes of memory-based vulnerabilities non-exploitable at the binary level, without requiring source code rewrites.
For FDA reviewers, this provides measurable evidence that exploitation risk has been reduced even where patching is not immediately possible. It strengthens the cybersecurity risk assessment section of the submission and supports the assurance case that the device is secure despite known vulnerabilities.
Postmarket Monitoring (RunSafe Identify)
Section 524B requires evidence that a postmarket monitoring plan is operational. RunSafe Identify enables continuous monitoring for newly disclosed CVEs affecting SBOM components, including memory-based zero-day disclosures. It also performs SBOM comparisons between builds, so manufacturers can demonstrate that changes to the software inventory are tracked and reviewed.
This supports the postmarket cybersecurity plan with a structured, repeatable process rather than a policy statement.
What a Stronger 524B Submission Looks Like
FDA reviewers are looking for manufacturers who know their devices, control their software risk, and can demonstrate it in writing. The standard is governance, not perfection.
RunSafe helps manufacturers build that governance and document it in a format that FDA reviewers can evaluate. Earlier identification of vulnerabilities during development means fewer surprises during review, less expensive remediation, and a submission package that reflects real security posture rather than a snapshot assembled under deadline pressure.
RunSafe Security provides vulnerability identification, SBOM generation, and software protection for embedded devices. Learn more about how RunSafe supports medical device manufacturers in building and evidencing 524B-compliant cybersecurity programs.
FAQs
Section 524B of the FD&C Act requires manufacturers of “cyber devices” to include three core elements in pre-market submissions: a Software Bill of Materials (SBOM) identifying all software components; documented security assurance and remediation processes showing the device was developed securely and can be patched; and a postmarket monitoring plan demonstrating ongoing vulnerability management after FDA clearance. The FDA does not require zero vulnerabilities but evidence that the manufacturer understands and controls software risk across the device lifecycle.
Is an SBOM alone sufficient for FDA 524B compliance?
No. An SBOM is a required starting point, but 524B compliance requires manufacturers to go further. The FDA expects manufacturers to map SBOM components to known vulnerabilities, assess exploitability in the context of the specific device architecture, document risk-based remediation decisions, and demonstrate that vulnerability monitoring will continue postmarket. Submitting an SBOM without the supporting vulnerability analysis and governance documentation is a common reason submissions receive Additional Information (AI) requests.
What is a VEX document and why does it matter for FDA submissions?
A VEX (Vulnerability Exploitability eXchange) document communicates the exploitability status of CVEs identified in a device’s SBOM components. For each vulnerability, a VEX statement indicates whether it is exploitable, not affected, mitigated, or under investigation, along with a supporting rationale. FDA reviewers increasingly expect VEX documentation as part of the vulnerability management record because it demonstrates that the manufacturer has assessed risk in the context of its specific device, rather than simply generating a list of CVEs.
What happens if my FDA 524B submission has gaps in cybersecurity documentation?
The FDA will issue an Additional Information (AI) request — a formal request for clarification or supplemental evidence. Manufacturers have 180 calendar days to respond, but depending on the complexity of the request, a single AI cycle can add 30 to 90 or more days to the clearance timeline. Repeated AI cycles or incomplete responses can delay market entry significantly. Early vulnerability identification and complete submission documentation are the most reliable way to avoid this.
How should medical device manufacturers handle vulnerabilities that cannot be patched?
When patches are unavailable—which is common in embedded medical device development due to vendor timelines and device stability requirements—manufacturers should document that the vulnerability has been assessed for exploitability, identify any existing controls that mitigate the risk, and, where possible, implement technical measures that reduce exploitation risk at the binary level. The FDA expects a risk-based decision with documented justification, not necessarily a patch. Binary-level hardening tools can make classes of memory-based vulnerabilities non-exploitable without requiring source code changes, which provides measurable, documentable risk reduction.
What is a build-time SBOM and why does it matter for FDA compliance?
A build-time SBOM is generated during compilation and reflects the components included in the final software binary — unlike SBOMs derived from package manifests or dependency declarations, which can miss components added at compile time. For FDA submissions, a build-time SBOM is more defensible because it directly reflects what is in the device, not what was declared during development. The FDA expects a “live, validated” software inventory, and build-time generation is the most reliable way to demonstrate that the SBOM is accurate.
What is postmarket cybersecurity monitoring under FDA 524B?
Postmarket monitoring under 524B refers to the ongoing process of identifying newly disclosed vulnerabilities that affect a device’s software components after it has received FDA clearance and reached the market. Manufacturers are expected to maintain a documented, operational process for tracking new CVEs, assessing their relevance to the device, and responding in a structured way. A policy statement is not sufficient. The FDA looks for evidence that the process is real, repeatable, and tied to the actual software inventory in the device.
