On 13 July 2026 ENISA published an SME Cyber Resilience Maturity Assessment Model, together with a ready-to-use Excel tool. The document targets small and medium-sized enterprises that manufacture products with digital elements, which is the scope of Regulation (EU) 2024/2847, the Cyber Resilience Act, most of which applies on 11 December 2027, with the notification obligations applying from 11 September 2026. This article describes how the model works, what it actually covers, and how to combine it with the preparation of a CRA file.
How the model works
The model rests on five domains: governance and documentation; risk management, security by design and by default; vulnerability and patch management; product life cycle management; awareness, competence and skills. Each domain carries five questions, twenty-five in total, each scored on a 1 to 5 maturity scale: 1 not implemented, 2 informal, 3 documented but inconsistently applied, 4 consistently applied and reviewed, 5 measured and continuously improved.
The calculation is a plain average: mean of the five questions per domain, then mean of the five domains. The result places the company in one of three profiles: basic from 1.0 to 2.5, intermediate from 2.6 to 3.9, advanced from 4.0 to 5.0. An annex then proposes actions per profile and per domain, and ENISA recommends repeating the exercise once a year. Estimated completion time is about two hours. The Excel tool published with the report reproduces the questionnaire, the calculation and the dashboard exactly.
What the model measures
The scale addresses process consistency, not the content of the obligations. The same practice, vulnerability handling for instance, can score 2 when it rests on one person and habit, 3 when it is written down but unevenly followed, 4 when it is applied and reviewed. That reading is useful: it separates what is documented from what is actually practised, a distinction a requirements inventory does not always surface.
The thematic scope overlaps the CRA to a large extent. It covers product risk analysis, security by design, a software bill of materials (SBOM) in a machine-readable format, a coordinated vulnerability disclosure policy, support periods and end-of-support communication.
What the model does not measure
ENISA writes it twice: an advanced maturity level "does not replace legal obligations and should not be considered evidence of compliance" (ENISA, July 2026). The report also states that the mapping between its five domains and the CRA provisions is indicative, and that two domains, governance and documentation on one side and awareness and skills on the other, correspond to no stand-alone requirement of the regulation.
The reason lies in the nature of the exercise. The model answers the question "how consistently do our processes run?". A CRA file answers a different one: which obligations of the regulation are covered, by which documents, for which product. The Annex VII technical documentation, the EU declaration of conformity, the CE marking, the coordinated vulnerability disclosure policy, the 24-hour and 72-hour notification procedure: each of these exists or does not, and the regulation fixes their content. An average of 4.2 across five domains does not say whether the declaration of conformity has been drawn up.
The model also does not distinguish product classes (default, important, critical) or the resulting conformity assessment routes, a deliberate choice to stay generic. On notification, it checks that the company knows the regulation's basic expectations, without entering the Article 14 deadlines.
Combining the two exercises
The two readings complement each other. The ENISA model gives, in two hours, a process positioning with a simple vocabulary (basic, intermediate, advanced) that communicates well internally. Preparing the CRA file then requires obligation-level tracking: the scope and timeline of the regulation on one side, the deliverables on the other.
A reasonable working order for an SME in scope: run the ENISA self-assessment to locate the five domains and identify those scored 1 or 2; address vulnerability management first if it is weak, because the notification obligations apply before everything else; then build the file at obligation level, with the required documents. The awareness and competence domain, absent from the regulation as a stand-alone requirement, remains a real supporting capability; a workable awareness programme without a dedicated team exists.
Komplyo tracks the same five areas at the level of each obligation: 57 CRA requirements traced, partly derived from ISO 27001 and GDPR answers already given, with the associated deliverables (CVD policy, notification procedure, Annex VII technical documentation skeleton). The CRA diagnostic covers the same ground in 23 questions, in minutes, and its answers carry over into the full assessment. The same reservation applies to both exercises: a readiness percentage, like a maturity profile, measures progress, not compliance.