We’ve spent billions defending software. It’s time to protect execution

Cybersecurity has a fundamental blind spot. We spend enormous sums protecting software while the processor underneath it blindly executes whatever instructions it receives. That has to change. For the billions of embedded systems running cars, medical devices, industrial controllers, network equipment, and critical infrastructure, security needs an independent layer that can watch processors execute instructions.

The stakes are already visible. The United States recorded 3,322 reported data breaches in 2025, a record high. Cyberattacks accounted for 80% of them. These numbers do not tell us that every defense has failed, but they do tell us something important: adding more security products has not made the underlying problem disappear.

I have spent decades building technology, and one lesson keeps returning: when a system repeatedly fails in the same place, adding another layer around it is not necessarily progress. Sometimes you have to move the security boundary.

Today, that boundary is overwhelmingly software. We deploy firewalls, endpoint protection, intrusion detection, vulnerability scanners, sandboxes, monitoring systems, and countless other tools. They are valuable. But every software defense is itself software, and software contains bugs. We are often asking vulnerable software to protect vulnerable software.

That creates another problem: noise. A network operation center can receive thousands of alerts in a day. Some are genuine threats. Others are harmless. When defenders cannot reliably distinguish between them, they eventually face the same problem doctors faced during the early days of COVID-19 testing: a test that produces too many false alarms becomes less useful, even when the underlying science is sound.

The better question is: Is the machine actually doing what it is supposed to?

A processor executes instructions at extraordinary speed, but traditionally it has no understanding of whether those instructions are legitimate. If an attacker exploits a software vulnerability, the processor may execute the malicious instructions just as obediently as the legitimate ones.

Imagine instead an independent hardware layer watching those instructions as they execute. It could enforce rules about what the software is allowed to do. A buffer overflow could still exist in the underlying code, but the processor could stop the resulting prohibited behavior before it becomes an exploit.

That is fundamentally different from asking another piece of software to detect the attack after the fact. Hardware cannot be remotely rewritten in the same way software can. It can provide a security boundary that does not depend on every line of code being perfect.

And there is a useful side effect. This kind of oversight can expose bugs before the system is deployed in the field. During normal operation, a system could identify behavior that violates its rules and give developers evidence of a vulnerability they did not know existed. Security becomes part of the software development process rather than merely an emergency response mechanism.

We desperately need that backstop because memory-safety vulnerabilities, such as buffer overflow, remain stubbornly common. According to CISA, Microsoft has reported that roughly 70% of its annually assigned CVEs are memory-safety issues, while Google has reported a similar proportion among serious Chromium security bugs. CISA also points out that these problems persist despite years of fuzzing, static analysis, sandboxing, and other testing techniques.

This matters even more as AI accelerates both sides of the fight. In February 2026, Anthropic reported that Claude Opus 4.6 had helped identify and validate more than 500 high-severity vulnerabilities in open-source software. The same capability that gives defenders unprecedented visibility can give attackers unprecedented speed. Anthropic warned that AI models are already capable of identifying novel vulnerabilities and that the traditional time available for disclosure and remediation may no longer be sufficient.

Verizon’s 2026 Data Breach Investigations Report makes the urgency even clearer. Vulnerability exploitation became the leading initial access vector, responsible for 31% of breaches in its dataset. Verizon also reported that AI is helping attackers accelerate the exploitation process.

The future can go one of two ways.

Processors become active participants in security. Embedded systems can continue operating even when software contains flaws. Developers get continuous evidence about weaknesses. Manufacturers build devices that are harder to exploit. Cars, medical equipment, industrial machinery, and connected infrastructure become more trustworthy because the security boundary sits closer to the point where code becomes action.

The alternative is darker. We keep piling software defenses onto increasingly complex software stacks while attackers use AI to find weaknesses faster than humans can patch them. The attack surface grows, alerts multiply, and the code controlling physical systems becomes harder to trust. Eventually, the gap between discovering a vulnerability and exploiting it becomes shorter than our ability to respond. The implementation of oversight not only protects your applications, but it protects your cyber defense systems, making them able to do their jobs effectively.

We should not wait for that darker future to arrive.

Memory-safe languages, better development practices, testing, patching, and conventional cybersecurity all matter. Hardware oversight does not replace them. It gives them a backstop.

So the next time you evaluate an embedded platform, a connected device, or technology that will control something in the physical world, ask a harder question than “How secure is the software?” Ask: “What is watching the processor when the software fails?”

That is where cybersecurity needs to go next