Blog

The significance of independence in certification ecosystems

As cybersecurity landscapes continue to evolve, assurance mechanisms like Common Criteria (CC) and EUCC certifications have become vital components of procurement and deployment strategies for integrators, certification bodies, evaluators, regulators, and procurement professionals alike. The evaluation laboratory (ITSEF) and the certification body (CB) are critical entities within these ecosystems. This article delves into the importance of independence between these two entities, analyzing governance, assurance confidence, market trust, and risk management.

Section 1: Why independence between lab and certification body matters

The CC scheme defines distinct roles for ITSEF and CB:

• ITSEF: Responsible for conducting technical evaluations to determine whether a product meets the security requirements specified in the Protection Profile (PP) or Security Target (ST).
• CB: Verifies that the evaluation was performed correctly, ensures the ITSEF’s independence, and confirms that the certified product meets the relevant security requirements.

Independence between lab and CB is crucial for several reasons:

1. Trust: Independent review functions increase trust in the certification process. When a single entity performs both evaluations, it may create concerns about impartiality.
2. Impartiality: The CB’s role is to ensure that the ITSEF remains impartial and unbiased throughout the evaluation process.
3. Challenge mechanisms: Independence enables challenge mechanisms, allowing third parties to scrutinize certification decisions.

Commercial pressure and governance concentration can affect confidence in certification ecosystems:

• When a single entity controls both lab and CB functions, it may lead to conflicts of interest or biased evaluations.
• Concentration of governance can compromise the independence of evaluation processes.

Perception of independence also matters in conformity assessment ecosystems. Although not all assurance levels require identical levels of separation, EUCC Substantial (EAL1 to EAL3) and EUCC High (EAL4 to EAL7) assurance groupings have different characteristics:

EUCC Substantial / EAL1-EAL3

• Evaluation depth: Shallow
• Evaluator judgment involved: Moderate
• Governance and independence concerns: Low to moderate
• Risk tolerance: High

EUCC High / EAL4-EAL7

• Evaluation depth: Deep
• Evaluator judgment involved: High
• Governance and independence concerns: Moderate to high
• Risk tolerance: Low to moderate

For integrators and procurement organizations, performing an ISO 31000-style risk assessment is essential when relying on certifications with combined lab/CB structures.

Section 2: Performing a risk assessment

To perform a risk assessment, follow these steps:

1. Context establishment: Establish the context for the certification, including the deployment criticality and threat environment.
2. Risk identification: Identify potential risks associated with the combined lab/CB structure, such as biased evaluations or compromised independence.
3. Risk analysis: Analyze the likelihood and impact of each identified risk.
4. Risk evaluation: Evaluate the overall level of risk based on the analysis.
5. Risk treatment: Implement mitigations to reduce the overall level of risk.

Governance structure is just one contextual risk factor among many. Do not assume that combined lab/CB structures are automatically invalid or non-compliant. Instead, consider the acceptability of governance structures based on deployment criticality and threat environment.

Mitigations

• Independent penetration testing
• Supplier governance review
• Additional technical review
• Compensating architectural controls
• Procurement documentation of residual risk acceptance

To illustrate these concepts, consider the following table comparing lower and higher assurance considerations:

Assurance level	Governance concerns	Risk tolerance
EUCC Substantial (EAL1-EAL3)	Low to moderate	High
EUCC High (EAL4-EAL7)	Moderate to high	Low to moderate

A practical risk matrix can be used to show suggested governance concern levels based on assurance level and operational criticality:

Assurance level	Operational criticality	Governance concerns
EUCC Substantial (EAL1-EAL3)	High	High to Moderate
EUCC Substantial (EAL1-EAL3)	Moderate	Moderate to high
EUCC Substantial (EAL1-EAL3)	Low	Moderate to Low
EUCC High (EAL4-EAL7)	High	Very High
EUCC High (EAL4-EAL7)	Moderate	High

In conclusion, certification assurance is partly technical and partly institutional. As EUCC adoption matures, governance models will become increasingly important. Higher assurance environments may justify stronger scrutiny and compensating controls. ISO 31000-style proportional risk management provides a rational framework for making these decisions.

This article demonstrates the importance of independence between evaluation laboratories (ITSEF) and certification bodies (CB). By analyzing governance, assurance confidence, market trust, and risk management, integrators, procurement organizations, and regulators can make informed decisions about certification reliance.

How NenkinTracker helps you see the structure

NenkinTracker records the issuing scheme and, where published, the evaluation lab for every Common Criteria certificate we ingest. That makes it straightforward to filter or compare certificates by the combination of CAB and lab, which is useful when you want to understand the structural backing behind a certificate, not just its EAL number. Explore the tracker to review certificates. For background on the schemes, see the EUCC guide and BSI guide.

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

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

The product, briefly

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

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

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

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

Segment	Value	Meaning
Scheme	EUCC	The certification scheme
Issuing body	3095	Numeric code for the issuing certification body (here, DEKRA Spain)
Year	2026	Calendar year of issuance
Sequence	01	First certificate from this body in this year
Language	EN	Language of the certificate document (English)

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

The two roles: NCCA and CAB

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

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

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

The assurance level: EAL1, AVA_VAN.1

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

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

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

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

The Common Criteria version

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

Validity period: 5 years

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

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

The document set

A full EUCC certificate publishes three main documents:

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

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

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

Protection Profile

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

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

What is distinctive about this versus a CCRA certificate

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

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

Where to find more

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

April 2026 was a quiet-to-moderate month in Common Criteria and adjacent schemes. We logged 31 new certifications across five of the seven schemes we track, dominated as usual by smart card and chip work on the CCRA side, with a small but interesting trickle on EUCC and growing PSA Certified activity in the IoT space. This is the first of what will become a monthly recap series. The intent is to make it easier to see the certification landscape in motion, instead of as a static catalog.

Five-year context

A single month is too short a window to read a trend, especially with monthly N in the low tens for most schemes. To anchor April 2026 against history, here is the same month in each of the previous four years, and the year-to-date through end-of-April for each year.

Two things to read out of these. One, April 2026’s CCRA cadence (19) is the slowest April in the five-year window, but that follows a February pull-forward of 124 issuances, so the year is still ahead on aggregate. Two, EUCC and ESA have transitioned from “essentially zero” to meaningful flow over 2025-2026, consistent with the broader regulatory shift in the EU. With the cadence still in low double digits per scheme, individual months will swing 50 percent or more on publication clustering alone, so one slow April should not be over-read.

The numbers

Scheme	April issuances
CCRA	19
ESA	5
PSA	4
EUCC	2
SESIP	1
MIFARE	0
EMVCo	0

Top vendors by April cert count: STMicroelectronics (9), Nuvoton Technology (4), Samsung Electronics (2). Most of the rest were one-shots from a long tail of vendors.

What dominated: smart card silicon at high assurance

The biggest single thread in April was secure-element and cryptographic-library work from STMicroelectronics, with five separate CCRA certifications around the NesLib cryptographic library family on ST31N600 and ST33K1M5 series chips (EAL5+, ALC_DVS.2, ALC_FLR.2, AVA_VAN.5). Two more STMicro entries covered the ST33J2M0 secure element with the same EAL5+ profile. Samsung Electronics shipped two CCRA certifications for the S3FT9MH and S3FT9MF chip families at EAL5+ with the augmented SAR set typical for smart card products.

This is the bread and butter of CCRA: chip and crypto-library certifications at EAL5+ with augmented vulnerability analysis (AVA_VAN.5), used downstream by anyone building payment cards, eIDs, passports, or eUICCs.

TPM activity from Nuvoton

Nuvoton Technology contributed four certifications for the NPCT7xx TPM 2.0 family, all at EAL4+ with ALC_DVS.2, ALC_FLR.1, and AVA_VAN.4. These are configuration-version variants (1.1.5.5, 1.3.5.5, 1.4.5.5, 1.5.5.5) of the same underlying TPM, recertified separately. EAL4+ is the typical landing spot for TPM modules: high enough to be procurement-credible, low enough to be commercially practical at volume.

Two EUCC issuances worth flagging

EUCC remains a slow ramp. April delivered two new certificates, both worth a closer look:

• Kernkonzept GmbH, L4Re Secure Separation Kernel CC 1.0.2 (EUCC-3087-2026-04-0003, issued 2026-04-16). A secure separation kernel is a security-critical primitive for partitioned systems; an EUCC issuance for one is a useful data point for anyone tracking high-assurance OS components in the EU framework.
• DISTROMEL, S.A., Distromel Waste Container Identification System (EUCC-3095-2026-01, issued 2026-04-28). A Spanish vendor of waste-management infrastructure took an EUCC cert for an IoT product. Less typical for the scheme. We have written a separate walkthrough of this certificate in Anatomy of an EUCC Certificate.

Combined, EUCC year-to-date sits at 12 issuances. The scheme is real and operational, but the volume is still an order of magnitude below CCRA.

PSA, ESA, and the rest

PSA Certified continues its quiet but steady IoT-focused output: four April certifications including Safetrust (IoT sensor), MAKSA LTD (MKC44 series), GigaDevice (GD32F5HC microcontroller series), and Globaltronics (GE101/GE301 smart electricity meter family).

ESA contributed five certifications, all from Chinese semiconductor vendors (Eastcompeace EPT 3371U, Beijing Huahong HHSGG1620I, Withheld vendor, CEC Huada CIU98M50, Megahunt MH1701). ESA is GSMA’s eUICC Security Assurance scheme; April’s batch came from Chinese eUICC silicon vendors.

CCRA also picked up a few notable non-chip entries this month: Belkin KVM switches (F1DN102KVM family), Juniper SRX300/320/340/345/etc. on Junos OS 24.4R1, an HPE Juniper QFX5120-48YM switch, RathonTech’s Rathon-SSO single sign-on, and Cogito Group’s Jellyfish Certificate Authority v7.0.

On the maintenance side

Beyond fresh issuances, April also brought five reviewed post-issuance document changes across the schemes we monitor. We covered the spectrum of what those look like in a separate post: see What Actually Changes After a Product Is Certified. Highlights this month included a Security Target update referencing a NIT technical decision (TD0990 around CTR_DRBG), a clarification on page 13 of a certification report concerning IC delivery, and a guidance-document addition for an evaluated cryptographic library.

Year so far in one paragraph

Through 4 May 2026, our catalog records 243 certifications issued in calendar year 2026, distributed: CCRA 182, PSA 28, ESA 14, EUCC 12, SESIP 6, MIFARE 1. The monthly cadence has not been smooth: January saw 64, February jumped to 124 (a publication cluster on the CCRA portal), March dropped to 22, and April recovered to 31. The spike seen in February was also likely influenced by the sunset of the European national certification schemes as EUCC began taking over under the EU Cybersecurity Act. We will dig into the year-to-date numbers more carefully in Common Criteria in 2026 So Far.

What we are watching in May

A handful of things on our radar going into May:

• Whether the CCRA February-publication pattern repeats, or whether March-April’s slower pace becomes the new baseline
• EUCC issuance velocity: 12 in four months is not enough to read a trend
• Any first MIFARE certifications of 2026 (just one issuance YTD, against an installed base of 111 catalogued)
• Movement on EAL6+ and EAL7 work, which has been thin so far this year (10 and 3 respectively across all of 2026)

Four months into 2026, the certification picture is clear enough to draw some conclusions. We are tracking 243 new certifications issued between 1 January and 4 May 2026, across the seven schemes we monitor. This post breaks them down by scheme, month, EAL package, and vendor, and notes a few patterns that are worth flagging.

Volume by month: not as steady as you might expect

Month	Issuances
January	64
February	124
March	22
April	31
May (through 4 May)	2

February dwarfed every other month. The cluster was driven primarily by the CCRA portal publishing a large batch of certifications dated within a tight window: the issuance dates are spread, but the publication cycle is bursty. This is a known characteristic of the CCRA workflow. Subsequent months returned to a more typical 20-30 issuances per month range.

The takeaway for anyone trying to read CC-issuance trend data: do not over-fit to a single month. The publication cadence introduces noise that the underlying evaluation pipeline does not.

Volume by scheme

Scheme	YTD issuances	Catalog total
CCRA	182	1,888
PSA	28	267
ESA	14	58
EUCC	12	29
SESIP	6	91
MIFARE	1	111
EMVCo	0	0

CCRA carries 75 percent of YTD volume, consistent with its catalog dominance. PSA Certified’s 28 issuances represent a continued steady pace from the IoT platform side. EUCC’s 12 issuances doubled its catalog in four months, but the absolute number remains small enough that it is too early to call EUCC “operational at scale.” SESIP at 6 is slower than its catalog history would imply.

EAL distribution

Of the 243 YTD certifications, the EAL package distribution is:

Package	Count
EAL1	2
EAL2	14
EAL2+	10
EAL3+	10
EAL4	2
EAL4+	39
EAL5	4
EAL5+	48
EAL6+	10
EAL7	2
EAL7+	1
No EAL listed	101

A few observations:

• The largest single bucket is “no EAL listed” (101). This is mostly PSA Certified, SESIP, and ESA entries, where the assurance language is scheme-specific rather than a CC EAL package. NIAP-style PP-conformance evaluations on CCRA also land here when the certificate does not declare an EAL.
• Among CC-style EAL packages, EAL5+ is the most common landing spot (48 issuances), followed closely by EAL4+ (39). This reflects the smart card and TPM-heavy mix of CCRA work.
• EAL6+ shows up 10 times YTD, mostly in high-assurance secure-element and cryptographic-library work. EAL7 and EAL7+ together: just 3 issuances. This is normal; EAL7 evaluations are rare every year.

Top vendors year to date

Issuances	Vendor
14	STMicroelectronics
14	THALES DIS FRANCE SA
12	NXP Semiconductors Germany GmbH
10	Samsung Electronics Co. Ltd.
10	Infineon Technologies AG
8	KYOCERA Document Solutions Inc.
7	Nuvoton Technology
7	Novatek Microelectronics Corporation
5	NXP Semiconductors Netherlands N.V.
5	IN SMART IDENTITY FRANCE

The top of the list is exactly what you would expect: the major secure-element and chip vendors, with Thales DIS France there for ID, payment, and eUICC product work, and Kyocera there for printer (HCD) certifications. Note that NXP appears as two distinct vendor entries (Germany GmbH and Netherlands N.V.), which together account for 17 issuances and would top the list if combined.

The YTD ranking is broadly consistent with the all-time ranking: STMicro (138 all-time), NXP Semiconductors (112), Infineon (104), Samsung (103), Thales (100). The same five vendors have produced more than 25 percent of all 2,444 catalogued certifications.

What the data is telling us

A few patterns worth pulling out:

• CC remains a chip-and-card industry first, everything else second. The top vendors, the most common EAL packages, and the dominant Protection Profiles all point to the same conclusion: silicon and smart card products are the modal CC certificate. General-purpose IT (network devices, OS, applications) is a real but smaller share.
• EUCC is real but small. 12 issuances in four months is enough to confirm the scheme is operating end to end (NCCAs, CABs, ENISA registry, document publication), but not enough to draw any quantitative conclusion about adoption pace yet. Worth watching.
• The non-CC schemes are not exotica. PSA’s 28 YTD and ESA’s 14 add real volume. SESIP, MIFARE, and EMVCo round out a landscape that anyone building or procuring connected products should be aware of. We have a separate wiki entry on these in Beyond Common Criteria: SESIP, PSA, ESA, EMVCo, and MIFARE.
• Publication cadence is not evaluation cadence. February’s 124-issuance spike does not mean the labs got 4x faster; it means the portal flushed a backlog. Treat monthly counts as noisy.

What we will be looking for next

We will publish a six-month checkpoint after June, with an extra column once May and June close. The interesting questions for that next post:

• Does the February pattern repeat (mid-year publication burst), or has it already happened for 2026?
• Does EUCC pass 25 issuances in a single half-year for the first time?
• Does any single vendor cross 25 YTD on its own?

There are 267 distinct Protection Profiles referenced by certificates in our catalogue. The distribution is heavily concentrated: a handful of PPs account for the bulk of certified products, and a long tail covers everything else. This post walks through the top of that distribution, what each PP is for, and what procurement teams can take from it.

The top 15 by product count

Rank	Products	Protection Profile
1	289	SECURITY_IC_AUGP_V1.0
2	156	PP_HCD_V1.0
3	56	CPP_ND_V2.2E
4	55	MRTD_ICAO_BA_V1.10
5	35	EPASS_PACE_V1.0,MRTD_ICAO_EAC_V1.3
6	31	TPM 2021 02
7	30	PP_HCD_EAL2_V1.0
8	26	BSI-PP-0099-V2
9	24	SGP.25 Embedded UICC for Consumer Devices Protection Profile v1.0
10	22	PP_SSCD_PART2..PART5 (composite)
11	21	SGP.25 Embedded UICC for Consumer Devices Protection Profile v2.1
12	19	SMARTMETERGATEWAYPP_V1.3
13	19	CPP_HCD_V1.0E
14	19	JAVA_OC
15	19	MRTD_ICAO_EAC_V1.3

Smart card ICs dominate (and it is not close)

The single most-used PP in the catalogue is SECURITY_IC_AUGP_V1.0, the Security IC Platform Protection Profile with Augmentation Packages, issued by Eurosmart and certified by BSI as BSI-CC-PP-0084, with 289 conforming products. Add the Java Card open-configuration profiles BSI-PP-0099-V2 (26 products) and JAVA_OC (19 products), which sit on top of the same security IC platforms, and the smart card silicon and Java Card family alone accounts for over 330 products.

Why is this PP so dominant? Two reasons:

1. The PP fits a real product category exactly. Every secure element, eID chip, payment IC, and eSIM controller fits the same threat model: physical attacker with side-channel and fault-injection capabilities, evaluating against AVA_VAN.5. The PP encodes that threat model, and the chip vendors all certify against it.
2. The chip vendors certify a lot. STMicro, NXP, Infineon, Samsung, and Nuvoton between them produce dozens of certified chip variants per year. Each one consumes a fresh certification, but they all conform to the same PP.

If you are evaluating a payment card, a passport, or an eSIM, you will end up reading SECURITY_IC_AUGP and its successors many times.

Printers and multi-function devices: the HCD family

Hardcopy Device (HCD) Protection Profiles cover printers, scanners, and multi-function devices. We see three variants in the top 15:

• PP_HCD_V1.0 (156 products): the 2015 Hardcopy Device PP developed jointly by IPA (Japan) and NIAP (United States), aligned with the IEEE 2600 series
• PP_HCD_EAL2_V1.0 (30 products): an EAL2 variant
• CPP_HCD_V1.0E (19 products): the collaborative Protection Profile (cPP) for HCDs, produced by the HCD international Technical Community (HCD-iTC)

Combined, the HCD family covers more than 200 certified products. This is mostly Kyocera, Ricoh, HP, and other major printer vendors certifying enterprise printer/copier lines for government and regulated procurement.

Network devices: NDcPP

CPP_ND_V2.2E (56 products) is the Network Device collaborative Protection Profile (NDcPP), the standard PP that NIAP and other NIAP-aligned schemes require for firewalls, VPN gateways, routers, and switches. Cisco, Juniper, HPE, and others certify their network gear against NDcPP variants. If you are buying enterprise networking equipment with a CC certification, this is overwhelmingly the PP you will encounter.

Travel documents and eIDs: the MRTD family

The ICAO Machine-Readable Travel Document family appears multiple times:

• MRTD_ICAO_BA_V1.10 (55 products): Basic Access Control variant
• EPASS_PACE_V1.0,MRTD_ICAO_EAC_V1.3 (35 products): Composite of PACE and Extended Access Control
• MRTD_ICAO_EAC_V1.3 (19 products): EAC standalone

Together over 100 products. This is the worldwide passport, eID, and electronic travel document chip ecosystem, certified primarily under the BSI scheme.

TPMs

TPM 2021 02 (31 products) is the TCG’s TPM 2.0 Protection Profile from February 2021. It covers Trusted Platform Modules used in PCs, servers, and embedded systems. Nuvoton, Infineon, STMicro, and ST33-family chips dominate the certifications here.

Embedded UICCs (eSIMs)

The two SGP.25 Embedded UICC entries (v1.0: 24 products; v2.1: 21 products) cover eSIM platforms for consumer devices: phones, watches, and similar. The PP family is governed by GSMA. The split between v1.0 and v2.1 in the data reflects a generational transition that is still in progress.

Smart meters

SMARTMETERGATEWAYPP_V1.3 (19 products) is BSI’s Smart Meter Gateway PP, used for German smart-meter infrastructure. A vertical PP for a regulated national procurement context, with a tightly defined product class.

Signature creation devices

PP_SSCD_PART2..PART5 (22 products) is the composite Secure Signature Creation Device PP set, used by qualified signature creation devices under EU eIDAS regulations.

What this distribution means for procurement

Three practical takeaways:

1. A small number of PPs cover the products you actually buy. If you procure smart cards, printers, network devices, travel documents, TPMs, eSIMs, smart meters, or signature creation devices, you can specify the relevant PP by name. There is no need to write your own security requirements: the PPs are vendor-independent and well-tested.
2. PP conformance is a tighter spec than EAL alone. “EAL4+ certified” can mean many things. “Conformant to NDcPP v2.2E at EAL4+” specifies what was actually evaluated. For procurement language, prefer the latter.
3. Outside the top 15, PPs are very specific. The long tail (over 250 PPs with fewer than 19 products each) is mostly very narrow product categories: specific national PPs, niche industry PPs, or older PPs being phased out. If you need a PP for a less common category, the long tail is where you look.

Where to find them

To compare certified products, explore NenkinTracker and review the Protection Profile claims in their certification records.

There is a common assumption baked into how the security industry talks about certified products: a certificate is the end of the story. The evaluator signs off, the certifying body issues the document, the vendor updates a marketing page, and from that point onward the product is “certified.” Done.

In practice, the documents that back a certification continue to move after the cert is issued. We know this because we monitor those documents. NenkinTracker continuously ingests certification artifacts from seven schemes (SESIP, CCRA, EUCC, EMVCo, PSA, ESA, MIFARE), hashes every PDF version we see, and records when a document changes after it was first published. Below is what that has actually looked like since we started watching.

The full spectrum, from cosmetic to consequential

Not every change is meaningful. A lot of what we see is noise:

PDF metadata only. A new file is published, the SHA-256 differs from the previous version, but a careful diff shows that only the document properties or producer string changed. The content is identical. We flag these so they do not surprise anyone, then close them out.

Editorial corrections. A lab name spelled differently. A footer date adjusted. A typo in a heading. These are real changes to the document, and they would silently invalidate any internal hash you might be keeping yourself, but they do not change what was evaluated or what the product actually does.

In the middle of the spectrum, things get more interesting:

Clarifications to existing report content. An evaluator updates a paragraph that was previously ambiguous. For example, a section of a certification report can be rewritten to clarify exactly how the evaluated software is delivered to a downstream integrator. Nothing about the product changed; the description of what was already evaluated got more precise.

New supporting documents added to the evaluation set. A vendor publishes additional guidance, such as a coding-guidance document for an evaluated library, and the certification record is updated to reference it. The product is the same. The body of guidance a user is expected to follow grew.

Validity extensions, often bundled with other updates. A certificate’s expiry date moves out by a year. In the same publication, scheme documents and developer guidance are silently refreshed. The product remains certified, but the documentation surface around it is not the one a user studied at issuance.

And then there are the changes that matter most:

Substantive additions to the Security Target. An ST gets a new compliance claim against a NIT technical decision, with corresponding evaluator acknowledgement. The functional claims a buyer is relying on are not the same as they were on day one.

Updates that arguably warrant re-evaluation. A small number of changes that we have seen are large enough that we have asked, internally, whether the original evaluation envelope still covers what the document now describes. We do not adjudicate that question publicly. We do flag the change, classify it, and make sure it is visible to anyone who cares.

Why this matters

If your supply chain depends on a Common Criteria, EUCC, SESIP, or PSA certificate, the certificate is a snapshot. The documents behind it are a moving record. “What has changed since the cert was issued?” is a real question with a real answer, and in our experience the answer is rarely zero.

Since we started monitoring, we have catalogued 23 post-issuance document changes across the schemes we cover. The interesting part is not the total; it is that every band described above shows up in normal operation, in roughly the proportions you would expect from a system where post-issuance change is treated as routine but not always loudly announced.

What we do about it

For every document we track, we record the version, the hash, and a classification of how significant the change is. Followers of a product are notified when a new version is published. Material changes, the ones at the high end of the spectrum, are flagged for broader broadcast. Nothing about this is novel; the certifying bodies do publish their updates. It is just that nobody is sitting and watching all of them at once. We are.

If you operate a product that depends on a certified component, or you are a lab, or you are a regulator, and you want to know what is actually changing in the corpus you depend on, that is what we are for.

The EU Cybersecurity Certification scheme for Common Criteria, EUCC, is the EU’s first regulatory cybersecurity certification scheme adopted under the Cybersecurity Act. It uses Common Criteria (ISO/IEC 15408) as its evaluation methodology, but it sits inside the EU regulatory framework rather than the international voluntary CCRA arrangement. For EU member states, EUCC is the successor to SOG-IS for high-assurance Common Criteria certifications.

If you are a vendor with existing CCRA or SOG-IS certificates, or a buyer whose procurement framework references either, you need to plan for the transition. This guide walks through the key questions and what to do about each.

Note: Migration mechanics are still being refined by ENISA, the European Cybersecurity Certification Group, and the participating national certification authorities. Treat this guide as orientation; consult your scheme contact for the current operational details.

What is changing

The shift from SOG-IS or national CCRA certification to EUCC affects three layers:

1. The legal basis

• CCRA is a voluntary multilateral arrangement among national schemes, most recently revised in 2014. Membership is voluntary and certificates are recognised within stated assurance limits.
• EUCC is a voluntary regulatory scheme operated under the EU Cybersecurity Act (Regulation (EU) 2019/881) and Implementing Regulation (EU) 2024/482, since amended by Regulation (EU) 2024/3144 (December 2024) and Regulation (EU) 2025/2462 (December 2025). EU sectoral regulation can require EUCC certification as a legal prerequisite even though the scheme itself is voluntary.

The practical implication: an EUCC certificate carries regulatory weight inside the EU that a CCRA certificate alone does not.

2. The recognition perimeter

• SOG-IS provided mutual recognition for high-assurance evaluations among participating European nations. SOG-IS is winding down for EU member states as EUCC takes over.
• EUCC provides mutual recognition across EU member states under the Cybersecurity Act framework.
• CCRA continues as the international recognition arrangement for participating non-EU nations, plus Australia, New Zealand, Norway, and others. EU national schemes remain CCRA members; certificates issued under those schemes can carry both EUCC and CCRA recognition where applicable.

For a vendor, this means the geography of recognition changes: EU markets shift toward EUCC; non-EU markets continue under CCRA national schemes.

3. The operational rules

EUCC adds EU-specific procedures on top of standard Common Criteria for:

• Vulnerability handling: certificate holders have explicit obligations on vulnerability management and patch dissemination.
• Maintenance and conformity reporting: structured around EU regulatory cadence.
• Authority and supervision: national certification authorities operate under ENISA coordination and the European Cybersecurity Certification Group.

The underlying ISO/IEC 15408 evaluation methodology is unchanged. EUCC adds the regulatory wrapping; the technical work the lab performs is the same Common Criteria evaluation.

What stays the same

Many things do not change with the move to EUCC:

• The standard: ISO/IEC 15408 (Common Criteria) and ISO/IEC 18045 (CEM).
• The structure of evaluation evidence: Security Targets, Protection Profiles, Certification Reports, TOE descriptions.
• The role of the lab: accredited ITSEFs continue to perform the technical evaluation work.
• The role of the national authority: existing CCRA national authorities operate as national certification authorities under EUCC.
• The Common Criteria Portal: continues as a registry for international CCRA-recognised certifications. EUCC certificates have their own registry under ENISA.

For a vendor mid-evaluation, the framework label may change but the evaluation itself does not need to be redone from scratch.

Migration paths for existing certificates

There are three main scenarios. Treat the specific procedures here as guidance; the operative rules are set by ENISA and the national certification authorities and may evolve.

Scenario 1: Existing SOG-IS certificate

SOG-IS certificates are eligible for transition into EUCC under defined procedures. The vendor coordinates with the issuing national authority. The exact transition path depends on the certificate’s assurance level, the underlying Protection Profile, and the SOG-IS technical domain.

For high-assurance smart card and secure element certifications, an explicit transition mechanism exists so that SOG-IS recognition can flow into EUCC without a fresh evaluation, subject to the issuing authority’s review.

Scenario 2: Existing CCRA certificate from a non-EU scheme

A CCRA certificate issued by a non-EU scheme is not automatically an EUCC certificate. EU buyers that require EUCC will need an EUCC certificate; the existing CCRA certificate continues to support CCRA recognition in non-EU markets.

The path forward typically involves either a fresh EUCC evaluation through an EU national certification authority, or a structured re-recognition procedure where the underlying evaluation evidence is reused.

Scenario 3: Existing CCRA certificate from an EU national scheme

For EU national schemes that are also CCRA members (BSI, ANSSI, OCSI, and others), existing certificates may transition into EUCC under procedures defined by the issuing authority. The certificate continues to be valid in non-EU CCRA markets and gains EUCC recognition for EU regulatory contexts.

The migration mechanics are scheme-specific. The issuing scheme is the operative source of truth.

Decisions for vendors

If you sell into EU markets, three decisions need attention.

Decision 1: What is your target market mix?

• EU regulated procurement and EU sectoral compliance: EUCC will increasingly be a prerequisite. Plan for EUCC certification or transition.
• Non-EU government procurement and international markets: CCRA national-scheme certification continues to apply. Maintain those certifications.
• Both: A combined approach is normal. Budget for the dual-track work, and pick a primary scheme to anchor the work.

Decision 2: Which national certification authority leads?

EUCC certifications are issued by an EU national certification authority. The choice influences:

• Lab availability: some labs are accredited under specific national authorities.
• Familiarity with your product category: some authorities have deeper history in specific domains (smart cards, network devices, OS).
• Relationship and language: if you have an existing relationship with a CCRA national scheme that is also operating as a national certification authority under EUCC, continuity matters.

Decision 3: How do you handle vulnerability and maintenance obligations?

EUCC’s explicit obligations on vulnerability management and patch dissemination are a step up from typical CCRA practice. Vendors should confirm internally that the processes exist to meet those obligations: PSIRT capability, customer notification procedures, patch release tracking, and conformity reporting.

Decisions for buyers

If you are writing procurement requirements that touch Common Criteria, three things to check.

1. Does your sectoral regulation explicitly cite EUCC? If yes, EUCC certificates are required. CCRA-only certificates are not a substitute inside that regulatory framework.
2. Are you procuring from inside or outside the EU? EU-internal procurement is increasingly EUCC-aligned. Procurement from non-EU suppliers may rely on CCRA national-scheme certificates that gain EUCC recognition through transition procedures.
3. What is the validity horizon? Existing SOG-IS certificates remain in force during the transition window. Procurement should accept SOG-IS-era certificates with active SOG-IS recognition while the EUCC transition completes; reject those whose recognition has lapsed.

Watching the transition

The EUCC transition is moving in stages. Vendors and buyers should watch for:

• ENISA publications on operational rules, transition procedures, and EUCC registry.
• National certification authority guidance on per-domain transition (smart card, network devices, etc.).
• EU sectoral regulation updates that cite EUCC as a compliance route, particularly for radio equipment, NIS2-relevant products, and AI Act-relevant components.

NenkinTracker tracks both EUCC and CCRA certifications, links related certificates across schemes where the link is published, and helps you follow changes across both frameworks. Explore the tracker.

You have a vendor proposal in front of you. The vendor has attached a Common Criteria certificate. You need to decide whether the certificate actually says what the vendor implies it says. This guide walks through the parts of a Common Criteria certificate, what each part means, and the small handful of checks that catch the majority of misinterpretations.

The certificate is a pointer, not the evidence

The first thing to internalise: the certificate document is a one-page or two-page summary. It is not the full evaluation. The real content lives in three accompanying documents:

• The Security Target (ST), which defines exactly what was evaluated.
• The Certification Report, which summarises what the lab did and confirms the result.
• Any maintenance reports issued after the original certificate.

If you read only the certificate page and skip the ST and the certification report, you cannot tell what the certificate actually covers. The certificate page exists to give you a stable identifier that points at those documents. Treat it as a pointer.

The parts of a typical certificate

Common Criteria certificates are issued by national scheme bodies and look slightly different from scheme to scheme, but they all carry the same core fields. Here is what to look at, in priority order.

1. Certificate identifier

A scheme-specific ID such as BSI-DSZ-CC-1234-2024, ANSSI-CC-2024/12, or an EUCC-format identifier. This is the canonical handle for the certificate. Use it to pull up the corresponding entry in the Common Criteria Portal, the issuing scheme’s registry, or NenkinTracker.

Check: the ID on the document the vendor handed you matches the entry in the official registry. ID typos and outright fabricated certificates have happened.

2. Issuing scheme

Which national scheme issued the certificate. BSI (Germany), ANSSI (France), NIAP (USA), JISEC (Japan), CCCS (Canada), OCSI (Italy), and others. The scheme determines which mutual-recognition arrangement applies to the certificate.

Check: if your procurement requires a specific scheme (for example, US federal procurement that requires NIAP), confirm the scheme matches.

3. Date of issue and validity period

When the certificate was issued and, in most cases, how long it remains valid. See our certificate validity reference for what happens when the period expires.

Check: the certificate is currently in force, taking into account any maintenance reports that may have extended assurance to a newer product version. An expired certificate is generally not acceptable as active evidence.

4. Target of Evaluation (TOE)

The most important field on the page. The TOE is the specific product, configuration, and version that was evaluated. The TOE is rarely identical to the entire product the vendor sells. A certificate for a network appliance might cover only one firmware revision running on one specific hardware model.

Check: the TOE description in the certificate matches the product version the vendor is offering you. This is the single most common source of certificate misinterpretation. A vendor selling firmware version 3.0 with a certificate for firmware version 2.4 is, strictly, selling an uncertified product.

5. Protection Profile conformance

Which Protection Profile (PP), if any, the evaluation conformed to. PP conformance is the most precise way to compare certified products in the same category.

Check: if your procurement requirements name a specific PP, confirm conformance to that PP and that the PP version on the certificate matches what your requirements specify.

6. Evaluation Assurance Level (EAL)

The EAL, often with a + sign indicating augmentation (for example, EAL4+). The EAL tells you how rigorously the evaluation was performed, not how secure the product is.

Check: the EAL meets your minimum requirement. If the certificate carries a +, look in the Security Target to see exactly which assurance components were augmented; not all EAL4+ evaluations are the same.

7. Vendor and developer

The vendor named on the certificate, sometimes split into a developer and a sponsor. The certificate is bound to this entity. A certificate issued to vendor A is not transferable to vendor B if vendor A’s product is acquired or relabelled, unless the new vendor goes through assurance-continuity procedures with the issuing scheme.

Check: the vendor on the certificate is the entity actually selling you the product.

The five checks that catch most problems

If you only have time for the short version, run these five checks every time:

1. Look up the certificate ID in the Common Criteria Portal or a structured database such as NenkinTracker’s certifications database. Confirm the certificate exists and is in the state the vendor claims.
2. Read the TOE description in the Security Target and confirm the version the vendor is selling falls inside the TOE boundary.
3. Confirm the certificate is active, not archived, withdrawn, or suspended.
4. Match the Protection Profile on the certificate against any PP requirement in your procurement.
5. Look for maintenance reports that extend assurance to newer product versions. If the base certificate is for an old version and there is no maintenance report covering the version you are buying, the evaluation does not cover what you are buying.

Common misreadings to avoid

• “EAL4 means it is more secure than EAL2.” It means the evaluation was more rigorous, not that the product is more secure. See our EAL guide for what the levels actually measure.
• “The certificate covers the entire product.” It covers the TOE described in the Security Target. Read the TOE description.
• “A certificate for firmware 1.0 covers firmware 2.0 because they are the same product.” Not unless a maintenance report explicitly extends assurance to 2.0.
• “This certificate was issued by an EU member state, so it is an EUCC certificate.” Pre-EUCC certificates issued under SOG-IS or directly under a national CCRA scheme are not EUCC certificates. See our EUCC vs CCRA reference.
• “The vendor has the CC logo on their marketing material, so the product is certified.” Marketing claims are not certificates. Look up the certificate.

Where to find the source documents

Every Common Criteria certificate is published by the issuing scheme together with the Security Target and the Certification Report. Most schemes also publish maintenance reports as separate documents.

• The Common Criteria Portal lists CCRA-recognised certifications.
• Each national scheme runs its own registry: BSI, ANSSI, NIAP, JISEC, CCCS, OCSI, and others.
• EUCC certificates are published through the EUCC registry under ENISA.
• NenkinTracker aggregates all of the above plus EUCC, SESIP, PSA Certified, EMVCo, ESA, and MIFARE into a single searchable database, archives the source documents, and tracks document version history.

If you build connected devices, certify chips, or write procurement requirements for IoT products, you have probably had to choose between SESIP and Common Criteria. The two methodologies look similar on paper. They share a lot of vocabulary. They produce certificates that can sit on the same shelf.

They are not interchangeable. They optimise for different deployment contexts, and choosing the wrong one means paying for assurance you do not need or claiming assurance you cannot defend.

The short version

• Common Criteria (ISO/IEC 15408) is the international standard for IT security evaluation. Designed for high-assurance products, government procurement, and complex IT systems. Evaluations are thorough, expensive, and slow.
• SESIP (Security Evaluation Standard for IoT Platforms) is GlobalPlatform’s evaluation methodology for connected device components. Designed for IoT scale: lighter-weight, faster, calibrated to typical IoT deployment threat models.

Both produce certificates. Both rely on accredited labs. Both define assurance levels. The difference is in what they are calibrated for: Common Criteria is calibrated for the worst-case threat models in government and high-stakes commercial markets; SESIP is calibrated for the much larger volume of consumer and industrial IoT products that need credible-but-proportionate security evidence.

Where each one fits

When Common Criteria is the right choice

• The product is going to government, defence, or regulated-sector procurement that requires CC certification.
• The product is a smart card, secure element, hardware security module, or other high-assurance component where EAL4+ with AVA_VAN.5 (or higher) is the established market norm.
• The threat model assumes capable, well-resourced attackers with physical access and substantial reverse-engineering capability.
• A relevant Protection Profile exists in the Common Criteria PP catalog.
• The procurement framework explicitly cites Common Criteria, EUCC, or a national CCRA scheme.

When SESIP is the right choice

• The product is an IoT chip, secure microcontroller, root of trust, or platform component, and the buyer is integrating it into a connected device.
• The threat model is bounded: remote attackers, casual physical attackers, supply-chain manipulation, but not nation-state physical attack.
• Time-to-market and evaluation cost matter, and a Common Criteria evaluation would take longer or cost more than the product economics support.
• The product is being evaluated as a building block that other products will compose with, and the buyer needs a clear, structured assurance claim without the overhead of a full CC evaluation.
• Industry frameworks for IoT security cite SESIP as an acceptable evaluation route, increasingly common, including in EU radio equipment regulation.

When you need both

It is not unusual for a single product to carry both certifications, or for a higher-level product to inherit one assurance regime through a component that carries the other. A smart card chip might be CC-certified at EAL5+ AVA_VAN.5, while a SESIP-certified IoT platform built around that chip cites the chip’s CC certificate as part of its own evidence.

How they actually differ

Assurance ladder

• Common Criteria uses Evaluation Assurance Levels EAL1 through EAL7. Most commercial products land at EAL2 or EAL4; smart cards and secure elements at EAL4+ to EAL6+.
• SESIP defines five levels (SESIP 1 to SESIP 5) calibrated to typical IoT deployment contexts. The top level, SESIP 5, is intended to be roughly equivalent to CC AVA_VAN.5-level resistance for the IoT context.

The levels are not directly equivalent and cross-mapping is approximate. SESIP 3 is, very roughly, comparable to a meaningful chunk of EAL4 in terms of evaluator activity, but the comparison breaks down quickly because the threat models differ.

Evaluation effort

A Common Criteria evaluation at EAL4+ with augmentation typically takes many months and substantial vendor effort: detailed design documentation, source code review, vulnerability analysis, penetration testing. The evaluator generates a comprehensive evidence package.

A SESIP evaluation at SESIP 1 or SESIP 2 is dramatically lighter. Higher SESIP levels approach CC-equivalent rigour for the specific IoT threat model but stay calibrated to faster cadence than CC.

Reuse and composition

SESIP was designed with composition in mind. A SESIP certificate explicitly states what assurance can be inherited by products that integrate the certified component. This is particularly valuable in IoT, where a final device often uses many certified components stacked together.

Common Criteria has its own composition mechanisms (composite evaluation, ETR for composition), but they are heavier-weight and tend to be used for tightly coupled hardware/software stacks like smart card OS on smart card chip.

Recognition

• CC certificates are recognised internationally under the CCRA within stated assurance limits, and within the EU under EUCC. See EUCC vs CCRA for the EU side.
• SESIP certificates are issued by accredited labs under the GlobalPlatform programme. Recognition is growing in IoT-specific frameworks but is not equivalent to the multilateral mutual recognition CCRA provides.

For a vendor selling internationally, that recognition gap matters. A CC certificate issued by one CCRA member can be cited in another with confidence; a SESIP certificate is increasingly accepted by IoT-specific frameworks but is not yet a substitute for CC where CC is required by procurement.

The decision in three questions

If you are picking between SESIP and Common Criteria for a new product or a procurement requirement, three questions usually settle it:

1. Does any regulation, sectoral framework, or buyer in your target market explicitly require Common Criteria, EUCC, or a national CCRA scheme certification? If yes, the answer is CC. SESIP can be additional evidence; it is not a substitute where CC is required.
2. Is the product a connected-device building block intended to be composed with other components, with the buyer integrating it into a final IoT device? If yes, SESIP is designed for exactly this case and is usually the right choice.
3. Does your threat model include capable physical attackers (smart card, payment terminal, root of trust)? If yes, CC at EAL4+ with AVA_VAN.5 (or the EUCC equivalent) is typically the floor.

If the answer to all three is no, you are probably looking at a commercial IoT or industrial product where SESIP offers a better cost-to-credibility ratio than CC.

How NenkinTracker treats both

NenkinTracker indexes SESIP, CCRA, EUCC, PSA Certified, EMVCo, ESA, and MIFARE certifications side by side. Products that hold certifications under multiple schemes appear with their certificates attached. Explore the tracker to search across schemes.

“What EAL do we need?” is one of the most common procurement questions in Common Criteria. It is also one of the most commonly answered backwards. Many procurement teams pick a number first and then look for products that meet it, when the right approach is to start with the threat environment, the regulatory requirements, and the available Protection Profiles, and let the EAL fall out of those constraints.

This post walks through the decision in the order it should actually be made.

Step 1: Be clear about what an EAL is

An Evaluation Assurance Level measures how rigorously a product was evaluated, not how secure it is. A simple product evaluated at EAL4 and a complex product evaluated at EAL2 may offer equivalent real-world security for their respective use cases.

That distinction matters because procurement teams sometimes treat EAL as a linear security score, leading to requirements like “must be EAL4 or higher” without considering whether a higher assurance level adds anything for the specific threat model.

For background on what each level requires, see our EAL reference and the EAL levels explained guide.

Step 2: Start from the regulatory requirement, if any

If your procurement is governed by a regulation, framework, or sector-specific scheme that names a specific EAL or Protection Profile, the decision is largely made for you.

• US federal procurement typically requires NIAP-certified products. NIAP requires conformance to a specific Protection Profile; the PP determines the assurance level rather than EAL being a free choice.
• EU government and EUCC-regulated procurement is increasingly aligned to EUCC. EUCC defines its own assurance levels mapped onto the EAL ladder; the regulation or sectoral framework citing EUCC will name the level.
• EU smart card and secure element markets historically demanded EAL4+ with augmentation such as AVA_VAN.5. This is migrating into the EUCC framework; see our EUCC vs CCRA reference.
• National defence procurement in CCRA member states often requires EAL4+ or higher under that nation’s scheme.
• Payment industry products typically require certifications under EMVCo and PCI in addition to or instead of CC.

If your procurement is bound by one of these frameworks, the rest of this guide is informational. The framework’s required EAL or PP is the answer.

Step 3: If you can choose, start with a Protection Profile

Outside regulated procurement, the best practice is to write requirements in terms of Protection Profile conformance, not EAL alone.

A PP describes what security functions a product in a given category should implement. It anchors the evaluation in a threat-relevant baseline rather than an arbitrary assurance level. “Conformant to NDcPP at EAL2” is more meaningful than “EAL4 certified” because the former says what was tested, not just how thoroughly.

If a Protection Profile exists for the category of product you are buying, search for products that conform to it. The PP already encodes the consensus on what assurance level is appropriate. Review the conformance claims in the certification records of candidate products. Explore the tracker to begin your search.

Step 4: If no PP applies, work back from threat severity

For categories without an applicable PP, the EAL question becomes: what level of evaluator effort do you need to trust the product?

A useful rough mapping, calibrated against current market practice:

Threat context	Typical EAL target
Commodity commercial IT, low-sensitivity data, public-facing services	EAL2
Enterprise infrastructure, business-critical data, internal admin tooling	EAL2 to EAL4
Regulated-sector infrastructure (health, finance, telecoms)	EAL4 or EAL4+
Government and defence non-classified	EAL4+ with augmentation
Smart cards, secure elements, payment terminals	EAL4+ with AVA_VAN.5, or higher
Government and defence classified, dedicated hardware roots of trust	EAL5 to EAL7

These are starting points, not rules. The right EAL depends on the threat environment, the regulatory regime, the product category, and the cost of failure.

Step 5: Understand what + means

A + after the EAL indicates augmentation. The base EAL is a standard package of assurance requirements; + means one or more additional assurance components were added on top.

Common augmentations include:

• AVA_VAN.5: enhanced vulnerability analysis. Required de facto for smart cards, secure elements, and HSMs in many markets.
• ALC_FLR.2 or ALC_FLR.3: flaw remediation procedures. Indicates the vendor has a defined process for handling security flaws found after certification.
• ALC_DVS.2: sufficiency of security measures during development. Used for products where supply-chain security matters.

EAL4+ is not a single thing. Two products labelled EAL4+ may have very different augmentations. Always look in the Security Target to see exactly which components were added.

Step 6: Avoid four common mistakes

These come up repeatedly in procurement reviews.

1. Specifying an EAL without a PP. “Must be EAL4 certified” is weaker than “must be conformant to PP-X at EAL2 or higher” because the EAL says nothing about what the product was tested to do. Specify the PP.
2. Asking for higher EAL “to be safe”. Higher EALs significantly increase evaluation cost and time. If the threat model does not require the additional assurance, the higher EAL adds expense without value, narrows the supplier pool, and slows procurement.
3. Treating CCRA recognition as universal. The CCRA recognises evaluations up to EAL2 across all members, and higher levels for specific collaborative Protection Profiles. EAL5 and above are typically recognised only within the issuing scheme. See EUCC vs CCRA for how this changes inside the EU.
4. Ignoring the TOE. A certificate covers a specific Target of Evaluation, not the entire product the vendor sells. A high EAL on a narrow TOE can be less meaningful than a lower EAL on a broader TOE. Read the Security Target.

Quick-reference decision flow

If you want a one-line summary:

1. Is your procurement governed by a regulation that names a level or PP? Use that.
2. Does an applicable Protection Profile exist? Specify PP conformance with the PP’s recommended EAL.
3. No PP, but high-assurance product category (smart card, HSM, secure element)? EAL4+ with AVA_VAN.5 is the typical baseline.
4. No PP, regulated-sector infrastructure? EAL4 or EAL4+.
5. No PP, general commercial IT? EAL2.
6. Defence or classified context? Talk to the relevant authority; standard answers do not apply.

How NenkinTracker helps

NenkinTracker lets you filter the Common Criteria certified product database by EAL, PP, scheme, and status, so you can shortlist products that match your decision quickly. Explore the tracker to compare certifications and build your shortlist.