Cyber Resilience Act Checklist: Article 14 Is Now Live

The starting gun has gone. What follows is the checklist we work through with manufacturers who now have to answer a 24-hour clock rather than plan for one.

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, and it now tests it against a platform that exists rather than one on a roadmap. If you want the full sequence of dates either side of this one, our Cyber Resilience Act timeline for 2026 and 2027 lays them out in order.

What the CRA Reporting Clock Actually Measures

Article 14's wording triggers a consistent set of questions for nearly every program we advise on. We break each of those questions down below, name what ready looks like, and name how that capability tends to break. First, five things about the obligation itself that decide whether the rest of the checklist applies to you:

• 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, but you choose the destination. The Single Reporting Platform makes your filing available to the CSIRT designated as coordinator and to ENISA at the same moment, and that CSIRT disseminates onward to other affected Member States and to market surveillance authorities. Selecting the right coordinator is your job, not the platform's. Under Article 16(2) a manufacturer can flag particularly exceptional circumstances, in which case ENISA receives only partial information until the receiving CSIRT releases the rest.
• Age is not a defense. Article 69(2) grandfathers products placed on the market before December 11, 2027 out of the CRA's substantive requirements unless they are substantially modified after that date. Article 69(3) carves Article 14 straight back out of that grandfathering. The reporting duty reaches every in-scope product already on the market, with no cut-off date and no exemption for age. A controller you stopped selling in 2023 is in scope for as long as it is still in service.You do not report backwards. Per the Commission's implementation FAQ, you are not required to retrospectively report exploitation you already knew about before September 11, 2026. Become aware after that date and the obligation applies, including where the underlying vulnerability was already well known.

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

The Single Reporting Platform, as It Actually Works

ENISA switched the Single Reporting Platform on at portal.cra-srp.enisa.europa.eu on September 11, 2026, the same day the obligation started binding. What shipped is what ENISA calls initial operating capability, and the distance between that and a finished tool is where a readiness plan written over the summer comes apart.

Six things about the platform that no plan drafted in August could have accounted for:

• Access runs on personal EU Login accounts with MFA. The people who file register as Assigned Representatives and authenticate with their own credentials, not a shared corporate login. If your named filer does not already hold an EU Login, that is an IT provisioning task sitting directly on the critical path at hour zero.
• One Primary AR per manufacturer, up to 20 Secondary ARs. The Primary AR can see every notification filed for the manufacturer. A Secondary AR can see only the ones they submitted themselves. Build your backup plan around that asymmetry, because a Secondary AR covering for a colleague at 2 a.m. cannot open the filing they are covering.
• Selecting the wrong CSIRT invalidates the filing. ENISA states plainly that a notification sent to the wrong coordinator may be invalidated and has to be resubmitted to the correct one. Article 14(7) sets the test: the Member State where decisions about your products' cybersecurity are predominantly taken, with a four-step fallback for manufacturers with no EU establishment. Settle that question in writing now, not while a clock is running.
• The 72-hour counter is wrong in this release. ENISA documents that the platform calculates the 72-hour due date as 48 hours after you submit the early warning, rather than 72 hours after you became aware. File an early warning at hour 20 and the platform can show you overdue while you are still inside the legal deadline. The counters are reminders. The obligation runs from awareness, and so should your own clock.
• There is no API. Notifications go through the web interface. ENISA says API functionality may be considered in a future phase, which means whatever you automate internally still ends at a human typing into a form.
• Registration is not a pre-flight task, on ENISA's own advice. To limit the validation workload on national CSIRTs, ENISA advises registering only when you need to submit. The AR-to-manufacturer association is validated by the CSIRT in parallel with reporting, and an unverified AR can file up to 20 notifications before verification becomes mandatory. Guidance elsewhere telling you to pre-register runs against what the agency is actually asking for.

The platform is English only at launch. Voluntary reporting under Article 15 is not built yet, so a vulnerability you want to disclose but cannot show is being exploited has no route through this system. Reporting duties for open-source software stewards under Article 24(3) do not begin until December 11, 2027.

None of this changes what you have to know about your own products. It changes how little slack there is once you know it.

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.

1. 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.

2. 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: 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. The platform's timers are not a safety net either. In the current release the 72-hour counter runs from your early warning submission rather than from the moment you became aware, so it can flag you overdue before you actually are, and it will not warn you when the real deadline is closer than the displayed one.

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.