The CRA Reporting Readiness Checklist

It’s your job to be ready when the gun goes off, and noticing when the stopwatch has started is also your responsibility. Consider this checklist your training plan.

Under Article 14 of the EU Cyber Resilience Act, you have 24 hours to act once you become aware that a vulnerability in your product is being actively exploited. Manufacturers underestimate how much work that opening clause can create. The regulation sets the timeline clearly, but it leaves the judgment call to you: how do you confirm whether a newly exploited flaw is present and reachable in one of your products? The checklist below tests your ability to finish that work in the time you have.

What the CRA Reporting Clock Actually Measures

Article 14's wording triggers a consistent set of questions for nearly every program we advise on. In this blog, we’ll break each of those questions down, explain what “ready” for September 11 should look like, and highlight common pitfalls. But first, a few basics:

• The trigger is exploitation in your product. Publication of the CVE does not start the clock. Neither does the availability of a patch, nor a customer's email asking whether you're affected. Take an EV charging controller you shipped in 2021, still supported and still running a TLS library a supplier compiled into it years ago. The 24-hour requirement kicks in only once you’ve established that the flaw is in your controller and that someone is exploiting it.
• The first filing is an early warning. It is your declaration to the authorities that you know about the vulnerability, and a list of the Member States where the affected product is sold. Remediation details can wait for the 72-hour notification and the final report.
• One submission routes everywhere. The single reporting platform sends your filing to the coordinating CSIRT in your Member State and to ENISA at the same time. ENISA passes it to other affected Member States and publishes vulnerabilities to the European Vulnerability Database.

For a severe incident rather than a vulnerability, the final report comes due within a month of the incident notification.

The Cyber Resilience Act Checklist: 6 Readiness Questions

Work down the list and score your own program honestly. Each item states what ready looks like, then names how that capability tends to break. These are the failure modes Finite State runs into most often when we assess a manufacturer's readiness. They stay invisible under normal operations and surface on the day the clock is running.

Scope and Inventory: Can You Tell Whether the Vulnerability Is in Something You Shipped?

Ready looks like:

• You maintain a component inventory for every product and version still inside its support window.
• The component inventory is derived from the actual firmware you shipped, not just from the build manifest.
• You can query it by component and version in minutes.
• Extra credit: compare supplier SBOMs against the binaries they describe.

Where it breaks: A manifest records what the build system believed it was assembling. Statically linked libraries and vendored code never appear in it, and supplier SBOMs usually carry the same gaps because the supplier cannot see its own full dependency tree either.

Reachability Analysis: Can You Prove the Vulnerable Code Is Reachable in Your Build?

Ready looks like:

• You can conclusively determine, per product and per build, whether the affected function is compiled into the image.
• You can test whether an external entry point can reach it in the deployed configuration.
• You can document every non-reachable finding with its justification.

Where it breaks: Severity scores describe the vulnerability, but they don’t tell you how it behaves in your product. CVSS and EPSS return the same value for every manufacturer shipping that library, so a team triaging on score alone cannot separate real exposure from code that never executes.

Reachability is the signal specific to your build, and it is how you know whether you are affected at all.

3. Coordinated Vulnerability Disclosure: Can a Researcher Reach You Before an Attacker Does?

Ready looks like:

• You have published a coordinated vulnerability disclosure policy, and you follow it.
• You have a monitored contact address for inbound reports.
• You work with reporters to disclose vulnerabilities and issue guidance to act on it once a fix ships.

Where it breaks: Teams consider it sufficient to report to ENISA under Article 14and lose track of the CVD responsibilities. While ENISA plays a role in publicly disclosing incidents, responsible coordinated disclosure is a different mechanism for identifying and addressing vulnerabilities before they become incidents. Our vulnerability handling guide walks both tracks in full.

4. Filing Authority: Who Has the Authority to File at 2 a.m.?

Ready looks like:

• A named person with standing authority to submit the early warning, plus a designated backup.
• Documentation that defines the path from the analyst who confirms exploitation to the person who files.
• You have run a timed drill against a real historical CVE, and addressed any lessons learned.

Where it breaks: An improvised approval process won’t come together in time overnight or during a weekend. Twenty-four hours sounds generous, but off-hours, time zone coordination, and unexpected legal reviews can easily result in a missed deadline.

5. Customer Notification: Can You Name the Affected Customers by Version and Market?

Ready looks like:

• You know which products, and which firmware versions, went into which markets.
• You maintain channels you can activate for one customer segment without emailing your whole install base.
• You have advisory language in draft, before you need it.

Where it breaks: You track regional variants and component data in different systems that may not agree or are updated on different schedules. Reporting to authorities and informing affected users are separate obligations, and the latter is required to earn and preserve customer trust.

6. VEX and Technical Documentation: Will the Reasoning Still Hold Up a Year From Now?

Ready looks like:

• You can record a disposition for every vulnerability in every product using the four VEX statuses: NOT AFFECTED, AFFECTED, FIXED, and UNDER INVESTIGATION.
• You update that record with every build and whenever the inventory or the code paths change, and you maintain past versions.
• An outside reviewer can follow each justification (e.g., not_affected, vulnerable function not present in the compiled binary, confirmed via binary analysis on build 4.2.1).

Where it breaks: If you lose the reasoning for your decision once a ticket is closed, you can’t recover it later. A defensible judgment you cannot reconstruct is no better than a guess. Documented dispositions should be preserved in your Annex VII technical documentation.

Every Checklist Answer Starts at the Shipped Image

Every item on that checklist rests on the same thing: knowing what actually went out the door. Affected-product determination, reachability, customer notification, and the disposition record all depend on the accuracy of your inventory.

That’s harder than it sounds, because most of what ships is code someone else wrote and compiled long before your team touched it. A manifest listing openssl, zlib, and busybox looks clean until binary analysis of the same image turns up a statically compiled libexpat and an mbedTLS build embedded as an opaque blob. When Finite State and Forescout examined five widely deployed OT and IoT cellular routers in 2024, each image averaged roughly 660 components and about 161 known vulnerabilities. The typical open-source component ran more than five years behind its current release. That’s real product risk that may not show up in a supplier survey.

Finite State is built to close that gap: an evidence-backed product-security platform for connected products, starting from the artifact you shipped. The Finite State Platform unpacks the compiled image to establish what is inside and correlates that inventory against exploit intelligence as new disclosures land. Reachability analysis then separates the exposures that execute from the ones that never will, and the VEX record carries those decisions forward as a governed artifact. Our managed CRA service runs the same cycle alongside teams who would rather not staff it in-house, with our analysts working the prioritization and disclosure calls. The regulatory determinations stay yours, grounded in evidence you can produce on demand.

What Happens After the First Filing

September 11 is an operations deadline, and clearing it well sets up everything that follows. The obligations arriving in December 2027 run on the same foundation:

• Ship products free of known exploitable vulnerabilities, in a secure default configuration.
• Operate a vulnerability handling process across the full support period.
• Maintain a machine-readable SBOM covering at least your top-level dependencies.
• Produce the EU declaration of conformity and the technical file behind it.

Each of those draws on the inventory, the evidence, and the record you are standing up now. Teams that build for September and then turn their attention elsewhere will build again in 2027, when the obligation list is longer, and the schedule is tighter. Keep the program running between the two deadlines and the December requirements arrive as additions to something that already works.

If you are reading this after September 11, nothing in the checklist changes. The obligation is simply live, and the next disclosure is the test.

See what your own firmware says. Book a demo and bring a product you have already shipped. We will unpack the image and show you what the manifest missed. If the program matters more than the platform right now, request a CRA walkthrough.