Cybersecurity is now a condition of FDA authorization
Cryptography used to be a quiet engineering detail, tucked into a firmware build and rarely discussed outside the development team. For connected medical devices, that era is over. FDA medical device cybersecurity is now a legal precondition that a manufacturer has to satisfy before a premarket submission will even be accepted.
Since March 29, 2023, Section 524B has required cyber device submissions to include a post-market vulnerability management plan, processes providing reasonable assurance of cybersecurity with updates and patches made available, and a software bill of materials. FDA’s guidance then sets out the cryptographic documentation, including encryption, authentication, and key management, that reviewers expect in support of those obligations. That date is not arbitrary. Section 524B was added to the Federal Food, Drug, and Cosmetic Act (FD&C Act) by Section 3305 of the Consolidated Appropriations Act, 2023, signed December 29, 2022, and took effect on March 29, 2023.
FDA has since sharpened its expectations. On February 3, 2026, FDA issued the current final guidance, ‘Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions,’ which supersedes the June 27, 2025 version. The 2026 revision aligns the document with the Quality Management System Regulation at 21 CFR Part 820, effective February 2, 2026. The guidance details quality-system and content expectations covering encryption, authentication, firmware signing, and key management. Its emphasis is telling: FDA cares about secure implementation, not merely whether a manufacturer selected an approved algorithm.
What counts as a cyber device under Section 524B
Before reading further, it helps to know whether a product is even in scope. Under Section 524B, a cyber device is a device that contains software, can connect to the internet, and has technological characteristics that could be vulnerable to cybersecurity threats.
Section 524B(b) sets out three requirements:
- A plan to monitor, identify, and address post-market cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures.
- Processes and procedures providing a reasonable assurance that the device and related systems are cybersecure, with post-market updates and patches made available on a reasonably justified regular cycle, and out of cycle for critical vulnerabilities.
- A software bill of materials (SBOM) covering commercial, open-source, and off-the-shelf software components.
These obligations reach across the common submission pathways. The submission types in scope include 510(k), PMA, PDP, De Novo, and HDE.
Why FDA medical device cybersecurity matters now, not later
The consequences arrive early in the process. FDA can issue a Refuse to Accept determination for a cyber device submission that lacks the required Section 524B information, which stops the submission before technical review begins. A gap in cryptographic documentation can halt a product before a reviewer reads a single clinical claim. FDA set out this policy in ‘Cybersecurity in Medical Devices: Refuse to Accept Policy for Cyber Devices and Related Systems Under Section 524B of the FD&C Act’ (March 2023), and has applied it to submissions since October 1, 2023.
The largest compliance exposure, though, sits in the installed base. Devices built before 2023 often rely on shared keys or static credentials, and those units are already deployed in clinical settings where replacement is slow and expensive.
There is a commercial dimension too. Health delivery organizations already collect device security information at procurement through the Manufacturer Disclosure Statement for Medical Device Security (MDS2, ANSI/NEMA HN 1-2019), and SBOM requests are now common in that process. In practice, cybersecurity has become a shared responsibility between manufacturer and health system, so the same evidence that satisfies a regulator increasingly decides whether a device wins the hospital contract at all.
How the guidance maps to cryptography
FDA’s expectations translate into a set of concrete control areas. Each one is straightforward to state and, for older devices, genuinely hard to satisfy.
Secure communications for data in transit
FDA expects authenticated, encrypted communication between the device, its companion apps, and cloud services, protecting the confidentiality and integrity of patient health information and control commands. Certificate-based mutual TLS is the common way to meet that expectation. Legacy devices are the challenge here: many were designed with limited or one-sided authentication and cannot easily establish strong, mutually authenticated channels.
Per-device identity and authentication
The guidance points toward a unique, per-device cryptographic identity that replaces the shared or default credentials common in legacy implants and bedside devices. Retrofitting distinct identities onto a fleet that was provisioned with a single shared key is difficult, because there was never a mechanism to tell one unit from another.
Signing firmware and software updates
FDA expects cryptographic signing and verification of firmware and software updates before installation, tied directly to the mandatory post-market update and patch process. Older devices frequently accept unsigned updates, so adding signature verification can require changes to a boot and update chain that was never built to check them.
The SBOM and cryptographic component inventory
The guidance calls for an inventory of the cryptographic libraries and algorithms embedded in device software, which feeds the required SBOM, including open-source and off-the-shelf components. For legacy products, the source of truth is often incomplete, and the embedded crypto libraries may be undocumented or no longer supported.
Key management across the device lifecycle
FDA expects documented key generation, rotation, and revocation that span a device’s multi-year deployed lifetime, including field-deployed legacy units. Many older devices have no way to rotate a key after manufacturing, which leaves a static secret in the field for the full clinical life of the product.
Protecting data at rest on the device
The guidance expects encryption of stored patient data and configuration on the device, with keys managed independently of intermittent connectivity. That independence is hard for constrained devices that lose network access for long periods, since they still need to protect stored data without calling home for a key.
What reviewers actually probe: an audit readiness checklist
Reviewers look for consistency and evidence, not intentions. Use this checklist to pressure-test a submission before it goes in:
- Cyber device determination documented consistently across the submission, under Section 524B(c).
- Specific encryption and authentication evidence for data in transit, at rest, and during device pairing.
- Firmware signing verification evidence.
- SBOM completeness across commercial, open-source, and off-the-shelf components, including their cryptographic libraries.
- A documented post-market vulnerability monitoring plan, including coordinated vulnerability disclosure.
- Legacy device compensating controls documented in the post-market management plan.
The legacy device challenge
The pre-2023 installed base deserves its own focus, because it carries the deepest risk. These devices commonly depend on shared keys and static credentials, and some cannot natively support strong cryptography at all.
FDA’s guidance leaves room for this reality. For units that cannot natively support strong cryptography, compensating controls should be identified and documented in the post-market management plan. That documentation is where a manufacturer demonstrates that a known limitation is being managed rather than ignored.
Procurement pressure makes the legacy question urgent even for products that already hold clearance. A device cleared years ago can still fail a hospital’s evidence request today, which turns a historical design decision into a present-day sales obstacle.
Comment Keyfactor vous aider
Each FDA control area maps to a specific capability, and Keyfactor’s platform is organized to deliver the evidence behind each one.
- Keyfactor AgileSec builds the cryptographic component inventory that feeds the required SBOM, including open-source and off-the-shelf dependencies.
- EJBCA provides the certificate-based mutual TLS that secures communications, and it supports the encryption of data at rest on the device.
- Keyfactor SignServer and Keyfactor Signum sign firmware and software updates so that only verified code installs.
- Keyfactor Command handles per-device identity and key lifecycle management, covering key generation, rotation, and revocation across the fleet.
Underneath these products, the Keyfactor Trust Control Plane operates as one system of record that observes, analyzes, provisions, orchestrates, and governs machine identities across the entire device fleet. That single source matters because it produces the same evidence FDA reviewers request in a submission and hospital buyers request during procurement, drawn from one consistent record rather than assembled by hand from scattered tools.
Ready to see how this maps to your device portfolio? Request a Demo.
Conclusion et prochaines étapes
FDA cybersecurity compliance is now provable, spanning both premarket clearance and post-market management. The reviewer wants documented encryption, authentication, signing, and key management, and the hospital wants the same assurance before it buys.
The practical shift is to treat cryptographic visibility and lifecycle management as an ongoing operating capability rather than a one-time submission task. Keys rotate, libraries age, and vulnerabilities surface long after a device ships, so the infrastructure that proves trust has to run continuously.
Start now. Assess your device portfolio and installed base against Section 524B, then build the cryptographic inventory and signing infrastructure before your next submission or procurement review. Request a Demo to see how Keyfactor supports that work end to end.
Got FDA medical device cybersecurity questions? We’ve got answers.
What is a cyber device under Section 524B?
A cyber device is a device that contains software, can connect to the internet, and has technological characteristics that could be vulnerable to cybersecurity threats. If a product meets all three conditions, it falls within Section 524B and its premarket cybersecurity requirements.
When did these requirements take effect?
Section 524B was added by the PATCH Act as part of the Consolidated Appropriations Act, 2023, and took effect on March 29, 2023. FDA current final guidance, ‘Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions,’ was issued February 3, 2026 and supersedes the June 27, 2025 version. The revision aligns the document with the Quality Management System Regulation at 21 CFR Part 820, effective February 2, 2026.
What happens if a submission lacks the required cybersecurity information?
FDA can issue a Refuse to Accept determination for a cyber device submission that lacks the required Section 524B information. For cyber devices, failure to comply with Section 524B(b)(2) is also a prohibited act under Section 301(q) of the FD&C Act.
What are the main premarket obligations?
A cyber device submission must include a cybersecurity plan, a post-market vulnerability monitoring process with coordinated vulnerability disclosure, processes that provide reasonable assurance of security with updates and patches made available, and a Software Bill of Materials (SBOM). These apply across submission types including 510(k), PMA, PDP, De Novo, and HDE.
What is an SBOM, and why does FDA require it?
An SBOM is a Software Bill of Materials that inventories the software components in a device, covering commercial, open-source, and off-the-shelf code. FDA requires it so reviewers can see the cryptographic libraries and dependencies embedded in a device and assess where vulnerabilities may live.
How does the guidance address encryption and key management?
The guidance emphasizes secure implementation over simply selecting an approved algorithm. It expects certificate-based mutual TLS for data in transit, encryption of data at rest, signed and verified firmware updates, and a documented key lifecycle covering generation, rotation, and revocation.
What is the biggest challenge for existing devices?
The pre-2023 installed base is the hardest problem, because many deployed devices rely on shared keys or static credentials and some cannot natively support strong cryptography. For those units, compensating controls should be identified and documented in the post-market management plan.
Is this only a regulatory concern?
No. Hospitals increasingly request SBOM and cryptographic evidence during procurement, so the same documentation that satisfies FDA also influences whether a device wins the hospital contract.
