EU Cyber Resilience Act: Why Secure by Design Is Now a Business Strategy Problem
The Cyber Resilience Act doesn’t just change what your products must do. It changes when compliance has to happen, who in your organisation is responsible for it, and what evidence you need to prove it. That is a different kind of problem from anything European product regulation has required before.
Secure by Design Is No Longer Optional
The phrase “secure by design” has been in circulation for years. Under the EU Cyber Resilience Act (Regulation EU 2024/2847), it stops being a principle and becomes a legal condition of market access.
From December 2027, any product with digital elements placed on the EU market must demonstrate that security was considered and implemented from the earliest stages of its design — not added at the end of development, not addressed at the point of launch, and not treated as a post-market concern. The CRA’s conformity requirements cannot be satisfied retrospectively. Security architecture decisions made at the beginning of a product’s life determine whether that product can legally be sold in Europe.
This is a structural shift in what product compliance means — and it has implications that reach well beyond engineering teams.
Compliance Is Moving Upstream
Historically, regulatory compliance for digital products was largely a final-stage activity. Legal review, documentation, and conformity assessment happened close to launch. The product was built; compliance was layered on.
The CRA makes that model unworkable. Conformity assessment under the CRA requires evidence of security decisions made during design and development — risk assessments conducted before architecture was fixed, threat models documented before code was written, vulnerability handling processes established before a product shipped. Evidence that cannot be produced during development cannot be manufactured after the fact.
This means compliance is no longer a gate at the end of a product lifecycle. It is a discipline that runs through the entire product development process, from initial conception through design, development, testing, launch, and the full supported life of the product in the field.
For organisations whose development processes were not built with this in mind, the gap between current practice and CRA readiness is not a documentation problem. It is an organisational one.
Who Owns This? The Governance Question
One of the clearest practical consequences of the CRA is that it makes cybersecurity a leadership question, not just a technical one.
Product leaders, technical leads, and executive decision-makers will increasingly need to understand how regulatory and security considerations shape what can be built, how it must be documented, and what obligations attach to it after sale. Supply chain decisions — which components to use, which open source dependencies to accept, which third-party integrations to include — carry compliance consequences that cannot be evaluated by engineering teams alone.
The CRA extends accountability throughout the supply chain. Manufacturers bear responsibility not only for the code they write but for the components, libraries, and dependencies their products rely on. Importers and distributors carry their own obligations. Organisations that market products under their own name, even where underlying software was developed by others, may be treated as manufacturers for CRA purposes and carry the full weight of those obligations.
Product strategy and compliance strategy, in this environment, are not separate conversations. They are the same conversation — and the organisations that recognise that earliest will be best positioned when December 2027 arrives.
The Open Source and Supply Chain Dimension
Most commercial software today incorporates significant open source components. Many products depend on third-party libraries, external service integrations, and cloud-based functionality that sits outside the direct control of the manufacturer.
The CRA does not exempt this complexity. Manufacturers are responsible for understanding, documenting, and managing the security of every component their product contains or depends on — including components they did not write. Software Bills of Materials (SBOMs) are part of the technical documentation the CRA requires, precisely because dependency visibility is a prerequisite for meaningful vulnerability management.
The supply chain dimension also creates indirect exposure. Even organisations that believe they fall outside the direct scope of the CRA may find themselves subject to increased security assurance requirements from customers and partners who are directly in scope. The CRA’s effect on procurement standards and supply chain expectations is likely to extend well beyond the organisations it formally regulates.
Standards, Conformity Assessment, and What Credibility Requires
The CRA operates through CE marking — the mechanism by which manufacturers declare that their product meets the regulation’s essential requirements. For the roughly 90% of products that fall into the default category, self-assessment is permitted. For products classified as Important Class II or Critical, third-party assessment by a Conformity Assessment Body is mandatory.
Harmonised standards providing a structured path to demonstrating conformity are still under development, with key standards expected around mid-2026 through 2027. In their absence, manufacturers must map their products directly against the CRA’s Annex I requirements and document that mapping with sufficient rigour to withstand regulatory scrutiny.
The conformity pathway for a given product depends on its classification, its technical architecture, its development history, and the evidence available to support its security claims. Getting the pathway wrong — or producing documentation that does not meet the standard required — creates market access risk, not just administrative inconvenience.
Key Dates
| Date | What happens |
|---|---|
| 11 September 2026 | Vulnerability reporting obligations begin — manufacturers must notify ENISA of actively exploited vulnerabilities within 24 hours |
| 11 December 2027 | Full CRA compliance mandatory — non-compliant products cannot carry CE marking or be placed on the EU market |
Non-compliance carries fines of up to €15 million or 2.5% of global annual turnover, whichever is higher.
The Real Compliance Challenge
The organisations that will find CRA compliance most difficult are not those that lack technical capability. They are those that have not yet recognised that compliance is an organisational challenge as much as a technical one — requiring documented processes, governance structures, supply chain visibility, evidence management, and cross-functional coordination that most product development cycles were not built to produce.
Identifying where your products stand, what evidence already exists, what gaps need to be closed, and which conformity pathway is appropriate — that analysis is where CRA readiness actually starts.
Understanding where your products stand under the CRA is the first conversation worth having. Get in touch