Time is becoming cybersecurity’s scarcest resource. In June 2026, the leaders of the Five Eyes cybersecurity agencies issued a joint statement warning that AI is transforming cyber risk, accelerating the speed, scale, and sophistication of threats. The statement acknowledged that AI will help defenders, too, but the theme throughout the update was speed.
Frontier AI models are collapsing the timeline between vulnerability discovery and the development of a working exploit. These models can analyze large codebases, identify weaknesses, assess exploitability, and, in some cases, help produce proof-of-concept exploits in hours rather than the days, weeks, or months a skilled researcher once needed. Anthropic’s Claude Mythos has been reported to identify large numbers of vulnerabilities in heavily scrutinized software, and other reporting has described frontier models producing exploit paths for newly disclosed vulnerabilities within very short windows.
The conclusion for security leaders is that organizations should now assume that vulnerabilities will be discovered in their software regularly and at a much faster clip, and that attackers can act on those discoveries sooner than ever.
The response, in many cases, has been to double down on patching, patching faster and more strategically. However, patching was already under strain on the old timeline. A 2026 Cloud Security Alliance report found that only 9% of organizations remediate critical or high-severity vulnerabilities in production within 24 hours, while 74% take between one and seven days.
Those numbers reflect the real constraints of updating critical software in particular. Critical systems require testing, embedded devices need firmware updates, OT environments have maintenance windows, and regulated products often require validation before any change ships. None of that changes because attackers got faster. A defense model that depends entirely on fixing every serious bug before someone exploits it was already fragile. Against AI-accelerated discovery and exploit development, it becomes untenable.
Mitigation Asks a Different Question
For most organizations, patching is the only vulnerability response they have ever known. A bug is found, so the bug must be fixed, and every hour until the fix ships is an hour of exposure. Vulnerability mitigation starts from a different premise. Rather than racing to remove each bug before it is attacked, mitigation hardens the software itself so that vulnerabilities are dramatically harder to exploit while they exist, before a patch is available, and while remediation is underway.
For example, most serious exploits, particularly against software written in C and C++, depend on memory corruption and on the attacker’s ability to predict how the target software is laid out in memory. Attackers locate useful fragments of legitimate code, chain them together, and hijack the program’s execution. Automated mitigation techniques, such as Load-time Function Randomization, take away the paths attackers know to use. Every device boots with a unique memory layout, so an exploit built to target a known path fails. The bug is still in the code, but entire classes of vulnerabilities, memory corruption flaws chief among them, stop converting into reliable compromise.
That distinction changes the time equation. AI-accelerated discovery only threatens an organization if the resulting exploit actually works. Mitigation attacks the exploit rather than the bug, which means protection takes effect the moment software is hardened and holds through the entire remediation window. Teams can still assess exposure, test the patch, and deploy on a schedule that their operations can absorb. They are no longer doing that work while fully exposed.
What Mitigation Looks Like in Practice
This approach has been proven against one of the most serious sets of embedded vulnerabilities of the last decade. In 2019, researchers disclosed URGENT/11, a group of eleven vulnerabilities in the widely deployed VxWorks real-time operating system, six of them critical remote code execution flaws affecting an estimated two billion embedded devices. Years later, many of those devices remain unpatched because updates are operationally risky, costly, or simply unavailable.
A U.S. military weapons program facing exactly that constraint applied Load-time Function Randomization to VxWorks devices that still contained the known flaws, then directed its red team to attack them. Randomization cut the supply of return-oriented programming gadgets, the reusable code fragments attackers chain together to hijack execution, from 14,500 to zero. The red team could not build a working exploit, even though vulnerabilities remained in the code.
Although the bugs were never patched, the systems were no longer practically exploitable. For devices where patching is measured in years or may never happen at all, that is the difference between exposure and resilience.
Making the Shift
Mitigation complements secure coding, Software Bills of Materials (SBOMs), vulnerability scanning, and patch management rather than replacing any of them. Known vulnerabilities should still be remediated, especially on exposed systems and software with active exploitation in the wild. The shift is in what carries the risk during the gap. Under a patch-only model, the gap is pure exposure. With mitigation in place, the gap is covered.
Teams making the shift to mitigation should start where the patch gap is most dangerous, including internet-facing systems, safety-critical environments, operational technology, embedded devices, defense systems, and products deployed at scale. Systems that are hardest to patch deserve attention first, because they are where discovery-to-exploit speed hurts most. Accurate, current SBOMs help teams see where affected components live when a new vulnerability drops, and pairing that visibility with mitigation is what changes the risk while remediation is pending.
For boards and executive teams, the risk equation can change significantly with mitigation in place. How fast an organization can patch still matters, but leadership should also ask how resilient systems are while remediation is underway, which products or environments cannot be patched quickly, and what protection exists if a vulnerability is exploited before a fix is available. Those questions treat vulnerability management as resilience under imperfect conditions rather than a race that defenders are structurally positioned to lose.
AI will make defenders faster too, helping teams find vulnerabilities earlier, triage findings, and accelerate remediation. But fighting speed with speed will only take you so far. The organizations that adapt best will pair disciplined remediation with automated mitigation that makes their software hard to exploit in the first place. Time may not be on the defender’s side, but it can be taken back.
_______
About Shane Fry
Shane Fry is the Chief Technology Officer at RunSafe Security and has over a decade of experience in both offensive and defensive cybersecurity. Shane began his career performing vulnerability assessments on a variety of software platforms, and his research has spanned all layers of the hardware and software stack. Shane leverages his offensive security expertise to advise on secure system design for private industry, contractors, and the U.S. government.
