The EU Cyber Resilience Act and EUCC: How Common Criteria Fits the New Rules
For most of Common Criteria’s history, a certificate was something a vendor chose to pursue. A government customer asked for it, a Protection Profile mandated it for a product category, or a procurement team scored it as a differentiator. Outside those pockets, certification was optional.
The EU Cyber Resilience Act changes the default. It does not make Common Criteria mandatory, and reading it that way is the most common mistake we see. What it does is make a baseline of product security a legal condition for selling almost anything digital in the EU, and it positions European cybersecurity certification, in practice EUCC, as the top rung of how you prove that security for the products that need the strongest evidence.
This post walks through what the CRA actually requires, how it connects to EUCC and Common Criteria, and what it means for vendors and procurement teams who already deal with certificates.
What the Cyber Resilience Act is
The Cyber Resilience Act (Regulation (EU) 2024/2847) sets horizontal cybersecurity requirements for “products with digital elements”, which is broad enough to cover almost any hardware or software that can connect to a device or network and is placed on the EU market. The text was published in the Official Journal in November 2024, and the regulation entered into force on 10 December 2024.
The obligations it places on manufacturers include security-by-design and by-default, a vulnerability handling process across the support period, a duty to ship security updates, and clear documentation for users. These are not certification requirements in themselves. They are product and process requirements that every in-scope manufacturer has to meet, and demonstrate, before applying the CE marking.
The European Commission maintains the official CRA overview, and the full legal text is on EUR-Lex.
The timeline is staggered
One reason the CRA is misread is that people latch onto a single date. There are several, and they matter for planning.
| Date | What applies |
|---|---|
| 10 December 2024 | Regulation enters into force |
| 11 June 2026 | Rules on notification of conformity assessment bodies apply |
| 11 September 2026 | Manufacturer reporting of actively exploited vulnerabilities and severe incidents applies |
| 11 December 2027 | The main body of manufacturer obligations applies |
The practical read: the reporting duties arrive first, in late 2026, and the full set of design, documentation, and conformity-assessment obligations lands at the end of 2027. A vendor planning a high-assurance evaluation, which can itself take a year or more, is already inside the window where that work needs to start.
Where Common Criteria and EUCC come in
The CRA does not ask every product to be certified. It defines conformity assessment routes that scale with risk, and certification sits at the top of that ladder.
The regulation sorts products with digital elements into tiers. The large default category can use internal self-assessment against the essential requirements. An important category, split into class I and class II, faces stricter routes: class I can use harmonised standards to self-assess, while class II is expected to involve harmonised standards conformance or a third-party (notified body) assessment. A small critical category sits above that, and here is the direct link to our world: for critical products, the Commission can require a European cybersecurity certificate obtained under a scheme adopted through the EU Cybersecurity Act.
Today the operational scheme that produces those certificates is EUCC, the Common Criteria-based scheme that became applicable in February 2025. EUCC issues certificates at assurance level “substantial” and “high”, with the “high” level mapping onto the higher EAL range and the augmented vulnerability analysis (AVA_VAN) work that smart card and secure-element vendors already know well.
So the chain is: the CRA creates the obligation, the Cybersecurity Act provides the certification machinery, and EUCC is the scheme that turns a Common Criteria evaluation into a certificate the CRA can point to. A certificate is not the same thing as CRA conformity, but for the products that need the strongest assurance, it is the recognised way to demonstrate the security claims.
What this means for vendors
If you build products with digital elements for the EU market, the CRA reframes certification from “nice differentiator” to “part of the conformity question”. A few practical implications:
- Find your tier first. Most products are in the default or important categories and will not need a certificate. Spending on an EAL5+ evaluation for a product that the CRA lets you self-assess is wasted money. The first task is honest classification, not certification.
- A current certificate is reusable evidence. If you already hold a Common Criteria or EUCC certificate, the Security Target, the evaluation report, and the vulnerability analysis are directly relevant to the CRA technical documentation. You are not starting from zero.
- Vulnerability handling is now a standing duty. The CRA expects a process across the whole support period, not a point-in-time check. This lines up with the maintenance and re-evaluation discipline that Common Criteria already encourages, and it is the part most vendors underestimate.
- Plan around the evaluation lead time. High-assurance evaluations are measured in quarters. With the main obligations applying from December 2027, the runway for the products that will need a certificate is shorter than it looks.
What this means for buyers and procurement
For procurement teams, the CRA is a quiet but real shift in leverage. After the obligations apply, the CE marking on a product with digital elements carries a cybersecurity meaning it did not before. That raises the floor for everything you buy.
It does not, however, replace the questions a careful buyer already asks. The CRA baseline is a floor, not a ceiling. For higher-risk deployments you will still want to know the assurance level, the scope of the evaluated configuration (the Target of Evaluation), and whether the certificate is current. A product can be CRA-compliant and still be a poor fit if its certified scope does not match how you intend to deploy it. We wrote about reading that scope carefully in Reading a Security Target as a Buyer.
The other shift is timing. Because certificates and conformity now have regulatory weight, their validity windows matter more. A certificate that lapses, or a product that drops out of its support period, is no longer just a procurement footnote.
The honest caveats
Two things are still moving. First, the delegated and implementing acts that pin down exactly which critical products require a certificate, and at what assurance level, are still being worked out. Anyone who tells you the precise certification list today is guessing ahead of the legal text. Second, the relationship between CRA conformity and existing certificates will be clarified through guidance and harmonised standards over the next couple of years. The direction is clear; the fine print is not all written.
What is not in doubt is the direction of travel: in the EU, product security is moving from voluntary to expected, and Common Criteria, through EUCC, is the established way to demonstrate it at the top of the risk ladder.
How NenkinTracker helps you stay ahead of this
The CRA makes certificate currency a compliance signal, not just a procurement nicety. NenkinTracker tracks Common Criteria and EUCC certifications across schemes, with change detection on the underlying documents, so you can see when a certificate is issued, updated, or approaching the end of its validity. If you are mapping a product portfolio against the EU framework, you can start tracking for free and follow the products and vendors that matter to you.
See also
- EUCC: The EU Cybersecurity Certification Scheme: background on the scheme the CRA leans on for critical products
- Common Criteria to EUCC Migration Guide: how existing CC certificates move into the EU framework
- EUCC vs CCRA: the two recognition frameworks a vendor now has to think about
- What is Common Criteria?: the evaluation methodology underneath EUCC
- Common Criteria vs FIPS 140-3: the comparable US assurance framework for context