Post Mythos Era: The Vulnerability is Not the Problem. The Operationalization is.

Why safety-critical industries are structurally unprepared for AI-era vulnerability volumes, and the thinking needed to change that.

There is a moment in vulnerability research that every embedded security practitioner knows, the moment when something that was supposed to be hidden is suddenly, undeniably visible. I have experienced it while capturing electromagnetic traces off a medical device microcontroller, watching the power signature of a firmware execution sequence betray secrets the device was never designed to reveal. The system was functioning exactly as its engineers intended. The vulnerability was real anyway.

That moment, the gap between what a product is designed to do and what an adversary can make it do, is what product security exists to close. And for decades, the medical device industry has been closing it slowly, incrementally, with modest tooling and hard-won regulatory frameworks that were built for a world where finding vulnerabilities was the hard part.

That world ended. AI-powered vulnerability discovery systems are now identifying security flaws in foundational software at a scale and depth that no human research team, no traditional scanner, and no regulatory timeline was designed to absorb. The rate of discovery has changed permanently. The rate of remediation in fielded medical devices has not, and it cannot, by design, because the regulatory obligations that protect patients also constrain how quickly a manufacturer can push a software change into a device that someone is depending on to keep them alive.

This is the collision that MedTech product security leadership must now navigate. It is not a technology problem. It is a governance crisis disguised as a tooling challenge, and the organisations that mistake one for the other will find themselves in front of the FDA, or a patient safety incident trying to explain why they had the information and still did not act.

For the product security leaders sitting inside similar ecosystem like Automotive, Aviation, Industrial Control System and other similar organisations, it should also be deeply uncomfortable. Because the question the technology is forcing into the open is one that most organisations have never honestly answered: when you know about a vulnerability in a fielded, safety-critical product, what do you actually do with that knowledge?

Most organisations do not have a good answer. And the volume AI is about to deliver will make that gap impossible to ignore.

The bottleneck in product vulnerability management has never been discovery. It has always been what comes after, and in safety-critical systems, that ‘after’ is more complex, more consequential, and more structurally broken than most leadership teams have been willing to admit.

Safety-Critical is a Different Problem Class Entirely

It is tempting to import the vocabulary and operating models of enterprise IT security into medical device product security. The terminology overlaps. Many of the tools are adjacent. The CVE database is the same one. But the problem class is categorically different, and the failure to recognise that distinction is responsible for much of the organisational dysfunction I see in product security programmes across the industry.

In enterprise IT, a patch is a technical event with an operational timeline. In a medical device, a patch is a regulatory event with a clinical consequence profile. An infusion pump delivering chemotherapy cannot be updated on a Tuesday night maintenance window. A Class III implantable cardiac monitor cannot receive a firmware change without a regulatory submission that, depending on the scope of the modification, requires FDA clearance. A ventilator in an ICU cannot be taken offline for a security update because the security team’s triage queue reached a threshold.

The consequence of this constraint is a structural feature of the domain that the industry has never fully reckoned with at the leadership level: the lifecycle of a medical device vulnerability is not a straight line from discovery to patch. It is an extended, constrained, and often publicly visible period during which a manufacturer knows about a vulnerability in a fielded device, cannot yet remediate it, and must demonstrate to regulators, healthcare providers, and patients that the risk is understood and actively managed.

The Reality of a Fielded Medical Device Vulnerability:

A vulnerability is identified today in the wireless communication stack of a widely deployed patient monitoring system. The finding is real, exploitable under specific network conditions, and present across 35,000 units in active clinical use across 400 hospitals globally.

The remediation pathway: validate the fix, conduct regression testing against clinical safety functions, prepare a 510(k) submission or PMA supplement, await FDA review, coordinate the update deployment with clinical engineering teams across 400 hospital systems, manage the devices that cannot be updated due to connectivity or contractual constraints.

Realistic timeline: 10 to 18 months. During which the vulnerability is known, the device is fielded, and the manufacturer must manage the gap.

This is the fundamental asymmetry that makes product vulnerability management categorically different from enterprise security, and that AI-powered discovery, however impressive, has not changed at all. The discovery layer has been transformed. The consequence layer remains exactly as constrained as it has always been.

The vulnerability management lifecycle in safety critical system is not a linear sequence from discovery to patch. It is a constrained optimisation problem, one that must simultaneously satisfy security requirements, regulatory obligations, operational continuity, and patient or public safety, often with these objectives in direct tension with each other.

No AI system scores that optimisation. No CVSS calculator solves it. It requires human judgment operating within a structured framework, and most product security organisations do not yet have that framework in place.

The Novel Problem Nobody is Naming: Vulnerability Temporal Mismatch

Here is an idea I have not seen articulated in the vulnerability management conversation, and I think it is the most important structural challenge that the current AI discovery moment is surfacing.

In traditional IT security, the moment a vulnerability is discovered and the moment it is relevant to your organisation are approximately the same. A CVE drops, you check your asset inventory, you patch. The temporal alignment between discovery and remediation opportunity is tight.

In safety-critical product security, these two moments are structurally decoupled, sometimes by years. The regulatory pathway, the clinical deployment constraints, the hospital system coordination requirements, the post-market surveillance obligations, all of these create a mandatory gap between when a manufacturer knows about a vulnerability and when they can close it. The gap is not a process failure. It is a patient safety feature of the regulatory framework.

The implication is one that most product security programmes have not yet built around: the primary challenge in medical device vulnerability management is not patching faster. It is managing the remediation gap with a level of rigour, documentation, and compensating control architecture that can withstand regulatory scrutiny and, in the worst case, clinical incident investigation.

The Temporal Mismatch Problem in Practice:

A vulnerability is discovered today in a wireless communication stack used across 40,000 fielded infusion pumps. The vulnerability is real and exploitable. But the pump is in active clinical use across 600 hospitals. A firmware update requires FDA 510(k) clearance or a PMA supplement. The validation and regulatory pathway takes 8 to 14 months. In the meantime, the vulnerability is public, the device is fielded, and the organisation must manage the gap between when the vulnerability is known and when remediation is actually possible.

This is not a failure of the security team. It is a structural property of the domain. And it means that ‘time to patch’, the metric most vulnerability management programmes optimise for, is not just irrelevant in this context. It is actively misleading.

The novel thinking the field needs is not better patch velocity metrics. It is a compensating control architecture designed explicitly for the remediation gap, a structured approach to reducing exploitability, limiting reachability, and documenting residual risk acceptance during the period between when a vulnerability is known and when remediation is actually executable. From the MedTech context, it includes network segmentation guidance for hospital operators, monitoring signatures for clinical security operations teams, documented risk acceptance by an accountable decision-maker, and a regulatory communication strategy calibrated to the severity and exploitability of the finding.

This is not the same as ignoring the vulnerability. It is a principled, documented, and auditable approach to managing the gap, one that can be presented to regulators, to clinical governance boards, and to boards of directors as evidence that the risk is understood and actively managed, not simply deferred.

Almost no product security programme has this capability today. The AI discovery moment is about to make its absence very visible.

The Second Overlooked Variable: Operational State is a Security Variable

Here is a second idea that the product security field is not yet building around, and it emerged directly from experience working with safety critical embedded systems.

The risk profile of a vulnerability in a medical device is not static. It changes depending on the clinical operational state the device is in, at the moment a potential exploitation event occurs. A vulnerability that represents a critical patient safety risk during active therapeutic operation may be entirely inconsequential when the device is in setup mode, transport configuration, or post-procedure standby. The attack surface, the exploitability, and the consequence severity all change with clinical state.

Consider what this means in practice. An infusion pump vulnerability that could alter drug delivery parameters during an active infusion carries a fundamentally different risk profile than the same vulnerability when the pump is idle and unconnected to a patient. A cardiac monitoring system vulnerability that could suppress an arrhythmia alert during active monitoring is categorically more severe than the same vulnerability during device configuration or data export. A surgical robot vulnerability exploitable during an active procedure is a different risk class than the same vulnerability during the post-procedure instrument cleaning cycle.

The Scoring Blind Spot:

Every CVSS score, every AI-generated severity rating, and every vulnerability triage workflow in use today assigns a single severity value to a finding, as if the device exists in one static operational state.

It does not. The attack surface, the exploitability, and the patient consequence of a successful exploit all change with clinical state. A vulnerability management programme that ignores operational context is not managing clinical risk. It is managing a spreadsheet.

This matters enormously for prioritisation. A vulnerability management programme that does not model operational state as a severity variable will systematically misjudge risk, overprioritizing findings that are technically severe but operationally constrained, and underprioritizing findings that appear moderate but are critically exposed during specific operational phases.

It also matters for regulatory submissions. FDA’s cybersecurity guidance for medical devices increasingly requires manufacturers to demonstrate that they have assessed risk in the context of intended use, not just in the abstract. A vulnerability risk assessment that ignores the clinical workflow context of when and how the device is operated is not just analytically incomplete. It is a regulatory exposure.

Building operational state awareness into vulnerability severity assessment is not a research aspiration. It is an engineering problem that the industry needs to solve, and soon.

What the AI Era Will Change for MedTech Product Security

The question C-suite leaders need to answer is not whether AI-powered vulnerability discovery will change their product security programme. It will, irreversibly. The question is whether that change arrives as a capability upgrade or a governance crisis.

Here is what will change, in ways that most MedTech organisations are not yet prepared for:

What changes	What it means for your organisation
Vulnerability volume	The finding backlog in your product security programme will grow by an order of magnitude. The triage capacity and prioritisation logic you have today were not designed for this volume. Programmes that rely on manual triage will collapse under it.
Public disclosure timeline	AI-powered researchers, including adversarial ones, will find vulnerabilities in your fielded devices that your internal team has not found. The window between a vulnerability existing and it being publicly known is shortening. Your post-market surveillance posture must assume earlier public exposure.
Regulatory expectation	FDA has signalled clearly that cybersecurity is a lifecycle obligation, not a pre-market checkbox. As AI-generated vulnerability intelligence becomes standard, regulators will expect manufacturers to demonstrate that they are monitoring at the same capability level. ‘We were not aware’ will become an increasingly difficult position to defend.
Litigation and liability surface	When AI tools can demonstrate that a vulnerability was findable, discoverable, and known in the research community before a patient safety incident, the question of manufacturer awareness and response becomes legally significant. The documentation of how you managed the remediation gap will matter in ways it has not before.
Competitive differentiation	Healthcare systems are beginning to ask meaningful cybersecurity questions in procurement. The manufacturers who can demonstrate structured, evidence-based vulnerability management, not just a security team and a scanner, will carry a measurable advantage in enterprise sales cycles.

None of these changes are contingent on your organisation adopting AI discovery tooling. They are consequences of the broader ecosystem shift. Your devices will be assessed by AI-powered researchers regardless of what tools you use internally. The question is whether your programme is designed to match the pace of discovery that is now occurring externally.

Where the Tooling is Moving, and What it Still Cannot Do

The vulnerability management program and platform market is evolving in directions that are relevant and, in some cases, genuinely useful for MedTech product security. The better platforms are moving beyond CVE aggregation toward contextualised risk prioritisation, correlating findings with asset metadata, device classification, environment context, and remediation workflow tracking to produce something closer to an operational risk signal than a raw severity score.

Platforms that approach the problem through the lens of operationalisation, asking not just what vulnerabilities exist but what they mean to this organisation, for these devices, in this regulatory context, right now, are oriented around the correct thesis. The gap between discovery and business-contextualised prioritisation is real, and systematic tooling that narrows it has genuine value.

For MedTech specifically, the capabilities that would matter most are ones the market is beginning to move toward, though none have yet fully arrived:

•       Device-class-aware risk scoring that can distinguish between a finding in a Class III implantable device and the same finding in a Class I general wellness product, not just as a metadata tag, but as a driver of the triage logic itself.

•       Regulatory submission linkage, the ability to connect a vulnerability finding directly to the risk management file entry, the post-market surveillance record, and the Design History File documentation, so that the evidence trail is assembled as a byproduct of the triage workflow rather than reconstructed manually at submission time.

•       Compensating control tracking during the remediation gap, structured documentation of what mitigations are in place between disclosure and patch delivery, in a format that can be presented to FDA, to hospital security teams, and to clinical governance bodies.

•       Clinical state context encoding, the ability to annotate a finding with the operational states in which it is exploitable, so that compensating controls and risk acceptance decisions can be scoped to the specific clinical contexts where patient exposure is real.

These are hard requirements, and the honest assessment is that no platform fully satisfies all of them today. The market is moving in the right direction. The gap between where tooling currently is and what MedTech product security actually requires remains significant, and that gap will not be closed by tool selection alone.

What the tooling still cannot do, and what no tool will do in the foreseeable future, is substitute for the organisational prerequisites. The organisational prerequisites, a clean device inventory with regulatory and clinical context encoded, a consistent risk taxonomy across the portfolio, defined decision authority for risk acceptance, an integrated workflow between security, clinical affairs, and regulatory teams, must exist before the tooling can systematise them.

A sophisticated platform implemented into an organisationally immature programme will produce better-formatted confusion, not better decisions.

What Leadership Must Own

The AI discovery era does not give MedTech leadership more time to build the product security capability that was always needed. It removes the remaining time. These are the decisions that only the C-suite can make, and that cannot be delegated to the security team, the quality team, or a vendor:

Define risk acceptance authority explicitly and in writing.

Who in your organisation can accept a known vulnerability in a fielded Class III device? What is the escalation path when the finding spans multiple product lines and regulatory classifications? If that authority is undefined, every ambiguous finding becomes an indefinite deferral. At AI-era discovery volumes, unlimited deferral is a patient safety liability.

Commission the compensating control architecture now.

The remediation gap in medical devices is not an edge case. It is the standard operating condition. The organisations that build a documented, validated compensating control framework before a significant public disclosure event will manage it. The ones that build it during the disclosure will be building it in front of regulators, hospital security officers, and in some cases the press.

Fund the contextual data infrastructure as operational investment, not project spend.

The device inventory that makes intelligent vulnerability prioritisation possible, clinical use context, regulatory classification, update pathway constraints, fielded population data, hospital system dependencies, degrades without active maintenance. It is not a one-time deliverable. If it is not funded as an ongoing operational capability, it will not exist when you need it.

Integrate clinical affairs into the vulnerability management workflow by design.

The clinical consequence of a vulnerability exploitation in an active therapeutic device is a clinical judgment, not a security judgment. If clinical affairs is not formally integrated into the vulnerability triage and risk acceptance process, your programme is making patient safety decisions without the people whose job it is to understand patient safety.

Treat the next FDA cybersecurity inspection as the minimum standard, not the ceiling.

Regulatory compliance is not product security. It is the floor. The organisations that will lead in the AI era are the ones that build programme maturity that exceeds regulatory requirement, because the regulatory requirement will continue to rise, and the distance between where you are today and where the regulation is heading is the risk exposure you are currently carrying.

The Reckoning is Already Here

I have spent time working at the physical boundary of what medical devices can be made to do , not through the software interface, but through the hardware itself. Side-channel analysis. Fault injection. The kind of testing that reveals what a device does when it is pushed beyond the threat model its designers imagined. What that work teaches you is that the gap between a device’s intended security posture and its actual security posture is almost always larger than anyone on the design team believed. Not because the engineers were careless. Because the threat model was built for a world that no longer exists.

AI-powered vulnerability discovery is doing the same thing to the medical device industry at scale. It is revealing the gap between the security posture manufacturers believed their products had and the security posture those products actually have, across thousands of CVEs, across foundational software components, across device families that have been deployed and trusted for years.

That revelation is not a crisis in itself. Vulnerabilities have always existed. What makes this moment different is the speed, the scale, and the inexorable nature of the exposure. There is no version of the future in which AI discovery tools are or will not be used against medical devices, by researchers, by regulators, and eventually by adversaries. The question is whether the industry’s product security programmes are built to respond at the same pace, or whether they remain calibrated to a discovery rate that no longer reflects reality.

The organisations that respond well will not be the ones that bought the best scanner. They will be the ones whose leadership understood that product security in a safety-critical industry is ultimately a governance question, about accountability, about evidence, about the chain of decisions between a known vulnerability and a patient in a hospital bed and built their programmes accordingly.

The AI era has arrived. The patients whose lives depend on these devices did not get a choice about that. Neither do you.