Security Highlight: The AI Race Against Time

There is a familiar saying in cybersecurity: “defenders have to succeed every time, while attackers only need to succeed once”. Although this oversimplifies how security works, it captures a longstanding challenge. Defenders work to identify and eliminate every vulnerability, while attackers search for one single weakness that might give them access.

Today, AI is changing the speed of that search. As vulnerability discovery and exploitation become faster, cheaper, and more scalable, the time available to respond is shrinking. For hardware and firmware, where fixes can take months or may not be possible at all, this is especially difficult. So, how can defenders keep pace, and is simply moving faster the answer?

AI Is Accelerating the Vulnerability Race

Recent developments demonstrate just how far AI capabilities in vulnerability discovery and exploitation have advanced. Anthropic’s Claude Mythos Preview achieved arbitrary code execution for 21 of 41 V8 vulnerabilities in its ExploitBench evaluation when results from two benchmark variants were combined. It was also able to escape the V8 sandbox in more than half of the tested environments.

Anthropic is also applying similar capabilities defensively. Its Project Glasswing uses AI to search open-source software for vulnerabilities, and Anthropic reported disclosing 6,157 vulnerabilities across 591 projects, with 516 patched, as of October 2, 2026.

OpenAI has demonstrated another side of what this change can look like. During a cyber-capability evaluation, AI models discovered and exploited a previously unknown vulnerability in a package-registry proxy to obtain internet access, then chained further exploits and stolen credentials to reach Hugging Face infrastructure. According to OpenAI, the incident occurred in an isolated evaluation environment with deliberately reduced safeguards, and OpenAI and Hugging Face detected and responded to the activity.

These demonstrations don’t show that autonomous AI exploitation is universally reliable. Benchmarks miss many real-world constraints, and models still have significant limitations. But they do show that the economics and speed of vulnerability discovery are changing.

A human security researcher has limited time to investigate potential weaknesses. AI agents can explore multiple hypotheses, fail, start over, and pursue alternative attack paths in parallel. As these capabilities improve, vulnerabilities that previously required substantial specialist effort may become considerably easier to discover.

Even security through obscurity, which has historically made some embedded systems more difficult to attack, may offer less protection.

At the 2026 [un]prompted.au conference, Brendan Dolan-Gavitt’ presentation Security Through Obscurity Is Dead and LLMs Killed It showed how LLM-based agents could assist with reverse engineering obscure systems, including building a functional QEMU model of HP printer firmware. Proprietary firmware formats, undocumented protocols, and unfamiliar architectures may no longer impose the same barriers when portions of the analysis can be automated.

To keep pace, defenders should be taking advantage of these same AI capabilities. AI can accelerate code review, fuzzing, reverse engineering, attack-surface exploration, and vulnerability validation, helping teams find and fix weaknesses before attackers do.

However, even the most advanced testing cannot guarantee that every vulnerability has been found. Finding and fixing 100 vulnerabilities does not mean that vulnerability 101 cannot exist. And even if defenders can match attackers in vulnerability discovery, they may not be able to match their speed when it comes to patching those weaknesses.

When Attacks Move Faster Than Patches

The gap between vulnerability discovery and remediation is particularly challenging in embedded systems. Unlike cloud services, where updates may be deployed relatively quickly, firmware updates often involve longer development, testing and validation cycles.

Microsoft has reported that operational technology (OT) systems can have years-long patching cycles, with updates sometimes tied to annual or twice-yearly maintenance outages. In its sample, more than 60% of devices were running older firmware containing eight or more known exploitable CVEs.

Similarly, a study of Siemens SIMATIC S7-1200 deployments found roughly eight to ten months between the releases of patched firmware and the first observed installations of those versions.

Hardware introduces an even greater constraint. Once a security assumption is committed to silicon, certain vulnerabilities may require a new chip revision to correct. For products already deployed, replacing the hardware may be prohibitively expensive or impractical.

This creates a fundamental mismatch. AI could increasingly enable attackers to discover and exploit vulnerabilities in hours or days, while remediation may take months or years.

Regulators, meanwhile, expect fast action. The EU Cyber Resilience Act (CRA) makes vulnerability management a priority throughout a product’s lifecycle and requires manufacturers to report actively exploited vulnerabilities with an early warning within 24 hours and a detailed notification within 72 hours. Reporting can happen in hours; firmware fixes still take months.

That is why firmware security needs to focus not only on how quickly vulnerabilities can be patched, but also on how quickly attacks can be detected and addressed.

Reversing the Asymmetry

Traditional vulnerability-driven security puts defenders at a disadvantage, and AI threatens to amplify this imbalance. Rather than accepting this asymmetry, defenders should look for ways to reverse it.

The goal is not to assume that every vulnerability can be prevented. Instead, it is to design systems where successfully exploiting one weakness does not automatically lead to complete compromise. Defense in depth is central to this approach.

Consider a vulnerability that allows an attacker to execute code on a device's main processor. That is a serious security failure, but it should not necessarily grant access to the device’s identity keys, sensitive security configurations, or every protected function.

Caliptra provides an example of how hardware security architecture can help establish such boundaries. Its architecture isolates important security-sensitive functions and key material from ordinary software. Its hardware-enforced key vault allows cryptographic operations to use protected secrets without exposing those secrets as ordinary software-readable data.

Detection and response can shift the balance further. An attacker may need to discover a vulnerability, exploit it, bypass isolation, access a protected resource, establish persistence, and avoid detection throughout the process. Instead of requiring every preventive measure to succeed, a system may be able to stop an attack when any one of several independent controls works. That is the asymmetry defenders should aim to create.

Firmware Already Offers Visibility

Fortunately, firmware and hardware already provide mechanisms that can help detect suspicious activity.

Detecting attacks at the firmware level does not mean putting a conventional endpoint detection and response agent on every microcontroller. It means making better use of the security mechanisms and system signals already available. Memory protection violations, stack-canary failures, control-flow violations, secure-boot failures, and unusual firmware-update activity can all indicate an attempt to bypass security boundaries or tamper with the device.

Individually, these signals may be incomplete or noisy. However, their value becomes clearer when considered as part of a broader security architecture.

When designing a product, manufacturers should ask themselves two questions:

• If an attacker bypasses a preventive security control, what evidence will the device be able to observe?
• What actions can the device take in response?

Depending on the system, those actions could include preserving forensic evidence, isolating a compromised subsystem, restricting sensitive operations, revoking credentials, reverting to known-good firmware, or notifying an external monitoring system. Which of these a device can support depends on its threat model, architecture, and deployment environment.

The underlying principle, however, is important. If a vulnerability takes six months to patch, detecting malicious activity within seconds could potentially reduce the damage an attacker can cause.

Don’t Freeze Tomorrow’s Defenses into Today’s Silicon

Detection and containment address part of the problem. Another important consideration is whether security implementations can adapt as threats evolve.

A completely hardwired cryptographic implementation can be fast and efficient, but if a new attack requires an implementation change or a new countermeasure, those gates are not going anywhere.

OpenTitan’s Big Number Accelerator (OTBN) illustrates an interesting approach. OTBN is a programmable processor designed for security-sensitive cryptographic workloads, combining conventional control flow with a 256-bit wide data path optimized for wide-integer arithmetic. Rather than committing every cryptographic operation to fixed-function logic, it provides a programmable foundation for implementing cryptographic algorithms and countermeasures.

That does not mean every crypto accelerator should become a CPU. Fixed-function hardware has important performance, area, power, and assurance advantages. The broader point is that programmability and adaptability can themselves be security properties. Where the tradeoffs make sense, hardware designers should avoid locking tomorrow’s countermeasures out of today’s designs.

The Principles Haven’t Changed

None of these ideas represent a new security principle. Finding and fixing vulnerabilities, applying defense in depth and least privilege, isolating sensitive assets, detecting attacks, responding to incidents, and designing for recovery remain fundamental. AI can help make many of these activities faster and more effective.

What has changed is the threat environment. Security can no longer depend on finding and fixing every vulnerability before an attacker does. Vulnerability discovery still matters, but it is no longer the entire game.

Testing the Defense, Not Just the Bug

This shift also changes the role of security labs. As vulnerability discovery accelerates, periodic product evaluations alone may no longer be sufficient. Labs may need to work more continuously with product teams, helping develop AI-enabled testing capabilities to discover, validate, and address vulnerabilities throughout a product’s lifetime.

At the same time, evaluations need to look beyond individual vulnerabilities and assess the security architecture itself. Does compromising one processor expose the entire device, or can defense in depth contain the damage? Can attacks be detected, and can those detection mechanisms be bypassed?

Existing measures such as CVSS and JIL focus largely on characterizing vulnerabilities and the effort required to find and exploit them. They say less about containment, detection, response, and recovery. As these properties become more important, security labs may need new tests — and perhaps new ratings — to measure how well a product remains defensible even after a vulnerability has been exploited.

The security principles have not changed. The threat has, and our defenses and evaluations need to change with it.

Want more stories like this? Subscribe to the Keysight Device Security Bulletin for monthly highlights on device security trends and practical insights — brought to you by the Keysight device security team.

Related Posts