" " indicates required fields
By Ken Zalevsky, VP and GM, C2A Security
A revision would likely do more than refresh a decade-old document. It could clarify what manufacturers need to monitor, maintain, and demonstrate long after a device reaches the market.
When FDA finalized its Postmarket Management of Cybersecurity in Medical Devices guidance in December 2016, connected medical devices were already common, but the tools and expectations were different. SBOMs were not yet a regulatory expectation, Section 524B did not exist, and many manufacturers were building their first formal vulnerability management programs.
On October 1, 2026, CDRH included a planned draft revision of its postmarket cybersecurity guidance on the B-list of its FY 2027 guidance agenda. That means FDA intends to publish it as resources permit. The timing is uncertain: in FY 2026, CDRH published seven of 11 listed guidances, only two from the B-list.
Nothing has been released yet. But its appearance on the list signals that FDA may be ready to update its postmarket recommendations.
A Lot Has Changed Since 2016
Since 2016, Congress has added Section 524B to the Federal Food, Drug, and Cosmetic Act. It requires qualifying cyber devices submitted through 510(k), De Novo, PMA, and other specified pathways to have a postmarket vulnerability management plan, security update and patch processes, and an SBOM.
FDA finalized its premarket cybersecurity guidance in September 2023, updated it in June 2025, and revised it again in February 2026 to align with the Quality Management System Regulation (QMSR), which took effect on February 2, 2026.
The premarket side has been modernized. The dedicated postmarket guidance, covering devices that may remain in use for ten, fifteen, or twenty years, predates these changes. Section 524B and the newer premarket guidance already address postmarket responsibilities, but a revision could connect the pieces.
What follows is my view of where the draft may go. None of it is confirmed until FDA publishes. But the direction is not hard to read.
From Recommendations to Demonstrable Commitments
Section 524B requires manufacturers of qualifying cyber devices to plan for monitoring and addressing postmarket vulnerabilities, including coordinated vulnerability disclosure. It also requires routine security updates and out-of-cycle patches for critical vulnerabilities that could cause uncontrolled risk.
The 2016 guidance framed much of this activity as recommendations. A revision may focus more explicitly on how manufacturers show that the plan submitted for authorization is actually being carried out. Having a plan is one thing. Demonstrating that vulnerabilities were monitored, assessed, and addressed years later is another.
FDA’s February 2026 premarket guidance already recommends tracking patch rates, time to patch, and time from patch availability to implementation in the field, to the extent known. It recommends reporting those metrics in premarket submissions and PMA annual reports, when available.
Can a manufacturer reconstruct which device versions were affected, how risk was assessed, and what happened next? That is the difference between documenting an intention and demonstrating a process.
The SBOM Becomes a Living Document
Many manufacturers still treat the SBOM as a premarket deliverable, generated for a submission and filed away. In the postmarket world, that approach does not hold up.
Every software release can change the SBOM. Any component can be found to contain a newly disclosed vulnerability. A revision may emphasize maintaining accurate SBOMs for fielded versions, monitoring components for vulnerabilities, and using that information for postmarket risk decisions.
A draft could also address communications to customers. Vulnerability Exploitability eXchange (VEX) can convey whether a vulnerability affects a product, although FDA does not require that format.
This is the challenge we are addressing at C2A Security. EVSec connects SBOMs with device architecture, vulnerability intelligence, risk assessments, and compliance evidence so manufacturers can assess CVEs in the context of the versions and functions that matter.
Is the SBOM for each fielded version current? Who is watching for vulnerabilities? And how quickly can the team tell whether a new CVE actually affects a device?
Risk Assessment Needs Context, Not Volume
The 2016 guidance introduced a framework built around patient harm, distinguishing controlled from uncontrolled risk. That remains sound, and I would expect it to stay. What has changed is the scale.
A connected device can contain hundreds of third-party components. Across a portfolio, that means thousands of components and a steady stream of vulnerability alerts. A vulnerability in a component may not be exploitable in the device’s configuration. Some issues will be urgent; others may not affect the product.
A modernized guidance could reference the FDA-qualified MITRE medical-device CVSS rubric, CISA’s Known Exploited Vulnerabilities (KEV) catalog, and the Exploit Prediction Scoring System (EPSS). None replaces assessment of the device’s architecture, exposure, clinical use, and patient harm.
The goal remains the same: distinguish real patient risk from noise. That requires context, not a longer CVE list.
Reporting Rules and the Routine Patch
The 2016 guidance explained when a cybersecurity fix may be a routine update or patch not reportable under 21 CFR Part 806. It also described limited circumstances in which FDA did not intend to enforce Part 806 reporting for vulnerabilities presenting uncontrolled risk.
That is not a blanket exemption. Conditions include no known related serious adverse events or deaths; communicating with customers, interim controls, and a remediation plan within 30 days; a validated fix or long-term control within 60 days; and active information sharing through an Information Sharing and Analysis Organization (ISAO). Other reporting obligations may still apply.
Those conditions are worth revisiting. The guidance’s references to former Part 820 quality-system provisions also need updating to reflect QMSR. QMSR did not change Part 806. Manufacturers should watch this area closely because it affects how much administrative work accompanies a security fix.
The Hospital Is the Other Half of Postmarket
This is the area I am watching most closely, and it is also the most speculative.
Postmarket cybersecurity does not end at the manufacturer. When a vulnerability affects a fielded device, the hospital must find affected units, decide what to do, and keep patient care running. Hospital security teams need version-specific information, interim mitigations, and support timelines. Much of that information comes from manufacturers.
These are not new requests. The Health Sector Coordinating Council’s Joint Security Plan 2.0 and legacy technology guidance describe shared responsibilities, especially when devices cannot be patched immediately.
The proposed HIPAA Security Rule update has intensified the discussion, but it remains a proposal. The regulatory agenda projects final action in July 2027, not an effective or compliance date. Hospitals need actionable security information regardless.
If FDA addresses the quality and timing of manufacturer-to-hospital communications, it could benefit both sides.
Don’t Wait for the Draft
It would be easy to wait for FDA to publish before acting. I would not recommend it.
The draft may take time, and the final guidance longer. But accurate SBOMs, vulnerability monitoring, contextual risk assessment, timely patching, and clear customer communication are already central to postmarket cybersecurity and Section 524B obligations for qualifying cyber devices.
Building those capabilities across fielded products takes time. Better to have them in place when the draft arrives than to start afterward.
Where This Leaves Manufacturers
Whatever the final guidance looks like, every manufacturer should be able to answer these questions:
• Is the SBOM for every supported product and fielded software version current?
• Are those components being monitored for newly disclosed vulnerabilities?
• Can we determine quickly which vulnerabilities are actually exploitable in our devices?
• Are we meeting our documented patch and remediation commitments?
• Can our hospital customers get the information they need to act?
• And can we demonstrate our decisions and actions to FDA when asked?
CDRH is accepting comments through November 30, 2026, under docket FDA-2012-N-1021. FDA invites proposed policy content, not just priority rankings. Manufacturers and hospitals can help shape the draft.
The postmarket guidance may not change as quickly as some would like. But the direction is consistent with everything else in medical device cybersecurity. The emphasis is moving from documenting what an organization intends to do toward demonstrating what it actually does, for as long as its devices remain in use.
At C2A Security, that is what EVSec is designed to support: connecting SBOMs, contextual vulnerability prioritization, risk assessments, and compliance evidence so manufacturers can focus on what matters and document their response.
Want to see how EVSec can help your team manage cybersecurity across fielded medical devices? Schedule a demo.
