How to Turn Your ENISA Maturity Score Into a CRA Action Plan

Most SMEs that run ENISA's new self-assessment tool will end up staring at a spreadsheet full of numbers between 1 and 5 and wondering: now what? The score is not the destination. It's the starting point for a sequenced plan - and that translation step is where most organisations get stuck.

This post walks through exactly that: what each domain in the model is actually measuring, what a low score in each one means for your CRA obligations, and how to sequence the remediation work so you're not trying to fix everything at once.

Not legal advice. This post explains a publicly available ENISA tool and how its outputs relate to CRA obligations. It is not a substitute for legal or regulatory counsel.

---

The tool, briefly

On 13 July 2026, ENISA published the SME Cyber Resilience Maturity Assessment Model - a free, downloadable Excel questionnaire designed to help micro, small and medium-sized enterprises measure their CRA readiness. It arrived three weeks after ENISA's SME CRA Survey Report, which found that most SMEs know the CRA exists but few have turned that awareness into practical readiness.

The survey behind the model covered 194 organisations across 31 countries between February and March 2026, and found that roughly two-thirds had heard of the CRA - yet practical understanding of its requirements consistently lagged behind that awareness.

The tool is the agency's direct response to that gap. You can download it from enisa.europa.eu.

---

What the five domains are actually measuring

The model scores your organisation across five domains, each rated 1-5 per criterion, rolling up into an overall profile of basic, intermediate, or advanced.

Understanding what each domain is really testing - and which CRA obligations it maps to - is what makes the score actionable.

1. Governance and documentation

This domain checks whether product security has a home in your organisation: written policies, assigned ownership, management oversight, and records that would survive an audit. A score of 1 or 2 here typically means security decisions are made informally, with no documented process and no clear owner.

CRA relevance: Technical documentation under Article 23 and Annex VII requires evidence of your security approach - not just that you have one, but that it is defined, approved, and maintained. An informal governance posture means your technical file is likely incomplete before you've written a single line of it.

First actions at low score: Assign a named product security owner. Draft a one-page product security policy. Start a decision log. These are lightweight but they create the paper trail that Article 23 documentation depends on.

2. Risk management and security by design/by default

This domain tests whether you identify threats systematically, whether security requirements are set before development begins, and whether your default configuration is secure out of the box.

CRA relevance: Annex I, Part I requires that products are designed, developed, and produced to ensure an appropriate level of cybersecurity - including that they are delivered with a secure default configuration. A low score here is a direct signal that your Annex I obligations are not yet embedded in your development process.

First actions at low score: Run a structured threat model on your product (even a lightweight STRIDE exercise). Document the output. Define what "secure by default" means for your specific product and write it down.

3. Vulnerability management

This domain covers how you detect, track, prioritise, and patch vulnerabilities - including your coordinated disclosure process. ENISA's survey found that incident response and product lifecycle management were the weakest areas overall, particularly for microenterprises.

CRA relevance: Annex I, Part II requires manufacturers to identify and document vulnerabilities, apply patches without delay, and operate a coordinated vulnerability disclosure policy. The Article 14 reporting duty - which begins on 11 September 2026 - assumes you can detect and triage an actively exploited vulnerability quickly enough to hit a 24-hour notification window.

First actions at low score: Establish a CVD policy (ENISA has a template). Subscribe to relevant vulnerability feeds (NVD, EUVD). Assign someone to triage incoming reports. Document the process before a real incident tests it.

4. Product lifecycle management

This domain assesses whether security continues after a product ships: whether you track deployed versions, push updates reliably, and have a defined end-of-support date communicated to users.

CRA relevance: The CRA requires manufacturers to maintain an appropriate level of cybersecurity throughout the declared support period. ENISA's model notes explicitly that security does not end at the moment a product is placed on the market. A low score here means your post-market obligations - update delivery, support period declaration, end-of-life communication - are not yet operationalised.

First actions at low score: Define and document your support period for each product. Establish a process for delivering security updates. Communicate end-of-support dates to users in a findable place.

5. Cybersecurity skills

This domain checks whether your team has the competence to execute on the other four domains - including whether training is planned, whether external expertise is brought in where internal capability is thin, and whether security knowledge is kept current.

CRA relevance: Skills gaps are a root cause, not a symptom. An organisation that scores well on governance but has no one who can actually run a threat model or triage a CVE will fail to execute its own policies.

First actions at low score: Map current skills against what each domain requires. Identify the two or three most critical gaps. Address them through training, hiring, or a defined external support arrangement - and document that arrangement.

---

How to sequence the work: using Annex B

The model's Annex B is specifically designed to help SMEs prioritise. ENISA's guidance states that actions should be applied proportionally, taking into account the size of the organisation, the type of product, and the associated risks - and that for microenterprises, simpler approaches may be sufficient, provided they enable consistent, traceable, and timely management.

A practical sequencing approach:

1. Identify your floor. Any domain scoring below 2.5 is a priority regardless of everything else. These represent gaps that are likely to block your technical documentation or your conformity assessment.
2. Fix governance first. Without documented ownership and policies, improvements in other domains are fragile - they depend on individuals rather than process.
3. Tackle vulnerability management before September 2026. The Article 14 reporting duty is live from 11 September. If your vulnerability detection and triage process is informal, that deadline is the most immediate forcing function.
4. Pick 3-6 actions per quarter. The tool is designed to be re-run periodically. Set a realistic scope for each cycle rather than attempting a full transformation in one pass.

---

Your scores mapped to CRA work - try it below

Enter your domain scores from the ENISA Excel tool. The planner below will show you which domains to prioritise and what the first concrete actions look like for each.

---

What the maturity profile feeds into - and what it doesn't replace

Running the tool and improving your scores is genuinely useful preparation. It forces you to document practices that were previously informal, assign ownership that was previously assumed, and identify gaps before a market surveillance authority does.

But the maturity profile is an input to your CRA roadmap, not a substitute for it. The mandatory steps - product classification, technical documentation under Annex VII, conformity assessment under Article 32, and the EU Declaration of Conformity - are separate legal obligations that the maturity score does not satisfy.

The Excel tool automatically calculates maturity scores and is designed to be reused, so an SME can re-run the same assessment periodically and track whether it is actually closing gaps over time. That reusability is one of its most practical features: run it now to establish a baseline, then re-run it after each improvement cycle to measure progress.

For the full sequenced compliance roadmap - from product scoping through to Declaration of Conformity - see our CRA compliance checklist. If your organisation qualifies as a micro or small enterprise, the separate obligations and reliefs under Article 33 are covered in our Article 33 guide.

---