Anatomy of an EUCC Certificate: A Walkthrough of EUCC-3095-2026-01

EUCC is the new EU-managed certification scheme that builds on Common Criteria methodology under the regulatory backing of the EU Cybersecurity Act. As of May 2026, the scheme has issued 29 certificates total, with 12 of those landing in the first four months of 2026. The scheme is real and operational, but the corpus is still small enough that any given EUCC certificate is worth looking at carefully.

This post walks through one specific certificate, EUCC-3095-2026-01 (Distromel Waste Container Identification System), issued on 28 April 2026. The point is not the product; the point is to use a real recent certificate to teach what an EUCC certificate looks like in practice and how it differs from the classical CCRA structure most readers will be familiar with.

The product, briefly

The certified product is a waste container identification and data integrity solution from DISTROMEL, S.A., a Spanish vendor based in Huesca, Aragon. The product is an IoT-class system used by waste-management operators to identify containers, log pickups, and ensure data integrity in the chain from container to billing system.

It is an unusual EUCC entry: most EUCC certifications so far have been smart card or platform components, not finished IoT systems. That is itself useful context: the EUCC scheme is open to product categories well beyond the traditional CC corpus.

Anatomy of the certificate ID: EUCC-3095-2026-01_EN

The certificate identifier follows a structured format set by the EUCC framework:

SegmentValueMeaning
SchemeEUCCThe certification scheme
Issuing body3095Numeric code for the issuing certification body (here, DEKRA Spain)
Year2026Calendar year of issuance
Sequence01First certificate from this body in this year
LanguageENLanguage of the certificate document (English)

This matters because the issuing-body code (3095 in this case) is stable across certificates, so you can use it to find the full set of certificates issued by a given CAB. For comparison, the 3087 prefix appears on certificates issued by another European CAB; 3090 appears on a third. The numbering is not contiguous and is not a quality signal; it is just an identifier.

The two roles: NCCA and CAB

EUCC introduces a clearer split between two roles that classical CCRA blurred:

  • NCCA (National Cybersecurity Certification Authority): the EU member state’s national authority responsible for the scheme in its territory. For this certificate, the NCCA is Spain.
  • CAB (Conformity Assessment Body): the accredited body that performs the evaluation and issues the certificate. Here, the CAB is DEKRA TESTING AND CERTIFICATION S.A.U., also Spanish.

In CCRA terms, the NCCA is roughly equivalent to the national scheme body (BSI, ANSSI, NIAP), and the CAB is the accredited evaluation lab plus the certifying body function. EUCC formalises this split into two separate roles in the regulation.

The assurance level: EAL1, AVA_VAN.1

This certificate’s security level is EAL1, with AVA_VAN.1, the lowest CC assurance package. That is a deliberate choice and worth understanding:

  • EAL1 is “functionally tested”: the evaluator confirms the product behaves as documented, but does not subject it to deep design analysis or significant attack-resistance testing.
  • AVA_VAN.1 is the lowest vulnerability assessment level: the evaluator searches for obvious public vulnerabilities but does not attempt sophisticated penetration testing.

EAL1 is a sensible choice for a product class like this one, where the threat model is operational integrity (the device should report what it actually senses, and the data trail should not be trivially forgeable) rather than resistance to a high-skilled adversary with physical access. EUCC supports the full EAL1-EAL7 range; this certificate sits at the basic end.

For procurement context, EAL1 is roughly aligned with the EUCC regulation’s “substantial” assurance level (EAL2 to EAL4 typically map to “substantial”; EAL5+ and above to “high”). The “substantial” / “high” labels are regulatory; the EAL package is the technical assurance specification.

The Common Criteria version

The certificate references CC:2022 Release 1 with CEM:2022. This is the current Common Criteria standard, and EUCC certificates issued from 2026 onward are largely on this version. CC:2022 is the major standard revision that introduced new requirement structures and refined SAR families. Certificates from older schemes will often still reference CC:2017 or CC:3.1 Revision 5.

Validity period: 5 years

Issuance date: 28 April 2026. Expiry: 28 April 2031. EUCC’s default validity period for a non-maintained certificate is 5 years, which is shorter than what some national schemes have used historically (BSI’s CC certificates can in principle remain valid up to a vendor-managed maintenance window).

The implication for procurement and compliance teams: an EUCC certificate has a hard expiry. After expiry, the product is no longer EUCC-certified unless a re-evaluation or maintenance procedure has happened.

The document set

A full EUCC certificate publishes three main documents:

  1. Certificate document: the signed certificate itself, listing the product, vendor, holder, validity, and assurance package
  2. Security Target (ST): the vendor’s specification of what the product does and what threats it claims to resist
  3. Certification Report: the CAB’s report on what was evaluated and how

For this certificate, all three are hosted on the ENISA EUCC certificate registry at certification.enisa.europa.eu. This is a structural difference from CCRA: classical CC certificates are typically published on the issuing national scheme’s portal (commoncriteriaportal.org for the international corpus, plus per-scheme portals for some national-only certificates). EUCC centralises publication on ENISA’s registry, which is one of the scheme’s deliverables under the EU Cybersecurity Act.

The certification report is identified internally as FCS506_02 EN EUCC Distromel_WCIS Certification Report v1.0, a CAB-internal naming convention separate from the EUCC certificate ID.

Protection Profile

This certificate claims no Protection Profile conformance: the Security Target was authored bespoke for this product. That is permitted under EUCC and CC generally, especially for product categories where no relevant PP exists. An IoT waste-management system does not have an established PP in the CC catalogue, so a vendor-authored ST is the practical option.

If an EUCC certificate did claim PP conformance, it would appear in the metadata alongside the ST URL.

What is distinctive about this versus a CCRA certificate

Side by side with a typical CCRA certificate, the EUCC one differs on a few axes:

  • Regulatory backing: EUCC operates under EU Regulation 2019/881 (Cybersecurity Act) and Implementing Regulation (EU) 2024/482. CCRA is an inter-governmental arrangement with no equivalent statutory force.
  • Centralised registry: All EUCC certificates publish on the ENISA registry. CCRA is decentralised across national portals.
  • NCCA / CAB split: EUCC formally separates the national authority role from the conformity assessment body role.
  • Default 5-year validity: Hard expiry by default; less reliance on open-ended vendor-managed maintenance windows.
  • Scheme-defined assurance labels: EUCC adds “substantial” and “high” labels on top of the EAL/SAR packaging.

Where to find more

The certificate, ST, and certification report are public on the ENISA registry. The full set of EUCC certificates is browsable in NenkinTracker’s catalog under the EUCC scheme view, and direct links from each cert detail page take you back to the canonical ENISA documents.

See also