Embedded Systems Security in 2026: The Shift from Code to Chain of Custody

Embedded systems security is entering a critical phase in 2026. Manufacturers are dealing with tightening global regulations, increased attacks on unmanaged edge devices, and growing concern over software supply chain vulnerabilities buried deep in firmware.

“Teams must shift from ‘add safety and security later’ to a secure/safety development life cycle,” said Hareesha KoratikereRameshappa, Senior Technical Product Manager at Phantom AI, an automotive AI software company whose products run on embedded systems.

Across sectors such as healthcare, manufacturing, energy, automotive, and consumer IoT, long device lifecycles and historically limited visibility into deployed assets have created an environment where vulnerabilities can persist for years. 

According to embedded security expert Marta Rybczyńska, most recent attacks on embedded systems still depend on old bugs and vulnerabilities. 

“There are still devices running software, like the Linux kernel, from 15 years ago or more. And they do not have a valid update option usually,” she said. “However, I think that we will see a rapid change in the next few months.”

Rybczyńska says we’re likely to see new tools that will be able to identify vulnerabilities directly from firmware images, which dramatically lowers the effort required for analysis. That shift will hit smaller vendors hardest, since many of their products have avoided scrutiny until now because the effort to analyze them outweighed the payoff.

Another new challenge to embedded security is that threat actors are now targeting weaknesses in embedded systems directly.

The attack surface itself has shifted upward into the tooling, dependencies, and pipelines used to build embedded software.

Embedded Devices and Software Supply Chain Attacks

There have always been concerns about embedded security, experts say.

“Security for embedded systems or physical products is not a new topic; it is a decades-old challenge about product misuse when these systems are not protected against attacks or malfunctions,” KoratikereRameshappa said.

Traditionally, embedded security focused on hardening individual devices: locking down firmware, restricting physical access, and patching known vulnerabilities. Now, attackers are operating at a systems level, chaining weaknesses across devices, cloud services, development pipelines, and third-party software components.

Take the March TeamPCP campaign, a cascading supply chain attack that compromised widely trusted security and developer tools and turned them into distribution vectors for malware. Rather than exploiting a single device or vulnerability, the group moved laterally across ecosystems, poisoning CI/CD pipelines, open-source packages, and AI infrastructure to harvest credentials and propagate access at scale. 

Within days, compromises of tools like Trivy, Checkmarx KICS, LiteLLM, and the Telnyx SDK enabled the theft of cloud tokens, SSH keys, and Kubernetes secrets from hundreds of thousands of environments, illustrating how modern embedded and software systems can be breached indirectly through the very infrastructure designed to secure them.

Shortly after came the Axios attacks. Attackers hijacked a maintainer account and pushed malicious versions of the package that introduced a hidden dependency, triggering the installation of a cross-platform remote access trojan on any system that pulled the update. Rather than targeting a specific device or vulnerability, the campaign turned a routine software update into an infection vector, enabling credential theft, persistent access, and lateral movement across thousands of environments within hours.

‍
In both cases, one of the most trusted layers in the development workflow became the delivery mechanism, said Anthony Feddersen, VP of Engineering at NetRise, a firmware analysis and security platform that exposes risks in embedded software. 

“That is the shift. We are moving from vulnerability exploitation to trust exploitation. That is the gap embedded teams are dealing with,” he said.

According to Feddersen, attackers are no longer primarily targeting broken code. They are targeting what engineers assume is safe: packages, build systems, and automation pipelines.

“When that happens,” he said, “a clean dependency list does not mean much.”

When AI Models Find Decades-Old Bugs

While AI in all its facets has been a concern for embedded teams for a while now, Anthropic’s announcement of Claude Mythos Preview showed that AI can find decades-old bugs in software and string together working exploits autonomously.

In the case of Mythos, the model can identify and then exploit zero-day vulnerabilities across all major operating systems and web browsers when asked to do so. The oldest bug discovered at the time of announcement was a 27-year-old bug in OpenBSD. 

“We're seeing LLM models, such as Anthropic's Mythos, getting exponentially better at finding and exploiting vulnerabilities in software that the world depends on,” said Shane Fry, CTO at RunSafe Security. “With each passing day, and each new LLM model breakthrough, organizations’ IT and cybersecurity units are going to get more and more behind.”

Rybczyńska is concerned that AI will flood teams with vulnerability reports, a burden for those who are attempting to use spreadsheets to document vulnerabilities for the EU Cyber Resilience Act (CRA). 

“That will put a heavy load on teams that manage CVEs manually,” she said. “As a result, embedded development will need to move toward faster release cycles, automated testing, and more selective use of dependencies. Licensing alone won’t be enough to guide those decisions.”

To secure embedded devices, Fry said, the move will be to focus less on patching and more on cyber defenses within devices themselves. 

“Software developers and device manufacturers will need to revisit the reactive patching mindset and instead deploy protections that operate within their software and devices to keep adversaries at bay, " he said.

Moving from “What’s in the Software?” to “Who Is Behind It?”

The embedded security conversation is evolving, says Feddersen. The core question is no longer only “what is in the software,” but increasingly “who is behind it.”

Software Bills of Materials (SBOMs) and software composition analysis have long helped teams understand dependencies, but they primarily answer an inventory question. They describe what components are present, not whether those components are trustworthy.

That distinction is becoming critical in embedded systems, where products are built on layered stacks of third-party and open-source code, often with limited visibility into long-term stewardship.

Feddersen describes the gap as one of context rather than coverage. Teams may know a component exists in their product but struggle to answer deeper questions, like where the component originated and who maintains it today.

“What recent attacks showed very clearly is that the weak point is often not the code alone. It is the chain of custody around the code,” he said. 

Feddersen notes that even mature security programs struggle here, because visibility into components is not the same as visibility into trust.

“SBOMs tell you what you think you have,” he said. “They do not tell you whether you should still trust it.”

Embedded Risk Extends into the Physical World

KoratikereRameshappa notes that embedded system compromises increasingly affect physical environments. Surveillance systems, vehicle cameras, and robotics platforms can be hacked to collect sensitive data, for example, and medical devices can be targeted to access patient data or disrupt care delivery. 

These risks represent a convergence of cyber and physical domains, where compromise can move beyond data loss into operational disruption or safety impact.

“As technology advances, the risk of hacking embedded systems and products increases,” said KoratikereRameshappa. “What was highly secure five years ago is now an easily vulnerable target because AI can reproduce its behavior. What is secure now will become an easy target for vulnerabilities as technology advances in the future.”

Embedded teams must continually update security in response to technology changes, ensuring products remain secure.

“In the months ahead, teams will focus more on hardening build pipelines, validating software origin, tightening CI/CD credentials, and making dependency decisions earlier,” Feddersen said.