Key Takeaways
- The 2026 LaPorte Report defines Embedded Runtime Security (ERS) as a distinct discipline for protecting deployed embedded software at runtime.
- ERS makes exploit attempts fail at execution, rather than relying solely on vulnerability discovery and patching.
- It complements Software Bills of Materials (SBOMs), vulnerability scanning, patching, Zero Trust, and memory-safe development.
- Runtime techniques such as software memory protection can make memory-corruption exploits unreliable even before the underlying vulnerability is patched.
- ERS is particularly relevant for long-lived, safety-critical, air-gapped, legacy, and difficult-to-patch systems.
For embedded systems, finding a vulnerability and fixing it often happens on two very different timelines. A vulnerability might be disclosed today, but the affected software could be running inside an aircraft, medical device, vehicle, industrial controller, or other system that cannot simply take an emergency update. Patches may require extensive testing, coordinated field deployment, or another certification cycle, and some systems are air-gapped or difficult to reach at all.
Embedded Runtime Security (ERS) is a security discipline designed to address that gap. It was defined in the 2026 LaPorte Report special edition, “The Call for a Digital Golden Dome,” published by Lionfish Tech Advisors, which describes ERS as a class of active, in-place protections that make exploit attempts against deployed embedded software fail when they run, without waiting for a patch or requiring changes to source code.
What Is Embedded Runtime Security?
Embedded Runtime Security is the class of active, in-place protections that make an exploit attempt against deployed software fail at the moment it runs, without changing the software’s source code or behavior and without waiting for a patch.
The LaPorte Report introduced ERS as the flagship discipline within the Protect pillar of its broader Operational Software Assurance framework, with software memory protection as the anchor capability. The underlying idea is straightforward. Instead of making security depend entirely on how quickly a vulnerability can be removed, ERS changes the conditions an attacker relies on to exploit it successfully.
Traditional vulnerability management will find a vulnerability, assess it, patch it, and deploy an update. That process remains necessary, but embedded systems can introduce months between the first and last steps. The LaPorte Report describes embedded patch cycles ranging from three months to more than a year, with additional complications for certified, safety-critical, legacy, and air-gapped systems.
ERS adds a layer to that sequence: find the vulnerability, reduce its exploitability now, and patch when the system’s engineering and operational requirements allow. The vulnerability still exists and still needs remediation, but exploiting it becomes far less reliable while that remediation is underway.
Why Embedded Systems Need Runtime Protection
Embedded systems present a different security problem from conventional enterprise IT. A laptop, server, or cloud workload can often receive a security update quickly. That is not the case for firmware controlling an aircraft subsystem, production line, medical device, vehicle, or critical infrastructure, where systems frequently combine several difficult characteristics:
- Long product lifecycles
- Large C and C++ codebases
- Third-party and supplier binaries
- Real-time performance requirements
- Safety or mission certifications
- Limited compute resources
- Air-gapped or intermittently connected deployments
- Hardware that may remain in service for decades
At the same time, memory safety vulnerabilities remain a major share of exploitable software flaws. The research summarized in the LaPorte Report puts memory safety defects at roughly 70% of vulnerabilities in compiled code and approximately 75% of zero-day exploits. The result is a structural mismatch: vulnerabilities can be discovered quickly, while the software containing them changes slowly.
Several recent shifts are widening that mismatch. AI-assisted vulnerability discovery is increasing the rate at which flaws are found, software-defined systems are placing more code into safety- and mission-critical environments, and connected embedded devices are being deployed at a greater scale. ERS is designed to reduce the risk created by that gap.
How Embedded Runtime Security Works
ERS is a family of active protections rather than a single technology. That family includes address-space and binary randomization, control-flow integrity, stack and heap hardening, execution-integrity protections, software diversification, and runtime integrity techniques.
One of the key techniques is software memory protection. Many memory corruption attacks rely on predictable details about how software is arranged in memory. An attacker identifies useful instruction sequences, or “gadgets,” and assembles them into an exploit chain, as in a return-oriented programming (ROP) attack. If every deployed copy of the software shares the same internal layout, an exploit developed for one instance can potentially be reused against all of them.
Runtime randomization removes that predictability. Load-time Function Randomization (LFR), for example, changes the location of functions each time software loads. Different deployed instances, therefore, have different memory layouts, and those layouts change again on the next load. The vulnerability may still be present in the code, but the attacker can no longer rely on a predictable internal structure.
Think of a memory corruption exploit as a burglar working from a memorized floor plan. If every house has the same layout, the map remains useful. If the layout changes from house to house, the map becomes unreliable. For bad actors, instead of building a single reliable exploit that works across all identical devices, the attacker has to contend with a different execution environment on each device.
Embedded Runtime Security vs. Patching
ERS does not eliminate the need to patch software. Patching removes the underlying flaw, while ERS addresses what happens before the patch reaches every affected system.
Consider a vulnerability discovered in software running on an industrial controller. Before the issue actually disappears from the field, a vendor may need to:
- Confirm which products and versions are affected
- Develop and test the fix
- Validate the patch against real-time and safety requirements
- Coordinate deployment with operators
- Schedule maintenance or downtime
- Confirm the update across the installed base
For certified products, a software change can also trigger additional validation or certification work, and the vulnerability remains in place throughout that entire period. ERS adds a protective layer while the normal remediation process continues. Patching removes vulnerabilities when practical, and ERS keeps software defensible while those vulnerabilities remain in deployed systems.
Embedded Runtime Security vs. EDR and Zero Trust
Endpoint detection and response (EDR) and Zero Trust are important cybersecurity controls, but they operate at different layers than ERS.
EDR and extended detection and response (XDR) monitor endpoints for suspicious behavior. That model assumes a system can support an agent and provide the necessary telemetry, which many embedded devices, firmware environments, and real-time operating systems (RTOS) were never designed to do. Zero Trust governs access to systems and resources. It can limit who or what reaches a system, but it does not prevent vulnerable software from being exploited once it is reached. ERS focuses on the software execution layer itself.
Each control covers a different part of the problem:
- SBOMs and SCA provide software visibility
- Zero Trust governs access
- EDR and XDR monitor systems capable of supporting agents
- Patching removes known vulnerabilities
- Embedded runtime security helps prevent selected classes of vulnerabilities from becoming reliable exploits while the software is running
ERS fills the gap left by controls that operate before deployment or alongside the software, rather than within the software at the moment an exploit executes.
Where Embedded Runtime Security Applies
The strongest ERS use cases are for devices where software is long-lived, the consequences of exploitation are high, and fast patching is difficult.
Medical Devices
Connected medical devices can remain in service for years while operating under strict safety and regulatory requirements. Runtime protection provides an additional mitigation layer for vulnerabilities in fielded firmware while manufacturers work through their normal remediation and validation processes. In one fielded medical device analysis, runtime protection mitigated 49% of the 2,000 analyzed vulnerabilities and 77% of critical vulnerabilities.
Automotive Systems
Modern vehicles contain growing amounts of embedded software across electronic control units (ECUs) and software-defined vehicle architectures, and that software needs cybersecurity support well beyond launch. A vulnerability identified years into a vehicle’s service life may require an over-the-air (OTA) update, dealership service, supplier coordination, or another remediation path. Runtime protection reduces exploitability during that interval.
Industrial Control and OT
Industrial and operational technology (OT) environments frequently contain legacy devices, custom firmware, programmable logic controllers (PLCs), and RTOS-based systems that cannot support conventional endpoint security agents. Runtime hardening adds protection directly to deployed software rather than assuming an enterprise endpoint architecture can be built around it.
Aerospace and Avionics
Avionics combine long software lifecycles with strict requirements around deterministic behavior, testing, and certification, which makes major software changes expensive and operationally difficult. ERS is particularly relevant here because protections can be applied without changing the software’s intended behavior or requiring a wholesale rewrite.
Defense and Mission Systems
Military platforms can remain fielded for decades and may operate disconnected from conventional IT infrastructure. The LaPorte Report connects ERS directly to these environments because a runtime protection layer operates on deployed binaries without depending on constant network connectivity or immediate patch distribution. The underlying research also draws on Defense Advanced Research Projects Agency (DARPA) programs examining software hardening in military systems.
How ERS Fits Into Operational Software Assurance
ERS is part of a broader concept introduced in the LaPorte Report called Operational Software Assurance (OSA), which focuses on what happens to software after it enters service. After a product ships, organizations still need to understand what software they are running, determine whether vulnerabilities are exploitable, reduce exploitability, and demonstrate that protections remain in place throughout the software lifecycle.
Within that framework, ERS is the runtime protection discipline inside the Protect pillar. In practical terms, OSA asks organizations to:
- Identify what is running
- Understand where exploitable risk exists
- Protect deployed software against exploitation
- Maintain evidence that the protection remains in place
Long-lived software needs active protection after deployment in addition to better processes before release.
How RunSafe Approaches Embedded Runtime Security
RunSafe Security combines software visibility with runtime exploit mitigation for embedded systems.
RunSafe Identify generates build-time SBOMs for embedded software, including C/C++, firmware, cross-compiled builds, Yocto environments, RTOS images, and vendor toolchains. It provides the software inventory and vulnerability context needed to understand which components introduce risk.
RunSafe Protect applies runtime exploit mitigation to compiled C and C++ binaries and firmware using LFR. Protection is applied at build or integration time, and each deployed instance receives a unique memory layout that changes again whenever the software loads. Because the approach does not require rewriting application source code or replacing the compiler, it works with legacy software and third-party binaries where source code may not be available.
Together, the two connect three questions that are often handled separately: What am I running? Can it be exploited? How can I reduce that risk while the software remains deployed?
Closing the Gap Between Finding and Fixing
Embedded cybersecurity has made significant progress in software inventory, vulnerability detection, secure development, and patch management. None of those capabilities removes a basic operational reality, though: there will always be some period between discovering a vulnerability and removing it from every deployed device. For conventional IT, that window may be short. For embedded systems, it can last for months or longer, and ERS was specifically defined to address it.
By applying active protections to deployed software, ERS lets organizations decouple their security posture from how quickly they can find, patch, test, recertify, and redistribute every affected binary. As vulnerability discovery accelerates and embedded products stay in service longer, teams that build runtime protection into their lifecycle now will be able to handle new disclosures on their own engineering timelines.
Read the full Embedded Runtime Security Buyer’s Guide or download the ERS white paper to explore the evidence and evaluation framework in detail.
