Cybersecurity is now a matter of life and death. Our defenses must catch up

Most processors run inside vehicles, factories, medical equipment, and critical infrastructure, where a breach can cost lives. Cybersecurity has to be built into the hardware from the start, not patched in later.


Cybersecurity is now a matter of life and death. Our defenses must catch up
Image Credits Credit: Jothy Rosenberg

Cybersecurity leaders must stop treating security as an IT problem confined to corporate networks. Most processors run inside devices that control vehicles, factories, medical equipment, and critical infrastructure. When attackers compromise these systems, people can die. We need independent, hardware-based security designed into critical systems from the start, not another software patch after launch.

For decades, companies built digital walls around valuable data and called that cybersecurity. But the physical world is full of connected computers. Fortune Business Insights reports that nearly 98% of microprocessors go into embedded systems rather than conventional computers. These processors control machines, monitor industrial processes, and help operate essential services.

Cybersecurity is therefore no longer simply an IT expense. It is a public-safety responsibility that affects everyone who depends on modern infrastructure.

Clear warning signs

According to Verizon’s 2026 Data Breach Investigations Report, exploiting software vulnerabilities accounted for 31% of breaches. That makes it the leading initial access vector. This is a serious problem. Vulnerabilities can provide attackers with a way into systems whose failure could have consequences far beyond stolen data. Artificial intelligence accelerates vulnerability discovery and exploitation. Organizations must strengthen defenses before weaknesses become opportunities for attack.

Software is indispensable. But it is not flawless. National Library of Medicine research references Steve McConnell’s Code Complete. It notes that the industry rate of programming errors is roughly 15 to 50 defects per 1,000 lines of code. Modern automobiles have over 100 million lines of code. In spite of best efforts, neither the DoD nor NASA nor anyone has come close to building perfect, bug-free software.

Attackers need only one exploitable weakness. AI compounds the problem in two ways. Attackers can manipulate training data to distort a model’s behavior. Or they can poison the inputs an AI system uses to make decisions. When that system controls machinery or infrastructure, corrupted information can become dangerous physical action.

What is at stake

Researchers demonstrated that pacemakers could be vulnerable to remote exploitation, raising disturbing questions about the safety of connected medical devices. In 2015, researchers remotely took control of a Jeep in a staged demonstration. It exposed how attackers could manipulate a networked vehicle while driving. Even though it was staged, it still cost Fiat over $2 billion in recalls and brand damage.

Then there was the Triton malware attack against safety systems at a Saudi petrochemical plant. It targeted devices designed to shut operations down when conditions became dangerous. The goal of the attack was to destroy the equipment and kill everyone there. The attack failed because of a flaw in the attackers’ code, not because the threat was imaginary. We cannot make public safety dependent on criminals making mistakes.

I have also watched software quality assurance lose ground. Forty years ago, when I ran a large software organization, we maintained roughly one tester for every four developers. Later, I consulted for a major U.S. defense contractor. There, I found fewer than one tester for every 20 developers.

That contrast should alarm anyone responsible for technology that affects human safety. The prevailing attitude is to ship products quickly and fix problems later. That is dangerous when a software flaw can compromise a physical system. Patching after an attack is not an adequate safety strategy.

Hardware oversight

The solution is independent hardware oversight. A processor executes instructions. But it cannot reliably serve as the independent authority that decides whether to allow every instruction. Oversight works in real time. We are going to detect the problem before the instruction executes and could have done any damage. NASA’s Triple Modular Redundancy compares outputs from three systems. It offers an example of engineering safeguards designed for situations where failure is unacceptable.

Retrofitting security is no substitute for designing it properly. I have seen a chipmaker attempt to limit buffer-overflow attacks. It reserved four address bits on 64-bit processors to track buffers. Four bits represent just 16 possible values, while even ordinary programs can manage hundreds or thousands of buffers. Such a workaround cannot provide comprehensive protection. This illustrates a broader mistake in technology development. It is trying to bolt security onto an architecture that was never designed to enforce it.

Two futures

We have two possible futures. In the better one, processors gain independent mechanisms to enforce security rules while software runs. Vulnerabilities can still exist. But systems have another line of defense against their exploitation. Manufacturers can build more trustworthy devices. Infrastructure operators can reduce operational risks. The public can have greater confidence in the technology controlling essential services.

The alternative is far darker. We continue stacking software defenses onto vulnerable software. Meanwhile, attackers use AI to find and exploit weaknesses at increasing speed. A compromised medical device, industrial safety controller, or vehicle could turn a digital vulnerability into a physical emergency. Essential services could be disrupted, workers endangered, and public trust eroded. The cost would be measured not just in dollars, but potentially in lives.

What leaders must do

Technology executives must demand hardware-level protection when designing and purchasing safety-critical systems. Manufacturers must incorporate independent verification early in product development. They must not treat it as an optional upgrade.

Policymakers must establish security and integrity requirements for embedded devices used in critical infrastructure. And procurement teams must evaluate whether products can prevent prohibited behavior, not merely whether they can detect attacks after damage occurs.

Security is not an optional tax. It is a cost of doing business when human lives are at stake. When technology controls the physical world, we cannot simply hope the software behaves correctly. We must build systems that independently verify that it does.

Get the TNW newsletter

Get the most important tech news in your inbox each week.

Thanks! Check your inbox to confirm your subscription.

By subscribing you agree to our Privacy Statement.