When the source moves silently: a quiet EUCC reformat and what it tells us about CC publishing

A few weeks ago a data-quality check on our catalogue flagged a single Common Criteria certificate with four of five descriptive fields missing. It was a smart card platform entry under EUCC. The natural reaction is to fix the one entry. The more useful reaction was to ask why an entry that had been complete a few weeks earlier had decayed at all.

The answer was bigger than one cert. Between 29 April 2026 (the last day we saw the old format on the portal) and 13 May 2026 (the first day we saw the new one), ENISA changed the certificate identifier format catalogue-wide on the EUCC portal. The old format had variable shape, with anywhere from three to five numeric segments after the issuing-body code. The new format is a fixed shape, EUCC-{cab}-{year}-{10-digit-counter}-{5-digit-suffix}. Side by side, with illustrative IDs to show the shape change:

The PDF document URLs were re-issued at the same time, with new GUIDs. The visible content on the certificate pages did not change in any meaningful way. The identifiers and the document links did.

Anyone following an old reference today encounters this in practice (using an illustrative cert as the example):

A stored reference (April 2026):

  Certificate ID:          EUCC-1234-2025-04-0042
  Certificate page URL:    https://certification.enisa.europa.eu/certificates/eucc-1234-2025-04-0042_en
  Security Target PDF:     https://certification.enisa.europa.eu/sites/default/files/<old-guid>.pdf

The same reference today:

  Certificate ID lookup:   No match on the ENISA portal
  Certificate page URL:    HTTP 404 Not Found
  Security Target PDF:     HTTP 404 Not Found

The same certificate now lives at:

  Certificate ID:          EUCC-1234-2025-0000000042-00000
  Certificate page URL:    https://certification.enisa.europa.eu/certificates/eucc-1234-2025-0000000042-00000_en
  Security Target PDF:     A new URL with a new GUID, with no redirect from the old URL.

The new shape is the more orderly of the two. A fixed-width counter is easier to validate and easier to display in a table; the redesign itself is the kind of cleanup any data-publishing operation might reasonably want. The question this post is concerned with is not the destination. It is what happens around such a change when it ships without announcement.

There is no announcement of this change on the ENISA certification portal news feed, no entry on the EUCC scheme page, no item on the main ENISA news index, and no notice on the certificates listing itself. The most recent formal EUCC change of record is the second amendment to Implementing Regulation 2024/482, adopted on 8 December 2025; it covers definitions, ICT product series certification, assurance continuity, and state-of-the-art documents. The identifier format and the portal structure are not in scope.

This is worth a moment of public discussion. Not because ENISA did anything unusual, but because the structural problem the episode exposes is bigger than one source and bigger than one scheme.

The cost of a silent change

A certificate identifier is not just a label. It is the reference that procurement teams, auditors, integrators, and security analysts use to point at a specific certified product over time.

When a procurement team writes a requirement that says “this deployment requires the configuration certified under the relevant EUCC ID”, that string is meant to be a permanent reference. The contract is read by lawyers, by compliance officers, and by suppliers, and may be referenced years after it was signed. When the underlying identifier silently moves to a new format, the procurement reference no longer matches what is on the public registry. The certificate still exists. The product is still certified. But anyone reading the contract today and trying to look up the cited evidence on the ENISA portal finds nothing at that identifier, and has no signal that the identifier was simply renamed rather than withdrawn.

Industry analysts and authors cite specific cert IDs in market reports, white papers, and academic literature. Those citations are meant to outlive the report. When an editor checks a footnote five years on, “no longer resolves” is hard to distinguish from “was never real” without going back to the source by other means.

Security advisories and vulnerability disclosures often pin the affected certified configuration to a specific cert ID. If the ID changes and the document URLs change at the same time, an advisory that links to a specific Security Target finds the link broken and the equivalent under the new ID harder to locate without manual search.

Compliance binders, vendor certifications pages, and procurement supplier lists are full of saved cert URLs pointing at the Certificate PDF, the Security Target, and the Certification Report. When those URLs are re-issued, every saved bookmark, every footnote in a compliance package, every link in a vendor’s certifications page points at a 404. The replacement document may be byte-identical or it may not. The reader has no easy way to tell.

None of these costs are catastrophic in isolation. They are small structural drag that accumulates across every party that relies on the public catalogue. The publishing body, which sees only its own portal, has no visibility into the cost it has imposed on its readers, because there is no shared contract to violate.

This is a CC-wide pattern

It is worth being clear that EUCC is not the offender here. Public CC catalogues have been quietly restructured many times in recent years: scheme portals redesigning their listing pages, document archives republished at new URLs after the registry’s hosting changed, registry pages adding or removing detail sections without a public note. The mechanics differ, the result is the same. Anyone who had built a reference against the old layout discovers the change by accident, after the fact.

The structural issue is that the Common Criteria publishing layer, taken as a whole, has no shared contract. There is no shared publishing standard, no required versioning of that standard, no requirement to announce a breaking change, no agreed mechanism for redirecting from an old identifier to a new one, no public changelog. Each source treats its public catalogue as a website, not as a public record. From the source’s perspective this is reasonable: the certificates are public records and the portal is the way to look them up. From the reader’s perspective it is awkward, because the reader has invested in the structure of yesterday’s portal and has to rediscover today’s.

What a shared publishing contract would look like

The pieces that would help, none of which require new regulation, are well within reach of coordinated action among the publishing bodies:

• Stable certificate identifiers. Once a certificate is published, its identifier is immutable for the life of the certificate. If the publishing body wants to change its preferred format, the old identifier remains resolvable, either as-is or as a redirect to the new form. The principle is the same as the Web’s “cool URIs don’t change” guidance: the identifier is part of the public record.
• Stable document URLs. The Certificate PDF, the Security Target, and the Certification Report are the substance of the certification. The URLs that resolve them belong to the reader who saved the link, not to the publishing body’s content management strategy. When a document is re-issued (legitimately, for a maintenance update or a correction), it gets a new URL and the old URL redirects to it.
• A public changelog for structural changes. Any change to the way the catalogue is published (new format, removed field, renamed identifier scheme, portal reorganisation) is announced on a dated page that anyone can read. The same page covers what changed, when, and what the migration looks like for readers with stored references.
• A documented migration window. When the publishing body does want to change something structural, the old and new forms coexist for a published window, and there is a documented way to translate between them for as long as old references remain in circulation.

None of this is unusual. It is the baseline that public registries in other regulated industries (medicines, financial filings, public procurement) have settled on over the last decade. The Common Criteria publishing layer is not a special case that has to invent the practices from scratch. It can borrow from neighbouring fields and shorten the gap.

The right place for this conversation to happen is somewhere the EUCC, the CCRA, and the national schemes all have a seat. The Common Criteria Development Board, the EU’s stakeholder consultations under the Cybersecurity Act, and the SOG-IS Joint Interpretation Working Group are obvious candidates. It does not have to start as a regulation; a common-practice document would already be a large improvement on the current situation, in which the only effective guarantee to the people relying on the published record is whatever the source happens to keep stable on a given day.

NenkinTracker users

NenkinTracker users do not need to do anything. The EUCC corpus is current, with all 30 EUCC certificates published under their new identifiers and document URLs. Existing follows and saved links continue to work as before. The deeper fix, the one this post is about, is upstream and shared.