The Comfort of a Number
On July 13, 2026, ENISA published the SME Cyber Resilience Maturity Assessment Model. The name is a mouthful. The tool deserves attention. It is aimed at micro, small and medium-sized enterprises that manufacture or place products with digital elements on the market, and it can also be used by integrators and service providers. It covers five domains: governance and documentation; risk management and security by design and by default; vulnerability and patch management; product life cycle management; and awareness, competence and skills. Each criterion is assessed on five levels, from non-existent or informal practices to processes that are governed and continuously improved. The result feeds into three profiles: Basic, Intermediate and Advanced.
There is an official Excel workbook too. It guides the assessment, calculates the score and lets an organisation repeat the exercise over time. For a fifteen-person software company that has spent two years hearing the CRA described as a threatening cloud of articles, annexes, unfinished standards and moving dates, it is hard to imagine anything more reassuring. At last, a bounded object. Open it, answer the questions, see where you stand. Come back six months later and measure how far you have moved.
That relief is legitimate. The tool is free, readable and far closer to the life of an SME than frameworks built for organisations with a CISO, an in-house legal department and people who can devote Friday afternoon to governance. ENISA does not treat limited resources as a moral failure. It tries to turn a complex regulation into a route a small company can follow without pretending to be a bank.
And it is more rigorous than the phrase self-assessment might suggest. The document says scoring should be based on objective evidence—documented procedures, implemented practices and observable behaviour—not assumptions or informal impressions. It is not simply asking, “Do you think you are good at this?” It asks the organisation to look at what exists. Anyone who dismisses the model as another bureaucratic questionnaire has not read it.
Precisely because it is well designed, however, the number it produces will be remarkably easy to misuse.
The Sentence ENISA Wrote in Advance
ENISA puts the decisive warning in the executive summary and repeats it in the model’s objectives. Even an Advanced maturity level does not replace legal obligations and should not be considered evidence of conformity. This is not defensive boilerplate appended by lawyers. It is a design boundary: the model measures one thing, while the CRA ultimately asks for another.
The distinction feels intuitive until a score appears. Basic, Intermediate and Advanced are words that describe an organisation. Put them in a coloured cell and they begin to look like a verdict. Advanced no longer sounds like “our practices are fairly structured.” It sounds like “we passed.” Add the name of the European Union Agency for Cybersecurity at the top of the sheet, and the semantic shift becomes almost inevitable. An internal indicator turns into an external credential without anyone formally deciding that it should.
ENISA is not talking down its own work. It is making a more interesting point: maturity is favourable to conformity, but it is not conformity. An organisation that assigns responsibility, governs vulnerabilities, produces documentation and reviews its processes starts in a far better place than one held together by the memory of two people. It can still have a non-conforming product. Conversely, a relatively immature organisation may establish conformity for a simple, tightly bounded product, perhaps through a manual effort it will struggle to repeat for the next one.
The maturity score answers, “How dependable is the way we work?” A conformity assessment answers, “Does this product, in this configuration, meet these applicable requirements?” The questions are close. They are not interchangeable.
Two Self-Assessments, Two Objects
This is where a correction matters, because the quickest way to explain the difference is also legally wrong. One could say that the ENISA model is a self-assessment while conformity is something an outside body certifies. It would make for a clean story. The CRA does not tell that story.
The European Commission’s overview of conformity assessment is clear. For the default category, which includes most products with digital elements, the manufacturer may use internal control. This is Module A in Annex VIII: the manufacturer draws up the technical documentation, ensures that design, development, production and vulnerability handling meet the essential requirements, issues the EU declaration of conformity and takes responsibility for it. For some important product classes, internal control depends on the use of harmonised standards, common specifications or certification schemes. Important class II and critical products require third-party procedures or applicable European certification schemes. The details vary by category. The principle does not: Article 32 of the CRA does not define conformity by the presence of an auditor.
So yes, in many cases both operations are self-assessments. The same person may even coordinate them. What changes everything is the object of the statement.
In the maturity model, the object is the organisation and the consistency of its practices. The criteria cut across products, teams and processes. The model itself says that organisations should first identify which products fall within the CRA, determine their categories and establish the relevant conformity assessment procedures. It then notes that its score does not distinguish between product categories. That is not a flaw. It is the price of being useful across the organisation.
In a conformity assessment, the object is an identified product. The statement is not “we manage vulnerabilities well.” It is “this version of this product, with these components, throughout this support period, meets the applicable requirements, and we can show why.” The EU declaration is not a grade. It is an act through which the manufacturer attaches its name to that proposition and accepts responsibility for its truth.
The difference is not who fills in the form. It is what they assert, about which object, and with what consequences.
What the Number Discards
Every score is a compression machine. It takes a complex reality, throws almost all of it away and preserves a value that can be compared. That is exactly what makes a score useful: no chief executive wants four hundred pages of logs every quarter just to understand whether the company is improving. But the information discarded by compression is precisely what matters when conformity has to be established.
Take vulnerability management. An organisation may have defined roles, a documented process, monitored external sources, patching SLAs and periodic reviews. If the evidence supports those claims, that warrants a high level in the ENISA model. None of it guarantees that the process worked for every product. A report may have landed in the wrong backlog. An SBOM may not have been generated for one release. A dependency may be present in the distributed package and absent from the inventory. A vulnerability may have been classified as non-exploitable without anyone preserving the reasoning.
The maturity level still says something true about the organisation. But declaring that product conforming requires the chain that the score does not contain: the version assessed, the risk assessment, the component inventory, reports received, actual handling and remediation times, tests, documented decisions, the support period, responsibilities and dates. It must also be possible to reconstruct how that chain changed between one release and the next.
This is the easy point to miss. ENISA asks for objective evidence before a score is assigned, and rightly so. But the existence of evidence does not give the score a general power of attorney over it. Someone still has to establish that the evidence is relevant to the product, complete against the requirements that apply, current for the version placed on the market and maintained for the required period. The number says the house has a sound method for keeping records. It does not say the file we need is in the archive.
The Market Loves Proxies
That score will end up in tenders, supplier qualification packs and sales decks within months. No fraud is required. Following the incentives is enough.
Sales needs one sentence that closes the question about CRA readiness. “Advanced profile under the ENISA model” fits on one line, carries an authoritative name and saves everyone from explaining the difference between a default-category product and an important class II product. Procurement needs to reduce a hundred suppliers to a comparable table. Asking for a score is cheap. Opening technical files, sampling evidence and debating scope is expensive. Consultants need a repeatable engagement. Completing a spreadsheet has a beginning, an end and a deliverable that photographs well on the final slide.
None of the three has to lie for the proxy to take hold. Each only has to prefer the number to the next question.
This is Goodhart’s law in its familiar form: when a measure becomes a target, it ceases to be a good measure. If Advanced becomes an informal procurement requirement, organisations will start optimising how they answer. Not necessarily by falsifying anything. They will choose the most favourable perimeter, interpret “consistently applied” generously, prepare the evidence that raises the level and postpone the evidence that actually closes the product risk. A model designed to expose gaps will be used to make their average presentable.
ENISA’s authority increases the danger, not because ENISA made a mistake, but because its name will survive the warning that defines the tool’s limits. The logo will remain on the document. Somewhere between the publication page and the sales deck, the sentence “should not be considered evidence of conformity” will disappear.
From Score to Technical File
The right way to use the model is to treat every answer as the start of the work, not its conclusion. If a criterion says that vulnerabilities are tracked and prioritised, the next question is not “How many points is that worth?” It is: for which products, in which system, under which identifier, against which requirement, triggered by which event, reviewed by whom, and updated when?
That produces a chain. Criterion, product, requirement, evidence, owner, date, change history. If one of those links is missing, the score can still guide the internal roadmap, but it cannot be promoted into an evidentiary shortcut. If the links exist and are fed by ordinary work—the SBOM by the build, vulnerability records by the ticketing system, decisions by the release process—the score becomes almost secondary. The organisation has not merely declared itself mature. It has built the means to demonstrate its claims product by product.
This is the move from a hand-maintained register to a living inventory, and a more elegant document will not achieve it. It takes compliance as architecture: evidence generated by real systems, tied to decisions and kept long enough to outlive the people who made them.
It is also where the value of consulting becomes visible. Filling in the model for a client produces a tidier version of the client’s own perception. Sampling the answers, opening repositories, following a vulnerability from report to patch, comparing the SBOM with the distributed artefact and building the missing links turns a diagnosis into evidentiary capacity. These are different trades. The first leaves a score. The second leaves infrastructure that will continue to produce evidence after the consultant is no longer in the room.
The Mirror and the Window
The ENISA tool is not the answer to the Cyber Resilience Act. It is the question asked well. It asks an SME to look at five parts of its work that are too often kept apart and gives it a common language for deciding where to begin. Used that way, the profile matters less than the gap it exposes. Basic, Intermediate and Advanced are coordinates on a map, not stamps in a passport.
The CRA asks for a different step. Before placing a product on the market, the manufacturer must be able to close the argument around that object and sign it. Sometimes it will do so alone under Module A. Sometimes it will involve a notified body or use another permitted procedure. In either case, the quality of the answer depends on the evidence the maturity model helped uncover, not the level written in the final cell.
ENISA built a mirror. A mirror tells us where we stand, and that is already a great deal. Organisations that use it to look at themselves will get an honest roadmap, priorities and real costs. Those that hang it in front of other people as though it were a window will discover that no product, requirement or evidence can be seen through it. All it reflects is their own conviction that they are ready.
Key takeaways
The ENISA model is a strong diagnostic tool: it assesses five domains, asks organisations to base their answers on objective evidence, and exposes the areas an SME needs to address first.
An Advanced profile is not evidence of conformity, as ENISA states explicitly. It describes the maturity of an organisation’s practices, not the conformity of an identified version of a specific product.
The distinction is not self-assessment versus outside scrutiny. The CRA allows Module A internal control for many products, but that procedure requires technical documentation, product responsibility and an EU declaration of conformity.
A score breaks the connection between criterion, product, requirement and evidence. That compression makes it useful for orientation and dangerous when a tender or sales deck treats it as a substitute for a certificate.
Moving from score to technical file requires a verifiable chain: product, CRA requirement, evidence, owner, date and change history for every answer. A consultant creates value by building that chain, not by filling in the spreadsheet for the client.
Questions & answers
What does the ENISA CRA maturity model measure?
It measures how structured, consistently applied and continuously improved an organisation’s security practices are across five domains: governance and documentation, risk management and security by design, vulnerability and patch management, product life cycle, and skills. It is an organisational diagnosis intended to help SMEs understand where they stand and what to address first.
Does an Advanced ENISA rating prove conformity with the Cyber Resilience Act?
No. ENISA says so explicitly: even an Advanced profile does not replace legal obligations and must not be treated as evidence of conformity. The rating describes organisational maturity; conformity must be established for a specific product against the requirements and procedure that apply to it.
Does CRA conformity always require a notified body?
No. Manufacturers of default-category products may use Module A internal control and declare under their own responsibility that the product meets the essential requirements. Some important or critical product categories face stricter procedures that can involve harmonised standards, certification or a notified body.
What evidence is needed beyond a maturity score?
The evidence must be tied to the product and its version: risk assessment, technical documentation, a build-generated SBOM, vulnerability records, actual handling and remediation times, documented decisions, tests, the support period and change history. The ENISA tool can show where to look, but its final number cannot replace those artefacts.
How should an SME use the ENISA tool?
As a roadmap, not a shield. Each answer should be connected to the products concerned, the applicable CRA requirements, the available evidence and an owner responsible for keeping it current. The score’s value lies in the gap it reveals and the work it helps prioritise.
The author
