“Becoming aware” under the CRA: the technology stack you need to detect active exploitation

Article 14 of the Cyber Resilience Act applies from today. Every product with digital elements on the EU market, including the ones you shipped years ago, is now subject to the obligation to report actively exploited vulnerabilities and severe incidents through ENISA’s Single Reporting Platform. We covered the timeline, the penalties and the CVD policy requirement in our June article, and we will not repeat that here.

This article is about the harder question. The 24-hour clock starts when you become aware. Awareness is a conclusion your organisation reaches, not a notification that lands in an inbox. If you cannot reach that conclusion quickly and defensibly, one of two things happens. You miss the deadline because it took ten days to work out whether you were affected, or you file reports to ENISA about vulnerabilities that were never actively exploited in your product at all.

Below is the internal process a manufacturer needs, and the three technology capabilities that make it work: composition analysis that produces an SBOM, a threat intelligence function that correlates against it, and a lab that can reproduce an exploit against your actual product.

What “actively exploited” actually means

The CRA is precise about this and the precision matters. Article 3(42) defines an actively exploited vulnerability as one for which there is reliable evidence that malicious code was executed on a system by an actor without the system owner’s permission.

Compare that with Article 3(41), which defines an exploitable vulnerability as one that has the potential to be used by an adversary under practical operational conditions. The Commission’s Final Guidance (paragraph 231) makes the point that plenty of vulnerabilities are exploitable in a lab or a simulation and not under the conditions the product actually operates in. Exploitable does not trigger Article 14. Actively exploited does.

On the timing, the Final Guidance is clear at paragraphs 213 and 214. When a manufacturer detects a suspicious event, or a customer, researcher, CSIRT or journalist brings one to its attention, it must assess that event immediately. It is regarded as having become aware when, after that initial assessment, it has a reasonable degree of certainty that a vulnerability in its product is being actively exploited.

So there are three things a manufacturer has to establish before the clock starts. The vulnerability is in a product you ship. It is exploitable under that product’s operational conditions. There is reliable evidence that someone is exploiting it. Each of those maps to a specific capability, which is the rest of this article.

Why a CVE feed is not awareness, and not an excuse either

A CVE publication or a CISA KEV listing for a component you use is not, by itself, awareness. It is a suspicious event. It obliges you to run the assessment. The clock starts when the assessment concludes with reasonable certainty, not when the feed updates.

That cuts both ways. Paragraph 214 of the Final Guidance puts the emphasis on prompt action to carry out the assessment, particularly where the vulnerability may pose a significant risk. A manufacturer that receives a KEV alert on Monday and concludes its assessment the following Thursday, because nobody could find the firmware manifest, has a problem. A manufacturer that receives the same alert and has a timestamped record showing the SBOM query ran within the hour, the lab reproduction ran that afternoon, and the awareness decision was signed the same day, has a defence.

The risk runs in both directions. Over-report and you are sending ENISA and your CSIRT theoretical issues, which wastes their time and yours and makes your product look worse than it is. Under-report and you are in the top fine tier under Article 64(2). The only way out of that squeeze is an assessment process that is fast enough to be prompt and rigorous enough to be right.

Capability 1: know what is in every product version

The first question in any assessment is the simplest to state and, for most IoT manufacturers, the hardest to answer inside a working day. Is the affected component in a product we ship, and in which versions?

Without a machine-readable software bill of materials, answering this means an engineer pulling build manifests, checking which SDK version went into which firmware release, and hoping the vendor’s binary blob was documented somewhere. That takes days. With an SBOM per product per release, it is a query.

The composition analysis tooling needs to do a few specific things to be useful for CRA purposes:

1. Generate a CycloneDX or SPDX SBOM for every product and every firmware or software release still within its support period, and keep those historical SBOMs queryable. An SBOM for the current release alone does not tell you whether the units you shipped in 2023 are affected.
2. Cover binaries, not only source. IoT products are built on vendor board support packages, chipset SDKs and pre-compiled libraries. Source-only composition analysis misses most of what actually runs on the device. Binary analysis is the part that catches the OpenSSL build inside the Wi-Fi module firmware.
3. Capture transitive dependencies, including container base images for the cloud back-end. If your product has a remote data processing component, its components are in scope too.
4. Record the component identifiers (CPE, PURL) in a form that threat intelligence feeds can match against automatically. An SBOM that only a human can read does half the job.

Annex I Part II(1) requires the SBOM anyway from 11 December 2027, so this investment is not optional in the medium term. It also underpins Article 13(6), which requires you to report vulnerabilities you find in a third-party component back to the person maintaining that component. You cannot do that if you do not know which components you have.

The common trap we see: the SBOM covers the application layer that the manufacturer wrote, and nothing below it. The vendor BSP, the bootloader, the RTOS, and the container base image never appear in the build manifest because nobody wrote them, so nobody listed them.

Capability 2: know what attackers are doing

The second question is whether anyone is exploiting the vulnerability in the wild. This is where a cyber threat intelligence capability earns its place, and where most manufacturers currently rely on someone reading a newsletter.

The sources, in roughly descending order of reliability for CRA purposes:

• CISA’s Known Exploited Vulnerabilities catalogue. A KEV entry is close to the Article 3(42) standard by construction, because inclusion requires evidence of exploitation.
• ENISA’s European Vulnerability Database (EUVD), which flags exploitation status and is the EU-native reference the CSIRTs themselves work from.
• Vendor and national CERT advisories for the specific components in your SBOM.
• EPSS scores, which predict exploitation likelihood. Useful for prioritisation, not evidence of exploitation.
• Exploit availability tracking. Public proof-of-concept code raises the probability but is not, on its own, reliable evidence of malicious execution.
• Your own telemetry. Crash reports, anomalous OTA traffic, authentication anomalies, honeypot hits and customer support tickets describing behaviour that matches a known exploit pattern.

The capability that matters is correlation. The CTI platform ingests these feeds and matches them against your SBOM inventory so that an alert fires when a component you ship appears in KEV or EUVD, and the alert already says which products and which versions. Nobody should be manually cross-referencing a KEV update against a spreadsheet of firmware builds at 11pm.

One distinction worth drilling into your team. “Exploit code exists” and “exploitation observed” are different facts. The CRA definition needs the second one. And KEV or EUVD telling you a component is being exploited somewhere tells you it is exploited in some product. Whether it is being exploited in your product, under your product’s conditions, is a separate question. That is why fleet telemetry from your own deployed devices is often the only evidence that gets you to reasonable certainty about your own product specifically.

Finally, the alert has to land somewhere. A CTI feed that emails a shared inbox has not created awareness of anything. The output needs a queue with an owner, a service level, and an out-of-hours path.

Capability 3: prove it in your product

The third question is whether the exploit actually works under your product’s practical operational conditions. This is where paragraph 231 does real work. A vulnerability in a debug interface that ships disabled, or a code path that your product configuration never reaches, is a materially different assessment outcome from one that works against a default install over the network.

A test lab for this purpose does not need to be elaborate. It does need to exist before the day you need it. The minimum:

• Reference units for every product and every firmware version still in the support period. Not one unit of the current model. If you have four products and each has had six firmware releases, that is a shelf of devices with a label on each one.
• An isolated network segment with full packet capture, so you can observe what an exploit does without it reaching production or the corporate network.
• The ability to load a specific historical firmware build onto a reference unit and run a public proof-of-concept against it.
• Firmware extraction and debug tooling for the platforms you ship on.
• A written test procedure and an evidence template, so that the output of a reproduction is a document, not a Slack message.

The lab output does double duty. It answers the exploitability question for the awareness decision, and it produces most of the content for the 72-hour notification (general nature of the exploit, mitigating measures users can take) and the final report (severity and impact). The evidence you generate on day one is reused, not regenerated.

For a small manufacturer, this can be two shelves of reference devices, a managed switch with port mirroring, and a laptop. What the market surveillance authority will look for is that the procedure is documented and the evidence is timestamped, not that the lab has a budget line.

The glue: a timestamped decision record

The three capabilities produce evidence. The process has to produce a decision.

That means a case management workflow with immutable timestamps for every step. When did the suspicious event arrive, and from where. When did the SBOM query run and what did it return. When did the lab reproduction start and finish, and what was the result. What threat intelligence was reviewed. Who declared awareness, when, and on the basis of what evidence.

If a market surveillance authority questions the timing of a notification, this record is what you will be asked for under Article 31. “We became aware on Tuesday at 14:20 because that is when the CISO signed the assessment, and here are the three pieces of evidence it was based on” is a defensible position. “We think it was some time on Tuesday” is not.

One practical note. ENISA’s FAQ indicates the Single Reporting Platform will not offer an API at launch, so submission is through the web portal. Your internal workflow can be fully automated up to the point of drafting the notification, but a person will file it. Build that handover into the procedure.

Putting it together: the four-step assessment workflow

Steps 1 to 3 can run in parallel and usually should. Step 4 is the moment the 24-hour clock starts. Everything before it is assessment; everything after it is reporting.

Who is authorised to declare awareness?

The governance layer is short but it has to be written down. One named role, typically the CISO or Head of Product Security, with a named deputy. A documented threshold for what “reasonable degree of certainty” means in your organisation, ideally with worked examples. An escalation path that works at 6pm on a Friday. And no approval committee in the loop that adds days to a decision the regulation expects in hours.

External researcher reports come into this same workflow. Your CVD policy and contact address, covered in the June article, are one of the main ways the suspicious event reaches you. The assessment that follows is identical whether the trigger was a KEV alert or an email from a researcher.

Not sure whether your current tooling can answer these four questions inside a working day? Take the free CRA Readiness Assessment and find out where the gaps are.

What this looks like at different maturity levels

The obligation is identical for every manufacturer in scope. What differs is how long the assessment takes and how defensible the record is.

1. Minimum viable. Open-source composition analysis (Syft, Trivy or similar) producing a CycloneDX SBOM per release. A scheduled job that checks KEV and EUVD against the SBOM component list. A shelf of reference devices and a documented reproduction procedure. A ticketing system that timestamps every action. This is achievable for a five-person engineering team and it meets the bar.
2. Commercial composition analysis with binary scanning, so vendor firmware components are covered. A CTI platform with automated SBOM correlation and alert routing. A dedicated lab network segment with packet capture. Assessment turnaround measured in hours.
3. Fleet telemetry feeding exploitation indicators back from deployed devices. Honeypots running your own firmware. Automated VEX generation so that “not affected” decisions are recorded in machine-readable form and reused. An integrated workflow from alert to drafted notification.

Most manufacturers we talk to are somewhere between “nothing” and tier one. The jump to tier one is the one that matters for Article 14.

Attestra for vulnerability handling and reporting

Attestra sits on top of the SBOM, threat intelligence and lab capabilities described above. It does not replace them. What it does is turn their outputs into the decision record and the notifications.

The Vulnerability Handling and Reporting module gives you a guided triage workflow that walks a suspicious event through the four steps to a documented, timestamped “reasonable degree of certainty” decision. It drafts the 24-hour early warning, the 72-hour notification and the final report with the right fields at each stage, for your team to review and file. And every action is logged into an audit trail you can export straight into the technical documentation pack under Article 31.

If you already have an SBOM and a CTI feed, Attestra is the layer that makes them add up to a defensible awareness decision. If you do not, the Readiness Assessment above will tell you which one to fix first.

Talk to a CRA specialist

The clock is not the problem

Manufacturers who struggle with Article 14 will mostly not struggle because 24 hours is a short window. They will struggle because it took them a week to find out whether the component was in the product, and another week to work out whether the exploit worked against it. By the time they reached reasonable certainty, they could not show when they had reached it.

Awareness is an engineering capability before it is a legal one. The manufacturers who handle Article 14 without drama will be the ones whose SBOM answers the first question in minutes, whose threat intelligence answers the second without a human reading a feed, and whose lab answers the third with a document rather than a guess.

Frequently asked questions