CRA Readiness Assessment: 7 Questions to Score Your Product

Most CRA readiness assessments are a forty-tab spreadsheet that somebody starts in Q1, and nobody finishes. This one is seven questions that take about ten minutes to answer, and they leave you with a score out of seven—a clear, defensible number you can bring to a leadership meeting instead of a vague sense that the work is underway.

Answer each question about a single real product, not your portfolio and not the roadmap, but one product exactly as it ships today. Give yourself a point for each question you can answer with evidence rather than intention, take half points only where we tell you to, and be strict about it, because a market surveillance authority will be. Your total is your CRA readiness score.

One date to keep in view while you go: September 11, 2026, when the Article 14 reporting obligation takes effect. The rest of the regulation—the essential requirements and CE marking—does not apply until December 11, 2027, which leaves you two very different calendars to plan against.

1. Is your product actually in scope?

The scope test is two gates, and you need both.

Gate one: does the product contain software or firmware? Anything counts, from a full Linux distribution down to a microcontroller running a few kilobytes of C.

Gate two: can it connect to another device or a network? This is where teams talk themselves out of scope. Indirect connections count. USB counts. Bluetooth counts. A cloud API counts.

So a machine tool with firmware and a service port is a product with digital elements. So is a desktop application with no hardware at all. So is a component you sell to another manufacturer who puts it inside their product.

If you have been saying "we're not really an IoT company," check again. And if you are reading this thinking "surely not us," score yourself zero—not because you're wrong, but because you're not sure, and uncertainty about scope is the thing that turns a 2027 problem into a 2027 emergency. Our EU Cyber Resilience Act explainer walks the scope definitions in full.

Score: One point if you can state, in one sentence, why your product is in or out of scope and point to the article that says so.

2. What class is your product, and can you defend it?

The CRA sorts products into four tiers, and where you land decides how your conformity assessment has to be done. The vast majority sit in Default, which allows self-assessment. Important Class I and Important Class II raise the bar, with a notified body generally required at Class II, and Critical products sit at the top, where an EU cybersecurity certificate can be required.

The guessing phase is over. On November 28, 2025, the European Commission adopted Commission Implementing Regulation (EU) 2025/2392, published on December 1, 2025, and in force since December 21, 2025. It sets out the technical descriptions for every Annex III and Annex IV category, with non-exhaustive examples. You can look your product up.

The rule that trips teams in both directions: classification depends on your product's core functionality, not on every feature or component inside it. A smartphone that ships with a password manager is not a password manager. An app that embeds a browser is not a browser. Those stay Default.

Go the other way, though, and it costs you the whole exercise. Talk yourself into Default when your core function is genuinely a firewall or a VPN, and your conformity assessment isn't weak. It's invalid. So is the CE mark that sits on top of it.

There's one more trap waiting for Important Class I, and it is a live one right now. Self-assessment is only available if you apply harmonized standards in full. As of August 13, 2026, no CRA harmonized standard had been approved or had its reference published in the Official Journal. Drafts are useful for preparation, but they don't give you the Article 27 presumption of conformity, and until a reference is cited, the self-assessment route for Class I is not something you can plan around. Our guide to conformity assessments under the CRA covers the routes in detail.

Score: One point if you can name your class and cite the category description in 2025/2392 that supports it. Half a point if you know your class and haven't checked it against the implementing regulation.

3. Could you email us your SBOM today?

If we asked you for a current software bill of materials for one product, could you send it before the end of the day?

Not a policy that says you'll have one. Not a ticket in the backlog. The file.

• Machine-readable format. CycloneDX or SPDX; either is recognized.
• Top-level dependencies are the floor, not the target.
• It has to stay current across your whole support period, which means it regenerates with every build rather than getting refreshed before an audit.

The bonus half-point is the one almost nobody gets. Open that SBOM and tell us which components are end-of-life upstream.

That question breaks the chain. If a maintainer stopped shipping patches two years ago, you can detect a vulnerability in that component, you can file your early warning inside twenty-four hours, and then you can't fix it. The fix is what closes out your final report. No corrective measure means no clock start on the fourteen-day deadline, and a case that sits open with your coordinating CSIRT.

Knowing what's in your product is step one. Knowing what you can still patch is the one that protects you. That's the difference between an inventory built from supplier paperwork and a ground truth inventory built from the binary that actually shipped.

Score: One point for the file today. Half a point extra if you can flag the end-of-life components in it. Start with what an SBOM has to contain if you're building this from scratch.

4. What's your support period, and where can a customer see it?

There are two parts to this, and you need both for the point.

Part one: what is your declared support period? The expectation is at least five years, unless the product is reasonably expected to be used for a shorter period. A product expected to stay in service longer may need a longer one.

Part two, and this is where the point is actually won: where does the customer see it before they buy?

Most teams have a number, but it lives in a strategy deck with "TBC" next to it. That is not a declared support period. That's an intention.

And during that window, security updates are free. Not a service tier. Not bundled into a gold maintenance contract. Free. So if your commercial model currently charges for security patches after year two, that isn't a documentation gap. That's a business model change, and it belongs on your CFO's desk rather than your security lead's.

Score: One point if the number is declared, defensible, and visible to a buyer before purchase.

5. Who takes the twenty-four-hour call?

This is the question with a real deadline attached, and it's the closest one.

From September 11, 2026, a manufacturer that becomes aware of an actively exploited vulnerability in its product must notify ENISA and the relevant national CSIRT within twenty-four hours. A more detailed assessment follows within seventy-two hours, and a final report within fourteen days of a corrective or mitigating measure being available. Notifications go through the ENISA Single Reporting Platform, which routes to ENISA and the coordinating CSIRT at the same time.

Two details that catch people out. The obligation covers products already on the EU market, not just products you place after the deadline. And the stakes are market access. A market surveillance authority can restrict or withdraw a noncompliant product from the EU market—which, for most companies, is the same as losing the product line.

So: name the person who makes that call. Not the team. Not "security would handle it." A name, and a named backup, because vulnerabilities don't respect annual leave.

Then the follow-up: do they know how to file? Have they seen the reporting platform? Have you run a dry run against a real CVE from last quarter and timed it?

The clock starts when you become aware. Not when legal signs off. Not when the fix is ready. Twenty-four hours is not enough time to invent a process. It is barely enough time to execute one you already have, which is why rapid PSIRT response is an operational problem before it's a compliance one.

Score: One point for a named owner, a named backup, and a completed dry run.

6. Where does a researcher report a bug?

A researcher finds a flaw in your product right now. Where do they send it?

You need a published coordinated vulnerability disclosure policy and a single point of contact. Here's how to score it honestly. Pause here, open a browser, and type your own domain followed by /.well-known/security.txt.

If that's a 404, you don't get the point. The CRA doesn't name RFC 9116 anywhere, so a security.txt file isn't literally mandated. It is the cheapest way in existence to make your contact address publicly available and machine-findable, which is the outcome the regulation is after.

This one matters more than it looks, and not because it's hard. It's the least expensive requirement on the entire list. A page, an inbox, and a documented process for what happens after a report lands.

Which is exactly why failing it looks so bad to an authority. If a manufacturer hasn't done the cheap thing, the assumption is that it hasn't done the expensive things either. At a lot of companies today, that report goes to a generic sales inbox and quietly dies. That isn't a gap in your security. It's a gap in your compliance.

Score: One point if the policy is published, the contact resolves, and someone owns the inbox.

7. Could you hand over your technical file this week?

A market surveillance authority writes and asks for your technical documentation. How long until it's in their hands?

If the answer involves the word "assemble," that's a zero.

The technical file is your risk assessment, your design decisions, your vulnerability handling process, and your test evidence, plus the EU Declaration of Conformity and CE marking applied correctly. Under Article 13(13), you keep all of it for ten years from placing the product on the market, or for the length of your support period, whichever runs longer.

There's a mental shift here that makes the whole thing click for engineering teams. To an authority, your security is your documentation. If you can't evidence it, from their side of the table you didn't do it. Work you did and can't prove scores exactly the same as work you never did.

That's the argument for generating compliance evidence automatically as a byproduct of the build, rather than reconstructing it from Jira tickets and Slack threads eighteen months later.

Score: One point if the file exists, is current, and could go out this week.

How to Read Your Score

Six or seven. You're ahead of the field. Your job now is proving the answers hold up under someone else's questions instead of your own.

Three to five. This is where most serious product companies actually are. You have a defined gap list and just over fifteen months for the bulk of it. Start with whichever zero has September attached, which is question five.

Zero to two. Uncomfortable, and still better to know today than to find out in an information request.

Whatever the number, the shape of the problem is the same. Only one of these seven questions has a 2026 deadline. Everything else lands on December 11, 2027. So a low score doesn't mean you're in trouble. It means you have one urgent thing and six important things, and they need very different calendars.

One note if you're a small company. The CRA makes accommodations for microenterprises and small enterprises, including a simplified format for technical documentation. Worth checking whether that applies before you over-engineer the paperwork.

If you scored low on question two, get a second opinion on classification before you build anything else. Getting the class wrong doesn't slow your compliance work down. It invalidates it.

FAQ

When does the EU Cyber Resilience Act actually apply?

The CRA's Article 14 reporting obligations apply from September 11, 2026, twenty-one months after the regulation entered into force. The rest of the regulation, including the essential requirements and CE marking, applies in full on December 11, 2027. The reporting duty covers products already on the market, so it isn't limited to new releases.

Can I self-assess my product under the CRA?

Default-tier products can be self-assessed, and that covers most products. Important Class I products can only be self-assessed if you apply harmonized standards in full. As of August 13, 2026, no CRA harmonized standard had been cited in the Official Journal, so the presumption of conformity that unlocks self-assessment for Class I is not yet available. Class II generally requires a notified body, and Critical products can require an EU cybersecurity certificate.

What format does a CRA SBOM need to be in?

Machine-readable, in a recognized format. CycloneDX and SPDX are both accepted. Top-level dependencies are the minimum, and the SBOM has to stay current for the duration of your support period rather than being generated once for an audit. Our CRA SBOM and technical documentation guide covers the field-level requirements.

How long is a CRA support period?

At least five years from placing the product on the market, unless the product's reasonably expected lifetime is shorter. Products expected to stay in service longer than five years may need a longer period. Security updates during that window are provided free of charge, and the period has to be communicated to buyers before purchase.

Who do I report an actively exploited vulnerability to?

ENISA and the CSIRT designated as coordinator in the member state where you have your main establishment, through the Single Reporting Platform. If you have no establishment in the EU, this follows your authorized representative.

The whole thing takes about ten minutes and leaves you with a single number. Run it on a real product with your team rather than from memory, and run it before September 11 rather than after.

If you want a second set of eyes on the answers, book a CRA walkthrough, and we'll go through your gap list with you.