The CRA is not a legal side quest. It is a product discipline requirement that forces teams to prove they can build, support, and secure digital products over their full lifecycle.
The Cyber Resilience Act is one of those regulations that everyone says is important and very few explain properly. Most commentary treats it like a legal document to be interpreted. In reality, it is much more practical than that. It is a product security law that will affect how software and digital products are built, shipped, supported, and maintained.
If you build or sell digital products into the EU market, this matters. Not because it creates more paperwork, but because it raises the standard for what counts as a responsible product maker.
At its core, the Cyber Resilience Act is an EU regulation that sets cybersecurity requirements for products with digital elements placed on the EU market. That includes both hardware and software, and it applies across the product lifecycle rather than only at the point of sale.
That last point is where the CRA becomes interesting.
It is not concerned only with the security of a product at launch, but with whether that security can be maintained over time, whether vulnerabilities are handled properly, whether updates can be delivered effectively, and whether the manufacturer can demonstrate a disciplined approach to managing it all.
So what is it, really?
The simplest way to think about the CRA is this:
It is the EU telling the market that insecure digital products are no longer an acceptable business model.
For years, too many products have been shipped with weak defaults, vague support periods, poor patching discipline, unclear ownership, and dependency chains that nobody fully understands. The CRA is an attempt to force a higher standard: if you place a digital product on the EU market, you are expected to take cybersecurity seriously from design through to support and vulnerability handling.
That is why I do not think the CRA is best understood as a compliance exercise.
It is better understood as a product discipline law.
Why software teams should care
One of the biggest misunderstandings is that this sounds like an IoT or hardware regulation. It is not. Software teams should pay close attention, because the scope is much broader than many people assume.
The practical questions are not especially legal in nature. They are operational:
Do we know which products are in scope?
Do we know what components are inside them?
Can we show that security was considered during design and build?
Can we detect, triage, and fix vulnerabilities properly?
Can we support the product for the period customers are entitled to expect?
Can we produce the evidence to back any of that up?
This is where the CRA becomes useful. It takes things that many organisations still treat as "good practice" and moves them much closer to "expected and demonstrable".
The dates people should actually remember
The headline date most people quote is 11 December 2027, when the CRA generally starts to apply. But treating 2027 as the only date that matters is a good way to be caught unprepared.
Provisions for notified bodies apply from 11 June 2026, and key manufacturer reporting obligations apply earlier, from 11 September 2026.
That earlier date matters because it shifts the conversation away from theory and into readiness. It is one thing to say you take security seriously. It is another to detect a serious issue, understand its impact, gather evidence quickly, and follow a clear reporting path under time pressure.
This is why I suspect many organisations will discover that their biggest gap is not policy. It is readiness under pressure.
What the CRA changes in practice
In day-to-day terms, the CRA pushes organisations to become better at six things.
The first is product scoping. You need to know what you make, what is placed on the market, and who owns it.
The second is secure development with evidence. Not good intentions. Not a slide deck. Evidence.
The third is component and dependency visibility. Many teams are still less certain than they think about what is actually inside the products they ship.
The fourth is vulnerability handling. That includes receiving reports, investigating them, fixing issues, and communicating clearly.
The fifth is security updates and supportability. Security is no longer something that matters only during development. It becomes part of the obligation to maintain and support a product properly.
The sixth is technical documentation. A surprising number of organisations do more security work than they can actually prove. The CRA is unlikely to be sympathetic to that distinction.
Where most teams will struggle
Most organisations will not struggle because they have done nothing.
They will struggle because what they have is fragmented.
Engineering owns the build. Security owns scanning. Product owns release decisions. Support hears about issues first. Legal worries about disclosure. Nobody quite owns the whole chain from end to end.
That is manageable in ordinary times. It becomes a problem the moment you need to answer basic questions quickly:
What versions are affected?
Is this being actively exploited?
Which customers are exposed?
Can we patch safely?
What do we need to report?
Where is the evidence?
The CRA rewards organisations that can answer those questions without improvising.
The sensible way to prepare
If I were advising a team starting from scratch, I would not begin with a giant compliance programme and a hundred-row spreadsheet.
I would start with a readiness assessment built around a few blunt questions:
Which products are in scope?
What evidence do we have of secure development?
Can we generate or maintain an SBOM?
Do we have a workable vulnerability disclosure process?
Can we deliver security updates reliably?
Could we handle a reportable incident inside the required timelines?
Is our documentation real, current, and tied to actual products?
That gets you out of theory and into operational truth very quickly.
The real point
The CRA matters, but not because it gives compliance teams more paperwork.
It matters because it raises the floor for what it means to behave responsibly as a product maker in a digital market.
For strong teams, that will be uncomfortable but manageable.
For weaker teams, it will be revealing.
And that, to be fair, is probably the point.
Over the next few posts, I’ll break the CRA down into practical terms: what is in scope, why the earlier reporting obligations matter, where SBOMs and vulnerability handling fit, and how to assess readiness without turning it into theatre.
