FDA Medical Device Cybersecurity Guide: Premarket Submissions, SBOMs and Section 524B

Since 29 March 2023, a connected medical device cannot reach the US market unless the sponsor shows FDA it is cybersecure, and incomplete cybersecurity documentation is now one of the quickest ways to stall a submission. Section 524B of the Federal Food, Drug, and Cosmetic Act (FD&C Act) turned long-standing FDA guidance into statutory requirements for "cyber devices": a postmarket vulnerability plan, secure development processes, patching and a software bill of materials (SBOM). FDA's premarket guidance, most recently reissued on 3 February 2026 to align with the new Quality Management System Regulation (QMSR), sets out what a submission should contain. This guide covers who is in scope, what 524B and the guidance require, how to build the evidence, and how the 2016 postmarket guidance governs vulnerability handling after clearance. It is for regulatory affairs, product security and engineering teams at device manufacturers, and for hospital security teams who want to know what manufacturers must now provide. For securing devices already deployed in a hospital network, see the Medical Device Security Guide.

Key takeaways

• Section 524B is law, not guidance. Added by section 3305 of the Consolidated Appropriations Act, 2023 (signed 29 December 2022), it applies to 510(k), PMA, PDP, De Novo and HDE submissions for cyber devices from 29 March 2023.
• "Cyber device" is read broadly. FDA interprets the ability to connect to the internet to include Wi-Fi, cellular, Bluetooth, Bluetooth Low Energy, magnetic inductive links, USB, Ethernet and serial ports, and treats firmware and programmable logic as software.
• The SBOM must be machine-readable and maintained. FDA expects NTIA minimum elements plus each component's support level and end-of-support date, and an assessment of known vulnerabilities including those in CISA's KEV catalog.
• Cybersecurity sits inside the quality system. The February 2026 guidance ties a secure product development framework (SPDF) to the QMSR, which incorporates ISO 13485:2016 and took effect on 2 February 2026.
• Postmarket timelines are concrete. For an uncontrolled vulnerability, FDA's postmarket guidance expects customer communication within 30 days and a validated fix or compensating control within 60 days to qualify for reporting enforcement discretion.

What it is and who it applies to

US medical device cybersecurity regulation now has four layers that work together. Status below was confirmed on FDA.gov, eCFR and the US Code on 24 October 2026.

The cyber device definition

Under 524B(c), a cyber device is one that (1) includes software validated, installed or authorised by the sponsor as a device or in a device, (2) has the ability to connect to the internet, and (3) contains technological characteristics validated, installed or authorised by the sponsor that could be vulnerable to cybersecurity threats. FDA's guidance reads "ability to connect" as any intentional or unintentional connection by any means, including a USB port used for service. In practice almost every device with software and a data interface should be treated as in scope. Under 524B(d), FDA may exempt devices or categories by publishing a list in the Federal Register.

Which submissions

• Statutory scope: 524B(a) covers submissions under sections 510(k), 513 (De Novo), 515(c) and 515(f) (PMA and PDP) and 520(m) (HDE).
• Guidance scope: the premarket guidance also applies its recommendations to IDE, BLA and IND submissions for devices, and to devices that need no premarket submission, though 524B itself does not bind those.
• Modifications: a 510(k) or PMA supplement for a change to an existing cyber device triggers 524B as well (see Evidence and assessment).

Structure and key requirements

Section 524B(b): four statutory obligations

Section 3305 of the 2023 Act also allows FDA to treat reasonable assurance of cybersecurity as part of its safety and effectiveness determination. The guidance gives an example where missing encryption on an alarm function leads to a not substantially equivalent decision: cybersecurity is a clearance criterion, not a documentation formality.

What the premarket guidance asks for

• Secure product development framework: FDA recommends an SPDF covering the whole product lifecycle and names the Joint Security Plan (JSP2), IEC 81001-5-1 and ANSI/ISA 62443-4-1 as examples. The guidance says an SPDF may be one way to meet QMSR requirements.
• Security objectives: authenticity (including integrity), authorisation, availability, confidentiality, and secure, timely updatability and patchability.
• Threat modelling: across the whole medical device system, assuming the device operates in a hostile environment.
• Cybersecurity risk assessment: based on exploitability rather than probability, kept separate from but linked to ISO 14971 style safety risk management.
• Interoperability and third-party software: risks from wireless protocols and healthcare infrastructure, custodial control of source code, and plans for components that reach end of support.
• Unresolved anomalies: assess known software defects for security impact.
• Architecture views: at minimum a global system view, a multi-patient harm view, an updatability and patchability view, and security use case views, scaled to device risk.
• Security controls: eight categories: authentication, authorisation, cryptography, code, data and execution integrity, confidentiality, event detection and logging, resiliency and recovery, and firmware and software updates.
• Testing: verification of each control, threat mitigation testing, vulnerability testing, penetration testing with documented tester independence, fuzz testing, static and dynamic analysis and software composition analysis, repeated after release at regular intervals.
• Labelling and transparency: user-facing security information (see below) and a vulnerability management plan.

SBOM content FDA expects

• Machine-readable SBOM meeting the NTIA minimum elements, in an industry-accepted format such as SPDX or CycloneDX. See the SBOM Guide.
• For each component: support level (actively maintained, no longer maintained or abandoned) and end-of-support date.
• All known vulnerabilities in the device and its components, including entries in CISA's Known Exploited Vulnerabilities catalog, with how each was found.
• A safety and security risk assessment for each known vulnerability and the risk controls, including compensating controls.
• A justification if any SBOM information cannot be provided.

Identity and NHI requirements

Several of the guidance's control categories are, in practice, identity controls for machines and services. They are where reviewers and penetration testers most often find gaps.

• Authentication and authorisation: authenticate every user, device and service that talks to the device, and authorise by role. Avoid hardcoded or shared default credentials, and design service and maintenance access so that it does not rely on one password known to every field engineer. See the Device and IoT Identity Guide.
• Cryptographic keys: the cryptography category covers key management. Unique per-device keys or certificates, provisioned at manufacture and stored in protected hardware where possible, limit the damage from one extracted key.
• Update integrity: code integrity and secure updates depend on the manufacturer's signing keys. Treat them as the most privileged non-human credential you own: HSM-protected, used only by the release pipeline, with every signing event logged.
• Related systems: 524B(b)(2) extends reasonable assurance to related systems such as update servers and cloud services. The service accounts, API keys and tokens those systems use to reach devices belong in the threat model and the global system view. See the Healthcare Identity Security Guide.
• Logging: event detection and logging should record authentication events, configuration changes and update installs in a form hospital SIEM tools can ingest, as the labelling recommendations call for.

Implementation steps

1. Classify the portfolio. Apply the three-part cyber device test to each device and planned change. Default to "in scope" where any software and data interface exists, and record the reasoning.
2. Embed an SPDF in the QMS. Map security activities into ISO 13485 clause 7.3 design and development procedures under the QMSR, so that threat models, security requirements and test results become design history records. Use IEC 81001-5-1 or ISA 62443-4-1 as the process reference.
3. Threat model early. Build the system threat model and architecture views during design input, not after verification. See the Threat Modelling Guide.
4. Automate the SBOM. Generate it in the build pipeline, enrich it with support level and end-of-support data, and match it against vulnerability sources including KEV on every build.
5. Design the controls. Work through the eight control categories for each interface, starting with authentication, signed updates and logging, which are the hardest to retrofit.
6. Test independently. Run fuzzing, SCA and static analysis in the pipeline; commission a penetration test with documented independence on a representative build. Pilot the full documentation package on one submission before rolling it out across the portfolio.
7. Write the cybersecurity management plan. Define monitoring sources, the CVD policy, ISAO participation, patch timelines for both vulnerability categories and how fielded versions differ.
8. Prepare labelling. Produce customer security documentation, an MDS2 form and the machine-readable SBOM for users.
9. Operate postmarket. Run the plan: triage new vulnerabilities as controlled or uncontrolled, meet the 30 and 60 day expectations for uncontrolled risk, and keep a rollback path (prior validated firmware) for updates that fail in the field.

Evidence and assessment

Changes to cleared devices

• Changes that may affect cybersecurity: new connectivity, changed authentication or encryption algorithms, or a changed update mechanism need the full documentation set.
• Changes unlikely to affect cybersecurity: FDA still expects a reference to the existing plan (or the plan itself if none exists), a statement on any open critical vulnerabilities, a note of uncontrolled-risk vulnerabilities remediated since the last authorisation, and an SBOM.

Metrics FDA asks for

The guidance recommends at least three lifecycle metrics, reported in submissions and PMA annual reports where available: the percentage of identified vulnerabilities that are updated or patched; the time from identification to update or patch; and the time from patch availability to deployment on fielded devices. Add two internal measures: SBOM coverage of shipped versions (target 100 percent) and the number of components past end of support in fielded products.

Postmarket: controlled and uncontrolled risk

The 2016 postmarket guidance asks for a binary call based on exploitability and severity of patient harm, with essential performance defined per device. Controlled risk fixes are generally routine updates not reported under 21 CFR 806. For uncontrolled risk, FDA does not intend to enforce 806 reporting if there are no known serious adverse events or deaths, the manufacturer communicates with customers and identifies interim controls within 30 days, delivers a validated fix or long-term compensating control within 60 days, and actively participates in an ISAO. The guidance predates the QMSR and FDA notes that its Quality System references should be read against the current regulation.

Mapping to other frameworks

Devices sold in Europe face a different regime: the EU Medical Devices Regulation, which also removes medical devices from the scope of the EU Radio Equipment Directive cyber requirements. See the EU Radio Equipment Directive Cybersecurity Guide and, for the hospital side, the HIPAA Security Rule Guide.

Common pitfalls

• Assuming "no internet" means out of scope: a USB service port or Bluetooth link is enough under FDA's reading of 524B(c).
• A static SBOM: a spreadsheet produced once for the submission, without support levels, end-of-support dates or a process to keep it current for users.
• Probability-based scoring: using safety-style likelihood for cyber risk instead of exploitability, which reviewers routinely challenge.
• Shared service credentials: one maintenance password or key across the installed base, so one leak exposes every device in every hospital.
• Testing at the end: penetration testing after design freeze, leaving findings that need a redesign and delaying the submission.
• Unjustified patch timelines: a management plan that promises "timely" updates without stating and justifying timelines for each vulnerability category.

Practitioner checklist

• Apply the 524B(c) cyber device test to every device and planned modification, and record the outcome.
• Integrate SPDF activities into QMSR design controls (ISO 13485 clause 7.3).
• Maintain a system threat model and the four minimum architecture views.
• Generate a machine-readable SBOM per build with support level, end-of-support date and KEV matching.
• Remove hardcoded and shared credentials; provision unique device keys or certificates.
• Protect firmware signing keys in an HSM and log every signing event.
• Commission independent penetration testing and keep fuzzing and SCA in the pipeline.
• Publish a CVD policy, join an ISAO and justify patch timelines in the management plan.
• Track patch rate, time to patch and time to field deployment.
• Ship customer security documentation, including ports, secure configuration and end-of-support information.

Standards and references

• US Code (LII): 21 U.S.C. 360n-2, Ensuring cybersecurity of devices
• FDA: Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions
• FDA: Postmarket Management of Cybersecurity in Medical Devices
• FDA: Cybersecurity (Digital Health Center of Excellence)
• eCFR: 21 CFR Part 820, Quality Management System Regulation
• FDA: Quality Management System Regulation (QMSR)
• CISA: Known Exploited Vulnerabilities Catalog
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Medical Device Security Guide · SBOM Guide · IoT Security Guide · EU Cyber Resilience Act Guide. This guide summarises US FDA medical device cybersecurity requirements as of October 2026 and is not legal advice.