Protecting Execution in the Digital Age
We’ve spent billions defending software. It’s time to protect execution.
September 19, 2026 - 9:34 am Credit: © 480 Studio & Agency via Canva.com
Cybersecurity has a fundamental blind spot. We invest heavily in protecting software while neglecting the processor that blindly executes instructions. This needs to change. For billions of embedded systems powering cars, medical devices, industrial controllers, network equipment, and critical infrastructure, security requires an independent layer capable of monitoring processor execution.
The stakes are clear. The United States recorded 3,322 data breaches in 2025, a record high, with cyberattacks accounting for 80% of them. These numbers suggest that existing security measures, despite being extensive—including firewalls, endpoint protection, intrusion detection, vulnerability scanners, sandboxes, monitoring systems, and more—are not sufficient.
A recurring lesson in technology development is that simply adding layers of defense around a problem doesn't always solve it. Sometimes, moving the security boundary is necessary. Currently, this boundary resides predominantly in software.
While software defenses like firewalls, endpoint protection, and intrusion detection are valuable, they are themselves susceptible to bugs and vulnerabilities. We often ask vulnerable software to protect other vulnerable software. This creates a deluge of alerts, many of which are harmless, leading to a situation similar to the early days of COVID-19 testing when false alarms undermined the effectiveness of tests.
The key question is: Is the machine actually doing what it's supposed to?
Traditionally, processors execute instructions without understanding their legitimacy. If an attacker exploits a software vulnerability, the processor will blindly follow malicious instructions alongside legitimate ones.
Imagine instead an independent hardware layer observing these instructions as they execute. This layer could enforce rules dictating what software is permitted to do. A buffer overflow, for example, could still occur in the code but wouldn't turn into an exploit because the processor would stop the unauthorized behavior.
This approach fundamentally differs from relying on another piece of software to detect attacks after the fact. Hardware cannot be remotely altered like software can, providing a robust security boundary independent of code perfection.
Moreover, this oversight mechanism has a valuable side effect: it can expose bugs before deployment. During operation, the system could identify and report behavior violating its rules, enabling developers to discover previously unknown vulnerabilities. Security becomes integrated into the software development process rather than an afterthought.
Given the persistence of memory-safety vulnerabilities like buffer overflows, this backstop is desperately needed. According to CISA:
- Microsoft reports that approximately 70% of annually assigned CVEs are memory-safety issues.
- Google identifies a similar proportion among serious Chromium security bugs.
- CISA notes these vulnerabilities remain prevalent.