24 hours. Under the EU Cyber Resilience Act’s (CRA) new reporting obligations, that is exactly how long a device manufacturer has to report an actively exploited vulnerability or severe security incident. But the real exposure isn't the deadline itself, it’s the fact that most embedded teams are structurally incapable of knowing they’ve been compromised in the first place. Starting September 11, 2026, relying on the traditional incident response playbook of manual triage and customer escalations could expose teams to fines of up to €15 million or 2.5% of global turnover.
The obligation is harder to meet than it sounds because its scope is wider than most compliance programs assume: Article 14 doesn't wait for the CRA's full application in December 2027, and it doesn't apply only to new products. Under Article 69(3), it covers every product with digital elements placed on the EU market before that date, including devices shipped years ago whose firmware has not changed since.
Its trigger is even less forgiving. The 24-hour window opens the moment a manufacturer becomes aware of active exploitation or a serious security incident. On a typical embedded product, awareness is precisely what's missing. The vulnerable component may have entered the build through a third-party binary the manufacturer did not compile and the affected devices have been in the field for years. The age of the vulnerability is irrelevant: what triggers the obligation is the moment the manufacturer learns it is being actively exploited, whether on day one or ten years into a device's life. And without proper monitoring and visibility, an exploit can run silently for months before a customer escalation exposes it — so the countdown begins with nothing in hand: no scope, no root cause, no notification ready to file.
The reality is that most device manufacturers, OEMs, and physical AI companies are structurally and operationally unable to know within 24 hours that anything happened at all.
Why the Current Incident Response Playbook Fails
Consider how a typical embedded organisation finds out about the two events Article 14 regulates.
For vulnerabilities, someone monitors CVE feeds, usually as one responsibility among many, against a component list assembled at release from build manifests and vendor documentation. That list was incomplete the day it was written: closed-source drivers and vendor SDK payloads enter the build as opaque binaries whose contents no source-level tool can inventory and components introduced by the build process itself never appear in a source tree at all.
Worse, these CVE inventories go stale almost immediately, because while shipped firmware doesn't change, the list of known vulnerabilities against it now grows at machine speed. AI systems have industrialised vulnerability discovery, surfacing hundreds of high-severity flaws in mature, widely reviewed codebases in a matter of days. The window to react is collapsing just as quickly: the median time from disclosure to first exploitation has fallen from years to days over the past decade, and a growing share of exploited vulnerabilities are now weaponised within 24 hours of disclosure, or before any disclosure at all. When a component is later reported as actively exploited, the report demands answers: is it in our products, which builds, which variants, how many deployed units. Those answers come from archaeology, digging through build archives and release notes. That routinely takes longer than the entire reporting window.
For incidents, the situation is worse: most manufacturers have no visibility into their deployed devices at all. Traditional runtime tooling built for cloud and IT infrastructure doesn't run on a 256 MB industrial controller, so most fleets ship with no on-device telemetry whatsoever. Discovery happens downstream, via support tickets, anomalous behaviour reports, or a customer's SOC, and after the fact and the damage is done, with no automated forensic record of what actually occurred.
This workflow was tolerable when disclosure was voluntary and timelines were measured in quarters. Against a regulatory clock measured in hours, it fails by design. No amount of process documentation or on-call staffing fixes it, because the gap is architectural: the information the reports require is never captured in the first place.
Continuous Lifecycle Visibility
Exein's approach starts from a different premise: the only way to meet a 24-hour deadline is for the answers to exist before the clock starts. Instead of relying on a response team to assemble evidence after the fact, Exein monitors continuously across the device lifecycle, so that when an exploitable CVE is discovered or a device is attacked, awareness is immediate and the affected-product analysis is already done. The reporting deadlines then stop being an emergency staffing problem and become a quick lookup task. Exein’s continuous vulnerability monitoring covers three stages of the device lifecycle–before shipping, after shipping and in the field–where visibility is missing today.
Before shipping: Exein Analyzer works directly on the firmware image, requiring neither source code nor integration with the build system. It produces a complete SBOM of every component that is actually present in the build, including components the manufacturer did not knowingly include: vendor blobs, third-party drivers, transitive dependencies buried in an SDK. The distinction matters because a source-level inventory describes what was intended to ship and CRA’s Article 14 concerns what actually shipped.
After shipping: Analyzer's continuous vulnerability monitoring re-evaluates previously scanned firmware against updated CVE intelligence. When a new vulnerability is disclosed in a component shipped years earlier, it surfaces automatically, mapped to the exact builds, variants, and product lines affected. When the vulnerability is later flagged as actively exploited and the reporting obligation begins, the analysis that the 24-hour report demands is already done. The answers already exist the moment that the clock starts.
In the field: With Exein Runtime, a lightweight agent on the device enforces security policy at the kernel level. Photon, the flagship agent in the Runtime family, goes further and enforces preemptively: threats are blocked before they execute, not detected after the damage is done. A write to a protected model directory, an unexpected outbound connection, a spawned shell: the kernel will not proceed with the operation until Photon's policy approves it, because enforcement is built into the same kernel mechanism that Linux itself uses to authorise every operation. Where traditional detection amounts to reviewing camera footage after a break-in, Photon's enforcement is a lock that does not turn: the malicious operation is blocked before it executes, and every attempt is recorded with full context and aggregated fleet-wide.
For Article 14, this rewrites the starting position. Awareness has a timestamp: a recorded event on a known device, not a support call. Determining which devices are affected (i.e. how many, where, and in which deployments) takes minutes on the platform instead of weeks of manual investigation. Because every event is recorded as it happens, the root-cause analysis the final report requires is built from forensic evidence captured at the moment of the incident, with the full context of what occurred on the device already preserved.
Surviving an Exploit Without a Firmware Update
Consider a manufacturer of connected industrial gateways with 40,000 units deployed across Europe. In October, a vulnerability in a widely used networking library is added to CISA's Known Exploited Vulnerabilities (KEV) catalog. Without instrumentation, the following two weeks become a war room: which products use that library, which versions, which customers are affected, all assembled manually, under deadline, by engineers pulled off roadmap work. The early warning is filed late, or filed without substance.
With Exein integrated across the product lifecycle, the sequence looks different. Exein Analyzer’s continuous monitoring has already flagged the CVE against three firmware versions when it was first disclosed; the affected-product analysis exists before the exploitation report lands. The early warning is filed within hours, with specifics. The 72-hour notification then poses the harder question: what mitigating measures have been taken?
Fixing the vulnerability requires a firmware update and no embedded team validates and rolls one out in three days. The regulation's authors knew that. Protecting the devices does not have to wait for the fix. To exploit this vulnerability, an attacker has to make the gateway do something it has no legitimate reason to do, such as starting a command-line sessions. With Exein Runtime, the security team writes a rule that forbids exactly that action and pushes it to all 40,000 devices over the air, in seconds, with no firmware change and no reboot. The devices are protected immediately, the notification can state a mitigating measure already deployed in the field, and the firmware fix follows on its own schedule.
Visibility as a Feature, Not a Compliance Checkbox
Exein is not a certification body, and no software alone can establish CRA compliance. What Exein Analyzer and Exein Runtime provide is the capability Article 14 presupposes a manufacturer already has: knowing what is in the firmware before it ships, knowing when new vulnerabilities affect firmware already in the field, and knowing immediately, with evidence, when something happens to a deployed device. The reports become a byproduct of visibility rather than a scramble to manufacture it.
That's the larger shift this regulation forces on the industry. For twenty years, embedded security ended at the loading dock. From September 11, 2026, a product's security posture is the manufacturer's responsibility for as long as it's in the field. Visibility either exists as a built-in capability by then, or it doesn't, and the 24-hour clock is what exposes the difference.
The clock starts when the manufacturer becomes aware. Exein's job is to make sure that moment comes first, not last.
Exein Analyzer and Exein Runtime support CRA compliance preparation across the device lifecycle. Book a demo to see how they map to your product portfolio ahead of September 11, 2026.
Author
Sara Camnasio | Head of Product
