How to Read a Common Criteria Certificate

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 certificate lookup. 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.

See also

• Common Criteria overview - the standard the certificate is issued under.
• Security Target reference - the document the certificate points at.
• Certificate validity - what active, archived, and withdrawn states mean.
• Common Criteria certification process - how the certificate gets produced in the first place.

Continue reading

May 6, 2026

CAB and Lab Independence in Common Criteria: When the Separation Matters Most

Why independence between the evaluation lab (ITSEF) and certification body matters in Common Criteria and EUCC, and how to apply ISO 31000-style risk assessment to combined lab/CB structures at substantial versus high assurance.

common-criteriaeuccealprocurementguide

May 5, 2026

The Most-Used Protection Profiles in Common Criteria, by Product Count

Of the 267 Protection Profiles tracked in NenkinTracker, a small number account for the majority of certified products. Here is the head and the long tail.

common-criteriaprotection-profilesprocurementguide

Apr 29, 2026

Which EAL Do I Need? A Procurement Decision Guide

Pick the right Common Criteria Evaluation Assurance Level by working from threat model and procurement requirements, not vendor marketing. A practical decision guide.

ealcommon-criteriaprocurementguide