Why Embedded Security Needs Resilience as Zero-Day Attacks Rise

Zero-day attacks are on the rise in 2026. 

According to a recent report from the Identity Theft Resource Center (ITRC), the first half of the year saw a marked increase in zero-day attacks, most likely driven by AI tools scanning for vulnerabilities. The report predicts that zero-day attacks may double this year. For embedded developers, this presents a unique set of problems. 

While zero-day vulnerabilities are dangerous in any environment, it’s more difficult—and sometimes not possible—to patch or replace embedded software. Vulnerabilities linger, sometimes for years. 

Embedded teams can’t rely on patching. Instead, embedded security relies on building resilient systems that remain sound in the face of unknown vulnerabilities.

Attacks Have Changed, but So Have Embedded Systems 

It is well known that attackers are using AI to find unknown vulnerabilities faster than humans can. But attackers aren’t the only ones who have changed. Embedded attack surfaces are now much larger and more complex. 

Take the electronic control units (ECUs) in cars, for example. Ten years ago, says Leela Lakshmi Sirana Jayaram, an HIL engineer with Ford, ECUs were designed for a single, dedicated function such as engine control, braking, or steering. Communication was limited to internal CAN and LIN networks, and required dealership visits for software updates. 

That small, well-defined attack surface has expanded. Today’s vehicles incorporate cloud services, Over-the-Air (OTA) updates, smartphone systems, V2X communication, telematics, driver assistance, and Ethernet.

“Instead of multiple isolated ECUs, we are increasingly building highly connected distributed computing platforms,” Jayaram said.

The evolution of embedded systems has meant that testing and validation for those systems is also changing. This has been particularly important with the advent of software-defined vehicles (SDVs), Jayaram said.

“It is no longer enough to confirm a module functions correctly under normal and edge case conditions. We now have to validate that it fails safely and securely under abnormal conditions too.,” she said. “Test plans and test techniques had to be updated to cover at component level, the network level, and the system level, with dedicated security test cases for each boundary. Automotive validation is continuously evolving in this new era of SDV vehicles to make sure safe systems are brought into the market along with new feature content.”

Embedded Vulnerabilities Are Ordinary. Embedded Systems Aren’t.

While zero-days present unique challenges for embedded systems, the vulnerabilities themselves aren’t unique at all.

“The bug classes are the same,” says security researcher Bechir Bouali, founder of MachineMode Security. “Memory corruption and logic bugs look alike everywhere. What changes is the context: threat model and attack surface."

When analyzing firmware and embedded devices, Bouali finds a few common security weaknesses: memory corruption, command injection, authentication and authorization issues,  hardcoded or predictable credentials, and debug or test interfaces that were accidentally left enabled.

“None of it is sophisticated,” he said. “It survives because that code has never been looked at by anyone with an incentive to break it.”

The vulnerabilities might not be unique, but embedded environments are. Unlike traditional software, embedded devices offer attackers opportunities to interact directly with the hardware, creating attack paths that many product teams may not include in their threat models.

Embedded code also presents its own challenges. Embedded products rely heavily on proprietary versions of protocols, cryptography, and decoders, rather than established code libraries.

“Custom code that nobody outside the vendor has ever reviewed is a good attack surface,” said Bouali.

Even after researchers obtain a firmware image, identifying exactly what software is running inside it can become a reverse-engineering exercise of its own. This is more difficult than it sounds. Researchers may first need to obtain the firmware by extracting it directly from the device, then reverse engineering stripped binaries and identifying third-party components.

According to Bouali, vendors frequently modify open-source software without clearly identifying those changes, making it difficult to determine exactly which components and versions are present.

“If this is difficult for a researcher with the device on the bench, it is worse for the manufacturer who never had visibility into what their supplier shipped them,” he said. 

Security Is Now a Product Engineering Problem

The security challenge for embedded teams goes beyond finding vulnerabilities. The teams building these products must also navigate a reality in which much of the code they rely on is outside their control, and fixes aren’t simple to deploy. 

"Connected products are no longer self-contained,” says Sébastien De Bollivier, a developer who builds software for connected products. “The moment a device talks to a cloud backend, a payment provider, and three SDKs, most of your attack surface is code you didn't write and can't inspect."

De Bollivier has firsthand experience of how different security becomes when software runs on devices deployed outside the development team's control, often in environments with limited connectivity and nontechnical users. The difference is especially clear when compared with traditional web development.

“Web software has spoiled a generation of developers. You find a problem at 2 p.m., you deploy at 2:15, everyone is on the fixed version,” he said. 

Deployed devices don’t work that way.

“Your threat model stops being ‘someone attacks my server’ and becomes ‘someone is holding my device,’” he said. 

Unlike web applications, where fixes can often be deployed immediately, embedded products may remain exposed long after a patch exists. Developers can release updates, but they cannot always guarantee that every device receives or installs them. With so many moving parts, embedded developers are operating with little margin for error.

“The safety net web developers rely on—if we get it wrong, we can fix it instantly—isn't there,” he said. “Every decision is closer to permanent, which makes security work expensive to do late and very expensive to skip.”

The Goal Is Not Perfect Prevention, but Controlled Failure 

Embedded teams can’t eliminate every security flaw, nor can they assume that every vulnerability will be identified and patched before attackers begin targeting it. Instead, they must build systems that can withstand vulnerabilities no one anticipated.

“Prevention determines whether an attacker gets in. Containment determines what happens next,” says Niclas Braun, founder and CEO of For Safety Group Inc. (4SI). 

In practice, that means designing systems where trust is limited rather than assumed. 

Every device and component should have its own verifiable identity and narrowly defined authority, so a compromised component cannot automatically gain control over the rest of the system. Secure boot helps ensure that only approved firmware runs at startup. Hardware roots of trust protect foundational identities and cryptographic keys, while signed updates help prevent unauthorized code from being installed.

However, these controls cannot address every stage of an attack. Authentic software can still contain exploitable vulnerabilities, and approved firmware can still be manipulated in ways its developers never intended.

"Authenticity is important, but authenticity alone is not authorization,” says Braun.

This distinction is especially important in embedded systems, where devices may remain deployed for years and a single vulnerability can affect thousands of products. A Software Bill of Materials (SBOM) can help teams understand which components may be exposed, but it cannot prevent exploitation or contain an attacker once a vulnerability is found.

Braun says an SBOM is a map, not a shield. It can help teams identify exposed components and prioritize remediation, but it cannot prevent exploitation or limit what an attacker can do after compromise.

For embedded teams, that means resilience requires both mitigation and containment. Preventive mitigations reduce the likelihood that an attacker can successfully exploit a vulnerability, while containment limits the damage if a component is compromised.

“The goal isn’t to find and patch every zero-day before an attacker reaches it. That is a race with no finish line,” said Joseph M. Saunders, Founder and CEO of RunSafe Security. “Mitigations, like embedded runtime security, can stop an attacker from turning a vulnerability into a working exploit, even while the vulnerability is still present and before a patch is available.”

Mitigation works by disrupting the techniques attackers use to exploit a software flaw into reliable code execution or other useful capabilities. It does not remove the underlying vulnerability, but it can make it significantly more difficult—or sometimes impossible—to exploit successfully.

“As zero-day discovery accelerates, reducing exploitability gives embedded teams a durable layer of protection instead of forcing them to treat every new vulnerability as an immediate patching emergency,” Saunders said.

“Embedded security cannot guarantee that every vulnerability is known,” Braun said. “It can guarantee that one unknown vulnerability does not automatically become unlimited authority over the whole system.”