By Roland Atoui, Red Alert Labs
After several CRA Expert Group meetings, I am starting to feel that we are no longer discussing a regulation in the abstract.
At the beginning, the Cyber Resilience Act felt like a large map that everyone was trying to read at the same time. We were pointing at borders, asking where one responsibility ended and another began, debating remote data processing, substantial modifications, open source, RED, EUCC, standards, and the role of notified bodies.
The first meetings were about understanding the landscape.
This fifth meeting felt different.
This time, the discussion was not only about what the CRA means. It was about how we are going to make it work in factories, in software teams, in SMEs, in conformity assessment bodies, in market surveillance authorities, and eventually in the hands of users.
And that is where things become very real.
The pressure is now visible
One sentence from the meeting stayed with me: “December 2027 is tomorrow.”
It was said almost casually, but it captured the mood perfectly. The CRA implementation timeline is no longer theoretical. The deadlines are approaching, and everyone can feel the pressure: the Commission, Member States, manufacturers, standardisation experts, ENISA, market surveillance authorities, and conformity assessment bodies.
There is a lot of work happening in parallel. Guidance is being prepared. Standards are advancing. The Single Reporting Platform is being tested. Conformity assessment infrastructure is being shaped. ENISA is working on practical support for SMEs. Discussions on EUCC, SBOMs, AI Act, DORA and open source are all moving forward.
But the challenge is no longer only about producing documents.
The real challenge is coordination.
Because if guidance arrives late, if standards are interpreted differently, if notified bodies are not aligned, if SMEs are left alone, or if tools promise more than they can deliver, then the CRA risks becoming heavy before it becomes useful.
That is the balance we now need to get right.
Guidance is becoming the bridge between law and reality
A major part of the meeting focused on guidance, and rightly so.
The Commission has received a very large volume of feedback, including hundreds of responses and thousands of comments. This is encouraging, because it shows that stakeholders are engaged. But it also shows how many open questions remain.
The most sensitive topics are not surprising: substantial modification, support period, spare parts, placing on the market, software updates, remote data processing, core functionality, risk transfer, and due diligence.
These may sound like legal concepts, but for manufacturers they are very practical questions.
Imagine a company with a continuous production line. At what moment does a product need to comply? Is it the product type, or each individual unit? What happens when the same hardware continues to be produced after the CRA applies? What about embedded software updates? What about standalone software? What about a cloud component that is necessary for the product to function?
These are not academic debates. They affect production planning, product lifecycle decisions, support strategies, technical documentation, and conformity assessment.
What I appreciated is that the Commission seems to be moving toward a more practical and iterative approach, sharing revised sections progressively and allowing another round of feedback. That is important. In a regulation as horizontal as the CRA, no guidance will be perfect from day one. But it must be useful enough to help the ecosystem move.
At the same time, I think we must be careful with examples. They are necessary, because manufacturers need concrete illustrations. But examples should not become shortcuts or false safe harbours. Cybersecurity always depends on context. A product, its architecture, its intended use, its environment, and its update model all matter.
Guidance should help people think clearly, not replace the need to think.
SMEs need more than awareness
Another discussion that resonated with me was the one on SMEs.
It is encouraging to see that CRA awareness is growing. But awareness is not readiness.
Many SMEs now know that the CRA exists. The harder question is: what do they do next?
For a large company, CRA implementation may involve legal teams, compliance teams, cybersecurity architects, product managers, documentation specialists and external advisors. For a micro or small enterprise, the same person may be coding, selling, supporting customers, handling operations, and trying to understand regulatory obligations at night.
That reality matters.
When SMEs ask for templates, checklists, examples and practical guidance, they are not asking for shortcuts. They are asking for a way to survive the transition.
They need to understand how to build technical documentation, how to perform risk assessment, how to manage vulnerabilities, how to document secure development practices, how to deal with updates, and how to show evidence without becoming a mini-certification department.
This is where practical support becomes essential. Not another 200-page document that only specialists can read. SMEs need guidance that speaks the language of product development, engineering, and daily operations.
The CRA will only succeed if it can be implemented not only by the largest players, but also by the small companies that form the backbone of Europe’s innovation ecosystem.
There is no magic compliance button
The discussion on CRA compliance tooling was one of the most human moments of the meeting.
Everyone understands the need for tools. Manufacturers need help. SMEs need help. Authorities will also need tools. There are many EU-funded projects and many private initiatives emerging around CRA compliance support.
But there was also a clear concern: what happens when hundreds of tools start promising compliance?
This is where we need honesty.
A tool can help. It can generate an SBOM. It can scan dependencies. It can support vulnerability analysis. It can help structure technical documentation. It can identify gaps. It can automate evidence collection. It can support workflows.
But a tool cannot take responsibility.
The responsibility remains with the manufacturer. And where third-party conformity assessment is required, the judgment remains with competent conformity assessment bodies.
There is no magic button that makes a product compliant.
This point is important because the market will naturally look for simplification. That is understandable. But if we oversell automation, we risk creating a dangerous illusion: that compliance is something you can buy, click, export and forget.
In reality, CRA compliance is a discipline. It requires product understanding, architecture analysis, risk management, secure development, vulnerability handling, documentation, and lifecycle governance.
Tools should support that discipline. They should not pretend to replace it.
Conformity assessment is entering a delicate phase
As Red Alert Labs, this part of the meeting is particularly important to us.
The conformity assessment infrastructure for the CRA is still being built. Member States are preparing accreditation and notification processes. The Commission and ENISA are working on guidance for technical competence. There are discussions on Model B + C, Model H, subcontracting, testing reports, accreditation, and the future working group of notified bodies.
The difficulty is clear: the ecosystem needs notified bodies to be ready, but the harmonised standards are not fully available yet. So everyone is looking for pragmatic interim solutions while trying to avoid fragmentation.
This is a delicate moment.
If approaches diverge too much between Member States, manufacturers may face uncertainty. If notified bodies apply different levels of technical depth, trust may suffer. If testing competence is not aligned, the market may not get the level playing field it needs.
The Commission acknowledged that the first round may not be perfect and that harmonisation may be iterative. I think this is realistic. But it also means that the first months will matter a lot. Early practices will shape expectations.
From my perspective, the key is not only to create more notified bodies quickly. It is to create a reliable conformity assessment culture for the CRA.
That means technical competence, consistency, proportionality, and a shared understanding of what good evidence looks like.
SBOMs are becoming part of the evidence story
SBOMs were also discussed in detail, and the message is becoming clearer.
Many organisations have started their SBOM journey, but maturity is uneven. Some are experimenting. Some are integrating SBOMs into build pipelines. Others are still trying to understand what is expected.
This is normal.
An SBOM is easy to describe but harder to operationalise.
Generating a list of components is only the beginning. The real question is how that SBOM is maintained, consumed, linked to vulnerability management, shared across the supply chain, and used as evidence.
For me, the most important question is: what does a “good enough” SBOM look like in practice?
Because perfection is not realistic. But usefulness is necessary.
A useful SBOM should help identify exposure, support vulnerability handling, improve transparency, and give manufacturers and assessors a clearer view of the product’s software supply chain.
SBOMs should not become paperwork. They should become operational evidence.
The CRA is no longer alone
Another strong impression from the meeting is that the CRA is now deeply connected to the wider digital regulatory landscape.
The Commission discussed work on the interplay between the CRA and the AI Act, and between the CRA and DORA. This is important because companies do not experience regulations one by one. They experience them together.
A product may include AI. It may rely on cloud services. It may be used by a financial entity. It may include open source components. It may fall under sectoral rules. It may be affected by NIS2, DORA, AI Act, Data Act, RED, or future digital legislation.
For industry, the question is not “which regulation is interesting today?” The question is: how do we build one coherent evidence strategy that can support several regulatory obligations?
This is where I see a major opportunity.
If done well, the CRA can become a cybersecurity backbone for digital products. It can help structure evidence that is also useful for other regulatory frameworks. But if done poorly, it can become one more compliance silo.
The difference will depend on how well guidance, standards, and conformity assessment practices connect with each other.
International alignment: useful, but Europe’s model is different
The update on the Global Cybersecurity Labelling Initiative also raised important questions.
International alignment is valuable. Manufacturers operate globally. Different labels, requirements, and conformity routes can create friction and cost. A common understanding of cybersecurity expectations can help reduce barriers and improve trust.
But we must also be clear: the CRA is not a voluntary label.
It is a mandatory market access framework.
That distinction matters. In Europe, baseline cybersecurity should not become a marketing differentiator. It should be the condition for placing products on the market.
Labels may still have a role in other jurisdictions, public procurement or higher assurance use cases. But in the EU context, we must avoid confusing consumers and manufacturers about what is mandatory and what is optional.
International dialogue is useful. But it should support the CRA model, not dilute it.
What I take away
When I look back at this fifth meeting, I do not see a finished system. I see a system under construction.
That is normal.
The CRA is ambitious. It touches products, software, cloud dependencies, open source, supply chains, vulnerability reporting, lifecycle management, conformity assessment, market surveillance and international trade.
No single meeting can solve all of that.
But what I found encouraging is that the discussions are becoming more concrete. We are talking less about principles and more about implementation. Less about ambition and more about evidence. Less about theory and more about what manufacturers, SMEs, assessors and authorities actually need.
There is still a lot to clarify.
But the direction is becoming clearer.
The CRA is moving from policy to practice. And this is where the real work starts.
For us at Red Alert Labs, the mission is also clear: help manufacturers translate regulatory expectations into actionable cybersecurity evidence, support a consistent conformity assessment ecosystem, and contribute to a European market where trust is not declared but demonstrated.
The CRA is not just another regulation.
It is becoming one of the foundations of Europe’s digital trust model.
And like every foundation, what matters now is not only how it was designed but how carefully we build on it.
This article was originally published here.
