Skip to content
Nenkin

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.

DateWhat applies
10 December 2024Regulation enters into force
11 June 2026Rules on notification of conformity assessment bodies apply
11 September 2026Manufacturer reporting of actively exploited vulnerabilities and severe incidents applies
11 December 2027The 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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

Frequently asked questions

Does the Cyber Resilience Act require Common Criteria certification?
Not for most products. The Cyber Resilience Act sets baseline security requirements that the majority of products meet through self-assessment. Only a small set of critical products can be required to hold a European cybersecurity certificate, which in practice means an EUCC certificate built on Common Criteria methodology. The Commission defines that set through delegated acts.
When does the Cyber Resilience Act apply?
The regulation entered into force on 10 December 2024. The main obligations on manufacturers apply from 11 December 2027. Vulnerability and incident reporting obligations apply earlier, from 11 September 2026, and the rules on notifying conformity assessment bodies apply from 11 June 2026. Vendors have a staggered runway, not a single deadline.
What is the difference between the CRA and EUCC?
The Cyber Resilience Act is a regulation: it makes cybersecurity a legal condition for placing products with digital elements on the EU market. EUCC is a certification scheme under the EU Cybersecurity Act that produces Common Criteria certificates. The CRA is the obligation; EUCC is one of the tools a vendor can use to demonstrate conformity for higher-assurance products.
What are important and critical products under the CRA?
The CRA sorts products with digital elements into a default tier, an important tier (split into class I and class II), and a critical tier. Default products self-assess. Important products face stricter conformity routes, with class II expected to lean on harmonised standards or third-party assessment. Critical products can be required to hold a European cybersecurity certificate.
Can a Common Criteria certificate help with CRA compliance?
Yes. For products in the important and critical tiers, an existing EUCC or Common Criteria certificate provides documented, lab-verified evidence about the security functions and the vulnerability assessment. It does not automatically discharge every CRA obligation, but it is directly relevant evidence and a head start on the technical documentation the regulation expects.
Does the CRA apply to open-source software?
Partly. The CRA carves out non-commercial open-source software from the full manufacturer obligations and introduces a lighter role of open-source software steward for organisations that support open-source projects commercially used by others. Open-source components shipped inside a commercial product still fall within that product's CRA scope.