FDA Section 524B Medical Device SBOM and Postmarket Cybersecurity: Implementation Guide
Reach 50,000+ security professionals
Sponsor a newsletter slot and put your brand in front of CISOs, engineers, and IT decision-makers.
Medical device cybersecurity shifted from aspirational guidance to enforceable requirement in October 2023, when the FDA began refusing to accept premarket submissions lacking the cybersecurity documentation required by Section 524B of the FD&C Act. For manufacturers who had not built SBOM generation and postmarket vulnerability management programs, this created an immediate submission backlog. For teams building compliance programs now, the requirements are specific and testable. For broader SBOM implementation context applicable across software-intensive products, see this software supply chain security and SBOM implementation guide.
What Section 524B Actually Requires
Section 524B applies to any premarket submission (510(k), PMA, De Novo, HDE) for a device that contains software or that is or contains a device with cyber components. The requirements are:
1. Software bill of materials: The SBOM must include all commercial, open-source, and off-the-shelf software components. The FDA guidance references NTIA minimum elements: supplier name, component name, component version, other unique identifiers, dependency relationships, author of SBOM data, and timestamp.
2. Postmarket vulnerability monitoring: The manufacturer must describe a plan for monitoring newly disclosed vulnerabilities in SBOM components. The plan must specify the monitoring sources (NVD, vendor advisories, ICS-CERT, sector ISACs), the assessment process for evaluating clinical impact, and the response timeline targets.
3. Patch and update capability: The device must be capable of receiving security updates. The submission must describe how updates are delivered (OTA, physical access, hospital IT workflow), tested (regression testing scope), and authorized (code signing, firmware validation).
4. Coordinated vulnerability disclosure: The manufacturer must have a published vulnerability disclosure policy that provides security researchers with a defined channel to report vulnerabilities and commits to a response timeline.
5. Secure product development lifecycle: The submission must reference the SPDF the manufacturer uses (NIST SP 800-218, IEC 62443-4-1, or equivalent) and describe how cybersecurity is integrated into design, testing, and postmarket phases.
The FDA guidance notes that simply having an SBOM is not sufficient -- the SBOM must be current as of the submission date and must reflect the actual software version submitted.
Building a Compliant SBOM Pipeline
An SBOM pipeline for a medical device must be repeatable, version-controlled, and capable of producing an accurate SBOM for any released firmware or software version on demand. The key steps:
Step 1 -- Choose a generation approach:
- Source-analysis tools (Syft, FOSSA, Black Duck): scan source code and build artifacts to identify components. Highest accuracy for components included in the build.
- Binary analysis tools (Binwalk, Firmwalker, BinwalkX): extract and analyze compiled firmware images to identify embedded components. Required for devices where source code is not available for all components (OEM modules, third-party stacks).
- Build system integration (CMake component declarations, Yocto layer metadata): generate SBOM from build system component declarations. Most accurate but requires that all components are declared in the build system.
Step 2 -- Choose a format: The FDA guidance references SPDX and CycloneDX as acceptable formats. CycloneDX is generally preferred for medical device submissions because it has explicit support for vulnerability data linking and has been adopted by several FDA-focused SBOM tools.
Step 3 -- Establish version locking: The SBOM must reflect the exact component versions in the submitted device. This requires that the SBOM generation runs against the same build artifact (firmware image, installer package) that is submitted to the FDA, not against a development snapshot.
Step 4 -- Integrate with VEX: A Vulnerability Exploitability eXchange (VEX) document, linked to the SBOM, provides the manufacturer's assessment of whether disclosed vulnerabilities in SBOM components are exploitable in the specific device context. VEX reduces false-positive burden for hospital security teams managing device inventories.
Step 5 -- Archive by submission version: Maintain an archive of SBOM by firmware/software version so that postmarket vulnerability assessments can be traced back to the exact component list in deployed devices.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Postmarket Vulnerability Management Program Requirements
The FDA requires a postmarket vulnerability management plan that describes how the manufacturer will:
Monitor for new vulnerabilities: Establish subscriptions to NVD CVE feeds filtered by SBOM components, vendor security advisories for all third-party components, ICS-CERT/CISA advisories for healthcare sector, and relevant ISAC feeds (H-ISAC). Automated SBOM-CVE matching tools (Anchore, FOSSA, Dependency-Track) can alert when a newly disclosed CVE matches a component in a shipped device SBOM.
Assess clinical impact: A newly disclosed CVE affecting an SBOM component requires a clinical risk assessment, not just a CVSS score. The assessment must answer: is the vulnerable component reachable from the attack surface of the device in its clinical use context? If exploited, what is the worst-case clinical impact (device malfunction, incorrect therapy delivery, data breach)? The FDA's postmarket cybersecurity guidance provides a risk framework distinguishing controlled (device has compensating controls) from uncontrolled (device is clinically vulnerable) risk.
Respond within defined timelines: The FDA distinguishes between:
- Critical/uncontrolled risk: Requires response within 30 days (patch deployment, mitigations, or clinical advisory)
- Non-critical/controlled risk: Requires a remediation plan within a reasonable timeframe, with routine patch deployment
Document decisions: Every vulnerability assessment decision must be documented: the CVE, the affected SBOM component, the clinical risk assessment, the remediation decision, and the deployment timeline. This documentation becomes part of the device history record.
Notify FDA when required: Certain cybersecurity incidents or significant vulnerabilities may trigger mandatory adverse event reporting. Document the criteria the organization uses to assess FDA notification requirements.
Patch and Update Delivery for Medical Devices
Section 524B requires that medical devices can receive security updates. This is a design requirement that affects pre-market architecture, not just a postmarket operations question.
Update delivery mechanisms for medical devices:
- OTA (over-the-air) via hospital network: Requires network connectivity from the device, which introduces additional attack surface that must be evaluated. Update packages must be code-signed and validated before installation.
- Portable media (USB, SD card): Lower attack surface but requires physical access and hospital IT coordination. Appropriate for air-gapped devices.
- Vendor-managed service: Manufacturer connects to the device remotely to push updates. Requires a secure remote access channel with strong authentication and audit logging.
Code signing requirements: All software updates must be signed by the manufacturer. The device must validate the signature before installing an update. Describe the key management process (CA, certificate rotation, key protection) in the submission.
Regression testing scope: The submission must describe what testing is required before an update is released. The FDA distinguishes between cybersecurity-only patches (which may require less regression testing than functional changes) and updates that change device functionality.
510(k) implications: Not all cybersecurity updates require a new 510(k). The FDA's 2022 guidance on when changes to software require a new premarket submission applies: cybersecurity patches that do not change intended use or risk profile generally do not require a new submission, but significant changes to the update delivery mechanism itself may.
Coordinated Vulnerability Disclosure Policy
Section 524B requires manufacturers to maintain a coordinated vulnerability disclosure (CVD) policy. The FDA's 2023 guidance specifies that the CVD policy must include:
A reporting channel: An email address or web form where researchers can submit vulnerability reports. The channel must be monitored and must not bounce or go to a catch-all inbox that is rarely reviewed.
Acknowledgment timeline: Manufacturers must commit to acknowledging receipt of a vulnerability report within a specified timeframe. The FDA recommends 24-72 hours.
Response timeline: Manufacturers must commit to providing a substantive response to the researcher within a specified timeframe. Industry standard is 90 days, though the FDA does not mandate a specific number.
Safe harbor commitment: The CVD policy must include a commitment not to pursue legal action against researchers who report vulnerabilities through the defined channel in good faith, within the scope of the policy.
PSIRT establishment: Most manufacturers building CVD programs also establish a Product Security Incident Response Team (PSIRT) to manage the intake, triage, assessment, and response workflow for reported vulnerabilities. The FDA guidance on the IMDRF PSIRT framework provides a template.
Common Submission Deficiencies and How to Avoid Them
The FDA publishes deficiency letter patterns through guidance updates and presentation materials. The most common Section 524B deficiencies observed in submissions:
SBOM generated from development snapshot, not released firmware: The SBOM must reflect the exact component versions in the submitted device image. If the SBOM was generated from a development branch rather than the released firmware, component versions may differ.
Missing transitive dependencies: The SBOM must include not just first-level dependencies but all transitive dependencies. Many teams generate SBOMs that include direct dependencies but miss libraries that those libraries depend on.
No VEX document: Submitting an SBOM that lists components with known CVEs without a VEX assessment leaves the FDA reviewer without the manufacturer's exploitability assessment. The FDA may issue a deficiency requesting the assessment rather than rejecting outright, but it delays the review.
Postmarket plan lacks monitoring sources: The postmarket vulnerability monitoring plan must name the specific sources the organization monitors. A generic statement that vulnerabilities will be monitored without naming NVD, vendor advisories, and sector feeds is insufficient.
Update mechanism not described for all device variants: If the device is sold in multiple configurations (network-connected and standalone), the update delivery mechanism must be described for each configuration.
The bottom line
FDA Section 524B compliance for medical device premarket submissions requires three concrete deliverables: a machine-readable SBOM in SPDX or CycloneDX format generated from the released firmware image (including transitive dependencies), a postmarket vulnerability management plan that names monitoring sources, defines clinical impact assessment criteria, and commits to response timelines, and a coordinated vulnerability disclosure policy with a monitored reporting channel and safe harbor commitment. Teams that have not yet integrated SBOM generation into the firmware build pipeline should do so before the next submission deadline -- retrospective SBOM generation from shipped firmware is possible but prone to errors from missing transitive dependencies. For the GRC framework context that postmarket vulnerability management fits within, see this compliance automation and GRC platform guide.
Frequently asked questions
When did FDA Section 524B become enforceable?
Section 524B was enacted in December 2022 as part of the Omnibus Consolidated Appropriations Act. The FDA provided an 18-month advisory period before beginning to enforce the submission requirements. In October 2023, the FDA began refusing to accept premarket submissions (510(k), PMA, De Novo, HDE) that did not include the required cybersecurity documentation. Submissions received before October 2023 that were already under review were not retroactively rejected, but any new submission from that date forward is subject to the requirements.
What SBOM format does the FDA require?
The FDA does not mandate a specific SBOM format but references SPDX and CycloneDX as acceptable formats in its guidance. CycloneDX version 1.4 or later is generally preferred for medical device submissions because it has explicit support for vulnerability data linking and VEX documents, which are increasingly expected alongside the SBOM. SPDX version 2.3 or later is also fully acceptable. The minimum data elements required follow the NTIA minimum elements: supplier name, component name, component version, unique identifiers, dependency relationships, SBOM author, and timestamp.
Does every cybersecurity patch require a new 510(k)?
No. Cybersecurity patches that do not change the device's intended use, indications for use, or risk profile generally do not require a new 510(k) submission. The FDA's guidance on software changes that require a new premarket submission applies to cybersecurity updates the same as functional updates. If a cybersecurity update is a pure bug fix or vulnerability patch that does not add new functionality or change the device's operating parameters, it typically falls under the exemption. Document the rationale for the determination and retain it in the device history record.
What is a VEX document and does the FDA require it?
A Vulnerability Exploitability eXchange (VEX) document is a machine-readable statement by the manufacturer about whether specific CVEs in SBOM components are exploitable in the context of the specific device. VEX status values include: 'not affected' (the vulnerable component is present but the vulnerability is not exploitable in this device), 'affected' (the device is vulnerable), 'fixed' (the vulnerability has been patched), and 'under investigation'. The FDA does not formally require a VEX document with submissions, but providing one alongside the SBOM significantly reduces deficiency requests and reviewer burden, as it preemptively answers the clinical risk question for known CVEs.
What is the FDA's expected response timeline for critical vulnerabilities?
The FDA's postmarket cybersecurity guidance distinguishes between vulnerabilities that present controlled risk (compensating controls exist) and uncontrolled risk (the device is clinically vulnerable without mitigations). For uncontrolled risk vulnerabilities, the FDA expects a response within 30 days, which may be a patch deployment, a clinical advisory, or a compensating mitigation deployed through hospital networks. For controlled risk, the expectation is a remediation plan on a reasonable schedule. These timelines should be documented in the postmarket vulnerability management plan submitted with the premarket application.
Does Section 524B apply to Software as a Medical Device (SaMD)?
Yes. Section 524B applies to any premarket submission that includes software, including Software as a Medical Device (SaMD) submissions. For SaMD, the SBOM covers the cloud services, libraries, containers, and third-party APIs that the software depends on. The postmarket vulnerability management requirements apply to the SaMD's software supply chain, and the update delivery mechanism is typically the continuous deployment pipeline -- which must include code signing and regression testing before production deployment.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Daily briefings + Google Top Stories in one step.
Enter your email and we'll subscribe you to the daily briefing and add Decryption Digest to your Google Search feed at the same time.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.