Blog

The cryptography inside certified products is about to change in a way it has not since the move from single DES. Not because anything is broken today, but because the algorithms that protect long-lived data and devices are being replaced before a large quantum computer exists to break the old ones. The standards landed in 2024. The certificates have to follow.

This post is about that follow-on. What post-quantum cryptography (PQC) actually is at this point, how Common Criteria and EUCC handle cryptography, and what the transition means for the smart cards, secure elements, and security appliances that carry certificates.

The standards are no longer hypothetical

For years PQC was a NIST competition and a research topic. That phase is over. In August 2024 NIST published the first three finished standards:

• FIPS 203, ML-KEM: a key-encapsulation mechanism derived from CRYSTALS-Kyber, for establishing shared keys.
• FIPS 204, ML-DSA: a digital signature scheme derived from CRYSTALS-Dilithium.
• FIPS 205, SLH-DSA: a stateless hash-based signature scheme derived from SPHINCS+, valued because its security rests on hash functions rather than lattice problems.

NIST has since selected HQC as a backup key-encapsulation mechanism, to be standardised separately, so the ecosystem is not betting everything on lattice-based maths. The authoritative reference is the NIST Post-Quantum Cryptography project.

The point for our world is simple: these are now named, versioned algorithms that an evaluation can reference, the same way it references AES or ECDSA today.

Why the pressure is here before the threat is

The usual objection is that there is no quantum computer that can break RSA or elliptic-curve cryptography yet. That is true, and it does not buy as much time as it sounds.

Two reasons. First, harvest now, decrypt later: an adversary can record encrypted data today and decrypt it once the capability exists. Anything with a long confidentiality lifetime, government records, health data, identity credentials, is already at risk. Second, certified products are long-lived. A secure element designed into a passport, a payment card, or an industrial controller may be in the field for ten or fifteen years. If it cannot be updated, the algorithm it ships with has to be safe for that whole window. The product that needs PQC first is precisely the kind that gets a Common Criteria certificate.

How Common Criteria handles cryptography today

This is where people misread the impact. Common Criteria does not usually re-prove the mathematics of an algorithm. As we covered in Common Criteria vs FIPS 140-3, CC evaluations typically defer algorithm-level correctness to a cryptographic catalogue and focus on the security architecture around it.

In the US that catalogue is FIPS and the Cryptographic Algorithm Validation Program. In Europe, evaluations under EUCC and the national CC schemes lean on the SOG-IS Agreed Cryptographic Mechanisms document, the reference for which algorithms and parameters are acceptable in an evaluated product. So the first gate for PQC in European certification is not each lab; it is that catalogue adding the new algorithms and their approved parameters.

What CC does assess directly is the implementation. For a smart card or secure element, that is the hard part. A lattice-based scheme like ML-KEM or ML-DSA has a different side-channel and fault-attack surface than RSA or ECC, and the augmented vulnerability analysis (AVA_VAN) that high-assurance hardware undergoes has to be redone against the new code and the new attack surface. That is genuine evaluation work, which is why a PQC update is rarely a free ride on an existing certificate.

What changes for a certified product

Walk it through the way a vendor experiences it:

1. The Security Target changes. Adding a post-quantum algorithm changes the cryptographic claims the product makes. A claim change means the Security Target is no longer the document that was evaluated.
2. That triggers maintenance or re-evaluation. Depending on the scope of the change, the vendor goes through an assurance continuity or maintenance process, or a fresh evaluation. We described the spectrum of post-issuance change in What Actually Changes After a Product Is Certified; a new algorithm sits at the heavier end of it.
3. Hybrid is the common first step. Many early movers do not rip out classical cryptography. They ship a hybrid scheme that runs a classical and a post-quantum mechanism together, so the product is no weaker than before even if the new algorithm has a surprise. Germany’s BSI has been an early and vocal proponent of this hybrid approach in its guidance.
4. Crypto-agility becomes a design question. A product that can swap algorithms in firmware has a short path through all of the above. A product that baked one algorithm into silicon needs a new part. Buyers are starting to ask which one they are getting.

What this means for procurement

For procurement teams, PQC adds a question to the list you already ask about a certificate. It is not enough that a product is certified; for anything with a long deployment life, the relevant questions are whether it has a post-quantum path, whether that path is a firmware update or a hardware refresh, and whether the certificate you are relying on still describes the configuration you will actually run once PQC is enabled.

This is the same discipline that already applies to assurance level and evaluated scope, extended to the algorithm layer. A certificate issued in 2024 against classical-only cryptography is still a valid certificate. It just may not describe the post-quantum configuration you will need by the end of the decade.

What to watch

The transition will show up in the catalogue as a wave of maintenance updates and re-issuances rather than a single event. Concretely, the things worth tracking over the next few years are the SOG-IS catalogue adding the new algorithms and parameters, the first EUCC and CCRA certificates citing ML-KEM or ML-DSA in their Security Targets, and national roadmaps (the US CNSA 2.0 suite, the EU coordinated transition roadmap) firming up their dates. The standards are done. The certified ecosystem catching up is the part that will play out in public, one updated certificate at a time.

How NenkinTracker helps you see the transition

PQC migration is going to be visible as document changes: updated Security Targets, new certification reports, fresh issuances of familiar products. NenkinTracker versions the documents behind every certification it tracks and flags when they change, so you can watch specific products and vendors move to post-quantum cryptography instead of rechecking scheme portals by hand. If you maintain a portfolio of certified hardware, you can start tracking for free.

For most of Common Criteria’s history, a certificate was something a vendor chose to pursue. A government customer asked for it, a Protection Profile mandated it for a product category, or a procurement team scored it as a differentiator. Outside those pockets, certification was optional.

The EU Cyber Resilience Act changes the default. It does not make Common Criteria mandatory, and reading it that way is the most common mistake we see. What it does is make a baseline of product security a legal condition for selling almost anything digital in the EU, and it positions European cybersecurity certification, in practice EUCC, as the top rung of how you prove that security for the products that need the strongest evidence.

This post walks through what the CRA actually requires, how it connects to EUCC and Common Criteria, and what it means for vendors and procurement teams who already deal with certificates.

What the Cyber Resilience Act is

The Cyber Resilience Act (Regulation (EU) 2024/2847) sets horizontal cybersecurity requirements for “products with digital elements”, which is broad enough to cover almost any hardware or software that can connect to a device or network and is placed on the EU market. The text was published in the Official Journal in November 2024, and the regulation entered into force on 10 December 2024.

The obligations it places on manufacturers include security-by-design and by-default, a vulnerability handling process across the support period, a duty to ship security updates, and clear documentation for users. These are not certification requirements in themselves. They are product and process requirements that every in-scope manufacturer has to meet, and demonstrate, before applying the CE marking.

The European Commission maintains the official CRA overview, and the full legal text is on EUR-Lex.

The timeline is staggered

One reason the CRA is misread is that people latch onto a single date. There are several, and they matter for planning.

Date	What applies
10 December 2024	Regulation enters into force
11 June 2026	Rules on notification of conformity assessment bodies apply
11 September 2026	Manufacturer reporting of actively exploited vulnerabilities and severe incidents applies
11 December 2027	The main body of manufacturer obligations applies

The practical read: the reporting duties arrive first, in late 2026, and the full set of design, documentation, and conformity-assessment obligations lands at the end of 2027. A vendor planning a high-assurance evaluation, which can itself take a year or more, is already inside the window where that work needs to start.

Where Common Criteria and EUCC come in

The CRA does not ask every product to be certified. It defines conformity assessment routes that scale with risk, and certification sits at the top of that ladder.

The regulation sorts products with digital elements into tiers. The large default category can use internal self-assessment against the essential requirements. An important category, split into class I and class II, faces stricter routes: class I can use harmonised standards to self-assess, while class II is expected to involve harmonised standards conformance or a third-party (notified body) assessment. A small critical category sits above that, and here is the direct link to our world: for critical products, the Commission can require a European cybersecurity certificate obtained under a scheme adopted through the EU Cybersecurity Act.

Today the operational scheme that produces those certificates is EUCC, the Common Criteria-based scheme that became applicable in February 2025. EUCC issues certificates at assurance level “substantial” and “high”, with the “high” level mapping onto the higher EAL range and the augmented vulnerability analysis (AVA_VAN) work that smart card and secure-element vendors already know well.

So the chain is: the CRA creates the obligation, the Cybersecurity Act provides the certification machinery, and EUCC is the scheme that turns a Common Criteria evaluation into a certificate the CRA can point to. A certificate is not the same thing as CRA conformity, but for the products that need the strongest assurance, it is the recognised way to demonstrate the security claims.

What this means for vendors

If you build products with digital elements for the EU market, the CRA reframes certification from “nice differentiator” to “part of the conformity question”. A few practical implications:

1. Find your tier first. Most products are in the default or important categories and will not need a certificate. Spending on an EAL5+ evaluation for a product that the CRA lets you self-assess is wasted money. The first task is honest classification, not certification.
2. A current certificate is reusable evidence. If you already hold a Common Criteria or EUCC certificate, the Security Target, the evaluation report, and the vulnerability analysis are directly relevant to the CRA technical documentation. You are not starting from zero.
3. Vulnerability handling is now a standing duty. The CRA expects a process across the whole support period, not a point-in-time check. This lines up with the maintenance and re-evaluation discipline that Common Criteria already encourages, and it is the part most vendors underestimate.
4. Plan around the evaluation lead time. High-assurance evaluations are measured in quarters. With the main obligations applying from December 2027, the runway for the products that will need a certificate is shorter than it looks.

What this means for buyers and procurement

For procurement teams, the CRA is a quiet but real shift in leverage. After the obligations apply, the CE marking on a product with digital elements carries a cybersecurity meaning it did not before. That raises the floor for everything you buy.

It does not, however, replace the questions a careful buyer already asks. The CRA baseline is a floor, not a ceiling. For higher-risk deployments you will still want to know the assurance level, the scope of the evaluated configuration (the Target of Evaluation), and whether the certificate is current. A product can be CRA-compliant and still be a poor fit if its certified scope does not match how you intend to deploy it. We wrote about reading that scope carefully in Reading a Security Target as a Buyer.

The other shift is timing. Because certificates and conformity now have regulatory weight, their validity windows matter more. A certificate that lapses, or a product that drops out of its support period, is no longer just a procurement footnote.

The honest caveats

Two things are still moving. First, the delegated and implementing acts that pin down exactly which critical products require a certificate, and at what assurance level, are still being worked out. Anyone who tells you the precise certification list today is guessing ahead of the legal text. Second, the relationship between CRA conformity and existing certificates will be clarified through guidance and harmonised standards over the next couple of years. The direction is clear; the fine print is not all written.

What is not in doubt is the direction of travel: in the EU, product security is moving from voluntary to expected, and Common Criteria, through EUCC, is the established way to demonstrate it at the top of the risk ladder.

How NenkinTracker helps you stay ahead of this

The CRA makes certificate currency a compliance signal, not just a procurement nicety. NenkinTracker tracks Common Criteria and EUCC certifications across schemes, with change detection on the underlying documents, so you can see when a certificate is issued, updated, or approaching the end of its validity. If you are mapping a product portfolio against the EU framework, you can start tracking for free and follow the products and vendors that matter to you.

Procurement teams choosing a secure element ask a small set of repeatable questions. Who has the most CC-certified parts? In which assurance bands? Against which Protection Profiles? In which schemes? This post answers those for the four vendors that dominate the smart card and secure microcontroller market: STMicroelectronics, NXP Semiconductors, Infineon Technologies, and Samsung Electronics.

Numbers come from the NenkinTracker catalogue as of 2026-05-06. NXP appears under several legal-entity names (Germany GmbH, Netherlands N.V., USA Inc., and a few others); we have combined them into a single NXP bucket. Joint listings where an integrator (Idemia, Gemalto/Thales) is co-named with the chip vendor are excluded as integrator-led. Samsung SDS, a separate IT services subsidiary, is excluded.

STMicroelectronics

145 total certifications, 141 active and unexpired, 14 YTD 2026, average AVA_VAN 5.0. Most-used PP: Security IC Platform PP with Augmentation Packages v1.0 (80 certifications). EAL5+ is the modal package at 70 of 145; EAL6+ at 16, EAL4+ at 11. The remaining 48 lack a CC EAL package (mostly SESIP and PSA work). Year by year: 6, 16, 14, 32, 45, 14 from 2021 through YTD 2026, the most pronounced upward trajectory of the four. Notable lines: ST33 family secure microcontrollers (ST33K1M5A, ST33K1M5C, ST33G1M2 series), NESLIB cryptographic library, ST33KTPM2X TPM modules, and the ST31P platform. Scheme presence: CCRA 97, PSA 23, SESIP 21, ESA 3, EUCC 1.

NXP Semiconductors (combined entities)

264 total certifications, 230 active and unexpired, 23 YTD 2026, average AVA_VAN 5.0. Most-used PP: Security IC Platform PP v1.0 (35).

NXP has the largest combined catalogue, but the headline deserves a caveat: 97 of NXP’s 264 certifications are in MIFARE, NXP’s own scheme and product family. Strip MIFARE out and the NXP CC-style total is 167, second after ST and ahead of Infineon and Samsung. Both numbers are real; which is more useful depends on what you are buying.

150 of NXP’s certifications carry no EAL package (the MIFARE and SESIP/PSA portions). Among CC-style entries, EAL5+ leads at 55, EAL6+ at 30, EAL4+ at 22. Year by year: 20, 53, 50, 46, 27, 23 from 2021 through YTD 2026. NXP peaked in 2022 to 2023 and has trended downward since, the inverse of ST. Notable lines: ChipDoc eID and ePassport applets (22 certifications), the NXP eDoc Suite, JCOP Java Card platforms (JCOP 4 P71, JCOP 4.5 P71, JCOP 8.x/9.x with eUICC extension), and the N7121 and N7122 Secure Smart Card Controllers. Scheme presence: CCRA 114, MIFARE 97, SESIP 26, PSA 23, EUCC 4.

Infineon Technologies

104 total certifications, 103 active and unexpired, 10 YTD 2026, average AVA_VAN 4.75. Most-used PP: Security IC Platform PP with Augmentation Packages v1.0 (50). EAL6+ is the modal package at 51 of 104, the only vendor of the four where EAL6+ outweighs EAL5+. EAL5+ is second at 26, EAL4+ at 14. The 4.75 AVA_VAN average is the lowest here only because of a tail of AVA_VAN.4 certifications (9 of 36 parsed); the bulk of security IC work is at AVA_VAN.5. Year by year: 20, 9, 7, 24, 31, 10 from 2021 through YTD 2026, with the 2025 spike driven by SECORA ID X applet collections and OPTIGA TPM rollouts. Notable lines: SECORA ID X, the IFX_CCI security controller family, OPTIGA Trusted Platform Modules, and Infineon eID-OS. Scheme presence: CCRA 92, PSA 8, SESIP 3, EUCC 1.

Samsung Electronics

105 total certifications, 100 active and unexpired, 10 YTD 2026, average AVA_VAN 5.0. Most-used PP: Security IC Platform PP with Augmentation Packages v1.0 (80). Samsung’s portfolio is the most concentrated of the four: 80 of 105 certifications conform to that PP, BSI-CC-PP-0084 (the Eurosmart-issued successor to the 2007 BSI-CC-PP-0035 Security IC PP). EAL6+ leads at 49, EAL5+ at 33. All 35 Samsung certifications with a parsed AVA_VAN are at AVA_VAN.5, the cleanest record here. Year by year: 14, 15, 18, 27, 19, 10 from 2021 through YTD 2026. Notable lines: the S3D family (S3D384C, S3D352C, S3D300C, S3D264C, S3D232C and the E variants), S3FT9 and S3FV9 RISC microcontrollers, the S3B512C/SC3512C secure element, and Samsung Knox work. Scheme presence: CCRA 101, EUCC 3, SESIP 1. Samsung has effectively no presence in PSA, ESA, MIFARE, or EMVCo.

Head-to-head

Metric	ST	NXP	Infineon	Samsung
Total certs	145	264	104	105
Total ex-MIFARE	145	167	104	105
YTD 2026	14	23	10	10
Active certs	141	230	103	100
Modal EAL	EAL5+	EAL5+	EAL6+	EAL6+
EAL6+ count	16	30	51	49
Avg AVA_VAN	5.0	5.0	4.75	5.0
Top PP usage	80	35	50	80
Schemes used	5	5	4	3
EUCC certs	1	4	1	3
2025 volume	45	27	31	19

A few observations:

• NXP leads on raw catalogue size, but more than a third of that lead is MIFARE. Ex-MIFARE the gap between NXP (167) and ST (145) narrows considerably.
• Infineon and Samsung are EAL6+ houses. Their portfolios skew higher than ST or NXP, which lean to EAL5+. If your constraint is the highest CC assurance available off the shelf, those two catalogues are the densest hunting grounds.
• Samsung is the most CCRA-concentrated. Minimal presence in non-CC schemes. If you need a chip that is also PSA Certified or SESIP attested, you are looking at NXP, ST, or Infineon, in that order.
• EUCC is still small everywhere. 1 to 4 certificates per vendor. Vendor-level adoption conclusions are premature.
• 2025 is when ST broke away. Until 2024 all four were in the same range. ST’s 45 in 2025 was nearly double Samsung’s.
• All four converge on the same PP. Security IC Platform PP with Augmentation Packages v1.0 is the most-used PP for every vendor here. See the most-used Protection Profiles.

Method note

Counts are from the NenkinTracker public bulk SEO manifest as of 2026-05-06. “Active and unexpired” means status is Active or unset and either no expiry is recorded or it lies in the future. “Average AVA_VAN” is the arithmetic mean across certifications whose security level string includes one. This is a comparison piece, not a buying guide: per-part pricing, supply, toolchain quality, second-source policy, and export controls are not in a certificates database.

A few weeks ago we walked through the most-used Protection Profiles in our catalogue. The story there was concentration: a small number of PPs cover the bulk of certified products. This post is the other side. Of the 267 PPs we track, half are referenced by exactly one certified product. The long tail has procurement consequences worth thinking about before anyone writes a PP requirement into a tender.

How the 267 PPs split out

Conforming products	Number of PPs	Share
1	133	49.8%
2	51	19.1%
3 to 5	34	12.7%
6 to 10	28	10.5%
11 or more	21	7.9%

Just under 70% of the catalogue’s PPs have one or two conforming products. The 21 PPs with 11 or more products account for roughly two-thirds of all PP-product associations, while the 133 singletons account for 9% of them. This is a very long tail.

Why so many PPs get used once

Four patterns explain almost all 133 singletons.

Superseded versions. Many are older revisions of profiles whose newer version is widely used. PP_OS_V4.2.1 has one product; PP_OS_V4.3 carries the rest. PP_MD_V3.1 has one; PP_MDF_V3.3 carries the modern Mobile Device Family certifications. These are stragglers, certified just before the PP was revised and never re-certified.

Composite PP claims. A large share of singletons are claim strings that combine a base PP with PP-Modules and PP-Packages from the NIAP collaborative ecosystem. A string like CPP_ND_V3.0E,MOD_VPNGW_V1.3,MOD_MACSEC_V1.0,PKG_SSH_V1.0 describes a module mix only one product has claimed. The base components are common; the exact combination is unique. Treat these as variations of the popular PPs.

National PPs. Several singletons originate in a single national scheme and never crossed over. KECS-PP-1232-2023 DB ENCRYPTION V3.0 (Korean database encryption) and KECS-PP-1348-2025 SSO V3.1 (Korean single sign-on) each have two Korean products. PP_DCSSI_MASS_STORAGE_ENCRYPT_APP_V1.4 is a French ANSSI mass-storage encryption profile with one French product. These PPs serve a regulated domestic market and were not really intended to attract international conformance.

Niche and one-off categories. A few singletons describe genuinely narrow product categories. RECOBS_V1.0 is a remote-controlled-browser-system PP (m-privacy’s TightGate-Pro). HIS PP is a Turkish Health Information System PP (TMYPACS). FSDPP_OSP_V1.7 is a fingerprint sensor PP (a Dermalog reader). BAROC_SC_PP_V1.0 is the Bankers Association of the Republic of China smart-card PP (an Infineon SLM10TLD). Real PPs, just for very specific use cases.

A few rare PPs worth naming

A handful are worth naming, because a procurement team writing requirements for an unusual product class may stumble onto one of these and not realise how thin the conforming population is.

• PP_PSS_V3.0. Peripheral Sharing Switch PP. One product (a Belkin Secure KVM family). If you want a CC-certified KVM, this is the PP.
• TEE PROTECTION PROFILE. GlobalPlatform TEE PP, generic form. One product (Qualcomm’s TEE on Snapdragon 865). Modern TEE certifications mostly use scheme-specific composite claims.
• CALYPSO BASIC. Calypso transit ticketing PP. One product (Infineon SLM10TLD with Calypso Move).
• PP_COS_G2. German eHealth Card OS Generation 2 PP. One product (G+D STARCOS for the German GKV).
• IEEE 2600.2-2009. Older Hardcopy Device PP. Two products (one Kyocera, one HP). PP_HCD_V1.0 and CPP_HCD_V1.0E carry the rest of the printer ecosystem.
• PDCP_V1.3. Java Card platform PP. One composite product (a Gemalto/Thales JavaCard MultiApp on Infineon M7892).
• PP_DCSSI_MASS_STORAGE_ENCRYPT_APP_V1.4. French mass-storage encryption PP. One product (PrimX Cryhod).

Why this matters for procurement

If you are writing a tender that names a Protection Profile, look up the conforming product count first. The most-used PPs give you a real market. The long tail does not.

Specifying a singleton PP is effectively specifying one vendor. “Conformant to RECOBS_V1.0” picks one product. “Conformant to BAROC_SC_PP_V1.0” picks one chip. If that is the intent, write it down honestly. If not, broaden the requirement.

Evaluator and lab familiarity matters. Labs that have run dozens of NDcPP or SECURITY_IC_AUGP evaluations are fast and predictable. A PP that has been used once means the lab is starting from scratch on the threat model, the assurance activities, and the conformance argument. Cost and schedule risk both go up.

No comparator products means no comparator pricing. With one certified vendor you have no second source and no negotiating leverage. Re-certifying a competitor against the same PP is a project measured in months and six figures.

Older PPs may be on the way out. A singleton against an older revision (PP_OS_V4.2.1, PP_MD_V3.1, MRTD_ICAO_EAC_V1.1) often signals a PP whose successor is now standard. Specifying the old one locks procurement to a narrow and shrinking pool.

A reasonable default

Pick PPs from the head of the distribution, not the tail. If your product category does not have a widely-used PP, that is itself useful information: write the requirement around EAL plus specific functional and assurance components, or use a Security Target with no PP claim. Both are normal, and both compete more easily than a singleton-PP requirement.

Before locking a PP into a tender, review the conformance claims in candidate products’ certification records. Explore NenkinTracker to start comparing products.

May 2026 was a quiet-to-moderate month in Common Criteria and adjacent schemes. We logged 32 new certifications across five of the seven schemes we track, led this time not by the usual chip-and-crypto wave but by a large batch of French electronic-identity work, with smart card silicon, multifunction printers, and a steady eUICC trickle filling in behind it. This is the latest in our monthly recap series; the previous instalment is April 2026 in Common Criteria.

Five-year context

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

Two things to read out of these. One, May 2026’s CCRA cadence (23) is the slowest May since 2022, well below the 41 of May 2025, but that follows February’s 125-issuance publication cluster, so the year is still ahead: CCRA’s year-to-date of 209 is the highest reading in the five-year window. Two, ESA and EUCC have both moved decisively off their near-zero historical baselines, ESA to 16 year-to-date and EUCC to 13, consistent with the EU regulatory shift pulling more work into the European schemes. With per-scheme cadence still in the low tens, any single month will swing widely on publication timing, so one slow May should not be over-read.

The numbers

Scheme	May issuances
CCRA	23
ESA	4
PSA	3
SESIP	1
MIFARE	1
EUCC	0
EMVCo	0

Top vendors by May certification count: IN SMART IDENTITY FRANCE (11), STMicroelectronics (5), Thales DIS France (3). The rest were one-shots and pairs from a long tail of vendors.

What dominated: French electronic identity

The single biggest thread in May was electronic-identity work from IN SMART IDENTITY FRANCE, which accounted for 11 of the month’s 32 certifications. These cover the Combicao applet (versions 2.1 and 2.2) running on the ID-One Cosmo V9 and ID-One Cosmo X platforms, in the various configurations a national identity programme needs: EAC with PACE, BAC and CA, and SSCD (the qualified signature configuration). A separate ID-A applet on ID-One Cosmo X rounded out the set. Most landed at EAL5+ with ALC_DVS.2 and AVA_VAN.5, the assurance profile expected of identity-document chips.

A batch like this is how identity programmes show up in the data: one vendor, one platform, many separately certified configurations, because each deployment profile (border control, qualified signature, contactless travel document) is a distinct evaluated target.

Smart card silicon from STMicroelectronics

The other familiar thread was secure-element and cryptographic-library work from STMicroelectronics. May brought the NesLib 6.11.3 cryptographic library on the ST31N600 at EAL5+ (ALC_DVS.2, ALC_FLR, AVA_VAN.5), plus two entries for the ST31R480 secure element, one at EAL5+ and one at a lower configuration. This is the bread and butter of the smart card supply chain: chip and crypto-library certifications that sit underneath the cards, passports, and eUICCs everyone else builds on.

Mobile, print, and network on the CCRA side

CCRA also picked up its usual mix of non-chip entries. Google Pixel devices on Android 16 were certified under the mobile-device profile, the annual cadence for Pixel platform certifications. Office hardware was well represented, with Fujifilm Apeos multifunction printers and a Ricoh multifunction family both certified against the hardcopy-device protection profile. On the network side, the Nokia 1830 Photonic Service Switch took an EAL3+ certificate, and Galleon Embedded Computing certified two encryption-layer products aimed at rugged and defence deployments. Symantec’s Data Center Security Server Advanced rounded out the software side at EAL2+.

ESA and the eUICC line

ESA, the GSMA eUICC Security Assurance scheme, contributed four certifications, three of them from Thales DIS France: the Helium R1.05 and two MSM IoT eUICC products, with the fourth from a withheld vendor. ESA’s year-to-date of 16 is already well above its full historical pace, tracking the growth of remote SIM provisioning in IoT.

PSA, SESIP, and MIFARE

PSA Certified added three IoT-focused entries: a PixArt multi-protocol RF MCU family, the STMicroelectronics STM32H5 microcontroller series, and a Shanghai Fudan Microelectronics product family. The STM32H5 also appears on the SESIP side, certified at SESIP assurance level 3, a good example of one product carrying complementary certifications under different schemes. MIFARE contributed a single entry: an NXP secure element with MIFARE DESFire EV2, the first MIFARE issuance since March.

On the EUCC line

The EUCC scheme line recorded no new certificate in May specifically, but the year-to-date picture is the real story: 13 EUCC certificates through the end of May, against 2 at this point in 2025 and zero in the three years before. The scheme has moved from a standing start to a steady, if still small, flow in well under two years. We walked through one EUCC certificate end to end in Anatomy of an EUCC Certificate.

Year so far in one paragraph

Through the end of May 2026, our catalogue records 280 certifications issued in calendar year 2026, distributed CCRA 209, PSA 32, ESA 16, EUCC 13, SESIP 8, MIFARE 2. The monthly cadence has been anything but smooth: January 64, February 125 (a publication cluster on the CCRA portal, likely tied to the sunset of European national schemes as EUCC takes over), March 24, April 35, and May 32. Monthly counts reflect certificates published and recorded as of early June and can edge up slightly as late filings are added. We dig into the year-to-date numbers more carefully in Common Criteria in 2026 So Far.

What we are watching in June

A few things on our radar going into June:

• Whether CCRA’s spring slowdown (24, 35, 23 across March to May) holds, or whether another publication cluster lands
• ESA’s momentum: 16 year-to-date already beats its recent full-year pace, and IoT eUICC demand shows no sign of cooling
• The EUCC line resuming issuance after a zero month, with year-to-date already an order of magnitude ahead of history
• High-assurance work: EAL6+ and EAL7 combined sit at 13 issuances across all of 2026 so far, still a thin slice of the total

How NenkinTracker helps you see this

A monthly recap is a snapshot; the value is in watching it move. NenkinTracker tracks Common Criteria and adjacent-scheme certifications as they are issued, across CCRA, EUCC, ESA, PSA, SESIP, and MIFARE, with change detection on the underlying documents so you see new issuances and post-issuance updates as they happen. You can start tracking for free and follow the schemes, vendors, and products that matter to you.

EUCC has been issuing certificates for 14 months, since 2 April 2025. With 30 certificates in the catalog and 13 landing in the first four months of 2026, there is now enough data to say something beyond “the scheme exists.” First in a quarterly EUCC progress check.

Issuance velocity: still small, but not flat

Period	EUCC issuances
2025 (full year)	17
2026 year to date (latest issuance 28 April)	13
Total catalog	30

Thirteen issuances in the first four months puts 2026 on a pace of about three per month, faster than 2025’s average of 1.4 per month. Trajectory is up, absolute volume remains small. For comparison, CCRA published 207 new certifications in 2026 so far. EUCC is producing roughly 6 percent of CCRA’s volume.

Monthly cadence is bursty in a way that mirrors CCRA:

Month	EUCC issuances
2025-04	2
2025-07	1
2025-08	2
2025-09	1
2025-10	3
2025-11	1
2025-12	7
2026-01	2
2026-02	7
2026-03	1
2026-04	3

Two months (December 2025 and February 2026) account for 14 of the 30 EUCC certificates. The other 12 months range from 0 to 3, and May 2026 added none. Treat any single-month EUCC count with the same skepticism you would treat a CCRA monthly count: publication is bursty, evaluation is not.

Issuing-body distribution: ANSSI is doing most of the work

EUCC certificate IDs follow the format EUCC-<NCCA-code>-<year>-<seq>. The codes break down as follows:

Code	Certification body	Country	Issuances
3090	ANSSI	France	17
3110	TrustCB B.V.	Netherlands	7
3087	BSI	Germany	4
3095	DEKRA Testing and Certification	Spain	2

All 30 issuances come from these four bodies. ANSSI is the operational center of gravity, with more than half the catalog. TrustCB issued the entire 2026 NXP secure-element batch. Italy, Sweden, and the Nordic countries are not yet visible.

How many EUCC certificates are actual CCRA migrations?

This is the question that matters. Vendors can put an EUCC certificate on a brand-new product, or they can re-certify a product they had already certified under a national CCRA scheme. Only the second case represents the regulatory transition the scheme was designed to enable, and the data is lopsided toward it.

We compared all 30 EUCC certificates against the 1,914 certificates in the CCRA catalog to see how many cover a product that was already certified under CCRA.

EUCC certificate	Count
Covers a product already certified under CCRA	28
Genuinely new, no CCRA counterpart	2

So 28 of the 30 EUCC certificates, over 90 percent, re-certify a product that already holds a CCRA certificate. That is the opposite of what you might expect from a “new scheme”: EUCC issuance to date is overwhelmingly re-certification of already-certified silicon and platforms, not new products entering certification for the first time.

The overlap runs across the catalog’s core silicon and platforms. STMicroelectronics’ ST54J / ST54K NFC controller, the Thales Smart Tachograph G2 on MultiApp V4.0.1, and the Cisco Intersight Virtual Appliance 1.0.9 carry the same product name in both catalogs. The Samsung secure-element families (S3SSE1A, S3NSEN6, S3NSN6H, the S3D series), the NXP JCOP platforms on SN300 and SE310, the Infineon IFX_CCI security controllers, the Nuvoton NPCT7xx TPM 2.0 batch, IDEMIA’s CombICAO on Cosmo X squared and SCE900U, STMicroelectronics ST31P450, Cisco Nexus 9000, Huawei ATN routers, EFR’s Secure Smart Grid Hub, and Kernkonzept’s L4Re Secure Separation Kernel each appear as a CCRA certificate too, often at the same version. In every case the product sits in the CCRA catalog under an ANSSI, BSI, or other national-scheme certificate.

Only two EUCC certificates have no CCRA counterpart: GMV’s GNSS Cryptographic Module and Distromel’s Waste Container Identification System. Distromel’s is the genuinely novel one, an EAL1 industrial product from a vendor with no prior CC history. Everything else is a known product wearing a second badge.

Notable 2026 EUCC certificates

The 13 EUCC certificates issued in 2026 span a wider product mix than most readers might expect:

• NXP JCOP 8.x on SE310 A0 and JCOP 8.x/9.x on SN300 B2 (TrustCB, January 2026, EAL5+). Java Card platforms for eUICC and identity.
• CombICAO v3.1 on Cosmo X squared in four configurations (ANSSI, February 2026, EAL5+). eID and SSCD smart cards.
• NPCT7xx TPM2.0 rev 1.59 in three configurations (ANSSI, February 2026, EAL4+). Trusted Platform Modules.
• L4Re Secure Separation Kernel CC 1.0.2 (BSI, April 2026). A separation-kernel OS, a notable departure from the silicon-heavy norm.
• Distromel Waste Container Identification System (DEKRA, April 2026, EAL1). The lowest assurance level in the EUCC catalog and the most surprising product. We took it apart in Anatomy of an EUCC Certificate.
• EFR Secure Smart Grid Hub (SGH-S) (BSI, March 2026). Energy infrastructure.

Honest assessment

After 14 months EUCC is operational, but it has not displaced the CCRA pipeline at any meaningful scale. The clearest signal in the data is that the transition is asymmetric: 28 of the 30 EUCC certificates re-certify a product that already holds a CCRA certificate, and in the cases we checked (ST54J, L4Re, the Samsung S3SSE1A) that CCRA certificate is still active, not withdrawn. EUCC is functioning as an additive layer, not a replacement, even for vendors with a clear regulatory motivation to migrate.

Three things to watch over the next quarter:

• Does any single month cross 10 EUCC issuances? December 2025 and February 2026 both hit 7.
• Does any non-French, non-Dutch, non-German NCCA enter the data?
• Do any of the 28 dual-certified products see their original CCRA certificates withdrawn? That would be the cleanest signal of true migration rather than additive layering.

Procurement specs for high-assurance products often pin both a Common Criteria EAL and a FIPS 140-3 level. A typical line item: “EAL 5+ or higher, FIPS 140-3 Level 3 or higher.” That phrasing is fine, because each clause picks one standard’s ladder. The trouble starts when someone tries to collapse the two into a single tier: “EAL 6+ is roughly FIPS 140-3 Level 4, right?”

It is not. The question is asking which level on ladder A corresponds to which level on ladder B, when the two ladders measure different buildings.

This guide is the answer for the high end specifically: EAL 6, EAL 6+, and EAL 7 on the Common Criteria side, and FIPS 140-3 Level 3 and Level 4 on the cryptographic side. If you want the general comparison, start with the Common Criteria vs FIPS 140-3 overview.

The short answer

EAL 6+ and FIPS 140-3 Level 4 are not equivalent, comparable, or interchangeable. They evaluate different things:

• EAL 6+ evaluates the whole product’s design and implementation, using semiformal verification of the security policy and High attack potential vulnerability analysis. Scope: whatever the Security Target says it is, typically a smart card OS, separation kernel, or high-assurance embedded platform.
• FIPS 140-3 Level 4 evaluates a cryptographic module’s algorithms, key management, physical tamper resistance, and environmental failure protection against NIST-defined module requirements. Scope: the cryptographic boundary, not the surrounding product.

A product can hold both, one, or neither. High-end HSMs and government smart cards usually hold both. Neither programme references the other as a prerequisite.

What EAL 6+ actually evaluates

EAL 6 is the second-highest Common Criteria assurance level. It is defined in ISO/IEC 15408-3 and demands semiformal verification of design correspondence, layered internal structure, and vulnerability analysis at High attack potential. The ”+” adds augmentations on top of base EAL 6.

The key assurance components at EAL 6 include:

• ADV_SPM.1: a formal security policy model, written in a mathematically precise notation
• ADV_TDS.5: a complete semiformal modular design of the TOE
• ADV_INT.3: minimally complex, layered TOE internals, so the trusted computing base can be minimized
• ADV_IMP.2: a complete mapping of the implementation representation
• ALC_CMC.5 and ALC_DVS.2: hardened life-cycle controls and demonstrated sufficiency of development security measures
• AVA_VAN.5: advanced methodical vulnerability analysis assuming High attack potential (experts with specialized equipment and extended time)

Two things to note. First, EAL 6 already includes AVA_VAN.5, so the ”+” in EAL 6+ is usually flaw remediation (ALC_FLR.2 or ALC_FLR.3) rather than a stronger attack model. Always read the Security Target to see exactly what was augmented. Second, the gap between EAL 5+ with AVA_VAN.5 and base EAL 6 is in design assurance, not attacker model: both resist High attack potential, but EAL 6 forces a formal policy model, semiformal design verification, and layered internals on top.

Where you actually see EAL 6 and EAL 6+ certificates: top-tier smart card ICs, smart card operating systems, a small set of high-assurance separation kernels, and a handful of defense or critical-infrastructure trust anchors. Almost all of them come out of BSI or ANSSI, which were the SOG-IS schemes that historically issued the highest-assurance smart card certificates and that pattern carried into EUCC.

EAL 7 sits above EAL 6 by replacing semiformal artifacts with formal ones across the functional specification (ADV_FSP.6), TOE design (ADV_TDS.6), and correspondence between them. Vulnerability analysis stays at AVA_VAN.5. For a cryptographic product the practical effect is that EAL 7 forces the TOE scope down to a small, formally tractable core. That is why HSMs and smart card OSes target EAL 5+ or EAL 6+ rather than EAL 7: the useful TOE is too large to verify formally end to end. EAL 7 is reserved for things like separation kernels, where the formally verified core is the product.

What FIPS 140-3 actually evaluates

FIPS 140-3 is the NIST cryptographic module standard, derived from ISO/IEC 19790. A FIPS 140-3 evaluation runs against the cryptographic module boundary, defined by the vendor and reviewed by an accredited Cryptographic and Security Testing (CST) laboratory. The Cryptographic Module Validation Program (CMVP), run jointly by NIST and CCCS, issues the certificate.

Eleven requirement areas are tested across four assurance levels. The two relevant to this comparison are Level 3 and Level 4.

FIPS 140-3 Level 3

Level 3 introduces serious physical security expectations:

• Identity-based authentication: operators authenticate as individuals, not just roles
• Strong tamper resistance: enclosures detect tampering and actively zeroize plaintext critical security parameters (CSPs) when attacked
• Operator authentication for service entry: cryptographic services that touch CSPs require authenticated access
• Trusted channels: critical security parameters cross module boundaries only over trusted channels with strong cryptographic protection
• Module software/firmware integrity: digitally signed and version-controlled

Level 3 is the realistic ceiling for most commercial HSMs that need to fit into PCIe slots, USB form factors, or 1U appliances. The vast majority of HSM cryptographic modules on the CMVP validated list are Level 3.

FIPS 140-3 Level 4

Level 4 adds two things that drive cost and engineering effort significantly:

• Environmental failure protection (EFP) or environmental failure testing (EFT): the module must detect and respond safely to extreme voltage, temperature, and frequency conditions designed to subvert it. This is meant to defeat attacks that try to glitch or freeze the module into leaking keys.
• Multi-factor identity-based authentication for cryptographic officers
• Physical security at the highest level: full enclosure protection against intrusion, including grids, conductive shields, or potting that triggers active zeroization on penetration

In practice, Level 4 modules are tamper-active in a way Level 3 modules typically are not: physical attack does not just leave evidence, it causes the module to destroy its own keys before the attacker can extract them. The form factor cost is significant. Level 4 modules are usually large, expensive, and dedicated to high-value protection use cases (root key storage for PKIs, certificate authorities, military and intelligence cryptographic systems).

The Level 4 validated module list at CMVP is much shorter than Level 3. Many vendors who could technically reach Level 4 stop at Level 3 because procurement does not demand the extra cost.

Why a direct mapping does not work

It is tempting to line up the two ladders. EAL 6+ at the top of the practical CC range, FIPS 140-3 Level 4 at the top of the FIPS range, and call them comparable tiers. The mapping fails for three independent reasons.

Different attack surfaces. EAL 6+ resists High attack potential against the security policy claimed in the Security Target. That covers logical attacks, side channels, fault injection, and physical attacks against the whole product, scoped by whatever the ST says is in scope. FIPS 140-3 Level 4 resists physical and environmental attacks against the cryptographic module specifically. The two cover overlapping but not identical surfaces. A cryptographic module’s tamper response is one thing the CC evaluator might check via AVA_VAN.5, but it is not what the EAL number itself promises.

Different evaluation methodology. EAL 6+ verifies that the design correctly implements the security policy through formal modelling and semiformal correspondence. FIPS 140-3 verifies that the cryptographic module passes specific NIST-defined tests, including CAVP algorithm validation. The CC evaluator reads design documents and reasons about correspondence; the CST lab runs algorithm test vectors and physical tamper tests. Both are rigorous, but they answer different questions.

Different scope. EAL 6+ TOEs can be very large: a smart card OS includes a memory manager, file system, applet runtime, communication stack, and crypto library. FIPS 140-3 cuts a smaller boundary inside that: just the cryptographic engine. The CC certificate says something about the whole TOE; the FIPS certificate says something about a subset of it.

Put together: an EAL 6+ smart card OS without a FIPS 140-3 validation on its crypto module gives you assurance about the OS design and side-channel resistance, but no NIST-blessed statement that the algorithm implementations match the standards. A FIPS 140-3 Level 4 cryptographic module without a CC certificate around it gives you assurance about the crypto and physical tamper resistance, but no statement about how the surrounding product handles roles, audit, or secure boot.

Where they coincide in real products

Most products at the high end carry both. The pairing follows a pattern by product category.

Product category	Typical CC target	Typical FIPS 140-3 target
Top-tier smart card IC (chip)	EAL 5+ or EAL 6+ with AVA_VAN.5, against a chip PP	Often validated as part of a composite; the chip itself may not carry a separate FIPS cert
Smart card OS / Java Card platform	EAL 5+ or EAL 6+, composite with the chip cert	FIPS 140-3 Level 3 on the cryptographic services
Network HSM (PCIe / appliance)	EAL 4+ with AVA_VAN.5, against the HSM PP or a vendor ST	FIPS 140-3 Level 3, occasionally Level 4 for root-key use cases
Cloud HSM service backend	EAL 4+ on the underlying module (inherited)	FIPS 140-3 Level 3 on the underlying module (inherited)
Secure element / eSIM	EAL 4+ to EAL 5+ against eUICC or SE PPs	FIPS 140-3 Level 3 (less common at Level 4)
High-assurance separation kernel	EAL 6+ or EAL 7	Not applicable (no crypto module boundary inside the kernel)
Defense / TS-grade cryptographic module	EAL 6+ where required by national scheme	FIPS 140-3 Level 4 where US federal mandates apply

A few patterns are worth calling out.

HSMs cluster at EAL 4+ and FIPS Level 3. Even though HSMs are the obvious candidate for high assurance on both axes, the commercial reality is that most procurement specs settle for EAL 4+ with AVA_VAN.5 and FIPS 140-3 Level 3. The jump to EAL 5+ or EAL 6+ on the CC side, or to Level 4 on the FIPS side, is reserved for a narrower set of programmes (root certificate authorities, sovereign key escrow, defense).

Smart cards skew higher on EAL than HSMs. Smart card ICs and OSes at EAL 5+ or EAL 6+ are common, because the smart card market historically anchored to SOG-IS High assurance and that pattern persists in EUCC. They typically pair with FIPS 140-3 Level 3 on the cryptographic services, not Level 4, because the form factor and use case do not need Level 4’s environmental failure protection.

EAL 7 products usually do not carry FIPS at all. EAL 7 TOEs are small, formally tractable cores like separation kernels. They do not have a cryptographic module boundary inside them in the FIPS sense, so they are not candidates for a FIPS 140-3 certificate. A larger product wrapping an EAL 7 kernel may have a separately FIPS-validated cryptographic module in another component.

Cost and timeline at the high end

Both certifications are expensive. The combination is more expensive than the sum.

A base EAL 6 evaluation typically runs into the low millions of USD and takes two to four years of calendar time. The cost drivers are the formal security policy model (which most vendors do not have in their existing development process and must build), the semiformal design verification work, the strengthened development security and life-cycle controls, and the AVA_VAN.5 vulnerability analysis. Adding ”+” augmentations such as ALC_FLR.3 increases scope modestly; the bulk of the cost is base EAL 6.

A FIPS 140-3 Level 4 validation typically costs USD 200K to USD 1M and takes 12 to 24 months. The cost driver is the physical security engineering (active tamper response, environmental failure protection) and the CMVP queue at NIST. Level 3 is cheaper because the physical security expectations are bounded.

Combined programmes at EAL 6+ and FIPS 140-3 Level 4 are usually multi-year, multi-million-dollar efforts. Most vendors who go this far have institutional customers who fund the certification cost via long-term contracts. This is why so few products reach this combined tier and why the ones that do tend to come from the same handful of vendors.

When you need which

A simplified decision frame, given a procurement question:

• Need cryptographic algorithm and physical assurance only? FIPS 140-3 is sufficient. Pick Level 3 for typical commercial HSM use; pick Level 4 for root key storage, certificate authorities, or anything where environmental failure protection is required.
• Need whole-product assurance only? Common Criteria is sufficient. Pick an EAL that matches the threat model and any applicable Protection Profile. EAL 4+ with AVA_VAN.5 is the practical ceiling for general-purpose IT; EAL 5+ to EAL 6+ for smart card and embedded high-assurance products.
• Need both? You almost certainly need both certificates, not a single “highest tier” certificate. A CC certificate at EAL 5+ or higher and a FIPS 140-3 validation at Level 3 or higher is the typical pairing.

If procurement asks for “EAL 6+ or FIPS 140-3 Level 4” as alternatives, the spec is malformed. They are not alternatives. Ask the procurement team to pick which of the two underlying questions they are trying to answer: do they want whole-product security architecture assurance, or do they want cryptographic module assurance? Most of the time the honest answer is both, with the right level on each axis.

Tracking

NenkinTracker tracks Common Criteria certifications across all CCRA member schemes, including the EAL 5+, EAL 6, EAL 6+, and EAL 7 long tail. You can filter by EAL, by scheme, by product category, and watch for new certificates, maintenance reports, and expirations.

For FIPS 140-3, the authoritative source remains the CMVP validated modules list maintained by NIST. NenkinTracker does not ingest CMVP today.

To monitor the Common Criteria side across BSI, ANSSI, NIAP, and the wider scheme landscape, you can start tracking for free.

The CMVP moves every active FIPS 140-2 certificate to the historical list on 21 September 2026. After that date, FIPS 140-3 is the only active cryptographic module standard at NIST and CCCS. The date is not new. It was set in 2021 when CMVP stopped accepting new FIPS 140-2 submissions, and the five-year sunset window for existing 140-2 certificates was published at the same time.

What is new, as the date approaches, is how visible the gap has become. A meaningful share of FIPS 140-2 certificates on the active list today belong to modules whose vendors have not yet submitted a FIPS 140-3 successor, or have submitted one that is still sitting in the CMVP review queue. The procurement-side consequence is concrete: an RFP issued in late 2026 that calls for “a FIPS 140 validated module” needs to make a choice about how to handle a market where some vendors have a clean 140-3 certificate, some have only a historical 140-2 certificate, and some are in the queue between the two.

This post walks through what changes on the sunset date, the language to write into procurement specs ahead of it, and the lead times vendors and buyers should plan against. It is intentionally focused on the cryptographic module side. If you also need the broader picture of how Common Criteria and FIPS relate, start with Common Criteria vs FIPS 140-3.

The CMVP timeline in one place

The Cryptographic Module Validation Program (CMVP), run jointly by NIST and CCCS, has used the same lifecycle structure for FIPS 140-2 since the standard was published in 2001. The transition to FIPS 140-3 follows a defined path:

1. 22 September 2020: FIPS 140-3 takes effect. CMVP begins accepting FIPS 140-3 submissions in parallel with 140-2.
2. 22 September 2021: CMVP stops accepting new FIPS 140-2 submissions. From this date forward, every new validation must be against FIPS 140-3, which aligns with ISO/IEC 19790:2012 and ISO/IEC 24759:2017.
3. 21 September 2026: All remaining FIPS 140-2 certificates that are still on the active list are moved to the historical list. This is the sunset date this post is about.
4. After 21 September 2026: FIPS 140-3 is the only standard on the active list. FIPS 140-2 records remain publicly readable under “Historical”.

The framing on CMVP’s site distinguishes three states for any module certificate. Active means the certificate is current and the module is treated as compliant for federal procurement that references FIPS 140. Historical means the certificate is still valid as a public record but is no longer recognised as compliant for new procurement against current federal requirements. Revoked is a separate state used when CMVP withdraws a certificate for cause, and is rare.

The September 2026 move is not a revocation. The certificates are not deleted. The lookup at csrc.nist.gov will still resolve them. What changes is the bucket they appear in, and how federal regulations and procurement policies treat that bucket.

Active, historical, revoked: what each means for procurement

The three lifecycle states map directly onto procurement decisions, and the mapping is worth being precise about.

Active certificates are the only ones that satisfy a federal procurement requirement of the form “the product must be FIPS 140 validated” at time of award. NIST publishes the active list as the authoritative source. After 21 September 2026, every certificate on this list will be a FIPS 140-3 certificate.

Historical certificates record a validation that was once active. For federal procurement purposes, the position published by NIST and reinforced by CISA and OMB guidance is that historical certificates do not satisfy new requirements that call for FIPS validation. The certificate still exists, the validation record is still public, and the vendor can still cite the certificate number, but a procurement that requires an active validation will read the historical bucket as non-compliant.

This is the point where the language used in older RFPs starts to break. “FIPS 140 validated” without further qualification was a workable shorthand when active and historical were rarely distinguished, because most agencies dealt with currently-active certificates. After September 2026, every FIPS 140-2 certificate that has not been re-validated to 140-3 will be in the historical bucket, and “FIPS 140 validated” no longer specifies which bucket the procurement will accept.

Revoked certificates are an unrelated case. CMVP revokes a certificate when it finds, post-validation, that the module does not meet the standard or that the vendor cannot maintain the documented configuration. Revocation is rare and is not what is happening to FIPS 140-2 in September 2026.

The practical takeaway: a procurement spec that wants to be unambiguous needs to name the standard version and the lifecycle state at time of award, not just the program name.

What RFP language should change

A procurement clause that worked in 2024 is unlikely to age well past 21 September 2026 without revision. Three patterns to update.

Replace “FIPS 140 validated” with “FIPS 140-3 validated on the CMVP active list at time of award”. The phrase has to do two things: pin the standard version (since 140-2 is moving to historical on the sunset date) and pin the lifecycle state (since both 140-2 and 140-3 records sit on the same CMVP site, distinguished only by their active or historical bucket). Both qualifications are needed. A spec that says only “FIPS 140-3 validated” will, in edge cases, accept a 140-3 certificate that has itself moved to historical, which is not normally what the buyer means.

Require the vendor to name the certificate number and current bucket. A procurement response that asserts compliance without citing a specific CMVP certificate number is a response that cannot be checked against the public record. Ask for the number, ask for the active/historical state at submission time, and ask the vendor to commit to notifying the buyer if the certificate moves to historical during the contract.

Define an interim path for modules where the vendor’s 140-3 certificate is in the CMVP queue. This is the hardest part. The CMVP review queue has run between twelve and eighteen months for most of the last three years, sometimes longer for complex modules. A vendor whose 140-2 certificate moves to historical in September 2026 may have its 140-3 successor sitting in the queue with no public ETA. Procurement teams have three workable options: accept the historical 140-2 certificate as a documented interim posture with a contractually-bound 140-3 milestone; accept a different vendor whose 140-3 certificate is already on the active list; or pause the acquisition until the queue clears. The third option is rarely tenable for mission systems. The first option is the one most agencies have used in past transitions, and it works only if it is written into the contract.

A useful clause shape, in plain prose: “The module shall be FIPS 140-3 validated and on the CMVP active list at time of award. Where the vendor’s FIPS 140-3 validation is in the CMVP review queue at time of award, the vendor shall provide the queue submission record, an active FIPS 140-2 certificate, and a written commitment to deliver an active FIPS 140-3 certificate within twelve months of award.” Adapt to the specific procurement vehicle and the agency’s risk tolerance.

Re-validation lead times: what to plan against

The dominant variable in any 140-3 timeline is the CMVP review queue at NIST. The other components are bounded; the queue is not.

Pre-submission work is the vendor’s responsibility and runs in parallel with whatever development work is happening on the module. Producing the security policy document, the algorithm certificates from CAVP, and the test evidence required by ISO/IEC 24759 typically takes three to six months for a module that previously cleared 140-2 on the same hardware. A module with significant changes (new processor, new tamper enclosure, new key store) can take longer.

Lab testing is performed by an accredited Cryptographic and Security Testing (CST) laboratory. For a module that has previously been validated under 140-2 and is being re-submitted with similar architecture under 140-3, the lab phase is typically two to four months. A fresh module or a substantially redesigned one runs longer. The lab phase produces the validation report that is submitted to CMVP.

CMVP review is the queue. NIST publishes the current queue status on the CMVP “Modules in Process” list, which is updated weekly. Average wait times have been twelve to eighteen months since 2022, with reports of longer queues for complex modules and shorter queues for simpler software-only modules. NIST has publicly worked to reduce the backlog, and recent quarters have shown improvement, but the queue is still the gating constraint.

Total elapsed time from “we decide to start a 140-3 programme” to “we have a certificate on the active list” is therefore eighteen to twenty-four months in the typical case, and longer for complex modules. A vendor that started in early 2025 might land an active certificate in late 2026. A vendor that starts in mid 2026 will not land an active certificate before late 2027 at the earliest, and more realistically mid 2028.

The implication for both sides of the procurement relationship: the sunset is not far enough away to wait. If a vendor has not started, the gap between the 140-2 sunset and the 140-3 certificate is now a contractual exposure that has to be managed with the buyer, not a problem that resolves by itself.

A vendor checklist for the sunset

For a vendor with a FIPS 140-2 certificate currently on the active list, the work breaks down into a small number of explicit items. Most of these are obvious once stated, but the cost of missing one is a procurement-eligibility gap that can run quarters or longer.

1. Inventory every certificate. List the module name, certificate number, current lifecycle state, and the embedded modules (sub-chips, firmware libraries) that the certificate references. Cross-check this list against your sales record. Modules that look retired internally are sometimes still cited in active customer contracts.
2. Identify which of those modules has a FIPS 140-3 successor on the active list, which has one in the CMVP queue, and which has nothing in process. The third bucket is the urgent one.
3. For each module in the third bucket, decide whether it will be re-validated, replaced by a different module, or quietly retired. The cost of re-validation is substantial; the cost of letting a customer-cited module move to historical with no successor is higher if customers depend on it.
4. For modules in the queue, monitor the CMVP “Modules in Process” status weekly and keep customers informed. A vendor who proactively communicates queue position to its procurement counterparts buys substantial goodwill versus one who waits for the buyer to ask.
5. Update sales collateral and any procurement-facing language that quotes “FIPS 140 validated” without a version. After September 2026, that language reads as ambiguous at best and misleading at worst.
6. For modules that are also part of a Common Criteria evaluation, coordinate with the CC scheme on whether the underlying module’s lifecycle change triggers an assurance continuity review. Some Security Targets reference the FIPS certificate number explicitly, and a move to historical can be relevant to the CC body even if the CC certificate itself is not directly affected.

Common Criteria cross-reference

Common Criteria and FIPS are independent programmes, but procurement decisions routinely require both. The clearest case is the NIAP Protection Profile family for US government network devices, mobile platforms, and operating systems, which typically requires that the cryptographic module be FIPS validated as a prerequisite for the CC evaluation. After the September 2026 sunset, those PPs effectively require FIPS 140-3 validation, because a FIPS 140-2 certificate on the historical list will not satisfy the active-validation prerequisite.

The implication for a vendor running both programmes at the same product:

• If your CC evaluation cites a specific FIPS certificate number in the Security Target, check whether that certificate is 140-2 or 140-3. A Security Target that cites a historical certificate may not pass an assurance continuity review.
• If your CC evaluation defers to “a FIPS-validated cryptographic module” without naming a certificate, the new module you certify under 140-3 has to be the one your CC-certified product actually ships with, which is sometimes a non-trivial coordination exercise across product lines.
• High-assurance pairings (HSMs at FIPS 140-3 Level 3 or Level 4 alongside a CC certificate at EAL 4+ or higher) need both programmes calendared together. EAL 6+ vs FIPS 140-3 covers the high-end pairing in more depth.

The cross-reference matters even when the procurement explicitly asks for only one of the two. Buyers who today specify only Common Criteria sometimes inherit the FIPS prerequisite through the chosen Protection Profile, and discover that on contract award rather than at spec-writing time.

What NenkinTracker shows you

NenkinTracker today focuses on Common Criteria certification tracking across all CCRA member schemes and the adjacent non-CC schemes (SESIP, PSA, EMVCo, ESA, MIFARE). We do not currently ingest the CMVP validated modules list directly, so a FIPS 140-3 certificate is not visible to the tracker as a first-class object the way a CC certificate is.

Where the tracker does help on the FIPS sunset specifically:

• CVE feed for the same products. A vendor’s FIPS-validated cryptographic module is almost always inside a product that also has a CC certificate or is otherwise tracked. NenkinTracker surfaces NVD CVE entries against the product, so you can see when a vulnerability affects a module that procurement has flagged as historical-only. That is a useful pre-renewal signal: a historical FIPS 140-2 module with a fresh CVE against it is a stronger trigger to push the vendor on the 140-3 timeline than a clean one.
• Document change tracking on the Common Criteria side. Security Targets, Certification Reports, and Maintenance documents on CC certificates get republished when the underlying module’s lifecycle status changes. NenkinTracker watches those PDFs and notifies you when a new version goes up. For a product that pairs CC and FIPS, the CC-side document change is often the earliest indicator that something on the FIPS side has moved.
• Notifications across the CC scheme landscape. If your procurement spec relies on a CC certificate that itself references a FIPS module, watching the CC certificate for any change is the cheapest way to catch a knock-on effect from the FIPS sunset before it propagates into your supply chain.

The authoritative source for FIPS 140-3 active and historical certificates remains the CMVP validated modules list maintained by NIST. Cross-reference CMVP for the FIPS bucket, and use NenkinTracker for the CC certificate, document, and CVE signals on the same products.

To start monitoring CC certificates and CVEs across BSI, ANSSI, NIAP, EUCC, and the wider scheme landscape, you can start a free trial.

There is a procurement bug baked into nearly every Common Criteria tender we see. The specification reads “EAL4 minimum.” The bid evaluation matrix has a single Common Criteria column. Every candidate whose certificate prints “EAL4” or “EAL4+” gets the same green tick. The matrix rolls up, the steering committee signs off, and a recommendation goes forward.

The plus sign hides the variation that actually matters. Two products both marketed as “EAL4+ certified” can have been measured against materially different assurance packages, and a specification at “EAL4+ minimum” resolution gives the bid evaluator no way to tell them apart. This post is about which augmentations move the procurement needle, how the same headline can mean very different things in practice, and the one-sentence change to your specification that closes the gap.

For the underlying machinery, the guide to EAL levels is the baseline explainer. This piece assumes you already know what an EAL is and goes straight at the specification-drafting problem.

What EAL4 actually fixes

EAL4 is a defined Security Assurance Requirements (SAR) package in Common Criteria Part 3, the assurance components catalogue. The package fixes which assurance components from which families the evaluation must address, at which level. For EAL4 (methodically designed, tested, and reviewed) the baseline includes things like ADV_IMP.1 (the evaluator gets a sample of the implementation representation), ATE_DPT.1 (testing covers the basic design), AVA_VAN.3 (focused vulnerability analysis at the enhanced-basic attack-potential level), and ALC_DVS.1 (basic development security).

Read the package as a contract between the evaluator, the developer, and the certifier: these are the assurance activities, performed to this depth, against these classes of evidence. A vendor with an EAL4 evaluation has paid for that contract to be executed end to end.

The procurement-relevant point is that bare EAL4 is a fixed shape. Two candidates both at base EAL4 have been measured against the same yardstick. Once a plus sign appears, the yardstick changes per certificate.

What the plus sign signals, and what it hides

“EAL4+” is industry shorthand for “EAL4 plus one or more augmented SARs.” The CC concept is augmentation: you take the EAL package and add specific components from outside it, or you raise specific components within it to a higher level. The certificate text usually spells the augmentation out, in the form EAL4+ALC_DVS.2+AVA_VAN.5 or similar. The Security Target is the authoritative source for which components were actually augmented.

In sales collateral, the ”+” frequently appears alone. That is where the trap lives. Two products both marketed as “EAL4+” can carry completely different augmentations. The plus tells you something was added; it does not tell you what.

The augmentations that actually move the procurement needle

Three augmentation families come up over and over in real certificates, and each one changes a buy decision in a different way.

AVA_VAN.5: high attack potential

AVA_VAN.5 (Advanced methodical vulnerability analysis) raises vulnerability assessment to the high attack potential level. The evaluator must consider an attacker with significant time, specialist expertise, deep knowledge of the TOE, and access to sophisticated equipment and bespoke tools. AVA_VAN.5 is the standard expectation for smart cards, secure elements, secure microcontrollers, payment terminals, hardware security modules, and other targets where a determined and well-funded adversary is realistic.

The EAL4 baseline of AVA_VAN.3 considers a much weaker adversary (enhanced-basic attack potential). The gap between the two is, by some margin, the most procurement-relevant difference inside the “EAL4+” envelope. If your threat model includes nation-state, organised-crime, or otherwise well-resourced attackers, an EAL4 evaluation without AVA_VAN.5 is not measuring what you need measured.

ALC_DVS.2: development security sufficiency

ALC_DVS.2 (Sufficiency of security measures) raises the bar in the Life-Cycle Support class. The developer must justify (not merely describe) that the physical, procedural, personnel, and other security measures around development and production are sufficient to protect the confidentiality and integrity of the TOE.

ALC_DVS.2 is common in integrated-circuit and smart-card evaluations, where it matters who has access to the design files, the masks, the keys, the test vectors, and the personalisation lines. If your supply chain crosses borders, jurisdictions, or contract manufacturers, ALC_DVS.2 is doing real work. If it is absent, the development environment is held only to the lighter ALC_DVS.1 baseline, which asks the developer to describe the controls rather than show that they are adequate against the assumed attacker.

ALC_FLR family: flaw remediation as a commitment

ALC_FLR.1 commits the vendor to a basic flaw remediation procedure. ALC_FLR.2 adds reporting to TOE users. ALC_FLR.3 adds systematic flaw-handling, user-registration, and tracking processes.

Crucially, ALC_FLR is not part of any EAL package by default. It has to be augmented in to appear on the certificate at all. If your operational threat model includes a steady drumbeat of CVEs (and for nearly every category of certified product, it should), an explicit ALC_FLR augmentation makes the vendor’s flaw-handling commitments part of the assurance claim rather than something the contract has to invent from scratch.

There are other augmentations you will run into (ADV_IMP.2 for the full implementation representation, ATE_DPT.2 for deeper testing, AVA_VAN.4 for moderate attack potential), but the three families above account for the bulk of procurement-material differences inside “EAL4+.” The EAL augmentations wiki entry walks the full catalogue.

Two hypothetical “EAL4+ certified” products

Consider two candidates for a high-value-target deployment, both with current certificates from a CCRA Certificate Authorizing scheme. The names and details are deliberately generic; the augmentation patterns are the procurement-relevant part.

Candidate A carries EAL4+ALC_FLR.1. Base EAL4 plus a basic flaw remediation procedure. Vulnerability assessment is at the EAL4 baseline of AVA_VAN.3 (enhanced-basic attack potential). Development security is at ALC_DVS.1. This is a perfectly respectable assurance posture for, say, a back-office network appliance evaluated in a corporate IT setting.

Candidate B carries EAL4+ALC_DVS.2+AVA_VAN.5+ALC_FLR.2. Same headline EAL, same plus sign in the marketing copy. Vulnerability assessment is now at high attack potential. Development security is justified rather than merely described. Flaw remediation includes user reporting. This is a smart-card-grade assurance posture.

	Candidate A	Candidate B
Headline	EAL4+	EAL4+
Vulnerability analysis	AVA_VAN.3 (enhanced-basic)	AVA_VAN.5 (high)
Development security	ALC_DVS.1 (baseline)	ALC_DVS.2 (sufficiency justified)
Flaw remediation	ALC_FLR.1 (basic)	ALC_FLR.2 (with user reporting)
Suitable for high-value-target deployment	No	Yes

For a deployment that has to resist a serious adversary (national-identity card personalisation, an EMV payment terminal, an eIDAS Qualified Signature Creation Device), Candidate A is not procurement-grade and Candidate B is. The ”+” sign on its own gives no way to see that. If your specification accepted “EAL4+ minimum,” your tender mechanically treated the two as equivalent.

This is not a hypothetical disagreement about labels. It is a real gap in assurance against the attacker you actually face.

How to write the specification so the trap does not bite

The fix is one sentence. Specify the augmented Security Assurance Requirements by name, not just the headline EAL with a plus sign.

• “EAL4 augmented by AVA_VAN.5 minimum” tells a vendor exactly what they must hold.
• “EAL4 augmented by ALC_DVS.2 and AVA_VAN.5 and ALC_FLR.2 minimum” tells them all three.
• “EAL4+ minimum” tells them nothing constraining about the augmentation.

The candidates’ Security Targets carry the answer, and the comparison is now apples to apples.

Two practical notes when drafting this language:

1. Quote the SAR component identifiers in CC Part 3 notation (AVA_VAN.5, ALC_DVS.2, ALC_FLR.2). Vendors and labs recognise the notation, and the bid evaluator who later reads the response will not have to guess what you meant.
2. Make the augmentation requirement testable. If you accept “AVA_VAN.5 or equivalent” you have re-opened the loophole. “AVA_VAN.5 minimum” closes it.

If your procurement category is one where high attack potential is a baseline expectation (smart cards, secure elements, payment terminals, HSMs, IC platforms, eIDAS QSCDs, national identity tokens), consider going further and writing the augmentation requirement at category level so it lands consistently across every tender your team issues. The Protection Profile catalogue is a good complementary lever: a PP often pins the augmentation expectation per category, and “conformant to PP X” is a tighter constraint than “EAL4+ minimum.”

For categories where the practical ceiling is genuinely higher than EAL4, the same rule applies one level up: EAL5 augmented with AVA_VAN.5 has a different procurement meaning than bare EAL5, and the specification should say which.

A note on EUCC

The EU Cybersecurity Act introduces its own assurance levels under EUCC, Substantial and High, mapped onto the AVA_VAN ladder rather than directly onto the EAL ladder. EUCC High lives broadly in the AVA_VAN.4 and AVA_VAN.5 territory; EUCC Substantial covers the lighter AVA_VAN.1 and AVA_VAN.2 zone.

The underlying SARs are the same Common Criteria components, so the procurement principle does not change. Specify the AVA_VAN level you actually need, and read the certificate at that resolution. The EUCC label gives you a regulatory hook; it does not relieve you of reading the Security Target.

Where this fits in the broader playbook

Specifying augmentations by name is one of the small, high-leverage moves that distinguishes assurance-driven procurement from box-ticking. The companion moves: verify the Target of Evaluation matches the SKU you are actually buying, check the certificate lifecycle state at the issuing scheme’s registry, read the Security Target instead of the brochure, and confirm the issuing scheme’s CCRA role if mutual recognition matters to you. The twelve procurement red flags post lists the full pattern set; how to read a CC certificate covers the document-side checks. For sector-specific category notes (smart-card chips, IC platforms, secure elements), the smart-card chip vendor comparison puts the augmentation question in context.

If a particular SAR notation is unfamiliar, the glossary carries definitions for the assurance classes, families, and components you will encounter on a CC certificate.

How NenkinTracker helps you see this

NenkinTracker indexes the augmentation string on every Common Criteria and EUCC certificate it tracks, alongside the headline EAL. The filter set lets you constrain by AVA_VAN level, by ALC_DVS level, and by ALC_FLR presence, so you can compare candidates at the augmentation resolution rather than the headline resolution. Two products both marketed as “EAL4+” stop being indistinguishable.

If you are about to issue a tender for a high-value-target category and you want a buyer-side reader to pressure-test the specification before it goes out, Nenkin’s procurement advisory covers exactly that. Founded by a former Technical Manager of the Norwegian Common Criteria certification authority, the practice sits buyer-side, does not take vendor referral fees, and writes recommendations attributable to a named advisor. The cheapest place to fix a specification of this kind is before signature.

Common Criteria certification is slow. From the moment a vendor files an evaluation with a certification body to the day the certificate is published on the scheme registry, twelve to eighteen months is a routine elapsed time, and more is normal for higher EAL targets. For most of that period the work is happening in plain sight on the certification body’s public pages, but invisible to anyone who is only reading the certificate registries.

The cost of that gap shows up wherever someone has to plan ahead with certified products. Procurement teams are the clearest case, but they are not the only one.

The gap in plain numbers

A registry of certificates tells you what is already certified. It tells you nothing about what will be available three quarters from now. For short purchasing cycles that may be fine. For anyone running a multi-year compliance programme or specifying a product against a regulation that calls for a particular EAL level, the lag is significant.

A simple way to picture it: the certified inventory is a stock, and the evaluation pipeline is a flow. The stock at any moment is the catalogue. The flow that will become next year’s stock is the set of products currently in evaluation. If you only see the stock, you are planning against today’s supply without any signal about what tomorrow’s supply will look like.

Most certification bodies publish their evaluation pipelines on their public sites. BSI publishes a list under “Products in Evaluation”. NIAP shows “Products in Evaluation” under the CCEVS programme. CCCS, JISEC, CSEC Sweden, TrustCB, and Brightsight all publish equivalent lists. The data is there. Until now there has not been a single place to read it, follow it, or be notified when something new appears.

What changes for procurement

The procurement use case is the most direct. A team writing a requirement that calls for, say, “an EAL4+ smart card with a Java Card protection profile” has historically been planning against the existing catalogue. The product they pick is often a product that was certified two or three years ago, because that is what shows on the registry today.

With a pipeline view in hand, the same team can:

• See which vendors are currently putting new platforms through evaluation at which labs, against which profiles. That tells the team what they will be choosing from in twelve to eighteen months, not in three years.
• Notice when a vendor’s newer-generation chip enters evaluation, signalling that the older generation in today’s catalogue is heading towards end of life as an actively certified product.
• Identify gaps. If no vendor has anything under evaluation in a category the team’s roadmap depends on, that is information the team needs before it commits to a procurement specification.
• Plan timing. A product entering evaluation in May at a lab whose average evaluation cycle is twelve months is unlikely to be certified before next May. A requirement issued now that can only be met by that product needs an alternative path or a waiver.

The single biggest practical effect is to extend the visible procurement horizon by roughly a year. That is the difference between “we will work with what is on the registry today” and “we will work with what we know is coming”. The regulated procurement use case walks through this for buyers whose specifications are bound by NIS2, automotive, or payments regulation.

What changes for compliance and CISOs

Compliance programmes pinned to certified components carry the same shape of risk as procurement specs, with longer feedback loops. NIS2 controls that call for certified cryptographic modules, PCI DSS requirements that point at PTS-approved devices, and automotive supplier programmes that require ISO/SAE 21434 evidence all live in this space.

The pipeline view lets a compliance lead:

• Anticipate when a deprecated certified product will have a successor on the registry, instead of discovering it the week the old certificate expires.
• Map the compliance roadmap to the actual supply pipeline, so the documentation team is not promising customers a certified migration path that does not exist in any evaluation queue.
• Spot scheme-level shifts. If the EUCC pipeline starts filling up with classes of product that previously evaluated under national CCRA schemes, that is a useful signal about where the centre of gravity is moving for European compliance.

CISOs sitting one layer above the compliance programme get a useful side benefit: an objective answer to the question “what is actually happening in our certified supply chain”. The pipeline list is not anyone’s marketing material. It is what the certification body has accepted into evaluation.

What changes for vendors

Vendor strategy is the use case most people do not bring up first, but it is real. The pipeline lists are public; the picture they paint is competitive intelligence.

A vendor working on a new secure element can see which competitor entered which lab with which profile, at roughly what time. That informs:

• Roadmap timing. If a direct competitor entered evaluation eight months ago at a lab with an average twelve-month cycle, an announcement is likely soon. Internal release decisions can factor that in.
• Lab capacity. If a target lab is currently working on several large evaluations, an early conversation about a planned engagement is more informative than the lab’s marketing-side responsiveness suggests.
• Cross-scheme positioning. A vendor that has so far evaluated under one scheme can read the pipeline at the other scheme to understand whether competitors are quietly broadening their certification footprint there.

This is not new information in any deep sense. Sales teams have always known the rough shape of competitor activity. The difference is having it in one place, dated, and queryable, rather than reconstructed from rumour.

What changes for analysts and auditors

Industry analysts publishing market overviews of certified products in a sector (smart card platforms, automotive secure elements, PSA chips) routinely face the question “is this list representative of where the market is going, or only of where it has been?” The answer has historically required calling individual vendors. The pipeline view turns it into a query against the public catalogue.

Auditors checking a vendor’s certification roadmap for a customer or for due diligence get a parallel benefit. A vendor that claims its next-generation product is “in evaluation” can be checked against the public pipeline list of the relevant certification body. Either the claim is in the list, or it is not.

What this is not

A few things worth being clear about.

A product appearing on a certification body’s evaluation list is not a guarantee that a certificate will issue. Evaluations are abandoned for many reasons, from a failed assurance argument to a commercial decision. The pipeline view tells you what is being attempted, not what will succeed.

The information is published by the certification body and reflects what the body has accepted into evaluation. It does not include what is being prepared internally but not yet formally entered. Vendor-side roadmaps remain private.

The fields published vary by scheme. BSI publishes a sponsor, a developer, and a registered title. NIAP publishes the product name, vendor, and a target assurance package. The level of detail is not uniform across sources, and the new view simply surfaces what each source actually publishes.

Where to start

For NenkinTracker users, the new view is live. Search now returns products that are only under evaluation, with an “Under Eval” badge and a filter chip to restrict the catalogue to that subset. Opening a product shows an “Under Evaluation” card with the source-published fields. Two new notification routes are available: subscribe to a certification body to be alerted whenever a new product enters evaluation there, or follow a specific product under evaluation to be alerted when it is registered and again when the certificate eventually issues.

The longer-term effect is the same in every case: the procurement, compliance, and vendor-strategy horizon shifts forward by something close to the length of an evaluation cycle. That is the part that has been quietly missing from the certified-product picture until now.