Key takeaways
- 524B is a legal requirement, not guidance — the FDA can refuse-to-accept a non-compliant submission.
- A cyber device is one with software, internet/network capability, and a vulnerability that could pose a risk.
- You must submit an SBOM listing every software component, including third-party and open source.
- Secure design is expected: signed firmware, secure boot, encrypted comms, and least-privilege access.
- Post-market matters most: a real plan for governed OTA patching and coordinated disclosure.
What changed in 2023
Section 524B of the FD&C Act made cybersecurity a statutory condition of premarket submission for connected devices. Before, cybersecurity lived in non-binding guidance; now the FDA can issue a refuse-to-accept decision if the package is missing. The practical effect: cybersecurity engineering moves to the front of the program, alongside your IEC 62304 lifecycle, not after clearance.
Are you a ‘cyber device’?
The statute defines a cyber device as one that (1) includes software, (2) has the ability to connect to the internet or a network, and (3) contains a technological characteristic that could be vulnerable to cybersecurity threats. Most connected medical IoT products meet all three. If you ship firmware that talks to a gateway, a phone or a cloud, assume you are in scope.
What the 524B package contains
| Element | What the FDA expects |
|---|---|
| Cybersecurity plan | How you identify, monitor and address vulnerabilities and exploits throughout the device lifecycle |
| SBOM | A machine-readable list of all software components, including commercial, open-source and off-the-shelf |
| Secure design evidence | Threat model, architecture, and controls: signed firmware, secure boot, encryption, authentication, least privilege |
| Post-market process | A documented process to release updates and patches on a reasonably justified cadence and out-of-cycle for critical issues |
| Coordinated disclosure | A vulnerability disclosure policy so researchers can report issues responsibly |
The four engineering controls reviewers look for
Signed firmware and secure boot
Devices must accept only firmware whose signature validates against a trusted key, and verify integrity at boot. This is the single most important defense against malicious updates — and a prerequisite for trustworthy OTA.
SBOM you can actually maintain
An SBOM is only useful if it stays current. Generate it from your build (a benefit of disciplined build tooling) so that when a component CVE lands, you can answer ‘are we affected?’ in minutes, not weeks.
Encrypted, authenticated communications
Data in transit between device, gateway and cloud must be encrypted and mutually authenticated. Least-privilege access keeps a compromised credential from owning the fleet.
Governed OTA for patching
524B’s post-market expectation is unworkable without a reliable, auditable update path. You need to push a signed patch to a defined population, verify it landed, and record who-changed-what. Ad-hoc updates do not satisfy a reviewer.
Post-market is where most plans are thin
Teams over-invest in the pre-market artifact and under-invest in the operational reality: monitoring for new vulnerabilities in your SBOM components, triaging them against deployed firmware versions, and shipping a patch under change control. This is an ongoing program, not a document. Pair it with the rest of your file via the compliant medical IoT hub, and align it to your 510(k) firmware evidence so the cybersecurity story is consistent across the submission.
North American and global alignment
524B is a US instrument, but its expectations echo the EU MDR’s security requirements and Health Canada’s guidance. Build the controls once — signed firmware, SBOM, governed patching — and you satisfy the substance across North American and global markets, with only the paperwork wrapper changing per jurisdiction.
Where Fundamentum fits
524B’s hardest requirement is operational: signed firmware and a governed, auditable way to patch a fleet for years. Fundamentum, our Canadian IoT platform, delivers exactly that — secure boot support, signed governed OTA, role-based access and an audit trail in a SOC 2 Type II perimeter — turning the post-market expectation into a working capability. It can interface with AWS, Azure or Google Cloud if your architecture requires it. See governed OTA →
Frequently asked questions
What is FDA 524B?
Section 524B of the FD&C Act, added by the 2023 Omnibus, makes cybersecurity a statutory pre-market requirement for connected medical devices. The FDA can issue a refuse-to-accept decision if a cyber-device submission lacks the required cybersecurity package.
What is a ‘cyber device’?
A device that (1) contains software, (2) can connect to the internet or a network, and (3) has a technological characteristic that could be vulnerable to cybersecurity threats. Most connected medical IoT products meet all three, so if your firmware talks to a gateway, phone or cloud, assume you are in scope.
What is an SBOM and why does 524B require it?
A software bill of materials is a machine-readable list of every software component, including open-source and off-the-shelf. 524B requires it so that when a component vulnerability is disclosed, you can quickly determine whether your shipped firmware is affected. Generate it from your build so it stays current.
Does 524B require over-the-air updates?
It requires a credible post-market process to release patches on a justified cadence and out-of-cycle for critical issues. In practice that means a reliable, auditable update path: push a signed patch to a defined population, verify it landed, and record the change. Ad-hoc updates do not satisfy a reviewer.
Does 524B apply outside the United States?
524B is a US instrument, but its expectations echo the EU MDR’s security requirements and Health Canada guidance. Build the controls once — signed firmware, SBOM, governed patching — and you satisfy the substance across North American and global markets, with only the paperwork wrapper changing per jurisdiction.
Related reading
Talk to an IoT engineer — free
Book a FREE 30-minute consultation with our team. No slides, no obligation — a working session on your connectivity, platform or compliance questions.
