Common Criteria Procurement Guide: Buying Security-Sensitive Products

Summary: A reference guide for procurement, integrator, and acquirer teams sourcing Common Criteria, EUCC, SESIP, PSA Certified, EMVCo, and MIFARE certified products. Explains how to read a certificate at procurement time, common procurement red flags, the contract commitments that should accompany an assurance claim, and how to verify ongoing validity.

This guide is written for procurement professionals, integrators, and government acquirers who need to source security-sensitive hardware and software and depend on third-party certifications to compare candidates. It does not replace a Common Criteria reading list for evaluators or vendors; it covers what a buyer actually needs to do with an assurance certificate during a procurement exercise.

What a certificate is, and what it is not

A Common Criteria certificate (and its siblings under EUCC, SESIP, PSA Certified, EMVCo, and MIFARE) is a point-in-time attestation. An accredited evaluation laboratory tested a specific configuration of a specific product against the claims in a published Security Target, to a stated assurance level, and the issuing scheme judged the evaluation evidence sufficient to issue a certificate. That is what the certificate says.

A certificate is not:

A guarantee that the product is secure in any colloquial sense
A statement about future versions, sibling SKUs, or regional variants
A statement about the product running outside the operational environment the Security Target assumes
A commitment by the vendor to keep the product secure, patched, or supported
A substitute for reading the Security Target

The procurement-team job is to bind the certificate’s scope to your specific use before signing the contract, and to bind the vendor to lifecycle commitments that match the deployment horizon.

Reading the Security Target at procurement time

The Security Target (ST) is authoritative; the brochure, the spec sheet, and the sales-team talk track are not. Six ST sections matter for procurement:

TOE identification and overview — names the exact configuration that was evaluated. Match the SKU, firmware version, and hardware revision against what the vendor is offering.
Conformance claims — declares Common Criteria version, the assurance package (EAL, SESIP level, PSA level), and any Protection Profile or SESIP profile claimed.
Security problem definition — lists threats addressed, assumptions about the environment, and organisational security policies enforced. Match each assumption against your deployment.
Security objectives — what the TOE achieves and what the environment must achieve.
Security requirements — the Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs) the product satisfies. Augmentations show up here.
TOE summary specification — how the TOE implements each SFR. The implementation detail that lets you tell two “EAL4-certified” products apart.

See the Security Target wiki entry for a deeper read of ST structure.

Certificate lifecycle states

Certificates are not static. Each scheme tracks lifecycle states with slightly different names; the procurement-relevant categories are:

Active: the certificate is current and the vendor is meeting any scheme-mandated surveillance.
Maintenance: the vendor has filed an impact analysis or maintenance report for a minor change to the certified product; the certificate covers the updated configuration.
Surveillance suspended: the scheme has paused surveillance, often pending vendor action. Procurement should treat this as a flag.
Archived: the certificate is no longer current but is retained for historical reference. Not a basis for procurement.
Expired: the certificate has lapsed by date. Not a basis for procurement.
Withdrawn / revoked: the scheme has formally removed the certificate. Usually a serious flag.

See CC certificate validity for the full state machine.

EAL augmentations and what they mean for buying

The Evaluation Assurance Level (EAL1 through EAL7) is a pre-defined package of Security Assurance Requirements. Augmentations add specific SARs on top of an EAL package, and they change the assurance picture materially.

The most common augmentations a procurement team will see:

AVA_VAN.3 is the EAL4 baseline for vulnerability assessment (enhanced-basic attack potential).
AVA_VAN.4 raises it to moderate attack potential, common at EAL5.
AVA_VAN.5 raises it to high attack potential, the smart-card / high-assurance level.
ALC_DVS.2 raises development security requirements beyond the EAL baseline, common in smart-card and HSM evaluations.
ALC_FLR family adds flaw remediation requirements (the vendor commits to a flaw-handling process).

A specification that reads “EAL4 minimum” is often weaker than the buyer thinks; a specification that reads “EAL4 augmented by AVA_VAN.5 minimum” is targeting smart-card-grade vulnerability resistance. See EAL levels explained.

Composite certifications and component dependencies

Many security products are evaluated compositely on top of a separately certified component. Smart cards layer applets on top of certified java card platforms on top of certified integrated circuits. SESIP IoT platforms compose on top of certified roots of trust. Each layer has its own certificate, and the composite claim is only as strong as its weakest in-date component.

Procurement implication: if the upstream component certificate has lapsed, been suspended, or been archived, the downstream composite claim is on shaky ground regardless of what the marketing page says. Verify the certificate chain, not just the top-level certificate.

CCRA mutual recognition and EUCC

The Common Criteria Recognition Arrangement (CCRA) lets one member nation’s certificate be accepted in another, up to EAL2 (or EAL4 within a Protection Profile). CCRA member roles:

Certificate Authorizing: the nation operates a scheme that can issue mutually recognised CC certificates. Examples include BSI (Germany), ANSSI (France), NIAP (United States), CCCS (Canada), JISEC (Japan), OCSI (Italy), CCN (Spain), SERTIT (Norway), and others.
Certificate Consuming: the nation accepts CC certificates issued by Authorizing members but does not itself issue mutually recognised certificates.

If a certificate is “issued” by a consuming-only scheme, mutual recognition does not apply. EUCC under the EU Cybersecurity Act overlays this for EU procurement: EUCC certificates have their own legal status under the EU CSA and are issued by national cybersecurity certification authorities. See EUCC vs CCRA.

Procurement red flags

Twelve recurring patterns that come up when a buyer mistakes a marketing certificate claim for an actual assurance commitment. Test every candidate against each one.

The certified TOE does not match the product SKU being sold. Buying a sibling SKU, regional variant, or later firmware can put you outside the certified scope.
Operational environment assumptions do not match your deployment. If the ST assumes physical security, trusted administrators, or network isolation you cannot provide, the certificate’s claims do not apply.
Security Target scope is narrower than the marketing claim. “EAL4-certified” can mean the product has an EAL4 certificate covering only specific modules.
The certificate is in surveillance suspended, archived, or expired status while still being marketed as current.
Optional features you need are outside the evaluated configuration. Cloud sync, remote management, integration adapters are often excluded from the TOE.
Composite certifications depend on a component certificate that is no longer valid. Verify the certificate chain, not just the top-level certificate.
EAL augmentations are dropped from cross-vendor comparisons. EAL4 and EAL4+ALC_DVS.2+AVA_VAN.5 are not the same.
Vulnerability assessment depth is below the threat model. AVA_VAN level should match the attacker you actually face.
The issuing scheme is not Certificate Authorizing under CCRA, or is consuming-only. Mutual recognition does not apply.
Maintenance updates have not been processed against the certificate after material releases. Assurance continuity has lapsed.
Patching SLAs, end-of-support, and re-evaluation triggers are not in the vendor contract. The certificate is point-in-time; the contract is what binds the future.
Known public CVEs against the certified product are not acknowledged in the vendor’s response. A vendor that does not surface relevant CVEs at procurement time is unlikely to handle the next one differently.

Contract clauses for certified products

A certificate alone does not commit the vendor to anything after delivery. The procurement contract should bind the lifecycle:

Patching service-level agreement with severity-based timelines (e.g. critical CVE patched within X business days).
Vulnerability disclosure obligations: vendor commits to notify the buyer of relevant CVEs and provide mitigation guidance.
Assurance-continuity commitments: vendor commits to file maintenance reports or impact analyses with the issuing scheme when material changes ship.
End-of-support and end-of-life dates: vendor commits to minimum support windows that match the deployment horizon, with notice obligations on changes.
Certificate renewal expectations: who pays for re-evaluation, when it must happen, and what happens if the certificate lapses mid-deployment.
Replacement obligations: vendor commitments if the certificate is suspended, archived, or expired before the contract term ends.
Right-to-audit: buyer reserves the right to verify ongoing certificate validity and vendor compliance with the commitments above.
Re-evaluation triggers: events that require renewed certification activity (major version, change of hardware platform, change in cryptographic suite).

CVEs and certified products

A Common Criteria evaluation tests a product against the threats listed in the Security Target. It does not exhaustively rule out vulnerabilities. Certified products do get CVEs, and how a vendor handles them is the procurement-time signal.

At bid evaluation:

Query public vulnerability databases (NVD) for CVEs against the candidate product and the certified configuration.
Ask the vendor to walk through each CVE and explain its applicability to the certified configuration.
Verify that the vendor has a flaw remediation process; if ALC_FLR is augmented in the certificate, the process is part of the assurance claim.
Confirm that patches issued post-certification have been processed through the scheme’s maintenance procedure.

NenkinTracker links published CVEs to certified products across all indexed schemes, surfacing the connection that public registries leave unconnected.

Sector-specific procurement notes

Defence and critical infrastructure: NATO and national procurement typically require CC certification at higher assurance levels, often with national-scheme augmentations. KVM switches, trusted peripherals, and tactical communications equipment fall here.
Public-sector ICT under NIS2 and EU CSA: EUCC certification will increasingly be the procurement-relevant assurance vehicle. Track which Protection Profiles are recognised under EUCC at the time of tender.
Financial services: payment terminals (EMVCo), HSMs and smart cards (CC at high EAL with AVA_VAN.5), and core-banking adjacent infrastructure (CC or EUCC).
Telecom operators: operator-grade routers, switches, firewalls, and base-station components. CC certification is increasingly accompanied by NESAS (3GPP) for network equipment.
Healthcare, identity, and digital signatures: eIDAS Qualified Signature Creation Devices (QSCDs) are certified under specific Protection Profiles; identity-system back-ends and biometric authentication products often require national-scheme certification.
National identity and travel documents: smart cards, secure microcontrollers, applets, and personalisation systems. Composite evaluations across IC, platform, and application layers are the norm.
Mobile and IoT product OEMs: SESIP and PSA Certified are the procurement-relevant schemes for upstream platform certification. OEM downstream evaluation builds on the upstream certificate.

How to verify a certificate before signature

A short procurement-team checklist:

Look up the certificate at the issuing scheme’s registry, not the vendor’s site. For CCRA certificates use the Common Criteria Portal; for EUCC use the EUCC registry; for SESIP, PSA Certified, EMVCo, and MIFARE use the respective scheme portals. Or use NenkinTracker, which indexes all of these.
Read the Security Target end to end, focusing on TOE identification, environment assumptions, and the SFR list.
Match the certificate identifier, TOE configuration, and ST version to the SKU you are buying.
Check certificate state (active, surveillance, suspended, archived, expired).
Check the certificate chain for composite certifications.
Query NVD for CVEs against the certified product.
Compare augmentations across candidate vendors, not just headline EAL numbers.
Confirm the issuing scheme’s CCRA role if mutual recognition matters to you.

Working with an independent procurement advisor

For high-value or high-assurance procurements, an independent advisor can pressure-test the vendor’s certificate claim and the procurement specification before signature. The advisor sits buyer-side, does not take vendor referral fees, and writes recommendations attributable to a named person.

Nenkin Technologies AS provides procurement advisory on this basis. The firm is the buyer-side counterpart to its vendor-side Common Criteria consultancy, and explicitly does not represent both sides of a single transaction. Founder Kjartan Kvassness Jaeger spent six years as Technical Manager of the Norwegian Common Criteria certification authority and represented Norway in the CC Development Board, the SOG-IS Joint Interpretation Working Group, and ISO SC 27/WG3.

Frequently asked questions

What does it mean for a product to be Common Criteria certified at procurement time?

A Common Criteria certificate is a point-in-time attestation that a specific configuration of a product (the Target of Evaluation) was tested by an accredited laboratory against the claims in a published Security Target and met them to a stated assurance level. At procurement time, the certificate is only meaningful for the exact SKU, firmware, and configuration named in the certificate package, deployed in an environment that satisfies the Security Target's assumptions. Reading the Security Target, not the brochure, is the procurement-team job.

How do I check that a CC certificate is currently valid?

Verify the certificate at the issuing scheme's registry rather than relying on the vendor's marketing page. Certificates move through lifecycle states (active, surveillance, suspended, archived, expired); the registry shows the current state. Cross-check the certificate identifier against the Common Criteria Portal for CCRA-recognised certificates, the EUCC registry for EUCC, and the relevant scheme portals for SESIP, PSA Certified, EMVCo, and MIFARE. NenkinTracker mirrors and indexes all of these in one searchable place.

What is the difference between EAL4 and EAL4+ for procurement?

EAL4 is a defined assurance package in Common Criteria Part 5. EAL4+ means EAL4 with additional augmentations, written as EAL4 plus the augmented assurance components, for example EAL4+ALC_DVS.2+AVA_VAN.5. The augmentations materially change what the evaluation tested. AVA_VAN.5 is high attack potential vulnerability assessment, used for smart cards and high-value targets; AVA_VAN.3 is the EAL4 baseline. Two "EAL4-certified" products can have very different real-world assurance if one has augmentations and the other does not.

What is the Target of Evaluation (TOE) and why does it matter for procurement?

The Target of Evaluation is the precise part of the product that the certificate covers. The TOE is usually narrower than the product as shipped, excluding the host operating system, optional features, integrations, and operational environment. A product can be "certified" while the part of it you are actually buying or using is outside the TOE boundary. Reading the TOE description in the Security Target before purchase is what distinguishes assurance-driven procurement from box-ticking.

What is a procurement red flag in a Security Target?

Common red flags include: the certified TOE does not match the SKU being sold; operational environment assumptions exclude your deployment; scope is narrower than the marketing claim; the certificate is in surveillance suspended, archived, or expired status; optional features you need are outside the evaluated configuration; composite certifications depend on a lapsed component certificate; EAL augmentations have been dropped from comparisons; vulnerability assessment depth (AVA_VAN) is below your threat model; the issuing scheme is consuming-only under CCRA; maintenance has not been processed after major releases; and the vendor response does not acknowledge known public CVEs.

What contract clauses should buyers add to procurement contracts for certified products?

Procurement contracts for security-sensitive products should include patching service-level agreements, vulnerability disclosure obligations, assurance-continuity commitments (maintenance reports filed against the certificate when material changes ship), end-of-support and end-of-life dates, certificate renewal expectations, replacement obligations on certificate lapse, and right-to-audit clauses. A certificate is a point-in-time attestation; the contract is what binds the vendor for the lifetime of the deployment.