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:

Look up the certificate ID in the Common Criteria Portal or a structured database such as NenkinTracker’s certifications database. Confirm the certificate exists and is in the state the vendor claims.
Read the TOE description in the Security Target and confirm the version the vendor is selling falls inside the TOE boundary.
Confirm the certificate is active, not archived, withdrawn, or suspended.
Match the Protection Profile on the certificate against any PP requirement in your procurement.
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.

Frequently asked questions

What does a Common Criteria certificate actually tell you?

The certificate is a one-page or two-page summary that points at the real evidence: the Security Target (what was evaluated), the Certification Report (what the lab did), and any maintenance reports issued afterwards. Reading only the certificate page gives you a stable identifier and the headline EAL, but you cannot tell what the certificate actually covers without reading the Security Target.

What is the Target of Evaluation (TOE) on a Common Criteria certificate?

The TOE is the specific product, configuration, and version that was evaluated. It is the most important field on a Common Criteria certificate, and rarely identical to the entire product the vendor sells. A certificate for a network appliance might cover only one firmware revision running on one hardware model. Always confirm the TOE description matches the product version actually being offered.

How do I verify a Common Criteria certificate is genuine?

Look up the certificate identifier (such as BSI-DSZ-CC-1234-2024, ANSSI-CC-2024/12, or an EUCC-format ID) in the issuing scheme's official registry, in the Common Criteria Portal, or in a structured database such as NenkinTracker's certifications database. Confirm the document the vendor handed you matches the registry entry. Fabricated and typoed certificates have happened.

How do I check if a Common Criteria certificate is still valid?

Confirm the certificate is currently in force and is in active state (not archived, withdrawn, or suspended). Check the issuing scheme's registry for the latest status. Also look for maintenance reports that may extend assurance to a newer product version, since the base certificate's date is not the operative validity period if a maintenance report has updated it.

What does EAL4+ on a Common Criteria certificate mean?

EAL4+ means the evaluation was at base EAL4 with one or more augmented assurance components. The plus sign by itself does not tell you which components were added. Common augmentations are AVA_VAN.5 (enhanced vulnerability analysis), ALC_DVS.2 (development security), and ALC_FLR.2 or ALC_FLR.3 (flaw remediation). Look in the Security Target for the exact components.

Is a vendor's marketing claim of CC certification proof of certification?

No. Marketing copy and the CC logo on a vendor data sheet are not certificates. Always look up the certificate identifier in the issuing scheme's registry or the Common Criteria Portal, confirm it is active, and read the Target of Evaluation in the Security Target to see whether the version being offered is actually covered.