FDA Premarket Cybersecurity: What 524B Requires
Section 524B of the Federal Food, Drug, and Cosmetic Act is the FDA’s premarket cybersecurity authority for medical devices. Added in 2023, it turned what had been guidance into statutory requirement: cyber devices must submit cybersecurity documentation as part of their 510(k), De Novo, or PMA marketing submissions.
If you manufacture a connected medical device, this guide covers what the documentation set is, which standards the FDA recognizes, when the requirement applies, and how to choose help if your team cannot produce the package alone.
What counts as a cyber device
The statute defines a cyber device broadly: any device that includes software validated, installed, or authorized by the sponsor, or that is connected to the internet or another network. That definition reaches most modern medical devices, from infusion pumps to imaging systems, and it reaches devices whose connectivity is incidental to their primary function.
The practical question for a submission team is rarely whether the device is a cyber device. It is what the device’s connectivity and software content oblige the security documentation to cover.
The documentation set the RFP names
The FDA’s premarket cybersecurity expectations center on a defined documentation package, and the medtech RFP template lists the deliverables so manufacturers can request exactly them: a security risk management plan and report aligned with the device’s overall risk management, a threat model and security architecture views, a software bill of materials, a vulnerability assessment against known vulnerabilities, penetration testing results where applicable, and the postmarket commitments: vulnerability disclosure policy and monitoring plan.
Each deliverable has an expected shape. The SBOM is typically CycloneDX or SPDX format. The security risk management work aligns with AAMI TIR57 and ISO 14971 practice, so security risk sits in the same management system as clinical risk. The architecture views show the device, its connectivity, and its trust boundaries.
Missing any one of them is the most common cause of a cybersecurity hold on a submission, and the cost of the hold is measured in quarters.
The standards the FDA recognizes
The recognized landscape has consolidated. IEC 81001-5-1 covers health software safety, effectiveness, and security. AAMI TIR57 maps security risk management into ISO 14971, the umbrella standard for medical device risk. UL 2900-2-1 addresses testable requirements for network-connectable devices, and MITRE’s work provides the vocabulary for threat modeling medical devices.
A qualified partner speaks these fluently, but the more useful test is practical: ask how many premarket cybersecurity submissions the partner has supported through to clearance or approval, and for which pathways (510(k), De Novo, PMA). Documented submission experience is the verifiable claim; standard-fluency is the baseline.
What the structured RFP captures
The medtech RFP asks the questions that scope the engagement properly: device classification and submission type, the regulatory status (pre-submission, 510(k) preparation, PMA supplement, post-market), the deliverables required, the standards to align with, the SBOM format and automation expectations, and the verification criteria, including the number of successful submissions you require evidence of.
Firms answer in comparable form, so a device maker can line up three consultancies against identical requirements instead of comparing capability decks.
Choosing help: what to verify
Documented premarket successes. How many cybersecurity submissions the firm has supported, through which pathways, and can they describe the work. Regulatory experience: has the team sat through FDA interactions, responded to hold letters, and worked the quality system context your submission lives in.
Certification depth at the holder level. The certifications that matter here are as much regulatory (RAC-class) as technical (CSSLP, IEC 62304 experience), because the deliverable is a submission document, not a penetration test report. The directory records named-holder certification claims where they are on record, and the gaps where they are not.
Frequently asked questions
Does 524B apply to every medical device submission?
It applies to cyber devices: devices including validated or authorized software, or with internet or network connectivity. If your device meets either condition, the cybersecurity documentation is part of the premarket submission. If it meets neither, the requirement does not attach, but few modern devices escape both prongs.
Which SBOM format does the FDA expect?
The FDA recognizes CycloneDX and SPDX as the established machine-readable formats. The substance matters more than the flavor: the SBOM must enumerate the software components, including open source, with enough detail (versions, provenance) to support vulnerability monitoring after clearance.
Can we produce the documentation in-house?
Teams with established security engineering and regulatory affairs functions sometimes can, and the effort is mostly aligning existing risk management with the security deliverables. The common failure mode is underestimating the architecture views and the post-market commitments. A scoped gap assessment from a listed firm is a cheap way to learn whether in-house is realistic.
How long does premarket cybersecurity support take?
It scales with the state of your risk management and software practices. The RFP asks for phases with durations and deliverables so firms quote structured timelines; expect the engagement to run in parallel with your design freeze, not after it, because the threat model and architecture views depend on the design state.
Related
Ready to buy?
Browse verified firms in this specialization or start a structured RFP.
Browse MedTech firms →