Since 2023, FDA can refuse to even accept a premarket submission for a cyber device that's missing specific cybersecurity documentation. Here's what that documentation actually is, and why it needs to start as an engineering artifact, not a paperwork exercise done after the code is frozen.
Section 3305 of the 2023 Omnibus Appropriations Act (the "PATCH Act" provisions) gave FDA explicit statutory authority over cybersecurity in premarket submissions for "cyber devices" — devices that include software, can connect to the internet, and contain technological characteristics that could be vulnerable to cybersecurity threats. FDA formalized its expectations in guidance on premarket cybersecurity submissions. The practical effect for an engineering team: cybersecurity documentation is no longer a nice-to-have appendix, it's a submission requirement, and FDA can issue a "refuse to accept" determination if it's missing. This is a description of the structural requirements as publicly documented in FDA guidance, not regulatory advice — the specific scope and depth required always needs confirmation from regulatory counsel for your device and submission type.
An SBOM is a machine-readable inventory of every software component in a device — commercial, open-source, and in-house — including version information. FDA guidance expects a SBOM as part of the cybersecurity documentation in a premarket submission, because a reviewer (and later, a hospital IT/security team) needs to be able to answer "is this device affected by CVE-2024-XXXXX" without reverse-engineering the firmware image. For an engineering team, this means dependency management can't be informal. If your build pulls in an RTOS, a TLS stack, a Bluetooth stack, and a dozen smaller libraries without a disciplined manifest of exactly which versions are in the shipped image, generating an accurate SBOM after the fact is a forensic exercise, not a report. Tools that generate SBOMs (in formats like SPDX or CycloneDX) directly from the build process, rather than reconstructed manually later, are the difference between this being a one-time cost and a recurring one across every release.
Beyond the SBOM, FDA guidance expects submissions to include a threat model: an analysis of the device's attack surface, the assets that need protection (patient safety, PHI, device availability), the threats against them, and the security controls implemented in response. This is meaningfully different from a generic risk register. A credible threat model has to reflect the actual architecture — what's exposed over Bluetooth or Wi-Fi, what firmware update mechanism exists and how it's authenticated, what happens if a cloud backend is unreachable, whether debug interfaces are disabled in production builds. Written by someone unfamiliar with the real system, it becomes boilerplate that doesn't hold up under review or, worse, doesn't reflect real exposure.
A few practical implications follow directly from these requirements:
The teams that handle this well don't treat SBOM generation and threat modeling as a document produced during the weeks before a submission is filed — they build the dependency discipline and secure-boot/update architecture in from the start, so the documentation is a report on real engineering decisions rather than a retrofit. We build connected firmware with that posture from day one — see our firmware work and how it connects to cloud & device platform security for the fleet-wide side of vulnerability monitoring, as part of our broader medical IoT and connected medical device development. For the broader regulatory context this sits inside, see our notes on regulatory basics for connected medical devices, IEC 62304 software safety classification, and staying submission-ready before a formal QMS exists.
