ENISA's SME Cyber Resilience Maturity Assessment Model is a structured self-assessment aid for product-security maturity, not a certificate or legal test of Cyber Resilience Act (CRA) conformity. It is useful for micro, small and medium-sized enterprises that need a practical way to identify weak or inconsistent security practices, prioritise improvement work and repeat the assessment over time.
The model was published by ENISA in July 2026 and is primarily aimed at organisations that manufacture and place products with digital elements on the market. ENISA also notes that organisations involved elsewhere in the product lifecycle, such as integrators or service providers, can use it to assess and improve product-security practices.
The right way to use the model is therefore as a maturity and planning tool: assess the current state, support each answer with real evidence, identify gaps, assign improvement actions and revisit the assessment. Do not turn the resulting maturity level into a statement that a product or organisation complies with the CRA.
What the ENISA model assesses
ENISA groups the assessment into five product-security domains. Each domain is broken into maturity criteria that describe increasingly consistent practices.
| Domain | What to examine in practice | Examples of evidence | | --- | --- | --- | | Governance and documentation | Ownership, policies, product-security responsibilities, documented decisions and retained records | Roles, policies, technical documentation, decision records, review minutes | | Risk management and security by design and by default | Product risk assessment, architecture decisions, secure defaults and risk-based engineering controls | Risk assessments, threat models, architecture records, security requirements, verification results | | Vulnerability and patch management | Vulnerability intake, assessment, remediation, updates and retained vulnerability decisions | Vulnerability records, SBOMs, triage decisions, patch records, security advisories, update evidence | | Product life cycle management | Security work across development, release, maintenance and support | Release records, support-period decisions, test evidence, update history, end-of-support planning | | Awareness, competence and skills | Whether people performing product-security work have appropriate knowledge and responsibilities | Training records, role definitions, competence plans, specialist review records |
ENISA describes three maturity profiles: basic, intermediate and advanced. These profiles are intended to show how consistently product-related risks are managed across the organisation. The accompanying spreadsheet tool can be used to calculate maturity results and repeat the assessment later to track progress.
The important boundary is explicit in ENISA's own material: an advanced maturity level does not replace legal obligations and should not be treated as evidence of compliance. Maturity describes the consistency of practices. CRA conformity depends on whether the applicable legal requirements are met for the relevant product and manufacturer context.
Start by defining the assessment scope
A maturity assessment is less useful when different teams score different things without realising it. Before answering the model, define the scope in operational terms.
Record at least:
- which legal entity is being assessed;
- which product, product family or product-development process is in scope;
- which teams and locations contribute to that product lifecycle;
- which releases or lifecycle phases are represented by the evidence;
- who owns each of the five domains; and
- the assessment date and the evidence cut-off date.
For a small organisation with one product, an organisation-level assessment may map closely to the product. For an SME with several products, shared engineering processes may be mature while a specific product still has incomplete risk, vulnerability or lifecycle evidence. Keeping those scopes separate prevents an organisation-wide score from hiding product-specific gaps.
Score the practice you can demonstrate, not the process you intend to have
The biggest risk in a self-assessment is aspirational scoring. A policy saying that security reviews should happen is not the same as evidence that they happen consistently and influence product decisions.
For every assessment item, ask three questions:
- Is the practice defined? There is an agreed process, responsibility or control.
- Is the practice performed? Recent product work shows that the process is actually used.
- Is the practice evidenced? The organisation can retain and retrieve records showing what was done, by whom, for which product or release, and with what result.
A mature practice should normally be visible in ordinary engineering and product-security records. Examples include a risk assessment connected to security requirements, a vulnerability decision with rationale and affected-product scope, a security-update record linked to the exact release, or a support-period decision supported by lifecycle assumptions.
This evidence-first approach also makes the assessment repeatable. A later reviewer can understand why a score was assigned instead of reconstructing the reasoning from memory.
Use the five domains to find process breaks between teams
The five domains are useful individually, but many CRA readiness problems appear at the hand-offs between them.
For example:
- a risk assessment may identify a security requirement, but the release process may not retain evidence that the requirement was verified;
- an SBOM may exist, but component information may not be connected to vulnerability triage decisions;
- a vulnerability may be fixed, but the organisation may not retain the affected-release scope, decision rationale or update evidence;
- a support period may be stated to users, but ownership for monitoring vulnerabilities through that period may be unclear; or
- a secure-development policy may exist, but engineers may not have defined training or review responsibilities for the relevant product technology.
These are maturity issues because the organisation has some of the necessary pieces but lacks a reliable lifecycle connection between them. During the assessment, record such cross-domain breaks explicitly rather than hiding them inside an average score.
Treat the maturity profile as a prioritisation signal
A maturity profile is useful when it changes what the organisation does next. It is much less useful when the result becomes a dashboard number with no owner or remediation plan.
For each identified gap, capture:
- the domain and assessment criterion;
- the current evidence supporting the score;
- the operational weakness or missing control;
- the affected product or lifecycle scope;
- the improvement action;
- the accountable owner;
- the target date;
- the evidence expected when the action is complete; and
- any dependency on another team, supplier or external process.
Then prioritise the work using product risk and regulatory significance rather than maturity score alone. A low-scoring training item and an unowned vulnerability-handling process are both maturity gaps, but they may not create the same operational or regulatory exposure.
A practical ordering is to address gaps that prevent the organisation from performing required product-security work, producing required evidence or responding within required lifecycle timelines before polishing already-functional processes.
Keep maturity assessment separate from CRA requirement coverage
The ENISA model takes CRA requirements into account, but it is not a replacement for a requirement-by-requirement legal and technical assessment.
Maintain two separate views:
- maturity view: how consistently the organisation performs product-security practices; and
- requirement view: which CRA obligations and essential requirements apply to the product, what implementation addresses them, and what evidence supports that conclusion.
The two views should inform each other. A weak maturity result may point to an area where requirement evidence is likely to be incomplete. A requirement gap may reveal that a supposedly mature process does not cover the actual product obligation. But the maturity result itself does not establish the legal status of the product.
This distinction also matters for conformity assessment. The CRA defines legal conformity-assessment routes based on product classification and other conditions. An ENISA maturity profile does not replace those procedures, alter the applicable product class or create a presumption of conformity.
Use the ENISA SME survey as context, not as a target score
ENISA's 2026 SME CRA survey explains why the maturity model focuses on practical implementation. The survey covered 194 organisations from 31 countries, including 25 EU Member States. ENISA reported a gap between awareness and practical readiness, with 66% of respondents having heard of the CRA before the survey.
ENISA also found that company size was a consistent maturity factor across the five domains, and that incident response and product lifecycle management were the weakest area overall, particularly for microcompanies. Technical-documentation and secure-development templates were among the most requested forms of support.
Those findings are useful signals for deciding where an SME should look carefully, but they are not benchmark targets. The survey sample does not determine what maturity level a particular manufacturer should have, and matching an average survey score does not demonstrate that the manufacturer's own product-security obligations are covered.
Connect the assessment to the CRA's SME support framework
The CRA itself recognises the implementation burden on smaller organisations. Article 33 provides for support measures tailored to microenterprises and small enterprises, including awareness and training activities, dedicated communication channels and support for testing and conformity-assessment activities. Member States may also establish cyber-resilience regulatory sandboxes for controlled development, validation and testing.
That support framework does not reduce the product-security obligations simply because the manufacturer is small. Instead, it recognises that implementation support may need to be proportionate and practical.
The ENISA maturity model fits that purpose well: it gives smaller organisations a structured way to identify where capability is missing before selecting the most useful guidance, training, template, external expertise or process improvement.
Run the assessment as a repeatable operating cycle
A useful maturity review can be run as a short, repeatable cycle rather than as a one-time project.
1. Prepare the evidence set
Collect recent records for the five domains before the workshop. Avoid scoring from memory where evidence should exist.
2. Score with the people who perform the work
Include engineering, product security, product ownership, compliance and release responsibilities as relevant. The person who owns a policy may not know how consistently it is applied in product work.
3. Record disagreements
If engineering and compliance score the same practice differently, treat the disagreement as useful information. It may reveal unclear ownership, inconsistent execution or evidence that is not accessible across teams.
4. Convert gaps into owned actions
Every material gap should have an owner, target state and expected evidence. Avoid generic actions such as “improve security process” that cannot be verified later.
5. Reassess after meaningful changes
Repeat the assessment after major process improvements, organisational changes or product-lifecycle milestones. Preserve the earlier result so that progress and regressions remain visible.
This turns the model from a questionnaire into a management tool for product-security capability.
What evidence to retain from the maturity assessment
The assessment itself can become useful security evidence if it is kept with enough context. Retain:
- the model and tool version used;
- the assessment date;
- organisation and product scope;
- participants and domain owners;
- scores and maturity profile;
- evidence references supporting material answers;
- identified gaps and risk rationale;
- agreed improvement actions and owners;
- follow-up status; and
- previous assessment versions for comparison.
Do not silently overwrite an earlier assessment when scores improve. Keeping the history shows what was known, what changed and which actions moved the organisation from one state to another.
An ENISA maturity score is most useful when each answer can be tied to the product evidence and decisions behind it. AA-sec is designed around traceability between requirements, assessments, security evidence, vulnerability work, decisions and exact product or lifecycle context, so a readiness review can remain connected to the underlying records instead of becoming a standalone spreadsheet. AA-sec does not determine CRA conformity or turn a maturity score into legal proof of compliance.
Key takeaway
Use ENISA's SME Cyber Resilience Maturity Assessment Model to answer a practical management question: where are our product-security practices inconsistent, weakly evidenced or insufficiently repeatable, and what should we improve next?
The model's five domains and three maturity profiles provide a structured way to organise that review. The strongest implementation is evidence-based, scoped to real product work, connected to owned improvement actions and repeated over time.
Keep one boundary explicit throughout: maturity is not conformity. The assessment can strengthen CRA readiness and reveal where product-security capability needs work, but the manufacturer still has to determine and evidence the applicable CRA requirements for its products and follow the legally required conformity-assessment path.