Blog

The vendor brochure says “EAL4 certified”. The certificate the vendor attached confirms it: EAL4, valid, in date, identifier resolves cleanly in the issuing scheme’s registry. Procurement signs off, the product gets purchased, and eighteen months later an auditor asks a question that nobody on the buyer side ever thought to ask. The cloud management plane the operations team enabled on day one is not part of the certified configuration. The certificate’s claims, read strictly, do not apply to how the product is actually deployed.

This is not an unusual outcome. It is the default outcome when the buyer never read the Security Target.

Why buyers read STs differently from evaluators

The Security Target is the central document in any Common Criteria evaluation. The vendor writes it (often with a consultant or the evaluation lab in support), the lab reviews it, and the certification body approves it before any evaluation work begins. The ST defines what is being evaluated and what claims the evaluation must support. The certificate at the end of the process is, in effect, an attestation that the claims in the ST were tested and held up.

An evaluator reads the ST in one direction: against the Common Criteria standard itself. Are the threats well-formed? Do the security objectives trace back to the threats and assumptions? Do the Security Functional Requirements implement the objectives? Is the conformance claim consistent and complete? The evaluator is checking that the document is internally coherent and that the evaluation activities it implies can actually be performed.

A buyer reads the ST in the opposite direction: against a specific deployment. Does the Target of Evaluation match the SKU on the quote? Do the environmental assumptions match the site this product is going to live on? Are the threats listed in the ST the threats actually being procured against, and what about the threats the ST does not list?

Both readings are valid. They ask different questions of the same document. If you have a deadline to recommend buy or no-buy, you need the buyer reading. The evaluator reading has already happened, by definition. That is what the certificate attests to.

TOE identification: match the certified configuration to the SKU you are buying

The first substantive section of any ST identifies the Target of Evaluation. The TOE is the part of the product the certificate covers; it is rarely the entire product the vendor sells.

Read the TOE identification with the vendor’s quote in your other hand. You are checking four things.

1. The product name as evaluated. Is it the same product family as the SKU on the quote, or a sibling product with a similar name? Vendors run product lines with shared branding and meaningfully different evaluated scopes. Treat the brand as a hint, not as proof.
2. The version or firmware revision. A certificate for firmware 2.4 does not, by itself, cover firmware 3.0. If the vendor is offering you the newer version, look for a maintenance report that extends assurance, or a re-evaluation that produced a fresh certificate.
3. The hardware platform. Many evaluations are scoped to a single hardware revision or to a defined list of revisions. A regional variant, an OEM-branded reseller version, or a redesigned mainboard can fall outside the scope.
4. The configuration. STs often describe the certified configuration as a specific set of enabled features and disabled features. If the configuration you plan to deploy differs, the certificate may not apply to it.

The TOE is described in two layers: a physical scope (which components, files, hardware modules sit inside the boundary) and a logical scope (which security functions are covered). Read both. A TOE described as “the cryptographic engine in firmware version 2.4 running on hardware revision A, with the local-administration interface enabled and the remote-management interface disabled” is a much narrower thing than the product on the data sheet.

This is the section where most buyer-side mismatches surface. It is also the section vendors are least likely to flag in a sales conversation, because the natural sales motion is to talk about the product, not about the carve-out.

Security problem definition: read assumptions and threats against your deployment

The security problem definition is a three-part section: the threats the TOE counters, the organisational security policies the TOE enforces, and the assumptions the TOE makes about its environment.

For a buyer, the assumptions are usually the most consequential of the three. They are written as if the TOE is being deployed in an idealised environment, and they are sometimes surprisingly demanding. Typical assumptions include physical security at the deployment site, trusted administrators, network isolation from untrusted networks, an authentication infrastructure of a stated type, and a host operating system at a stated patch level. If any of these assumptions fail in your deployment, the certificate’s claims do not apply to your installation. The product may still work, and may still be secure in a practical sense, but the certificate is no longer evidence of that.

The threats are the second thing to read. The certificate defends against the threats the ST lists, evaluated to the rigour of the chosen assurance package. Threats the ST does not list are out of scope by construction. If your threat model includes an attacker the ST does not consider (a malicious insider, a supply-chain compromise, a network-attached attacker when the ST assumes physical isolation), the certificate is silent on that risk. Silence is not denial, but it is not coverage either.

The organisational security policies are usually less interesting at procurement time, because they describe behavioural rules the deployment must enforce rather than attacker capabilities. Read them, but they rarely change a buy or no-buy decision on their own.

The honest test for this section is to read the assumptions and threats out loud against your actual deployment architecture. If you find yourself silently translating (“well, we do not exactly have a trusted administrator, but Alice is fine”) you have already found the mismatch.

Conformance claims: which CC version, which PP, which augmentations

The conformance claims section is short. It carries four pieces of information that change the assurance picture materially.

First, the Common Criteria version. CC:2022, CC:3.1 Revision 5, or one of the earlier revisions. The version affects which assurance components apply and how they are interpreted. Most current evaluations are on CC:2022 or CC:3.1R5.

Second, the Protection Profile conformance claim, if any. If the ST claims conformance to a PP, the ST inherits that PP’s requirements, and the certificate is comparable to any other certificate against the same PP. If the ST is “ST-only” with no PP claim, the requirement set is bespoke and cross-vendor comparison is harder. PP-conformant certificates are the apples-to-apples case; ST-only certificates each need to be read on their own terms.

Third, the assurance package: the EAL and any augmentations. EAL4 alone is not the same product as EAL4 augmented by AVA_VAN.5 and ALC_DVS.2. The augmentations are listed by their full component identifier in the conformance claim, and they change what the evaluation actually tested. AVA_VAN.5 vulnerability assessment against a high-attack-potential attacker is a categorically different activity from AVA_VAN.3 against an enhanced-basic attacker. Two products both advertised as “EAL4+” can have very different evaluation rigour behind them.

Fourth, look at what is missing. If the buyer specification asks for a particular augmentation (ALC_FLR for flaw remediation commitments, ALC_DVS for development security, AVA_VAN at a specified level) and the conformance claim does not include it, the certificate does not cover what the specification asked for. This sounds obvious. It is also the most common gap in cross-vendor comparison matrices, because the headline EAL is what gets copied into the matrix and the augmentations get truncated to ”+”.

A worked example: the cloud-managed perimeter firewall

Consider a hypothetical EAL4-augmented network firewall from an established vendor. The certificate is in date, the issuing scheme is a CCRA Certificate Authorizing scheme, and the augmentation set looks credible (ALC_DVS.2 and AVA_VAN.4). The buyer is a public-sector integrator looking for a firewall to sit at the perimeter of a regulated environment, with cloud-based central management because the deployment spans twelve sites across the country.

The certificate page is reassuring. The Security Target tells a different story.

The TOE identification scopes the evaluation to the firewall appliance running a specific firmware version, configured in standalone mode without the cloud management plane. The ST is explicit: “The cloud management interface is excluded from the TOE and is not within the scope of this evaluation.” The security problem definition assumes that management traffic is “performed locally by a trusted administrator through the appliance console or the local web UI.” The listed threats include network-attached attackers against the data plane; they do not include attackers against a cloud management plane that the ST has placed outside the scope.

The product the buyer plans to deploy has the cloud management plane enabled on day one, because the deployment is multi-site and local administration of each box is operationally impractical. The certificate, read strictly, covers a configuration the buyer is not using. The vendor’s marketing material does not flag this; the brochure says “EAL4-certified” and lists “centralised cloud management” two lines below. Both statements are true. Together, in the absence of the ST reading, they are misleading.

This is what the buyer reading of the ST surfaces. It is not a defect in the certificate (the certificate is valid for what it covers) and it is not necessarily a deal-breaker (the buyer may decide the unevaluated cloud management plane is acceptable risk, with compensating controls, perhaps locked down to a dedicated management VLAN with mutual TLS and offline credential rotation). But the decision needs to be made on the basis of what the ST actually says, not on the basis of the brochure.

The same shape of mismatch shows up in other categories. A smart card or secure IC ST may scope the evaluation to the chip’s secure element while leaving the host-side personalisation tooling out of scope. A SESIP or PSA-certified IoT platform may certify the bootloader and runtime while excluding the cloud back-end the device connects to. An eIDAS Qualified Signature Creation Device may carve out the signature creation function and leave the surrounding application stack to the integrator. The category changes; the structural pattern does not. The glossary entries for TOE, SFR, and SAR are worth a re-read at this point if any of these terms have gone hazy.

The closing argument: read the ST before signature, not after

The certificate is a pointer. The Certification Report is a summary. The Security Target is the document that defines the scope of what was evaluated, and it is the only document in the package with the level of detail a contract can reference. Procurement contracts for certified products typically cite a certificate identifier and a Security Target version. Anything outside the ST is, contractually, not part of what the vendor delivered as certified.

Reading the ST is a few hours of work. It is the cheapest piece of procurement due diligence available, and it is the part an auditor (or, eventually, a post-incident reviewer) will ask whether you did. The vendor cannot read the ST for you, because the vendor is the party whose claims are being checked. The lab cannot read it for you either; the lab’s job ended at the certificate.

If you have a Security Target in front of you and a deadline to recommend buy or no-buy, the four-section reading above is the buyer’s path through it. TOE identification against the SKU. Security problem definition against the deployment. Conformance claims against the specification. TOE summary specification against the implementation details that matter to your use case. That is the procurement read. Everything else in the document is structural overhead aimed at the evaluator, and you can skim it.

For supporting context, the Common Criteria procurement guide lists the broader red-flag set; the sibling Security Target Review for Buyers checklist sits one level more detailed; and the How to Read a Common Criteria Certificate field guide covers the one-page document the ST sits behind. If you are also comparing EAL claims across vendors, the EAL4 vs EAL4+ piece explains why the plus sign on its own carries no information, and the twelve procurement red flags post collects the wider set of patterns to test for in a vendor bid.

How NenkinTracker helps you see this

NenkinTracker indexes the published Security Target for every certificate it ingests, across Common Criteria, EUCC, SESIP, PSA, EMVCo, ESA, and MIFARE, and tracks document version history when an ST is updated as part of a maintenance procedure or re-evaluation. That means when you start a buyer-side review, the ST is one click from the certificate page rather than buried in a national scheme’s portal and a per-vendor PDF archive. For a side-by-side comparison of two candidates’ STs, that is the difference between an afternoon’s work and a week of document hunting.

For high-value or high-assurance procurements, the same review benefits from an independent advisor who can pressure-test the vendor’s certificate claim before signature, sit through the ST with you, and write a recommendation attributable to a named person. Nenkin Technologies AS offers procurement advisory on this basis: buyer-side only, no vendor referral fees, with specialty in smart cards and secure ICs, network and telecom infrastructure, IoT platforms (SESIP, PSA), mobile and payment, TEEs, and eIDAS Qualified Signature Creation Devices. The practice is led by a former Technical Manager of Norway’s Common Criteria scheme (2012 to 2018, in CCDB, SOG-IS JIWG, and ISO/IEC SC 27/WG3), now working under the Dutch scheme through Scandicert AS, with more than 20 years on the certifier and CAB side of the table. If you have an ST on your desk and a procurement deadline, that is the engagement to ask about.

For six years I was the Technical Manager of Norway’s Common Criteria certification scheme. The things I saw from that seat are not what most procurement teams imagine they are buying.

I spent 18 years inside the Norwegian national security authority before that, joining in 2000 after a defence-side career in the Army material command and TADKOM communications. The last six of those years, from 2012 to 2018, I held the Technical Manager role at SERTIT, the Norwegian scheme. I sat through more evaluation reviews than I can usefully count, across smart cards, secure ICs, network and telecom infrastructure, mobile and payment products, java card applications, Trusted Execution Environments, and eIDAS Qualified Signature Creation Devices. I represented Norway in the Common Criteria Development Board, in the SOG-IS Joint Interpretation Working Group, and in ISO SC 27/WG3, the working group that maintains the standard itself. Today I run Scandicert AS, performing evaluation and certification work inside the Dutch government scheme for SESIP IoT and eIDAS QSCD evaluations.

This post is about what that vantage point shows you, what a buyer does not see, and what I think buyers should do about it.

The job the title does not describe

“Technical Manager of a national CC scheme” does not, on its own, say much. The work itself is straightforward to summarise. You manage the relationship between the scheme and the accredited evaluation laboratories that perform the technical work. You monitor evaluations while they are running, attend technical meetings between the lab and the vendor when the questions get hard, and review the Evaluation Technical Report (ETR) before the certificate is signed. You host international meetings on behalf of your scheme, write your country’s position on interpretation questions that come up in the international bodies, and negotiate the result in committee.

What the role is not is what most outsiders imagine. The Technical Manager rarely runs tests. The lab does that. The Technical Manager reads the ETR: the lab’s accumulated record of what was actually evaluated, how scope shifted during the work, what questions were raised, and how the vendor answered. The ETR is confidential. It is never a document the buyer will see.

Three documents, three audiences

Pull the certification pipeline apart and you get three documents pointed at three audiences.

The ETR is written by the lab and read by the certifier. It is the working record of the evaluation: every iteration, every scope adjustment, every question the lab raised, every answer the vendor returned. The ETR is confidential to the scheme and the vendor.

The Security Target (ST) is written by the vendor and read by the lab and the certifier. It is authoritative. The ST defines the Target of Evaluation, declares the conformance claim, lists the assumptions about the deployment environment, and enumerates the security functional requirements. It is published with the certificate, but it is written for evaluators, not for buyers.

The certificate page is what the buyer reads. It is a summary: identifier, product name, assurance level, dates, signatures. The certificate points at the ST and the certification report; it does not reproduce them.

Three documents, three audiences, very different signals. The certifier’s view is the closest thing the process has to a single source of truth. None of it is exportable.

What I saw repeatedly from that seat

A handful of patterns came up often enough across schemes, sectors, and product categories that they are worth calling out as patterns rather than incidents.

Augmentations dropped from the procurement spec

A buyer writes “EAL4 minimum” into a specification. Two vendors respond. One holds an EAL4 certificate with augmentations such as AVA_VAN.5 and ALC_DVS.2 because the product is a smart card and the high-attack-potential vulnerability assessment is part of the certified scope. The other holds an EAL4 certificate with no augmentations because the product is general-purpose software at the EAL4 baseline. Both certificates say EAL4 on the front page. The work behind them is not comparable.

When the buyer’s evaluation matrix flattens “EAL4” into a single column, the augmented certificate gets no credit for the depth it actually carries, and the unaugmented certificate gets too much. The right specification names the augmentation, not just the level. From the certifier’s seat I watched this asymmetry repeat across product categories for years; from the buyer’s seat it usually goes unnoticed.

Composite chains that quietly invalidate

Many of the products I signed off on were composite evaluations. Smart card products are typically evaluated as an applet on top of a certified java card platform on top of a certified integrated circuit, with each layer holding its own certificate. SESIP IoT platform claims sit on top of certified roots of trust. eIDAS QSCDs compose against certified hardware and certified cryptographic libraries.

The composite certificate is only as strong as the weakest in-date underlying component. From the certifier’s chair you watch these chains carefully because a lapse anywhere quietly invalidates the composite claim. From the buyer’s chair the top-level certificate looks active and the chain is invisible. The vendor is rarely the party that volunteers a downstream impact when an upstream platform certificate is suspended or archived. Most buyers I observed never checked the chain.

Scope narrowing during evaluation, frozen at publication

A vendor enters an evaluation with one description of what the Target of Evaluation will cover. By the time the certificate is signed, the TOE is often substantially smaller. Features that turn out to be hard to evaluate get carved out. Optional functionality gets declared out of scope. Configurations the lab could not exercise to its satisfaction become “the evaluated configuration excludes …”. All of this lands in the Security Target as published, but the published ST is a snapshot at the end of the work, not a record of the path.

A buyer who reads only the certificate page never sees the journey. A buyer who reads the ST sees the destination but not the gradient. The certifier sees both, because the ETR carries the iterations explicitly and a Technical Manager has been reading that genre of document long enough to spot the shape of a late-stage carve-out at a glance.

Vendor maturity that shows up in how questions get answered

During an evaluation, the lab raises issues, the certifier may raise issues on top of those, and the vendor responds. Some vendors come back with structured analyses and a clear sense of what their own product does and does not promise. Others come back with marketing-shaped responses that do not engage with the technical question. By the time a certificate is issued, both hold the same certificate. The certificate cannot tell the buyer which is which.

The buyer is left to infer it from how the vendor responds at procurement time, which is often the first real chance they get. The signal is genuine but late. The certifier saw it months earlier.

Why this matters for buyers

Pull these threads together and the asymmetry is structural, not anyone’s fault. The lab reads the product, the vendor, and the test results. The certifier reads the ETR and pressure-tests it against the standard. The buyer reads the certificate and, if diligent, the ST. None of those three audiences sees the same picture, and the audience furthest down the chain has the least access to what was actually done.

A certificate is real evidence. It is also a pointer to a body of evidence the buyer cannot fully reconstruct. Reading the certificate and the ST gets you closer than reading the brochure. It does not get you the rest. Closing the rest of the gap requires reading the published documents with “what does this not say” front of mind, walking the composite chain, checking the lifecycle state at procurement time rather than at evaluation time, and translating the ST’s environmental assumptions into questions the vendor must answer in writing before signature.

That habit is hard to acquire inside a procurement department whose primary work is contracting, not evaluation. The patterns that matter are patterns of attention rather than patterns of fact. They are what a certifier learned to look for after the third or fourth time the same gap showed up in a different product category.

Where an independent advisor changes the calculation

There is a real role for an independent procurement advisor here, and it is not “we have read the standard.” Anyone can read the standard. The role is to read a published Security Target with the same skepticism a certifier brings to the ETR, to spot where the published scope is narrower than the marketing claim, to check the lifecycle state at procurement time rather than at evaluation time, to walk the composite certificate chain, and to translate the certificate’s assumptions into questions the buyer can put to the vendor in writing.

In short: reading certificates with “what does this not say” front of mind, rather than “what does this say.” That orientation is not exotic, and it does not require access to confidential documents. It does require having sat in the room across enough evaluations to know which carve-outs are routine and which ones are flags.

How Nenkin uses this

That experience is what Nenkin Technologies AS sells, buyer-side, through our procurement advisory practice. We sit on the buyer’s side of the table. We do not represent both sides of a single transaction. We do not take vendor referral fees. The recommendation we give a buyer is the recommendation we would give if we were spending the budget ourselves. The Common Criteria procurement guide and the twelve procurement red flags post collect the same patterns as free reference material, for procurement teams who would rather build the muscle in-house. NenkinTracker is where we surface the lifecycle states, composite chains, and CVE links the published portals leave disconnected.

A certificate is real evidence. It is also less evidence than buyers usually assume. Six years on the certifier’s side of the table taught me that the gap is structural, predictable, and worth closing before the contract gets signed.

A vendor sends you a single line of marketing copy. “Common Criteria EAL4+ certified.” “EUCC High.” “SESIP Level 3.” If that sentence lands in your procurement scorecard untouched, you are about to buy a security product on the strength of a checkbox. The certificate is being asked to do the work of evidence, and the bid is hoping you will let it.

This is a checklist post. It expands the twelve procurement red flags we work through on every buyer-side engagement at Nenkin Technologies AS. Each item is a pattern that has, at some point, turned what looked like a clean certified bid into a procurement that needed material rework. The examples are deliberately generic. The point is the pattern, not the vendor.

A note on where the list comes from. Co-founder Kjartan Kvassness Jaeger spent six years (2012 to 2018) as Technical Manager of the Norwegian Common Criteria certification authority and represented Norway in the Common Criteria Development Board, the SOG-IS Joint Interpretation Working Group, and ISO SC 27/WG3. He continues evaluation and certification work inside the Dutch government Common Criteria scheme through Scandicert AS. The catalogue below is what 20+ years of reading Security Targets and Evaluation Technical Reports from the certifier’s chair teaches you to look for once the same gaps keep opening up in different product categories.

For the broader reference, the Common Criteria procurement guide collects lifecycle states, contract clauses, and verification steps in one place. The companion buyer-side ST read is in reading a Security Target as a buyer. This post is the field checklist.

1. The certified TOE does not match the product SKU

The Target of Evaluation is the precise configuration that was evaluated. A certificate covers exactly the TOE named in the Security Target, almost never the whole vendor catalogue. Sibling SKUs, regional variants, optional cards, later firmware revisions: each one sits outside the certified perimeter unless a maintenance report explicitly extends assurance to it.

We have reviewed bids in which the vendor’s response cites a certificate covering firmware 2.4 on hardware model A, while the proposed delivery is firmware 3.0 on hardware model B. At face value that is an uncertified product. Either the vendor can point at the maintenance trail that extends the certificate to your SKU, or the assurance claim does not apply to what they are actually selling. There is no third option, and the procurement team is the only line of defence: the certifier cannot see into your purchase order, and the lab signed off on the SKU on the certificate, not the SKU on the quote. See how to read a Common Criteria certificate for the field-by-field walkthrough.

2. Operational environment assumptions do not match your deployment

Every Security Target lists assumptions about the world around the TOE: physical access control, trusted administrators, network isolation, key management procedures, sometimes anti-tamper conditions on the room the appliance lives in. The certificate’s claims only apply when the deployment satisfies those assumptions. Strictly. The CC standard is explicit on this; an evaluator cannot certify against a deployment they cannot see.

Take a hypothetical network appliance whose ST assumes the management interface sits on an isolated administrative network. Deployed inside a flat network reachable from a general-purpose user VLAN, the assurance claims simply do not bind. The vendor has not lied. The buyer has applied the product outside its certified envelope. Read the assumptions section of the ST and either confirm the deployment satisfies each one, or document the gap as a compensating-control requirement before signature. This is the one red flag the buyer is best placed to spot, because the buyer is the only party who knows the deployment in detail.

3. Security Target scope is narrower than the marketing claim

“EAL4-certified” in a brochure can mean the product has an EAL4 certificate covering specific modules while the rest of the feature set is explicitly excluded from the evaluation. The Security Target is authoritative; the brochure is not.

The Security Targets we have read across smart cards, network equipment, and IoT platforms tend to follow a similar pattern: the certificate covers, for example, the cryptographic module and the secure boot path, while the application layer, the management UI, and third-party integration adapters are scoped out. The vendor can truthfully say the product is EAL4-certified. The buyer who needs assurance over the application layer learns at deployment time that the certificate does not cover what they were buying it for. The check is mechanical and cheap: open the ST, read the TOE description, and confirm that each functional requirement in the procurement specification maps to a clause that places the requirement inside the TOE.

4. The certificate is in surveillance, suspended, archived, or expired status

Certificates move through lifecycle states. A product that was once certified can still be on the vendor’s marketing page well after the certificate has entered surveillance, been suspended, been archived, or has lapsed. The certificate validity reference covers the state machine: active, surveillance, suspended, archived, withdrawn, expired.

Verify the live status at procurement time, not the status at the date the marketing copy was last edited. The scheme registry is the source of truth, and the vendor’s data sheet is downstream of it by however many months. NenkinTracker mirrors and indexes the registry across CC, EUCC, SESIP, PSA Certified, EMVCo, ESA, and MIFARE, which collapses the multi-portal walk into a single lookup. A bid that quotes a certificate identifier without naming its current lifecycle state has left the buyer to do the registry work. Doing it is fine; finding out the certificate has been suspended is not.

5. Optional features you need are outside the evaluated configuration

Many evaluations explicitly exclude optional functionality from the TOE. Cloud sync, remote-management plug-ins, federation adapters, performance-tier accelerators, vendor-specific integration kits: any of these can sit outside the evaluated configuration while still shipping in the same SKU. From the certifier’s chair, you watch these exclusions happen during evaluation. Optional features that turned out to be hard to evaluate get carved out and the carve-out lands quietly in the ST.

The pattern that catches buyers: the procurement requirement is specifically for feature X, the ST excludes feature X from the TOE, and the bid response asserts the certificate covers the product. Both statements can be true and still leave the buyer outside the assurance perimeter for the exact reason they bought the product. Require the vendor to map each functional requirement in the specification back to a clause in the ST that places the requirement inside the TOE. If a requirement maps to an excluded feature, the certificate is not doing the assurance work the bid implies it is.

6. Composite certifications depend on a component certificate that is no longer valid

Java card platforms, applets, IoT platforms with separately certified Roots of Trust, and SESIP composite certificates depend on a chain of underlying certificates. See composite certifications for the structure. The composite claim is only as strong as the weakest in-date component. A lapsed underlying certificate quietly invalidates the composite claim without any change to the composite document itself.

Imagine an applet certificate that explicitly composes onto a specific java card platform certificate. If the underlying platform certificate has since been archived, the composite is operating outside its assurance basis even though the applet’s own certificate page still reads “active”. From the certifier’s side, you watch these chains because a lapse anywhere quietly invalidates the top. From the buyer’s side, the top-level certificate looks active and the chain is invisible. Composite chains have to be walked, not glanced at. Chain documentation lives in the Security Target and the Certification Report; live status lives in the issuing scheme’s registry; both have to agree.

7. EAL augmentations are dropped from cross-vendor comparisons

EAL4 and EAL4+ALC_DVS.2+AVA_VAN.5 look almost identical when a buyer’s evaluation matrix has a column called “Assurance Level” and a free-text cell underneath. The plus sign carries weight, and the components after it carry the actual difference in evaluation depth. See EAL augmentations for the full picture, and the dedicated post on why “EAL4” and “EAL4+” are not the same for the procurement-side argument.

When the comparison is flattened to bare EAL numbers, products that paid for the augmentations get under-credited, and products that did not get over-credited. The right specification names the augmentation, not just the level: “EAL4 augmented by AVA_VAN.5 and ALC_FLR.2 minimum” is procurement-grade; “EAL4+ minimum” is not. We rebuild bid-comparison matrices on every engagement to expose the augmented components explicitly, then weight them against the threat model.

8. Vulnerability assessment depth (AVA_VAN) is below the threat model

The AVA_VAN family runs from AVA_VAN.1 through AVA_VAN.5. Each level describes a more capable attacker the evaluator simulated against the TOE. A smart card defending against well-funded laboratory attackers needs AVA_VAN.5. A back-office product in a controlled-physical environment can live happily at AVA_VAN.2. The right level is driven by the threat, not by the vendor’s certification budget.

The red flag is mismatch, not low value per se. A payment terminal operating unattended in a retail setting and accepting AVA_VAN.2 is under-specified, because the deployment context exposes it to attackers the evaluator never simulated. An internal-network appliance demanding AVA_VAN.5 is over-specified, and will have a shorter vendor list than it needs at no real gain in residual risk. Pick the AVA_VAN level from the threat model in the operational specification, not from a generic procurement template.

9. The issuing scheme is not Certificate Authorizing under CCRA, or is consuming-only

Not every national scheme can issue mutually recognised CCRA certificates. Some are consuming-only: they accept certificates issued by Authorizing Participants but do not themselves issue mutually recognised certificates. EUCC adds another layer for EU procurements: certificates under EUCC are EU-side artefacts that interact with the CCRA framework on specific terms. See EUCC vs CCRA for the current picture and protection profiles for how cPP conformance changes recognition above EAL2.

For a buyer this matters when the procurement is cross-border, when the bid references an unfamiliar scheme, or when a national procurement framework requires a specific issuing authority. Confirm both that the issuing scheme is authorised to issue the certificate at the assurance level claimed, and that the certificate’s jurisdiction matches the procurement requirement. A perfectly good certificate issued by the wrong scheme can still leave the buyer without the recognition they assumed they were paying for.

10. Maintenance updates have not been processed after major releases

Assurance continuity requires the vendor to file impact analyses and Maintenance Reports with the issuing scheme after material changes to the product. If a firmware or software major version has shipped without a corresponding maintenance record, the certificate has drifted from the live product. The certificate page may still say “active”, but the product the buyer is receiving is no longer the product that was evaluated.

The check is mechanical. List the product versions released since the certificate was issued. For each material release, ask the vendor to point at the maintenance report that extends assurance to it. If a release is unaccompanied by a maintenance filing, decide explicitly whether to accept the gap, ask the vendor to file the maintenance, or treat the procurement as buying an uncertified version of a once-certified product. None of those choices is necessarily wrong. Making the choice unconsciously, by failing to check, is.

11. Patching SLAs and re-evaluation triggers are not in the vendor contract

A certificate is a point-in-time attestation. A procurement contract binds the vendor for the lifetime of the deployment, which can run five to ten years past the original certificate date. Patching commitments, vulnerability-disclosure obligations, end-of-support dates, replacement obligations on certificate lapse, and re-evaluation triggers belong in writing before signature, not in goodwill afterwards.

We see contracts that lift the certificate identifier and the EAL into the schedule of deliverables, and then say nothing about what the vendor commits to do when a new vulnerability lands, when the certificate is suspended for surveillance, or when a major release ships without a maintenance filing. The certificate has done its job; the contract has not done its. The procurement-advisory deliverable here is a clause set that turns the certificate from a marketing claim into an enforceable assurance commitment. The Common Criteria procurement guide has the longer treatment of which clauses tend to matter.

12. Known CVEs against the certified product are not acknowledged in the vendor’s response

Public vulnerability data exists for many certified products. NVD, vendor advisories, and the issuing scheme’s own impact analyses are searchable. A bid response that does not surface relevant CVEs, or cannot describe how each is mitigated in the certified configuration, is showing the buyer something about how the vendor will handle the next vulnerability too.

The red flag is not the existence of CVEs. Every interesting product has them. The red flag is silence. A credible bid includes a CVE position: which CVEs are known against the certified product, which apply to the certified configuration, what mitigations or patches are in place, and what the vendor’s process is for new CVEs disclosed during the contract period. A vendor that engages with the question is showing you the muscle they will use when something lands during the contract. A vendor that does not is showing you the absence of one.

How to run these checks during bid evaluation

The twelve patterns do not need a formal stage gate. In practice we work through them in three passes.

The first pass is certificate-and-TOE. Look up the certificate identifier in the issuing scheme’s registry and in the NenkinTracker certifications database. Confirm the lifecycle state against the issuing scheme’s record. Read the TOE description in the Security Target and check it covers the SKU being offered. Walk the composite chain if one exists. That single pass catches red flags 1, 3, 4, 6, 9, and 10.

The second pass is fit-to-deployment. Read the assumptions section of the Security Target, the optional-feature exclusions, and the AVA_VAN level. Compare each one against the procurement specification, not against the vendor’s brochure. That catches red flags 2, 5, 7, and 8. This is the pass that requires somebody who knows the deployment in detail, which usually means a procurement engineer working with the operational team that will run the product, not procurement on its own.

The third pass is contract-and-CVE. Pull the public CVE record for the certified product, including the Nenkin CVE view for cross-scheme aggregation. Compare the vendor’s response against the contract clauses you expect: patching, maintenance, re-evaluation, replacement. That catches red flags 11 and 12.

None of the three passes requires the buyer to be a certification specialist. Each requires somebody who can read the Security Target against the procurement specification as two parallel statements of what the product is supposed to do.

How NenkinTracker helps you run the first pass

The certificate-and-TOE pass is where the buyer most often runs out of patience, because it crosses up to seven scheme portals (CC, EUCC, SESIP, PSA, EMVCo, ESA, MIFARE) with different formats, different lifecycle conventions, and different update cadences. NenkinTracker indexes and continuously refreshes all of them in one place. The certifications database supports search by vendor, product, scheme, EAL, augmentation, and lifecycle state; the expired-certificates report catches the marketing-page-versus-registry gap; and the Common Criteria Portal alternative comparison shows where the indexed view goes beyond what the public CC Portal exposes today.

If you have a bid in front of you and want an independent read before signature, that is what the procurement advisory service line is for. The deliverables, the engagement model, and the credentials behind the work are on the service page. Buyer-side only: we do not represent both sides of a transaction, do not take vendor referral fees, and do not hold exclusive distribution arrangements. The recommendation you get is the recommendation we would give if we were spending the budget.

Email [email protected] with “Procurement advisory” in the subject line. Share the product category, the deployment context, and the rough timeline, and we will come back with an honest scoping read, including whether procurement advisory is the right shape of engagement for what you are buying.

The Common Criteria community holds one annual gathering where the schemes, the labs, the vendors, and the policy bodies all sit in one room. This year it is in Rome, from 28 September to 1 October 2026, at Cardo Roma. The conference is the 25th edition of ICCC, and the program looks more consequential than the average year. The published theme, “Managing Compliance Across an Expanding Certification Landscape,” is doing some work.

EUCC has crossed 30 published certificates since the previous edition. The EU Cyber Resilience Act is rewriting what conformity assessment means for connected products, with the operational details (which products, which assurance levels, which assessment routes) still being worked out. The host country, Italy, has just retired its national Common Criteria scheme in favour of the EU framework. Plenty of conversations that have been held bilaterally over the past twelve months will become public in late September.

This is a curtain-raiser. We have not been to every session yet (no one has, the program is still being finalised), but the shape of the week, the named tracks, and the sponsor list are enough to call out what is worth watching.

The shape of the week

ICCC26 runs over four days, with the first one optional. The full schedule of events is published on the conference site; the headline structure is:

• Monday 28 September: CC Action Plan Day. A pre-conference day framed around turning Common Criteria from a bottleneck into a competitive advantage for ICT developers. Included in the 4-day pass, optional otherwise.
• Tuesday 29 September: opening plenary keynote (09:00 to 10:15), morning plenary session (11:00 to 13:00), three concurrent tracks in the afternoon, welcome reception in the exhibits (17:30), evening dinner (19:30).
• Wednesday 30 September: four concurrent track blocks across the day. Exhibits close at end of day.
• Thursday 1 October: morning track sessions including the dedicated Assurance track, closing plenary 13:00 to 14:00, conference adjourns.

Expected attendance is over 400 delegates from 28 countries, which is the upper end of the typical ICCC range and consistent with a host city that draws well.

Why this edition matters more than the average year

Three regulatory currents collide in 2026, and ICCC26 is the first venue where the people who have to operationalise them will be in the same room since the picture took shape.

EUCC moved from draft framework to real publishing surface. When the community last met in Korea in October 2025, EUCC certificates were being issued but the registry was sparse and the operational details (CAB onboarding, ENISA portal behaviour, assurance continuity rules) were still being shaken down. Fifteen months on, the scheme has 30 published certificates, multiple active CABs across Member States, and an identifier format that has already been quietly reformatted once. Plenty to talk about.

The Cyber Resilience Act is now in scope for the same audience. CRA conformity assessment will lean on horizontal cybersecurity standards and, where appropriate, on EUCC. Which products land in which assurance route, what the gap between CRA self-assessment and a third-party EUCC certification will mean for vendors, and how labs will be resourced for the expected demand surge are all live questions.

The CC standard itself is in revision. “New CC ISO Revision Update” is a named track for the first time. The CC:2022 baseline is now embedded in EUCC, and the next revision will determine what schemes, labs, and vendors code against for the back half of the decade.

Layer on top of that the structural conversation about continuous assurance (what to do about vulnerabilities discovered after certification, how to handle patch management for certified products, how AVA_VAN guidance should evolve), and there is enough material to fill the four days twice over.

What we are watching, track by track

ICCC26 publishes six tracks. Based on the call for speakers and the precedent set by ICCC25’s agenda in Korea, here is what we expect from each.

Advances in the Use of Common Criteria. The A-track is where continuous assurance, vulnerability management beyond certification maintenance, attack potential and CVSS scoring, and post-quantum cryptography readiness will land. This is also typically where AI assurance, cloud, OT, and other emerging-domain topics appear, framed as “how does CC methodology apply here.” A useful track for anyone trying to certify something that does not look like a smart card.

Assurance. The dedicated Assurance track is new on the named-track list this year. We expect deeper sessions on AVA_VAN evolution, CEM:2022 in practice, evaluator-side methodology questions, and the supporting documents (the SOG-IS-era documents now being absorbed into the EUCC framework). This is the track for the labs.

Cybersecurity Certification Schemes Landscape. The L-track is where the regulatory comparisons happen. EUCC, CRA, candidate EUCS for cloud services, EU Digital Identity Wallet certification, and the relationship between the EU framework and the CCRA. Expect at least one panel on what each scheme is for and where the overlaps are starting to bite.

Meeting Customer Requirements. The M-track is the procurement and deployment side. What buyers actually want to read on a certificate, how to express security requirements in a contract, the gap between EAL packages (still how the procurement community thinks) and the EUCC Substantial / High labels (how the regulator thinks). Useful for anyone on the buying side of certified products.

New CC ISO Revision Update. The first time this has been a named track. The CC standard revision cycle is slow-moving but high-stakes plumbing. The schemes, the labs, and the vendors all want a quiet runway with no surprises. Worth watching for any early signals on what the next revision will and will not contain.

Updates from Schemes and iTCs. The U-track is the regular reports from CCRA national schemes (BSI, ANSSI, NIAP, OCSI, NSCIB, CCCS, JISEC, KECS, and others) and from the international Technical Communities. Mostly status reports, occasionally newsworthy when a scheme announces a process change or a new product category coming into scope.

The split between A, L, M, and U has been stable for years. The Assurance and CC ISO Revision tracks being named separately this year is the structural change worth noticing.

The host scheme is its own case study

OCSI (Organismo di Certificazione della Sicurezza Informatica) is Italy’s national CC body, transferred to the Italian Cybersecurity Agency (ACN) in July 2022. On 27 February 2026, OCSI wound down its national CC scheme and now functions as Italy’s EUCC NCCA, per ACN’s own statement on the OCSI page. Italian CC evaluations now route through the EUCC framework rather than through a parallel national scheme.

That makes Rome a slightly unusual host city. ICCC is normally hosted by a country whose national scheme is still actively issuing under CCRA. Italy is one of the first CCRA Authorising members to have completed the transition the rest of the EU is in the middle of. Whatever lessons OCSI and ACN have learned from running the transition end to end (CAB readiness, vendor communication, the practical mechanics of redirecting in-flight evaluations) will be one of the more useful informal threads of the week. Rome also hosted ICCC7 in 2007, so this is Italy’s second turn at the conference.

The exhibit floor reads as a map of the lab market

The published sponsor list for ICCC26 is a useful snapshot of the active CC evaluation and consulting market.

• Title sponsors: Securus Consulting Group (Platinum), UL Solutions (Gold), Brightsight, Intertek Acumen Security with EWA-Canada, LGAI Technological Center, and TUV Informationstechnik (TUViT, all Silver).
• Leading sponsors: CCLab (hosting the opening reception), DEKRA (track sponsor), konfidas, Teron Labs (badges and lanyards), Zhejiang Wonsec (WiFi).
• Exhibitors: eShard, Red Alert Labs.
• Supporting associations: CCUF, EUCC ISAC, Eurosmart, Global Platform, OASIS, Trusted Connectivity Alliance, Biometric Update.

That roster spans BSI-licensed labs, ANSSI-licensed labs, NIAP CCTLs, and EUCC-accredited CABs. It also covers the consulting tier (Securus, konfidas) and the policy and standards bodies (Eurosmart, OASIS, Trusted Connectivity Alliance). For procurement and integration teams trying to map who can evaluate what under which scheme, walking the exhibit floor at ICCC26 is probably the highest-bandwidth way to do that in person.

Practical notes for delegates

• Early-bird registration (via the official ICCC26 site) closes 18 August 2026. Saves EUR 380 on the 3-day pass (EUR 1,150 vs EUR 1,530) or EUR 490 on the 4-day pass that includes Action Plan Day (EUR 1,460 vs EUR 1,950).
• Refund window closes 8 September 2026; cancellations after that date are non-refundable.
• Speaker slides are due to the organisers on 8 September. Speakers receive complimentary full conference registration.
• Session format is 30-minute talks (including Q&A) and 60-minute panels.
• Venue is Cardo Roma, in the southern EUR business district. Allow more travel time from the historic centre than the map suggests.
• Side meetings typically cluster around the welcome reception (Tuesday evening) and the lunches; the schedule does not formally allocate working-group time, so most bilateral conversations happen at the margins.

How NenkinTracker helps you see this

The schemes, labs, CABs, and vendors heading to Rome are the bodies generating the records we ingest every day. NenkinTracker indexes certificates across seven schemes (CCRA, EUCC, SESIP, PSA, ESA, EMVCo, MIFARE). Explore the tracker to follow products across these schemes.

If you are heading to ICCC26, useful pre-conference reading is a quick refresher on where each scheme stands now: the EUCC corpus, your home national scheme, and any vendor portfolios you follow. Those are the views the tracker is built around.

We will publish a follow-up after the conference with the program details that turned out to matter, the announcements that landed, and any structural changes to scheme practice worth flagging.

EUCC, the EU’s Common Criteria-based cybersecurity certification scheme, just crossed 30 published certificates. That milestone is worth pausing on. EUCC is the first scheme adopted under the EU Cybersecurity Act framework, and it represents the most ambitious attempt in years to coordinate Common Criteria certification across the Union under a single regulatory umbrella.

The first EUCC certificates could be delivered from 27 February 2025, when Member States, through their National Cybersecurity Certification Authorities (NCCAs), gained the operational mandate to issue. Just over fifteen months later, the public ENISA registry lists 30 published certificates. Congratulations to the scheme bodies, the labs, the conformity assessment bodies, and the vendors that got it to that mark.

What 30 certificates says about scheme maturity

Thirty certificates in fifteen months is a respectable pace for a new CC scheme. New national CC schemes have historically taken years to move from regulatory approval to a steady issuance cadence; the EUCC’s combination of an existing Common Criteria methodology, a pan-EU mandate, and Member State certification bodies that were already accredited under SOG-IS gave it a faster runway than a green-field scheme would have had.

The pace also matters as a credibility signal. Procurement teams, integrators, and security-policy authors all need to know whether a new certification framework is going to become a real publishing surface or a regulatory framework that ends up sitting unused. Thirty certificates is enough to say the framework is being used. Not yet enough to say it has displaced the existing schemes, but enough that downstream policy decisions (EU Cyber Resilience Act references, sector-specific procurement guidelines, vertical accreditation programmes) can start to lean on it.

The CAB landscape

Certificates have been issued by multiple conformity assessment bodies (CABs) operating across several Member States. That distribution matters because it confirms that EUCC is operating as designed: a pan-EU scheme run by national authorities, not a single body issuing in the name of the Union. Each CAB is accredited in its home Member State, supervised by that state’s NCCA, and free to compete on its own merits within the EUCC framework. Different vendors choose different CABs for reasons of geography, language, sector expertise, and existing relationships.

The variety also matters as a resilience story. A scheme that depends on a single CAB issuing everything is fragile. A scheme that has several CABs producing certificates, each operating under independent national oversight, can keep functioning if one of them pauses, restructures, or is taken offline for accreditation review.

What is being certified

Most early EUCC certifications fall into the categories that the wider Common Criteria community has been certifying for years: smart cards, secure microcontrollers, embedded platforms, and the toolchains that sit around them. That is exactly what one would expect from a scheme that inherits its lab and CAB base from the SOG-IS era: the bodies that were already accredited for smart-card and platform evaluations were the first to bring their accreditation across to the EUCC framework.

The interesting thing is what is starting to appear alongside those traditional categories. Recent EUCC entries include IoT-class systems certified at lower assurance levels, and a small but growing share of certificates from product categories that have not historically been a CC mainstay. EUCC is not category-bound: it supports the full EAL1 to EAL7 range and accepts product classes outside the traditional CC smart-card corpus. The presence of those non-traditional entries in the first 30 certificates is a signal that the scheme is being tested across the breadth of its remit, not just at its smart-card sweet spot.

The Common Criteria standard underneath

EUCC certificates issued from 2026 onward are largely based on CC:2022 Release 1 with the Common Evaluation Methodology CEM:2022. That is the current Common Criteria standard, and it matters that EUCC is using it. Schemes that lag the standard make it harder for vendors to plan multi-scheme certifications and for regulators to write down requirements that apply across schemes. EUCC adopting the current CC version from the start aligns it with the international corpus and reduces friction for vendors that want to certify the same product under multiple frameworks.

What it means for the wider CC ecosystem

The bigger point: EUCC is the first concrete deliverable of the EU Cybersecurity Act’s certification framework. The framework is intended to host other schemes too (cloud services, 5G network components, EU Digital Identity Wallets, eventually IoT) under a common regulatory umbrella. Whether those other schemes succeed depends partly on whether EUCC can demonstrate that the framework actually works in practice. Thirty certificates is the first real evidence that it does.

There is, of course, still work to do. Publishing practice across CC schemes still needs better coordination, which is the subject of a companion post on the silent EUCC portal reformat. The Substantial and High assurance labels are still being absorbed by procurement teams who have spent twenty years thinking in EAL packages. Cross-recognition with CCRA national schemes is still being worked out by individual Member States. None of that is settled at 30 certificates. But none of it could be settled at zero certificates either, and 30 is a meaningful start.

Congratulations to everyone who got it here. The next 30 will likely come faster.

How NenkinTracker tracks EUCC

NenkinTracker indexes the full EUCC corpus under the EUCC scheme view. Every certificate is browsable with its CAB, issuance year, assurance level, Protection Profile claim (or lack of one), and the three core documents (the Certificate PDF, the Security Target, and the Certification Report). Direct links from each cert detail page lead back to the canonical ENISA registry entries.

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:

Old identifier (illustrative)	New identifier (illustrative)
EUCC-1234-2025-04-0042	EUCC-1234-2025-0000000042-00000
EUCC-5678-2026-03-0011	EUCC-5678-2026-0000000011-00000

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.

Today we added the App Defense Alliance (ADA) to NenkinTracker. ADA is the Google-led security certification program for Android apps, run by TrustCB B.V. as the certification body. It is the 8th scheme in our catalog, and the first new one since EUCC.

Around 220 active ADA certifications are now ingested. Roughly 76% are Google LLC apps under the MASA (Mobile App Security Assessment) track; the rest are third-party Android apps from vendors who have taken their products through ADA evaluation.

Two layouts in one scheme

ADA publishes under two different layouts on the source portal, and we ingest both:

• Standard ADA (52 certifications). A formal layout with Issuer, Security Profile, and Assurance Level AL2. The modern ADA certificate format.
• Legacy MASA (168 certifications). The lighter Mobile App Security Assessment that predates the formal ADA layout. No formal Issuer or Assurance Level, but the same Compliance Report PDF. Legacy MASA is still actively used today: Health Connect was issued under it in October 2025, and Chrome Canary in February 2026.

Both tracks land in NenkinTracker as real, current certifications. Legacy MASA certs carry a “Legacy MASA” badge in the UI, so you can tell the lighter track apart from a Standard ADA certificate at a glance.

In NenkinTracker today

• 220 new Android-app certifications added to the catalog
• 52 Standard ADA and 168 Legacy MASA, distinguished with a badge
• Both the Certificate PDF and the Compliance Report PDF are version-tracked under the same change-detection pipeline as every other scheme
• Notable products now tracked: Google ADS, Google Authenticator, Google Cloud Console, Android Device Policy, Chrome Canary, Health Connect, Nest, Waymo, Mercari, imo, plus around 200 more

The Certificate PDF for Standard ADA certs sits behind a JavaScript-gated button on the source portal, so a plain HTTP fetch lands on the portal shell rather than the file. We worked around that with a reverse-engineered Livewire flow. For users, the effect is simple: ADA certificate PDFs are now in your follow-the-product workflows and version-change notifications, the same way the other seven schemes already were.

Start a free NenkinTracker account to follow Android apps you care about, or browse the source catalog at cert.appdefensealliance.org.

See also

• SESIP vs Common Criteria: a useful frame for understanding ADA’s place among lighter, purpose-built assessment schemes.
• EUCC: What the EU Cybersecurity Certification Scheme Means for Common Criteria: the previous new scheme we added.

If your organization relies on Common Criteria or scheme-equivalent certifications in tenders, type approvals, or attestations, the next 12 months will be busy. Across the seven schemes we track, 432 certifications expire between 2026-05-06 and 2027-05-06, concentrated in a few vendors, a few peak months, and a single 2021 issuance cohort.

The headline number, by scheme

Scheme	Expiring 2026-05 to 2027-05
CCRA	410
MIFARE	15
SESIP	7
EUCC	0
PSA	0
ESA	0
EMVCo	0

CCRA carries 95 percent. MIFARE’s 15 are all NXP DESFire variants. EUCC’s zero is structural: the scheme entered into application in February 2025 and the first EUCC certificates were issued in April 2025, sitting on a five-year default, so volume does not start expiring until 2030. PSA and ESA use platform-version renewal rather than fixed expiry dates. See Beyond Common Criteria for how those schemes handle validity.

Mostly the 2021 cohort

The single most useful forecasting fact: 205 of the 432 expiring certificates (47 percent) were issued in calendar year 2021. The next-largest group is 2022 (92, 21 percent), with a long tail back to 2016. Most CCRA member schemes use a five-year validity window, so the wave is the 2021 issuance year coming due on schedule. If you procured a CC-evaluated product in 2021, assume its certificate is on this list unless you have checked.

Distribution by month

Expiry month	Count
2026-05	28
2026-06	33
2026-07	53
2026-08	31
2026-09	35
2026-10	34
2026-11	41
2026-12	63
2027-01	15
2027-02	22
2027-03	43
2027-04	34

Two peaks: July 2026 (53) and December 2026 (63). The December spike is partly a recent-issuance artifact: a cluster of Cisco networking certificates from 2024-25 all land on 2026-12-14. July is the cleaner read of the 2021 cohort. No quiet quarter: every month has at least 15 expirations.

EAL distribution of what is expiring

Package	Count
EAL1, EAL1+	3
EAL2, EAL2+	58
EAL3, EAL3+	27
EAL4, EAL4+	69
EAL5, EAL5+	64
EAL6+	29
EAL7	1
No EAL listed	181

“No EAL listed” is mostly NIAP-style PP-conformance certificates plus MIFARE and SESIP entries. Among EAL-bearing certificates, EAL4+ and EAL5+ together account for 133, consistent with the smart card and TPM mix in Common Criteria in 2026 So Far. EAL6+ carries 29 high-assurance secure-element expirations, mostly Infineon and Samsung. EAL7 has exactly one: Gemalto’s MultiApp V4 JavaCard Virtual Machine on 2027-04-22.

Top vendors by expiring-cert count

Expirations	Vendor
30	Cisco Systems
21	Infineon Technologies AG
19	Samsung Electronics
18	Huawei Technologies
17	STMicroelectronics
16	Thales DIS France
11	NXP Semiconductors (parent entity)
9	HP Inc.
9	Idemia
9	Kyocera Document Solutions

Cisco’s 30 stands out because its catalog is networking gear (firewalls, switches, routers), not the silicon-and-card volume driving most of the others. Teams running Cisco ASA 9.20, FTD 7.4, or Catalyst 9300/9400/9500/9600 in regulated environments should check whether they depend on the certified configuration. Combining NXP’s parent and subsidiary entries (Germany GmbH, Netherlands N.V.) lifts NXP to around 25.

Notable specific expiries

Worth flagging by name:

• Gemalto MultiApp V4 JavaCard Virtual Machine (CCRA, EAL7, 2027-04-22). The only EAL7 in the window.
• Infineon Security Controller IFX_CCI_000003h family on H13 (CCRA, EAL6+, 2026-08-04 and 2027-04-29). High-volume secure-element platform under payment and identity products.
• Samsung S3D350A / S3D300A / S3D264A series (CCRA, EAL6+, 2026-12-27). Smart card secure-element family with a broad composite footprint.
• NXP P6021y VB and P6022y VB Secure Smart Card Controllers (CCRA, EAL6+, both 2026-06-24). Platform under several Idemia ID-One Cosmo composites that also expire in this window.
• Cisco ASA 9.20 on Firepower 2100 / 4100 / 9300 and Catalyst 9300/9400/9500/9600 17.12 (multiple CCRA, late 2026). Most likely to surface in government and critical-infrastructure procurement language.

The Idemia / NXP case shows why cascading expiries matter: composites built on a platform must re-evaluate on the platform’s clock.

What procurement and compliance teams should do

The pattern is normal. The work is not optional.

1. Pull the certified products you rely on for tenders, attestations, or type approvals, and cross-check against this 12-month window.
2. For anything in the window, ask the vendor whether a successor is issued, in-evaluation, or planned, plus the expected date and lab.
3. Where a successor is already certified at equal or higher assurance, update product-acceptance lists now, not at the deadline.
4. For composites, check the platform certificate’s expiry separately. The composite cannot meaningfully outlive its platform.

NenkinTracker tracks expiry dates on every certificate and notifies you when successors publish.

To understand mutual recognition in IT security evaluations, it helps to go back to the very beginning. This entry is the historical companion to From SOG-IS to CCRA and EUCC: The New Landscape of Common Criteria Recognition, which focuses on where the ecosystem stands today.

Long before the term SOG-IS became widely used, European nations were already cooperating on the problem of evaluating and recognising trusted IT systems across borders. What later became the Senior Officials Group on Information Systems Security (SOG-IS) emerged during an era that predates Common Criteria, predates the internet as a workplace tool, and even predates email as a routine means of workplace communication by over a decade. Established as an advisory body to the European Commission, SOG-IS brought together security officials from European nations who were developing their own national IT security evaluation criteria for government use.

In those early years, countries such as the UK, France, Norway, Germany and the Netherlands (and others) had each built their own national frameworks for assessing the security of IT products. This led to an expensive and inconsistent situation that made cross-border procurement difficult. The practical solution was low-tech yet effective: member nations would certify products against their national criteria and circulate lists of certified products on paper.

As the group matured, the need for more harmonised criteria became apparent. This led to the development of ITSEC (Information Technology Security Evaluation Criteria), a European standard published in 1991 that attempted to unify the national frameworks. SOG-IS created a Mutual Recognition Agreement around ITSEC, which allowed certificates issued by one member scheme to be recognised by others. Today only version 2.0 of the SOG-IS MRA is available on the official website. The original SOG-IS MRA was practically identical, but only mentioned recognition based on ITSEC.

Although ITSEC never gained significant traction outside Europe, it established several foundational concepts that would later become central to Common Criteria: cross-border recognition, harmonised evaluation methodologies, evaluator cooperation, assurance levels, and trust relationships between national schemes. These ideas were carried forward into the Common Criteria Recognition Arrangement (CCRA), which was created in the late 1990s.

The CCRA marked a significant shift towards internationalisation, attempting to create a global recognition ecosystem spanning North America, Europe, and Asia-Pacific markets. This aligned well with the rapid internationalisation of the commercial IT industry during the late 1990s and early 2000s.

SOG-IS did not dissolve when the CCRA was created. Instead it continued as a parallel agreement maintained by its European members. The SOG-IS group eventually implemented an explicit technical domain structure that allowed mutual recognition up to EAL7 for certain product categories in 2010.

The modern EUCC framework represents the next major evolutionary step in this lineage: from national criteria, to European intergovernmental recognition, to global voluntary recognition, and now towards formalised regional cybersecurity regulation under EU law. The legacy of SOG-IS and ITSEC can be seen in the ongoing efforts to harmonise evaluation methodologies, promote cross-border recognition and establish trust relationships between national certification schemes.

This narrative arc highlights the evolution of mutual recognition from its humble beginnings in what became SOG-IS to the current global frameworks that govern IT security evaluations. By understanding the background for these agreements we can better appreciate the complexities and challenges involved in creating a unified system for evaluating the security of IT products.

It is still quite difficult.

Common Criteria certifications originate from many different schemes and regulatory ecosystems around the world.

Historically, developers, procurement authorities and integrators often treated “Common Criteria certified” as a relatively unified concept. In reality, the ecosystem has always consisted of multiple national schemes, overlapping recognition arrangements, different assurance philosophies and varying political objectives.

At Nenkin, one of our goals is to make this landscape easier to understand. Nenkin tracks cybersecurity certifications across multiple schemes and sources globally, helping users follow certifications, vulnerabilities, assurance claims, document changes and scheme activity in one place.

To understand the current transition from the Senior Officials Group Information Systems Security Mutual Recognition Agreement (SOG-IS MRA) to the EUCC, it is important to understand that the roots of European mutual recognition predate Common Criteria itself.

Before Common Criteria

Long before online certification portals, harmonised international standards and modern cybersecurity regulation, several European governments operated national IT security evaluation schemes using their own national criteria.

This was an era before email became routine workplace infrastructure. Certified product lists and evaluation information were exchanged physically between governments, often on paper. The ecosystem was small, government-centric and built largely around bilateral trust relationships between national security authorities.

The original Senior Officials Group Information Systems Security (SOG-IS) emerged from this environment as a European governmental cooperation forum focused on information assurance and security evaluation.

Over time, these nations recognised that duplicating expensive government evaluations across Europe created unnecessary inefficiencies. This led to early forms of mutual recognition built around the now-discontinued ITSEC criteria framework.

Although the ITSEC ecosystem never became globally dominant, it introduced many of the concepts that later became central to Common Criteria:

• assurance levels,
• harmonised methodologies,
• evaluator cooperation,
• technical peer confidence,
• and cross-border recognition of evaluation results.

When the Common Criteria Recognition Arrangement (CCRA) was established in 1999, many of these ideas were effectively internationalised. In many ways, the CCRA can be viewed as a global evolution of concepts first explored through European SOG-IS and ITSEC cooperation. For the detailed origin of the MRAs, read The Origin of Mutual Recognition: From SOG-IS to CCRA and EUCC.

For a period during the late 1990s and early 2000s, there was genuine optimism that Common Criteria could become a globally unified assurance language for commercial IT products.

Reality turned out to be more complicated.

Two Recognition Systems, One Increasingly Complex Ecosystem

For many years, Europe operated under two overlapping recognition arrangements:

• the global CCRA,
• and the European SOG-IS MRA.

Although they shared historical roots, they evolved in different directions.

The Global CCRA

The CCRA was designed as a global framework open to any participating nation willing to meet the required peer confidence obligations.

Its original ambition was broad mutual recognition of certificates up to EAL4.

That changed significantly with the 2014 revision of the arrangement:

• traditional Security Target-based evaluations effectively retained mutual recognition only up to EAL2,
• while broader recognition shifted toward collaborative Protection Profiles (cPPs),
• with ALC_FLR security patching assurance continuing to receive wider recognition.

The revised CCRA moved away from the earlier “recognise everything up to EAL4” philosophy and toward a more profile-centric assurance model.

The European SOG-IS MRA

At the same time, SOG-IS maintained a parallel European recognition structure.

Outside technical domains, SOG-IS recognised evaluations up to EAL4. Within technical domains such as smart cards and hardware security devices, recognition could extend to EAL7.

This created a layered recognition landscape:

• global recognition through CCRA,
• and deeper regional recognition through SOG-IS.

In practice, this became difficult for vendors, procurement authorities and even experienced practitioners to interpret consistently.

A product certified at EAL5 by a SOG-IS scheme might:

• carry only EAL2 recognition under CCRA,
• retain higher recognition only inside specific SOG-IS technical domains,
• and still lack mutual recognition of ALC_FLR security patching under SOG-IS itself.

The result was a recognition matrix that became increasingly difficult to understand.

The practical outcome was often that highly rigorous evaluations achieved little additional internationally recognised assurance value compared to substantially simpler evaluations.

At the same time, neither CCRA nor SOG-IS ever created automatic obligations for governments to accept products in procurement simply because they were mutually recognised.

That misunderstanding has persisted for years.

Mutual recognition did not automatically mean procurement acceptance, deployment approval or operational accreditation. Governments retained broad discretion based on procurement policy, national security considerations and sector-specific regulation.

The Hidden Complexity of the SOG-IS Era

The SOG-IS system also developed operational characteristics that increasingly frustrated both vendors and some participating schemes.

Technical domains became highly specialised communities with significant internal expertise, particularly around smart cards and hardware evaluations. While this improved technical depth, it also created barriers to transparency and market accessibility.

Admission into technical domains was slow, politically sensitive and heavily unanimous-driven. In practice, new entrants faced a difficult path toward full participation.

The ecosystem also relied on closed technical interpretation documents and evaluator guidance papers, including methodologies maintained within groups such as JHAS for smart card evaluations.

These documents were often unavailable not only to the public, but also to the end customers whose risks the evaluations were intended to address.

Over time, this contributed to a perception that parts of the recognition ecosystem had become increasingly opaque and difficult for outsiders to navigate.

At the same time, national interpretations of Common Criteria requirements gradually diverged between schemes. This weakened the predictability that mutual recognition was originally intended to provide.

Enter the EUCC

The EU Cybersecurity Act fundamentally changed the direction of European cybersecurity certification.

It mandated the European Union Agency for Cybersecurity to develop EU-wide cybersecurity certification schemes. The first major result was EUCC, adopted by the European Commission in 2024 and entering into force in 2025.

Structurally, EUCC is the successor to the SOG-IS era, but it differs in several important ways. For a deeper introduction to the scheme, see our earlier post on the EU Cybersecurity Certification Scheme.

EUCC Has Legal Standing

Unlike SOG-IS, which was always a voluntary intergovernmental arrangement, EUCC is an EU implementing regulation.

This is an important distinction.

EU member states are legally bound by it, and national certification schemes must transition into the EUCC framework. This represents a major governance shift, from voluntary recognition cooperation toward formal regulatory harmonisation.

EUCC Introduces Commercial Certification Bodies

Under SOG-IS, certification was mostly government-centric with only a few commercial CBs. The most known were set up in the United States, the Netherlands and Italy, while additional variants also exist.

Under EUCC, accredited commercial conformity assessment bodies can operate as ITSEFs (evaluation laboratories) and Certification Bodies (CBs).

These bodies operate under:

• ISO/IEC 17025 accreditation for laboratories,
• ISO/IEC 17065 accreditation for certification bodies,
• with supervision by national cybersecurity certification authorities (NCCAs).

For the High assurance level, additional NCCA authorisation is required.

This introduces significantly greater scalability into the European certification ecosystem if implemented effectively. We have written more about how this separation works in CAB and Lab Independence in Common Criteria.

EUCC Simplifies Recognition

Rather than using the traditional EAL1 to EAL7 recognition structure directly, EUCC introduces the assurance levels:

• Substantial
• High

The fragmented recognition matrix that characterised the CCRA and SOG-IS overlap is largely replaced with a single EU-wide recognition model.

The old questions:

“Which arrangement recognises this level?”

“Does this apply inside or outside technical domains?”

“Is ALC_FLR recognised?”

become far less central under EUCC.

The New Complication: EUCC and CCRA Coexistence

The transition, however, is not entirely seamless.

The CCRA and EUCC are built on somewhat different trust models.

Historically, CCRA recognition depended on certification schemes designed and set up by the individual member state, peer assessments and direct intergovernmental trust relationships developed over decades.

EUCC introduces commercial certification bodies operating under accreditation and regulatory supervision rather than direct government issuance of certificates.

From the CCRA perspective, this introduces a perceived structural trust gap.

This issue is formally acknowledged in the CCRA Management Committee document concerning CCRA and EUCC coexistence published in 2025.

The solution proposed is pragmatic, but follows already established CCRA practices used by several CCRA members. EUCC certificates may optionally carry the CCRA mark if additional government oversight is applied by the NCCA on a per-certificate basis.

Under this model the NCCA reviews the Security Target and assessment scope, reviews technical reporting before approval and ultimately authorises use of the CCRA recognition mark.

Importantly, the EUCC certificate itself remains valid even if the CCRA mark is withheld.

This creates a layered coexistence model rather than a direct merger between the two systems. We unpack more of this overlap in our Common Criteria vs EUCC migration guide.

What This Means for Vendors and Procurement Authorities

For developers and vendors, EUCC offers a significantly clearer path to EU-wide recognition than the old SOG-IS patchwork.

The replacement of closed interpretation communities with published state-of-the-art documents improves transparency, even if the resulting framework remains highly technical.

The introduction of commercial CBs should also gradually improve evaluation capacity and reduce bottlenecks.

Whether to additionally pursue CCRA recognition becomes a strategic decision:

• products targeting primarily EU regulatory environments may rely solely on EUCC,
• while products targeting broader international markets may still benefit from CCRA recognition.

For procurement authorities, the situation is improved, but not fully simplified.

An EUCC High certificate supervised by an NCCA represents a substantially different assurance proposition than the fragmented recognition arrangements of the past.

At the same time, the old reality still applies: mutual recognition does not automatically create procurement obligations.

That remains a matter of policy, regulation and operational risk acceptance outside the certification schemes themselves.

A More Mature View of Mutual Recognition

Earlier debates around Common Criteria recognition often became polarised: either mutual recognition was portrayed as highly effective, or as fundamentally broken.

Reality has always been more nuanced.

Mutual recognition operates simultaneously on several levels:

Layer	What it actually enables
Political	Confidence building between governments
Technical	Re-use of assurance evidence
Commercial	Reduced duplication for vendors
Regulatory	Support for market access
Procurement	Sometimes relevant, but never automatic

The core issue historically was not that mutual recognition accomplished nothing.

Rather, the expectations surrounding recognition often exceeded what the arrangements themselves were ever designed to guarantee.

The Road Ahead

The transition from SOG-IS to EUCC represents more than an administrative change.

It reflects a broader evolution in how cybersecurity assurance is governed: from relatively informal intergovernmental cooperation toward formal regulatory ecosystems tied directly to digital market regulation.

At the same time, the CCRA continues serving an important role as a global interoperability and coordination framework. Neither system fully replaces the other.

The long-term trajectory now appears to be either gradual convergence or long-term structured coexistence between:

• the EU regulatory certification ecosystem,
• and the broader global CCRA framework.

Whether that eventually evolves into a fully unified international recognition model remains uncertain.

What is already clear, however, is that understanding the governance structure behind a certificate is becoming just as important as understanding the technical evaluation itself.

And that is exactly the kind of complexity Nenkin is built to help navigate.