The Case for Operational Software Assurance

Embedded software within operational technology is in the crosshairs of artificial intelligence (AI), geopolitical tensions, and growing regulatory pressure. These small devices are often overlooked, as larger cybersecurity risks and breach stories fill the news. But when nation-state actors target programmable logic controllers (PLCs) and water systems are compromised and taken offline, the enduring security of these devices becomes crucial.

In September 2026, Lionfish Tech Advisors released a report called “The Call for a Digital Golden Dome.” The report puts into perspective the challenge of defending devices across critical infrastructure and defense over their 10- to 30-year lifetimes. That challenge, paired with the rising stakes of getting it wrong, led the report authors to define a new market category called Operational Software Assurance (OSA). OSA introduces the practice of keeping deployed software secure, protected, and compliant across its operational life, from source to runtime. 

Here is why I find that framing and call so critical for embedded engineers, embedded product security teams, and critical infrastructure operators today.

Assurance Cannot End at Software Development

For most of the software world, security is something you need to get right before you ship. You write carefully, scan, fix what you find, and release. However, a programmable logic controller installed today may still be running in 2050, long after the team that built it has moved on and the toolchain that compiled it has been retired. The code does not change, but the cyber risk surrounding it does.

OSA starts from the reality that assurance cannot end when software ships. It sounds simple until you sit with what it means for a device with a thirty-year service life. Teams also need to make security decisions about how to defend devices with no one watching, on hardware that cannot be recalled, updated on a whim, or taken offline without consequence. That is a different discipline from secure development, and it is well past time to put a name to it and take action.

The instinct is to reach for the tools we already have, but none of them cleanly fit the fielded base. Patching assumes you can push a fix and confirm it has landed, but embedded patch cycles can run from months to more than a year, and many devices will never receive another update. A Software Bill of Materials (SBOM), which every embedded team should now produce, tells you what is inside a device, but does not stop any of it from being exploited. 

The Golden Dome report organizes the missing work into three pillars that map onto how embedded teams already think. Identify means knowing what is actually in the shipped build and which flaws are reachable, not merely cataloged. Comply means generating the certification and reporting evidence regulators now demand as a byproduct of the work rather than a separate paper chase. Protect, the pillar I find most consequential, means making exploits fail at runtime, whether or not a patch exists yet.

The Shift from Counting Flaws to Denying Exploits

Protect concentrates on memory-safety bugs first because this area is where embedded devices are most exposed. Roughly 70 percent of serious software vulnerabilities are memory-safety defects, the buffer overflows, use-after-free errors, and out-of-bounds accesses that let an attacker corrupt memory and hijack a program's execution. The report cites an analysis putting that same class at about 75 percent of the flaws used in zero-day exploits. 

Most of the C and C++ code running in fielded devices was written for speed and long service life rather than for this threat, which makes the largest single source of exploitable risk also the one that embedded teams can do the least about after the fact. Deny that one class of attack and you remove most of the paths an adversary uses to turn a flaw into control.

That is where AI changes the calculus. When a machine can find memory-safety defects in widely reviewed code faster than maintainers can fix them, the count of open vulnerabilities stops telling you much. What matters is whether a given flaw can be turned into control of the device. Embedded Runtime Security (ERS), the discipline the report places inside Protect, works on that question directly. Randomizing a binary's memory layout removes the predictable structure an exploit needs, so a return-oriented programming attack, the technique behind most memory-corruption exploits, fails when it runs. While the flaw stays in the code, the attack against it does not work.

There is real-world evidence that these types of protection work. Under DARPA's High-Assurance Cyber Military Systems program, researchers hardened the software on military rotorcraft and unmanned aircraft and then turned a professional red team loose on it. Even after the red team was handed root access on one partition of the system, it could not reach across to affect flight operations. The underlying flaws never had to be found and patched first. The exploits built to use them simply could not do their job, which is exactly the outcome an operator of a long-lived, hard-to-patch system should want.

One observation from the report is especially interesting, because it inverts the usual anxiety about AI. Machine-speed discovery does not favor the attacker evenly. It favors whichever side already holds resilient code. If the flaws a machine finds in your firmware cannot be weaponized against the build in the field, AI’s speed advantage produces nothing. You do not have to find every bug first. You have to make the bugs that get found unusable. For an embedded team that cannot patch on demand, that is a far more realistic goal than staying ahead of every disclosure.

An Argument a Program Manager Can Sign

The economics point the same way. Runtime hardening is a fixed cost, applied once to the binary, while patching is a recurring expense that only grows as AI drives up the bug count. For certified systems, the gap is wider still. Because hardening changes a binary's memory layout without changing what the software does, it can be applied without sending the device back through full recertification, the cost that dominates any change in a DO-178C, EN 50128, or FDA-regulated program. That property is what moves OSA from aspirational to affordable for the teams who need it most.

For embedded engineers, product security teams, and the operators who keep critical infrastructure running, OSA is less a product to buy than an expectation to design toward. Hardening the fielded base at runtime makes flaws waiting to be found worthless to an attacker. 

The devices in the crosshairs may not have been built for this threat environment. Operational Software Assurance is how we keep them dependable anyway, across the decades they still have left to run.