ENISA's July 2026 SME maturity model never says which of its five levels the Cyber Resilience Act demands, and its CRA mapping is five rows at domain level; read against the regulation's own obligation verbs and application dates, the defensible floor is a band: Level-4 practice in the three mapped domains, with everything distinctive to Level 5 tracing to no CRA provision.
ENISA's July 2026 SME maturity model never says which of its five levels the Cyber Resilience Act demands, and its CRA mapping is five rows at domain level; read against the regulation's own obligation verbs and application dates, the defensible floor is a band: Level-4 practice in the three mapped domains, with everything distinctive to Level 5 tracing to no CRA provision.
Part of the Cyber Resilience Act already applies. Article 71(2) of Regulation (EU) 2024/2847 staggers the dates: one chapter live since 11 June 2026, Article 14's reporting duties from 11 September 2026 (about seven weeks after this post), the rest from 11 December 2027. In July 2026, ENISA published a maturity assessment model to help SME manufacturers prepare. The model has five levels. The regulation never says which one it wants; the word "maturity" does not appear anywhere in its text. I read the two documents against each other to work out where the floor sits. The answer is a band, and it is narrower than the model's "advanced" label suggests.
The application schedule sits in Article 71(2) of Regulation (EU) 2024/2847, the Cyber Resilience Act:
"This Regulation shall apply from 11 December 2027. However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026."
Three tranches, oldest first.
Since 11 June 2026: Chapter IV. Its heading is "NOTIFICATION OF CONFORMITY ASSESSMENT BODIES". This is machinery: how Member States designate notifying authorities, what notified bodies must look like, how they coordinate. The obligations in it fall on Member States and on the assessment bodies themselves. Nothing in Chapter IV puts a duty on manufacturers. The tranche exists so the assessment infrastructure stands before manufacturers need it: Art. 35(2) says Member States "shall strive to ensure, by 11 December 2026 that there is a sufficient number of notified bodies in the Union to carry out conformity assessments, in order to avoid bottlenecks and hindrances to market entry." Manufacturers' own conformity-assessment duties sit in Chapter III (Articles 27 to 32) and apply from 11 December 2027 with the rest.
From 11 September 2026: Article 14, "Reporting obligations of manufacturers". This is the first tranche that lands on manufacturers. Art. 14(1):
"A manufacturer shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7 of this Article, and to ENISA. The manufacturer shall notify that actively exploited vulnerability via the single reporting platform established pursuant to Article 16."
Art. 14(2) sets the clock: an early warning "within 24 hours of the manufacturer becoming aware of it", a vulnerability notification "within 72 hours", and a final report "no later than 14 days after a corrective or mitigating measure is available". Art. 14(3) and (4) apply the same rhythm to any severe incident having an impact on the security of the product: 24 hours, 72 hours, final report within one month. The single reporting platform is established, managed and maintained by ENISA (Art. 16(1)).
From 11 December 2027: everything else. That includes Article 13 (the manufacturer obligations), Annex I (the essential cybersecurity requirements), and the manufacturers' conformity-assessment duties. Most of what this post maps applies from this date.
Scope is Article 2. Art. 2(1):
"This Regulation applies to products with digital elements made available on the market, the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network."
The defined terms do the work. A "product with digital elements" is "a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately" (Art. 3(1)). A "manufacturer" is anyone who "develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge" (Art. 3(13)).
So here is the Cyber Resilience Act scope test in one forwardable paragraph. The regulation applies to a product when three things hold: it is software or hardware, including a component sold separately (Art. 3(1)); its intended or reasonably foreseeable use includes a direct or indirect, logical or physical connection to a device or network (Art. 2(1)); and it is made available on the EU market in the course of a commercial activity, paid or free (Art. 3(22)). The organization carrying the manufacturer obligations is the one marketing the product under its own name or trademark, even when development was outsourced (Art. 3(13)). The main exclusions are sectoral: medical devices under Regulations (EU) 2017/745 and 2017/746, vehicles under (EU) 2019/2144, aviation equipment certified under (EU) 2018/1139, marine equipment under Directive 2014/90/EU, spare parts made to identical specifications, and products developed exclusively for national security, defense or classified-information processing (Art. 2(2)–(7)).
One audience mismatch: ENISA's model says it "is primarily intended for SMEs acting as manufacturers, importers or distributors of products with digital elements", and can also serve integrators and service providers. That audience is wider than the set of actors carrying the Art. 13, Art. 14 and Annex I duties, which address manufacturers. The model's assessment content is manufacturer-shaped throughout; importer and distributor duties live in Articles 19 and 20 and are out of scope here.
ENISA's SME Cyber Resilience Maturity Assessment Model is a 36-page PDF dated July 2026 plus a companion spreadsheet, CRA_Maturity_Model_TOOL.xlsx, with four sheets: Dashboard, Questionnaire, Pivots, Checklist.
The structure: five assessment domains (governance and documentation; risk management and security by design and by default; vulnerability and patch management; product life cycle management; awareness, competence and skills), five questions per domain, 25 questions total (Annex A, pp. 20–24). Each question is answered on a five-level scale with generic descriptors: Level 1 "not implemented", Level 2 "informal or ad hoc", Level 3 "documented but inconsistently applied", Level 4 "consistently applied and regularly reviewed", Level 5 "measured, monitored and continuously improved". The PDF never names the levels; the spreadsheet does ("1 – Initial" through "5 – Optimised"). ENISA estimates the whole assessment at about two hours.
The model is strict about grade inflation (p. 17): a documented process nobody follows scores Level 2, not 3; where practices are inconsistent across products, Level 3 "may be more appropriate" than 4; no evidence of review and improvement caps a score at 4.
Scoring is arithmetic. Average the five answers per domain into a domain score, then average the five domain scores into an overall score. Profiles are score bands: basic 1.0–2.5, intermediate 2.6–3.9, advanced 4.0–5.0.
The sentence that bounds everything else in this post is in the executive summary (p. 5):
"Although it reflects practices supporting the implementation of the CRA, having an advanced maturity level does not replace legal obligations and should not be considered evidence of compliance. Instead, it supports organisations in strengthening their product security and cyber resilience over time in a structured and manageable way."
ENISA repeats the point twice more (p. 6, and in the Annex B intro: "Following these steps does not guarantee compliance"). So every use of "floor" below is an analytical reading of two texts side by side; it locates practice against the regulation's language and proves nothing to an authority.
The CRA link lives in Annex D, "mapping to Cyber Resilience Act requirements" (p. 33). ENISA's own intro sets expectations: it is "an indicative mapping", and "not all assessment criteria can be directly mapped to specific CRA provisions."
The structural fact first, because the whole floor question turns on it: the mapping is at domain level, and it is five rows long. It does not map maturity levels, profiles or individual questions to CRA provisions anywhere, and the spreadsheet contains no article mapping either. Nobody can read "the CRA requires Level N" out of this document, because ENISA never wrote a sentence of that shape in either direction.
Here are the five rows. The middle two columns condense ENISA's cells (quoted fragments are literal); the last column is my verification against the regulation's full text, which is analysis layered on top of the mapping and should be read as such.
| Domain | ENISA: "CRA requirements" | ENISA: "CRA provisions" | Checked against the regulation |
|---|---|---|---|
| Governance and documentation | "Not explicitly addressed as a stand-alone requirement in the CRA" | Supports Art. 13, Art. 31 and Annex VII (risk assessment, technical documentation, conformity assessment) | Holds, but undersells itself: Art. 13(12) technical documentation before placing on market, Art. 13(3)–(4) documented risk assessment inside it, Art. 31(1)–(2) and Annex VII are hard obligations regardless of the domain label |
| Risk management and security by design and by default | Annex I, Part I(1) and (2): risk assessment, secure design, protection against vulnerabilities, secure configuration | Art. 13 | Holds cleanly: Art. 13(1)–(4); Annex I Part I(1) and Part I(2)(a)–(m) |
| Vulnerability and patch management | Annex I, Part II: vulnerability handling, remediation, security updates, coordinated vulnerability disclosure | Arts. 13 and 14 | Holds cleanly: Annex I Part II(1)–(8); Art. 13(6) and 13(8); Art. 14. The only row citing Art. 14 |
| Product life cycle management | Annex I, Part II (security updates throughout the support period); Annex II (support-period information) | Art. 13 | Holds, with an omission: the domain's own chapter (p. 13) says it "includes addressing and reporting vulnerabilities", yet the row skips Art. 14. The cited duties are real: Art. 13(8), Art. 13(19), Annex II points 7 and 8(d) |
| Awareness, competence and skills | "Not explicitly addressed in the CRA" | "Indirectly supports" Art. 13 and Annex I implementation | Confirmed by full-text search: no training, awareness or competence obligation on manufacturers in the enacting terms. Art. 10 obliges Member States. Recital 23 says manufacturers "should ensure that their staff has the necessary skills" — a recital, not an enacting requirement |
Two seams inside ENISA's own document:
At domain granularity, everything ENISA cites checks out: no row names an article that misstates what it covers, and I found no inter-source contradiction. One naming collision before you open the tool: the spreadsheet names Level 2 "Basic" while the profile covering scores 1.0–2.5 is also called "basic", so the level name and the profile band are different things sharing a word.
Annex D is level-agnostic, so the floor has to be derived. The derivation has two inputs: the regulation's obligation verbs and the model's level descriptors.
The verbs first. Annex I Part II tells manufacturers to "put in place and enforce a policy on coordinated vulnerability disclosure" (II(5)), to "address and remediate vulnerabilities without delay" (II(2)), and to "apply effective and regular tests and reviews of the security of the product with digital elements" (II(3)). Art. 13(8) requires vulnerabilities to be "handled effectively" for the support period. Enforce, without delay, effective, regular: the text describes things actually happening, on an ongoing basis, for every product.
Now the descriptors. Level 3 is "documented but inconsistently applied", and the model's downgrade rules say a documented process that isn't followed scores Level 2, while for inconsistency across products Level 3 "may be more appropriate" than 4. An inconsistently applied CVD policy is not a policy that is "enforced". Remediation that happens for some products is not "without delay" for the others. The first level descriptor compatible with the regulation's verbs is Level 4: "consistently applied and regularly reviewed".
What does Level 5 add? The model is explicit (p. 17): "Level 4 indicates that practices are consistently applied, while Level 5 requires evidence of measurement (e.g. metrics or key performance indicators) and active improvement based on the results." I searched the regulation's enacting terms — articles and annexes — for those differentiators. The reproduction path, re-runnable:
$ curl -s 'https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847' -o cra.html$ pandoc cra.html -t plain -o cra.txt$ grep -ic 'maturity' cra.txt0$ grep -ic 'lessons learned' cra.txt0$ grep -ic 'tabletop' cra.txt0
Per control, the trace lines:
There is also an arguable middle band at question level: risk-based prioritization (Part II(2) frames remediation "in relation to the risks posed"), verifying that updates fix what they claim (implied by Part II(2) and II(3)), operational monitoring (Part II(3); Art. 13(7)), following external advisories (a plausible implication of Art. 13(5) due diligence on third-party components). None of these is cleanly absent, so none of them belongs in the no-trace list.
The reading I can defend, stated once: the CRA's floor, in this model's vocabulary, is a band of Level-4 practice in the three mapped domains (risk management and secure design, vulnerability and patch management, product life cycle management) plus the documentation duties behind the governance row. Nothing distinctive to Level 5 traces to any CRA provision, and the awareness domain's levels are recital territory at most. The band sits awkwardly against the profile names: 4.0 is numerically where "advanced" begins, so "intermediate" (2.6–3.9) undershoots the obligation verbs, while the advanced profile bundles in Level-5 content the regulation never asks for.
Three caveats on that band.
First, averaging can hide a sub-floor domain. The tool's worked example ships with domain scores of 1.8, 2.8, 4.4, 2.8 and 3.0, for an overall 3: "intermediate" overall, above 4 in vulnerability management, below 2 in governance. The model warns about this itself (Step 5, p. 18): the overall score "should not be considered in isolation. An intermediate score does not mean that all areas are performing at the same level." The number to hold against the band is the domain score, and only for the mapped domains.
Second, a counter-signal: ENISA does not treat CRA work as an upper-tier concern. Annex B's basic-maturity action list already contains CRA-derived items, among them "Identify the relevant market surveillance authority and understand basic reporting expectations under the CRA" (p. 26) and building a component inventory "(SBOM), using a commonly used and machine-readable format where feasible" (p. 27). Where the model starts CRA-relevant work (basic) and where practice matches the regulation's verbs (Level 4 in the mapped domains) are two different points on the same scale. The floor claim here is about the second.
Third, the spreadsheet's Dashboard hardcodes a "Target" of 5 for every domain. That is a spreadsheet default, not an ENISA recommendation stated anywhere in the report's prose, and the regulation sets no maximization target of any kind. The page-5 caveat still governs all of it: a 5.0 self-score is also not evidence of compliance.
Annex A has 25 questions and no CRA article or provision citations (one question, 1.5, names the CRA in prose). Here are seven, adapted from it, chosen by one rule: each must trace to a specific article or Annex I requirement. The clause IDs are the trace, verified against the regulation's full text.
Score each answer with the model's descriptors and its downgrade rules, honestly: documented-but-not-followed is a 2. Against the band derived above, these are the questions where "documented but inconsistently applied" falls short of the regulation's verbs. Same boundary as before: a self-score locates practice on ENISA's scale; per ENISA's own caveat, it is not evidence of compliance.
The two dates that make this current are 11 September 2026, when Art. 14's 24-hour and 72-hour reporting duties start, and 11 December 2027, when Art. 13 and Annex I follow. The spreadsheet run takes about two hours, and the band to hold the mapped-domain scores against is Level 4. For a specific product, its category and its conformity route, that is a question for qualified counsel, and for the conformity assessment the regulation itself prescribes.
devguard maps controls to the frameworks that require them, clause by clause — useful when CRA obligations sit next to ISO 27001 or NIS2 duties: devguard.ch.
Vadim leads engineering, the architecture, automation, and integrations that let compliance live. He's set on making a serious, audit-grade system genuinely easy to run.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.