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
Get the TNW newsletter
Get the most important tech news in your inbox each week.
Facts Only
* The United States recorded 3,322 reported data breaches in 2025.
* Cyberattacks accounted for 80% of the reported data breaches in 2025.
* Memory-safety vulnerabilities, such as buffer overflow, are widely reported; Microsoft reported that roughly 70% of its annual CVEs are memory-safety issues, and Google reported a similar proportion among serious Chromium security bugs.
* Anthropic reported that Claude Opus 4.6 helped identify and validate more than 500 high-severity vulnerabilities in open-source software in February 2026.
* Verizon’s 2026 Data Breach Investigations Report showed vulnerability exploitation as the leading initial access vector, responsible for 31% of breaches in its dataset.
* The future involves processors becoming active participants in security.
* Memory-safe languages, better development practices, testing, patching, and conventional cybersecurity are considered important alongside hardware oversight.
Executive Summary
A fundamental blind spot in cybersecurity exists where protection is layered on top of systems that execute instructions without inherent security awareness, particularly in embedded systems. The stakes are highlighted by the high volume of data breaches, where cyberattacks account for eighty percent of reported incidents, suggesting that increased defensive measures alone have not resolved the core problem. The author argues that adding more software defenses creates noise and compounds vulnerability, as software itself contains bugs, leading to a situation where defenders struggle to distinguish genuine threats from false alarms.
The central proposal is the necessity of an independent hardware layer to monitor processor execution. This separation addresses the limitation of software-only defenses, which are susceptible to embedded flaws, by creating a security boundary that enforces rules regardless of the underlying code's perfection. This oversight is posited not only as a defensive measure but also as a means to expose vulnerabilities during operation, integrating security into the development process rather than relying solely on post-incident response.
The urgency is amplified by the accelerating threat from Artificial Intelligence, which can rapidly identify vulnerabilities, increasing the speed at which exploitable flaws can be discovered and leveraged against physical systems. The proposed future involves processors actively participating in security, leading to more trustworthy embedded technologies, contrasting with a darker alternative where layered software defenses compound risk faster than remediation can occur.
Full Take
The argument pivots on the limitation of software-centric security models when applied to systems controlling physical reality. The pattern observed is a systemic failure in relying solely on the application layer for critical integrity checks, which inherently increases complexity and noise for human operators. The transition from asking "How secure is the software?" to "What is watching the processor when the software fails?" redefines the security locus from runtime monitoring to execution control. This echoes a historical tension between the visible state (the code) and the underlying mechanism (the hardware); the proposed solution seeks to establish an immutable, privileged layer that governs behavior, which offers systemic resilience against the inevitable imperfection of code.
The implication for cognitive sovereignty lies in resisting the instinct to solve complexity by adding more layers of equally flawed software defense. The risk is not just technical failure, but the erosion of the ability to trust control systems when the mechanism governing them remains opaque. The acceleration driven by AI amplifies this dynamic: if an adversary can utilize AI to find novel flaws faster than human-developed patches can be deployed, the latency between vulnerability discovery and exploitation shortens to a point where reactive security is insufficient. This suggests that true resilience requires shifting the boundary of trust to the lowest possible level—the physical execution layer.
The counter-pattern being pushed against is the idea that incremental additions of software tools equate to progress. The proposed direction demands a paradigm shift: viewing hardware oversight not as an add-on, but as the foundational necessity for effective defense mechanisms. This requires acknowledging that software security efforts are often compensatory rather than foundational when dealing with physical systems.
Bridge Questions: If hardware oversight guarantees process integrity, what specific architectural constraints could be placed on execution flows without impeding necessary operational flexibility? How can the concept of "memory-safe" development transition from a desirable practice to an enforceable, mandatory standard across all embedded domains? What are the ethical implications when security oversight becomes a non-negotiable physical constraint on system operation?
Sentinel — Human
This text exhibits the strong structure and nuanced argumentative weaving characteristic of expert human writing, synthesizing technical concepts with macro-level risks effectively.