Cyber Resilience Act Checklist for Manufacturers (2026–2027)

The reporting obligation has been live since September 11, 2026. What follows is the checklist we work through with manufacturers who now answer a 24-hour clock that is already running, followed by the full set of steps that has to be finished before December 11, 2027.

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 six readiness questions below test your ability to finish that work in the time you have, against the platform ENISA actually shipped. If you want the full sequence of dates either side of this one, our Cyber Resilience Act timeline 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. 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 personal credentials. 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.
• 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, and it will not warn you when the real deadline is closer than the displayed one. 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.
• ENISA advises registering only when you need to submit. To limit the validation workload on national CSIRTs, the agency asks manufacturers to register when they have a notification to file. 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. Creating the EU Login accounts in advance is still worth doing.

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 and checked against 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 14 and lose track of the CVD responsibilities. ENISA plays a role in handling exploited vulnerabilities after the fact. Coordinated disclosure is the separate 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: Dispositions get recorded once, at triage, and never revisited. A NOT AFFECTED status that held for build 4.2.1 can quietly become false in 4.3.0 after a library update changes a code path, and nobody notices because the record looks complete. The other common failure is a justification that rests on a severity score or a supplier's assurance, neither of which an outside reviewer can check against the product.

The CRA Compliance Checklist for Manufacturers: 12 Steps to December 2027

The six questions above cover the obligation that is live today. These twelve steps cover the whole regulation, in two phases. Tick them off product by product.

Phase 1: Now, because reporting is already running

• 1. Scope every product on the EU market. List each product with digital elements you make available, including legacy versions still in service. Article 69(3) puts all of them inside Article 14 reporting.
• 2. Classify each product by its core functionality. Default, Important Class I, Important Class II, or Critical under Article 7 and Annexes III and IV, using the technical descriptions in Implementing Regulation (EU) 2025/2392. Class decides your conformity route and your lead time.
• 3. Build a component inventory from shipped firmware. You need it for 24-hour reporting today, and it becomes the SBOM obligation in Annex I Part II(1) in 2027.
• 4. Stand up the reporting path. Named filer and backup, EU Login accounts with MFA, your coordinating CSIRT settled under Article 14(7), a written runbook, and one timed drill.
• 5. Publish a coordinated vulnerability disclosure policy and contact address. Annex I Part II points (5) and (6) require both, and researchers are already sending reports.

Phase 2: Before December 11, 2027

• 6. Run a cybersecurity risk assessment for each product. Article 13(2) requires it, and it drives which Annex I requirements apply and how you justify each control.
• 7. Design 2028 products against Annex I Part I. Secure by default, minimised attack surface, data protection, and a secure update mechanism. Architecture decisions made this year lock in what those products can claim. See our security by design guide for the CRA.
• 8. Operate vulnerability handling for the full support period. Annex I Part II: remediate without delay, test regularly, disclose fixed vulnerabilities, and distribute free security updates securely.
• 9. Set and publish each product's support period. It must reflect expected use and is generally at least five years under Article 13(8). Our post on CRA product lifecycle and support requirements covers how to set it.
• 10. Choose your conformity route and book assessors early. Module A self-assessment for Default products. Important Class I products need a cited harmonised standard to self-assess; none is cited yet, so plan for a notified body. Class II and Critical need third-party assessment or certification. See CRA conformity assessments.
• 11. Compile the technical file. Annex VII contents, including the risk assessment and SBOM, retained for ten years or the support period if longer under Article 13(13). See CRA SBOM and technical documentation.
• 12. Sign the EU Declaration of Conformity, affix the CE mark, and ship user information. Article 28 and Annex V for the declaration, Article 30 for CE marking, Annex II for the information that goes to users.

For the full narrative behind each step, our step-by-step CRA preparation guide walks through them in depth.

How Should You Prioritize CRA Security Tasks?

Prioritize by dependency and lead time: inventory first because reporting depends on it, then architecture decisions, assessor booking, and documentation that accumulates continuously.

Four rules decide the order for most manufacturers we work with:

1. Start with whatever the live obligation depends on. Article 14 can't be met without knowing what's inside each product, so the inventory comes before everything else. It also feeds steps 3, 8, and 11.
2. Next, work on the decisions that lock earliest. A product shipping in 2028 has its bootloader, update mechanism, and cryptographic primitives fixed in design reviews happening now. Miss that window and the only remaining option is a redesign.
3. Book external capacity before you need it. If any product lands in Important Class I without a cited standard, Class II, or Critical, notified body time is a queue. Teams that ask in mid-2027 will wait behind teams that asked in 2026.
4. Let documentation accumulate as you go. The technical file is the record of steps 1 through 10. Teams that capture evidence as each step closes finish the file in weeks. Teams that reconstruct it at the end spend months, and some of what they need will no longer exist.

If you have one quarter of capacity before the end of 2026, spend it on steps 1 through 5. Every later step reuses that work.

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

Reporting is the first operational obligation, and running it well sets up everything that follows. The obligations arriving on December 11, 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 running today. Teams that treat reporting as a one-off project 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.

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.

FAQ

What are the CRA compliance steps for manufacturers?

Scope your products, classify each by core functionality, build a component inventory from shipped firmware, and stand up Article 14 reporting now. Before December 11, 2027, complete a risk assessment, meet Annex I, run vulnerability handling, set the support period, choose a conformity route, compile the technical file, and sign the Declaration of Conformity.

Which CRA tasks should come first?

The inventory. Article 14 reporting has applied since September 11, 2026, and you can't confirm within 24 hours that an exploited vulnerability affects your products without knowing what's inside them. After that, prioritize architecture decisions for 2028 products and notified body booking for higher-risk classes.

Do we need to register on ENISA's reporting platform before an incident?

ENISA advises registering only when you need to submit, to limit validation work for national CSIRTs. Create the EU Login accounts with multi-factor authentication for your filer and backup in advance, and settle your coordinating CSIRT in writing, so registration on the day takes minutes.