Pre-Ship vs. Runtime Security: Building the Full Stack

When a connected device is compromised in the field, whether it's an automotive ECU, a medical patient monitor, or an industrial robotic manipulator arm, the root cause is rarely a novel, sophisticated zero-day exploit. The reality is far more "ordinary." More commonly, compromises trace back to aged, well-known vulnerabilities in third-party components that have existed in the product for years, often without the manufacturer's awareness that they were ever integrated into the firmware build.

This asymmetry makes connected-device security impossible to solve with a single control layer. Right now, the industry is rallying around what is termed "real-time," or runtime, security to close this gap. The core premise is legitimate, and it follows concepts already established in enterprise IT endpoint security, such as endpoint detection and response (EDR): if you can monitor code execution deep inside the device's operating system, down at the kernel level, and detect and then block anomalous behavior before it has a chance to execute, you compress the window between exploitation and response.

Why the Monitor Struggles on Embedded Devices

While theoretically an important capability, runtime security is fundamentally flawed as a standalone strategy on embedded systems. Its complexity and demands match those of servers and endpoint PCs, yet most power-efficient, constrained devices lack the processing bandwidth, memory capacity, and power budget to run sophisticated detection and response continuously. A built-in monitoring agent, for example, is feasible and effective on a modern laptop or a powerful server, but becomes costly and impractical on a constrained device in the field.

Monitoring cannot operate as unobtrusively on an embedded system as it does on a server, because it affects processing determinism, a property that many devices running real-time operating systems depend on for precise execution. Running continuously alongside the kernel or bare-metal code, it depletes the battery. Caching the signatures it compares against leaves a memory footprint many devices can't spare. And streaming activity telemetry to a SOC or SIEM consumes wireless bandwidth, a scarce resource in most deployments.

Between the determinism hit, the power draw, the memory footprint, and the bandwidth cost, runtime monitoring on embedded systems ends up highly application-dependent. The generic threat detection and response that works on IT endpoints is hard to replicate on a constrained device, and is rarely as effective there. Monitoring is still worth having where a device can support it, but it can only ever act on whatever you happened to ship. Product security is the system. The most capable monitor in the world is only as sound as the firmware you hand it!

The Pre-Ship Foundation: Ground Truth Software Inventory

An agent with unlimited compute and power, running on every device, would still report only what the firmware does at runtime, never what it is built from. It can't see that a compression library in the build reached end-of-life 18 months ago, that three supplier components were dropped from the declared manifest, or which of the thousands of vulnerabilities in the stack are actually reachable rather than dead code. Those are exactly the conditions that put a product most at risk.

The attack surface takes shape long before the device powers on, when the product is designed, sourced, and assembled. Pre-ship security is the discipline of understanding the product before it becomes a customer problem. For connected-device manufacturers, that means analyzing the artifacts that actually ship.

When device firmware is compiled, source-code SCA tools analyze the code structures, not the final compiled product, where components get statically linked, vendor packages and nested libraries get merged, and open-source libraries get pulled into builds through indirect paths. This is also why pre-ship security testing rooted in deep firmware binary analysis is non-negotiable. By reverse-engineering the final compiled firmware, you build not just a ground-truth software inventory, but an execution-path-level understanding of what the firmware actually does and what it can reach that might be exploitable. This binary-derived Software Bill of Materials (SBOM) reflects reality, capturing the vendored libraries and third-party components that source-code static analysis scanners miss.

With Finite State's Product Security OS, that inventory becomes the basis for prioritizing real exposure. Reachability analysis confirms which vulnerabilities are actually exploitable in the specific build context, which cuts false-positive noise by up to 90%. Instead of triaging thousands of findings that may never execute, your team works on the ones that genuinely matter.

Evidence You Can't Reconstruct After the Fact

Regulators no longer treat connected-device security as a point-in-time exercise. Frameworks like the EU CRA, FDA 524(b), ISO 21434, and IEC 62443 now require a maintained, continuous evidence program rather than an audit response assembled at the last minute.

A runtime control does not, on its own, produce a complete SBOM, map findings to regulatory controls, or determine which product versions in the field are affected by a newly disclosed vulnerability. Those obligations require a continuous product security program that starts well before release.

Evidence built continuously, at the cadence of development, is traceable, defensible, and already in the format the regulator expects. Evidence assembled after the fact is a reconstruction, and regulators can tell the difference. The same binary inventory and reachability decisions that make your monitoring effective also produce the SBOM, control mappings, and version-impact answers a regulator asks for. Because that evidence accumulates as you build, it is ready the moment a disclosure lands.

How Pre-Ship Makes the Monitor Work

Pre-ship and runtime aren't competing choices; they run in sequence, and the order matters. The pre-ship pass produces the concrete artifacts a monitor needs to mean anything: the SBOM, the VEX decisions, the ground-truth component inventory, and the reachability-filtered vulnerability disposition. On the constrained devices where monitoring is hardest to afford, that groundwork also sharpens the monitor itself: tuning detection against a known inventory lets the agent watch only the areas that actually matter, shrinking the search space enough to make monitoring viable on a device at all.

When a critical vulnerability surfaces in the field, response speed becomes an obligation. To meet the CRA's reporting windows, a 24-hour early warning and a 72-hour notification filed through the ENISA-operated Single Reporting Platform, you need more than a runtime signal. You need a trusted system of record that correlates the finding against the live SBOM and confirms which product versions are actually affected.

You cannot monitor your way out of a fundamentally flawed firmware build. Build the foundation first: know exactly what you're shipping, prove what's reachable, and document the evidence. The monitoring that follows depends on it.

Know What You're Shipping Before the Clock Starts

When an exploit surfaces in the field, the CRA's reporting clock starts immediately, and the first question is which product versions are affected. Our CRA Readiness Assessment shows where your pre-ship program stands against those deadlines and what it takes to answer that question from the evidence you already have, instead of reconstructing it under pressure.