For years, the question in cybersecurity always pointed to the organization:
“Do we have sufficient security measures?”
The Cyber Resilience Act (CRA) broadens the focus. From now on, the question is also aimed at the product:
“Has the software or device we develop, distribute or market been designed securely, and will it continue to be secure throughout its lifetime?”
This is not a minor nuance. It is a paradigm shift that affects manufacturers, developers, distributors and technology providers across Europe.
What exactly is CRA
The Cyber Resilience Act is a European regulation that establishes mandatory cybersecurity requirements for any product with digital elements that is marketed in the European Union.
Their logic is clear: too many products come to market with known vulnerabilities, no planned updates and no formal incident management process. CRA wants to change that.
To this end, it introduces concepts that until now were recommendations or best practices and converts them into obligations:
- Security by Design: security is not added at the end, it is planned from the beginning.
- Security by Default: the initial configuration must be secure, without the user having to do anything.
- Continuous vulnerability management: identify, prioritize, remediate and document throughout the product lifecycle.
- Notification obligations: if you detect an actively exploited vulnerability, you have 24 hours to issue an early warning.
- Transparency about support: you must clearly inform how long the product will receive security updates.
It is not about passing a one-time audit. CRA makes security a living, demonstrable process.
Who is affected: more than meets the eye
This is where many organizations are surprised. CRA doesn’t just affect hardware manufacturers or large platforms. It affects:
- Enterprise software and SaaS applications
- IoT devices and connected hardware
- Mobile applications
- Cloud platforms
- Connected industrial systems
And not only to those who develop, but also to those who distribute or import digital products in Europe.
If your company develops software, sells licenses, offers services as SaaS or integrates third-party products into your solutions, the CRA probably applies to you.
The calendar: less time than it seems
Full implementation of the regulation comes in December 2027, but there is an earlier date that should not be lost sight of:
September 11, 2026 – Reporting obligations for actively exploited vulnerabilities and serious incidents come into force.
That’s in just over a year. And preparing robust notification processes that work in 24 hours is not something you build in a few weeks.
The three implications that most change everyday life
1. Developing software is no longer enough: it must be demonstrated.
The CRA doesn’t ask if your product is safe. It asks if you can prove that it is. That means having technical documentation, vulnerability logs, update history, formalized incident response processes… and being able to present them to a regulator or a customer at any time.
2. The supply chain becomes its own responsibility
A vulnerability can enter through an open source library, a third-party API, an embedded SaaS component or a third-party vendor. CRA extends liability beyond your own code. If your product incorporates third-party components, you need to know what risk each of them represents.
3. Response times are drastically shortened.
24 hours to issue an early warning of an actively exploited vulnerability. If your incident management process relies on emails, calls and spreadsheets, that deadline may become impossible to meet.
What capabilities do you need to have (or build)
The CRA does not prescribe specific tools, but it does make clear what processes must be in place. In our experience working with technology organizations, these are the building blocks:
Risk and asset management Up-to-date product and component inventory, threat identification, impact assessment and residual risk monitoring. Without this, you can’t know what vulnerabilities affect you and how urgently. –> Risk Manager
Supply chain management Approval of suppliers, periodic evaluations, safety questionnaires, documented evidence. An unassessed supplier is an unmeasured risk. –> Third Party Manager
Vulnerability management Identification, prioritization, remediation and maintenance of an auditable history. This history can be requested by the regulator. –> Incident Manager
Incident management Recording, classification, assignment of responsible parties, response plans and traceability. Not as a document in a drawer, but as an active process that works under pressure. –> Incident Manager
Technical documentation and policies Policies, procedures, records, acceptances, evidence. Documentation is not bureaucracy: it is proof that you are doing things right. –> Policy Manager.
Security communication to customers More and more customers are asking how you manage security before signing a contract. Having a clear, centralized and up-to-date answer – certifications, policies, evidence – can make all the difference in a business process. –> Trust Center
CRA is not just a cost of compliance
Viewed from the outside, the CRA may seem like just another regulatory burden. But there is another way to read it.
Organizations that are able to demonstrate that they manage product safety rigorously – with documented processes, fast response times and transparency to their customers – will have a real advantage over competitors that continue to rely on informal processes.
In a market where digital trust is increasingly a purchasing criterion, CRA compliance can become a business case.
The question is not just whether you will comply with the CRA. It’s whether you’ll be able to demonstrate it efficiently when someone asks you to.
At ithikios we have developed different modules that will help you comply with the CRA and demonstrate compliance with the Trust Center, Incident Manager, Third Party Manager, Risk Manager and Policy Manager.
