The FDA published its updated premarket cybersecurity guidance on June 27, 2025, the first revision since the original 2023 document. The redline count looks dramatic, over 1,300 tracked changes. The substance is calmer. This is a clarifying revision, not an expanding one: the agency isn't handing manufacturers new obligations so much as spelling out how to meet the ones they already have, and closing the interpretive escape hatches while it's at it.
The update adds a section that formally defines a cyber device under Section 524B of the FD&C Act, and it settles the connectivity argument. A device with software is subject to cybersecurity oversight whether or not it ever touches a network. Embedded firmware counts. Programmable logic counts, FPGAs included.
I've heard the "our device is air-gapped, so this doesn't apply" position in more submission strategy meetings than I can count. It is now formally dead. If your device runs code, this guidance applies to it.
SBOM expectations got more precise. The bill of materials must be machine readable and human readable at the same time, and it must cover every software component, third-party and proprietary alike. A PDF export of a dependency scan doesn't clear that bar. The two-format requirement isn't bureaucratic fussiness either: machine readable feeds automated monitoring, human readable is what a reviewer actually opens. If your SBOM can't do both jobs, one of your two audiences is guessing.
The deeper change is the risk model. The guidance reaffirms that cybersecurity risk is not safety risk, and it directs manufacturers toward nonprobabilistic assessment built on exploitability and impact rather than severity times likelihood. FMEA on its own no longer carries a security argument. I'd call this the most consequential clarification in the document, because it retires the way many quality systems have shoehorned security into safety tooling for years.
To make implementation concrete, the FDA now cites ANSI AAMI SW96 as a key standard alongside AAMI TIR57. If you've been working from TIR57 alone, SW96 is the document that translates principles into lifecycle activities, and reviewers now have a named reference to hold submissions against. The guidance also grounds itself in real events, including the 2020 ransomware attack on a German hospital. The point of that example isn't subtle. Security failures surface as patient harm and regulatory exposure, not as abstract IT incidents.
Threat modeling, penetration testing, and risk assessment read as lifecycle activities in this revision, not premarket milestones. A previously cleared device that returns to the FDA with design or software modifications gets measured against the modern bar, not the bar it originally cleared. And manufacturers are expected to maintain a clear, auditable SOP for postmarket vulnerability management covering SBOM tracking, CVE triage, patch planning, and coordinated disclosure.
That last expectation is where I see teams underestimate the effort. Writing the SOP takes a week. Running it with evidence, across every product and every release, is a program.
We built ELTON for exactly this shape of obligation: continuous discovery and CVE triage against product SBOMs, contextual CVSSv4 scoring, postmarket monitoring, and living vulnerability reports that hold the audit trail as products evolve. The guidance asks for continuity, and continuity is a systems problem before it is a staffing problem.
My read on the 2025 update is simple. Manufacturers who treated the 2023 guidance as a documentation exercise will experience these clarifications as brand-new requirements, because the ambiguity they were living in is gone. Teams that built continuous processes will read the redlines and shrug. The distance between those two reactions is the whole story of this revision.
Start with one device. We build the twin from documentation your quality system already produces, run AI discovery remotely, and show you the graph: the handful to fix, and the evidence for everything else.