Blog

If you work in IT security procurement or compliance, you have almost certainly encountered two standards: Common Criteria (ISO/IEC 15408) and FIPS 140-3. Both are used to evaluate the security of IT products, both are required in government procurement, and both involve accredited labs - but they solve different problems.

This guide explains the differences, when each applies, and how they work together.

The short answer

• Common Criteria evaluates the overall security design of a product - access controls, audit logging, data protection, secure communications, and more. It asks: “Does this product do what it claims to do, securely?”
• FIPS 140-3 evaluates cryptographic modules specifically - encryption algorithms, key management, random number generation, and physical tamper resistance. It asks: “Does this product implement cryptography correctly?”

They are complementary. A firewall might need a Common Criteria certification to prove its security architecture is sound, and a FIPS 140-3 validation to prove its cryptographic engine meets federal standards.

Scope and focus

Aspect	Common Criteria	FIPS 140-3
Standard	ISO/IEC 15408	NIST SP 800-140 series (derived from ISO 19790)
What it evaluates	Entire product security design	Cryptographic module only
Assurance levels	EAL1-EAL7	Levels 1-4
Requirements defined by	Security Targets and Protection Profiles	NIST-defined module requirements
Evaluation labs	Common Criteria Testing Laboratories (ITSEFs)	Cryptographic and Security Testing (CST) labs
Certificate issued by	National CC scheme bodies (BSI, ANSSI, NIAP, etc.)	NIST/CCCS (Cryptographic Module Validation Program - CMVP)
Mutual recognition	31 nations via CCRA	US and Canada (CMVP)
Typical products	Firewalls, operating systems, smart cards, databases	HSMs, TPMs, VPN appliances, TLS libraries, disk encryption

How Common Criteria evaluations work

In a CC evaluation, the vendor writes a Security Target (ST) document that describes what the product does and what security claims it makes. Optionally, the ST conforms to a Protection Profile (PP) - a standardized set of requirements for a product category.

An accredited evaluation lab (ITSEF) then tests the product against the ST at a specified Evaluation Assurance Level (EAL1-EAL7). Higher EALs require more rigorous analysis: EAL1 is a basic functional test, while EAL4 involves source code review and vulnerability analysis. EAL5 and above add formal methods and are rare outside government/military contexts.

Once the evaluation passes, a national scheme body (like BSI in Germany, ANSSI in France, or NIAP in the USA) issues a certificate. Through the CCRA, certificates are recognized across 31 member nations.

For more detail, see our wiki article on Common Criteria.

How FIPS 140-3 validations work

FIPS 140-3 focuses specifically on the cryptographic boundary of a product - the module that performs encryption, decryption, hashing, signing, and key management.

The vendor submits the module to an accredited Cryptographic and Security Testing (CST) laboratory. The lab tests against 11 requirement areas defined by NIST, including:

• Cryptographic algorithm correctness (using CAVP - Cryptographic Algorithm Validation Program)
• Key management lifecycle
• Physical security (for hardware modules)
• Self-tests and error handling
• Roles, services, and authentication

The module is validated at one of four levels:

• Level 1 - Basic requirements, software-only modules
• Level 2 - Adds tamper evidence (physical coatings or seals) and role-based authentication
• Level 3 - Adds tamper resistance (active zeroization of keys when tampered) and identity-based authentication
• Level 4 - Adds environmental failure protection and the highest physical security requirements

Certificates are issued jointly by NIST (USA) and CCCS (Canada) through the Cryptographic Module Validation Program (CMVP).

When each is required

Common Criteria is typically required when:

• A government agency procures IT products under regulations that reference CC or ISO 15408
• A Protection Profile is mandated for a product category (e.g., NIAP requires PP conformance for US government network devices)
• EU regulations like the Cybersecurity Act or sector-specific rules reference EUCC (the EU’s CC-based scheme)
• Procurement RFPs specify EAL requirements

FIPS 140-3 is typically required when:

• US federal agencies procure products that handle sensitive (non-classified) information - mandated by FISMA and OMB policy
• Canadian federal agencies procure cryptographic products
• Financial, healthcare, or other regulated industries adopt FIPS as a baseline for cryptographic assurance
• DoD systems require FIPS-validated encryption for data at rest and in transit

Both are required when:

• A product has broad security functionality (warranting CC) and performs cryptography (warranting FIPS)
• Example: A VPN appliance might hold a CC certificate for its overall security architecture and a FIPS 140-3 validation for its IPsec/TLS cryptographic engine
• Example: A hardware security module (HSM) might carry both certifications

Key differences in practice

Flexibility vs. prescription. Common Criteria is flexible - the vendor defines their own security claims in the Security Target, and evaluations are scoped accordingly. FIPS 140-3 is prescriptive - every cryptographic module is tested against the same NIST-defined requirements.

Timeline. CC evaluations typically take 6-18 months depending on EAL level and product complexity. FIPS 140-3 validations have historically taken 12-24 months due to CMVP queue backlogs, though NIST has been working to reduce this.

Cost. Both are expensive. CC evaluations at EAL2-EAL4 typically range from $150K-$500K+. FIPS validations range from $50K-$300K+ depending on module complexity and testing scope.

International recognition. CC certificates are recognized across 31 CCRA nations. FIPS validations are primarily recognized in the US and Canada, though many other countries accept FIPS-validated cryptography as a baseline.

How they work together

In practice, many products carry both certifications. The certifications are independent - passing one does not grant or imply the other. However:

• A CC evaluation might reference FIPS validation as evidence that the cryptographic implementation is sound
• A Protection Profile might require that the TOE’s cryptographic module be FIPS-validated
• NIAP Protection Profiles for US government products frequently include FIPS 140 as a prerequisite

Tracking both

NenkinTracker currently focuses on Common Criteria certification tracking across all CCRA member schemes. If you need to monitor CC certifications across BSI, ANSSI, NIAP, and other schemes - with change detection and alerts - you can start tracking for free.

For FIPS 140-3, the authoritative source is the CMVP validated modules list maintained by NIST.

See also

• What is Common Criteria? — full background on the CC side of this comparison.
• Protection Profiles (PP) — how NIAP PPs often build FIPS 140 in as a prerequisite.
• Certification Schemes Overview — which CC schemes (notably NIAP) pair most often with FIPS.
• Common Criteria Certification Process Explained — what a CC evaluation looks like end-to-end.

Evaluation Assurance Levels - EAL1 through EAL7 - are one of the most visible aspects of Common Criteria certification. They appear in procurement requirements, vendor marketing materials, and compliance checklists. But they are also one of the most misunderstood.

This guide explains what each EAL level actually requires, what the practical differences are, and how to interpret EAL in procurement and compliance decisions.

What EAL measures (and what it does not)

An EAL indicates how thoroughly a product was evaluated, not how secure it is.

A product certified at EAL4 is not “more secure” than one at EAL2. It means the evaluation was more rigorous - more documentation was reviewed, more testing was performed, and more evidence was examined. A simple product evaluated at EAL4 and a complex product evaluated at EAL2 may offer equivalent real-world security for their respective use cases.

This distinction matters because procurement teams sometimes treat EAL as a linear security score, which leads to requirements like “must be EAL4 or higher” without considering whether the higher assurance level is relevant to the threat model.

The seven levels

EAL1Functionally tested

EAL2Structurally tested

EAL3Methodically tested

EAL4Source code reviewed

EAL5Semiformal design

EAL6Semiformal verified

EAL7Formally verified

EAL1 - Functionally tested

The lowest level. The evaluator confirms that the product functions as described in its documentation. No source code review, no design analysis, no vulnerability testing beyond what the documentation describes.

When it is used: Rarely in practice. EAL1 provides minimal assurance and is typically only seen in evaluations where any CC certificate is needed but cost must be minimized.

EAL2 - Structurally tested

The evaluator reviews the product’s high-level design, tests its security functions, and performs basic vulnerability analysis. The vendor must provide functional specifications, a high-level design document, and evidence of testing.

When it is used: Common for commercial products. EAL2 is the most frequently targeted level globally because it provides meaningful assurance without requiring source code access. Many CCRA schemes issue the majority of their certificates at EAL2.

EAL3 - Methodically tested and checked

Adds more structured testing and requires evidence that the development environment has basic security controls. The vendor must demonstrate that the product was developed using sound engineering practices.

When it is used: Less common than EAL2 or EAL4. EAL3 exists as a middle ground but is often skipped - vendors either stop at EAL2 or invest in EAL4.

EAL4 - Methodically designed, tested, and reviewed

The evaluator performs a source code review (or hardware design review), conducts independent vulnerability testing, and requires a detailed low-level design. The development environment must have documented security controls.

When it is used: This is the highest level commonly targeted for commercial products. EAL4 is widely considered the practical ceiling for products that are not designed specifically for government or military use. Smart cards, payment terminals, and government network devices frequently target EAL4 or EAL4+.

EAL5 - Semiformally designed and tested

Introduces semiformal methods - the security design must be expressed using a structured notation (not just prose). The evaluator performs more extensive covert channel analysis and the development environment must have strong configuration management.

When it is used: Primarily for products with high security requirements - smart card operating systems, high-assurance operating systems, and security-critical embedded systems. EAL5 evaluations are significantly more expensive and time-consuming than EAL4.

EAL6 - Semiformally verified design and tested

Requires a semiformal proof that the implementation corresponds to the formal security model. Adds structured vulnerability analysis and requires evidence of a structured development process with strong security controls.

When it is used: Very rare. Typically reserved for products used in high-security government applications or products that form part of critical national infrastructure.

EAL7 - Formally verified design and tested

The highest level. Requires formal (mathematical) methods to verify the security design. The evaluator must receive the complete implementation representation and verify it against a formal security model.

When it is used: Extremely rare. Only a handful of products worldwide have achieved EAL7. The cost and timeline are prohibitive for nearly all commercial products.

EAL augmentation (the ”+” notation)

You will often see certifications described as “EAL4+” or “EAL2+”. The + indicates that the evaluation included augmented assurance components - additional requirements beyond the base EAL level.

For example, EAL4+ ALC_DVS.2 means the product was evaluated at EAL4 with an additional requirement for development security controls at a higher level than EAL4 normally requires.

Common augmentations include:

• AVA_VAN.5 - Enhanced vulnerability analysis (going beyond the base level’s testing)
• ALC_DVS.2 - Stronger development security controls
• ALC_FLR.2/3 - Flaw remediation procedures

Augmentation is important because it allows vendors to strengthen specific areas without committing to a full higher EAL. A product at EAL4+ with enhanced vulnerability analysis may provide more relevant assurance for a specific threat model than a base EAL5 without augmentation.

Which EAL do I need?

The answer depends on your context:

Government procurement with specific requirements. If the procurement mandate or Protection Profile specifies an EAL level, use that. Many NIAP-approved Protection Profiles effectively require specific assurance activities that correspond to particular EAL ranges, even when they do not name an EAL directly.

Risk-based selection. Match the EAL to the threat environment. Products handling classified data or operating in adversarial environments warrant higher assurance. Products used in low-risk commercial environments may be adequately served by EAL2.

Practical ceiling. For most commercial procurement decisions, the relevant comparison is between EAL2 and EAL4 products. Below EAL2 offers limited assurance; above EAL4 involves exponentially increasing cost and timeline for incrementally increasing assurance.

Do not over-specify. Requiring EAL4 when EAL2 would suffice limits your vendor options and increases cost without proportional security benefit. Focus on what the evaluation actually tested - the Security Target scope and Protection Profile conformance - rather than the EAL number alone.

EAL distribution in practice

• EAL2 accounts for the largest share of active CC certificates globally
• EAL4 and EAL4+ is the second most common, particularly strong in smart card and payment terminal certifications (BSI and ANSSI issue many at this level)
• EAL5+ is primarily seen in smart card OS and secure microcontroller certifications from European schemes
• EAL1, EAL3, EAL6, and EAL7 are comparatively rare

Tracking EAL levels across schemes

NenkinTracker tracks EAL levels alongside all other certification metadata across CCRA member schemes. You can filter and compare products by assurance level, see how EAL distributions differ between schemes like BSI, ANSSI, and NIAP, and get alerted when certifications change.

Start tracking for free to see the current EAL landscape across all Common Criteria schemes.

See also

• Evaluation Assurance Levels (EAL) — compact reference for EAL1–EAL7 requirements.
• What is Common Criteria? — how EAL fits into the CC framework overall.
• Protection Profiles (PP) — pairing an EAL with a PP gives a complete evaluation target.
• Common Criteria Certification Process Explained — how EAL choice shapes timeline and cost.

Getting a product Common Criteria certified is a structured process involving multiple parties: the vendor (who builds the product), an evaluation lab (ITSEF - IT Security Evaluation Facility), and a national scheme body (who issues the certificate). Understanding this process matters whether you are pursuing certification for your own product or evaluating certified products for procurement.

Step 1

Preparation

Vendor selects EAL, writes Security Target, picks ITSEF.

→

Step 2

Evaluation

ITSEF reviews docs, tests, and issues Observation Reports.

→

Step 3

Certification

Scheme body reviews ETR and issues the certificate.

→

Step 4

Recognition

CCRA mutual recognition across 31 member nations.

The participants

Vendor (sponsor)

The organization that develops the product and pays for the evaluation. The vendor writes the Security Target, provides documentation and access to the product, and responds to evaluator questions throughout the process.

Evaluation lab (ITSEF)

An accredited laboratory that performs the technical evaluation. ITSEFs are accredited by national scheme bodies and must meet ISO 17025 standards. Major ITSEFs include Brightsight, TUViT, Serma Safety & Security, Leidos, and atsec.

National scheme body (certification body)

The government authority that oversees the evaluation process and issues the certificate. Examples include BSI (Germany), ANSSI (France), NIAP (USA), and CCCS (Canada). The scheme body reviews the evaluator’s findings and makes the final certification decision.

Step 1: Preparation

Before the formal evaluation begins, the vendor must:

Choose a target assurance level. This determines the depth and rigor of the evaluation. Most commercial products target EAL2 or EAL4. If a Protection Profile exists for the product category, the vendor should conform to it - many procurement requirements mandate PP conformance.

Write the Security Target (ST). The ST is the foundational document of a CC evaluation. It describes:

• The product being evaluated (the Target of Evaluation, or TOE)
• The security problem the product addresses (threats, assumptions, organizational policies)
• The security objectives and how the product meets them
• The security functional requirements (SFRs) - specific security behaviors
• The security assurance requirements (SARs) - what evidence and testing is required

Writing a good ST typically requires CC expertise. Many vendors work with consultants or their ITSEF to draft the ST.

Select an ITSEF. The vendor chooses an accredited lab. Factors include the lab’s experience with the product category, location, language, timeline, and cost.

Engage the scheme body. Depending on the national scheme, the vendor may need to register the evaluation upfront. Some schemes require a kickoff meeting.

Step 2: Evaluation

The ITSEF performs the evaluation according to the Common Evaluation Methodology (CEM) - the standardized methodology that defines exactly how each assurance requirement is tested.

Evaluation activities vary by EAL level but generally include:

Documentation review. The evaluator examines the ST, functional specifications, design documents, test documentation, and (at higher EALs) source code or hardware designs. The evaluator checks that the documentation is complete, consistent, and supports the security claims.

Functional testing. The evaluator independently tests the product’s security functions. This goes beyond the vendor’s own testing - the evaluator designs test cases based on the security functional requirements and executes them against the product.

Vulnerability analysis. The evaluator searches for vulnerabilities in the product’s design and implementation. The depth of this analysis increases with the EAL level. At EAL2, this is a basic analysis of public vulnerability information. At EAL4+, it includes source code review and penetration testing.

Development environment review. At EAL3 and above, the evaluator examines the vendor’s development practices - configuration management, delivery procedures, and development security controls.

Throughout the evaluation, the ITSEF produces an Evaluation Technical Report (ETR) documenting their findings, verdicts, and any issues discovered.

Observation Reports (ORs)

When the evaluator finds issues - incomplete documentation, failed test cases, design weaknesses - they issue Observation Reports. The vendor must address each OR before the evaluation can proceed. ORs are a normal part of the process and do not necessarily indicate a failed evaluation, but resolving them can extend the timeline.

Step 3: Certification

Once the ITSEF completes the evaluation and submits the ETR, the national scheme body reviews the findings.

The scheme body:

• Reviews the ETR for completeness and compliance with the CEM
• May request additional clarification from the ITSEF
• Verifies that the evaluation was conducted properly
• Makes the final certification decision

If approved, the scheme body issues a Common Criteria certificate and publishes a Certification Report (sometimes called a Validation Report in NIAP terminology). The certificate is typically listed on the national scheme’s website and on the Common Criteria Portal.

Step 4: Mutual recognition

Through the CCRA, certificates issued by one member nation are recognized by all other members. This means a product certified by BSI in Germany is accepted in the USA, France, Canada, South Korea, and 26 other nations - without requiring re-evaluation.

However, mutual recognition has limits:

• The CCRA currently recognizes certificates up to EAL2 + ALC_FLR for most product categories
• Higher EAL levels are mutually recognized only if the product conforms to a collaborative Protection Profile (cPP) endorsed by the CCRA
• Some nations have additional domestic requirements beyond CCRA recognition

Timeline and cost

Typical timelines

EAL Level	Typical duration	Notes
EAL2	6-12 months	Fastest path for commercial products
EAL4	12-18 months	Source code review adds significant time
EAL5+	18-36 months	Semiformal methods require specialized effort

These timelines include preparation, active evaluation, and certification decision. Actual durations vary significantly based on product complexity, documentation readiness, the number of Observation Reports, and scheme body queue times.

Cost factors

• Lab fees - the ITSEF’s evaluation work (largest cost component)
• Consulting - ST writing, evaluation preparation, and remediation support
• Vendor effort - internal time spent on documentation, OR responses, and product modifications
• Scheme fees - some national schemes charge certification and listing fees

Total costs range from approximately $100K for a straightforward EAL2 evaluation to $500K+ for EAL4 with complex products. EAL5+ costs can exceed $1M.

After certification

A CC certificate is not permanent. Key post-certification activities include:

Maintenance. If the vendor makes minor changes to a certified product (bug fixes, configuration updates), they can apply for a maintenance update without a full re-evaluation. The ITSEF reviews the changes, and if they do not affect the security functionality, the scheme body updates the certificate.

Re-evaluation. Major product changes (new features, architecture changes, new platforms) typically require a new evaluation. Some schemes offer an assurance continuity process that leverages previous evaluation work to reduce the scope and cost of re-evaluation.

Expiration and archival. Certificates can expire (typically after 5 years, though this varies by scheme) or be archived if the vendor does not maintain them. Expired and archived certificates remain publicly listed but are no longer considered active.

Monitoring the certification landscape

Tracking which products are certified, when certificates expire, and when maintenance updates occur is a significant operational task - especially when monitoring across multiple national schemes.

NenkinTracker automates this by aggregating certification data from all CCRA member schemes into one dashboard with change detection and alerts. Start tracking for free.

See also

• What is Common Criteria? — background on the ISO/IEC 15408 framework underlying the process.
• Evaluation Assurance Levels (EAL) — how EAL targets shape scope, duration, and cost of an evaluation.
• Protection Profiles (PP) — selecting a PP to target before evaluation begins.
• Common Criteria Schemes by Country — how BSI, ANSSI, NIAP, and others differ in process and focus.

The European Union Common Criteria-based Cybersecurity Certification Scheme (EUCC) is a new certification framework under the EU Cybersecurity Act (Regulation 2019/881). It represents the most significant structural change to Common Criteria certification in Europe since the CCRA was established.

For teams working with Common Criteria certified products - whether in procurement, compliance, or product security - the EUCC introduces changes to how certificates are issued, recognized, and maintained within the EU.

What is the EUCC?

The EUCC is the first EU-wide cybersecurity certification scheme adopted under the Cybersecurity Act. It is built on Common Criteria (ISO/IEC 15408) and the Common Evaluation Methodology (CEM), but wraps them in an EU regulatory framework that standardizes processes, governance, and recognition across all EU member states.

The scheme was formally adopted as Commission Implementing Regulation (EU) 2024/482 and applies to ICT products (hardware, software, and combined products).

Why the EUCC matters

Before the EUCC, Common Criteria certification in Europe was handled by national schemes - BSI in Germany, ANSSI in France, OCSI in Italy, NSCIB in the Netherlands, and others. Each scheme had its own processes, timelines, and administrative requirements, even though they all evaluated against the same ISO 15408 standard.

The EUCC aims to:

1. Unify the European CC landscape - One regulatory framework replaces the patchwork of national scheme practices
2. Ensure EU-wide recognition - EUCC certificates are valid across all EU member states without additional national requirements
3. Align with EU cybersecurity policy - The scheme integrates with other EU regulations like the Cyber Resilience Act (CRA) and NIS2 Directive
4. Standardize governance - National Cybersecurity Certification Authorities (NCCAs) operate under harmonized rules

Two assurance levels

The EUCC defines two assurance levels, mapped from Common Criteria:

Substantial

Maps to: EAL1-EAL4

• Certificates issued by accredited CABs (labs)
• NCCA oversight, not direct issuance
• Target for most commercial products

High

Maps to: EAL4+ and above

• Requires NCCA to issue or approve
• Protection Profile conformance expected
• Government, critical infrastructure, HSMs

”Substantial” level

• Corresponds to CC evaluation at EAL1-EAL4 (or equivalent)
• Certificates are issued by conformity assessment bodies (CABs) - essentially accredited evaluation labs
• The NCCA in each member state oversees the CABs but does not issue certificates directly at this level
• Most commercial products will target this level

”High” level

• Corresponds to CC evaluation at EAL4+ and above (with specific augmentations)
• Certificates at this level require NCCA involvement - the national authority must either issue or approve the certificate
• Intended for products with higher security requirements, government use, or critical infrastructure
• Protection Profile conformance is generally expected at this level

What changes from existing CC practice

Certificate issuance

Under existing CCRA practice, certificates are issued by national scheme bodies (BSI, ANSSI, etc.). Under the EUCC, “substantial” level certificates can be issued directly by accredited CABs (evaluation labs), without the national scheme body acting as certificate issuer. “High” level certificates still require NCCA involvement.

Validity period

EUCC certificates have a maximum validity of 5 years. After that, they must be renewed or they expire. This is more prescriptive than some existing national schemes, which may allow certificates to remain active indefinitely if maintained.

Vulnerability disclosure

The EUCC requires certificate holders to have processes for handling vulnerability reports related to certified products. If a significant vulnerability is discovered, the certificate may be suspended or withdrawn.

Marking

Products with EUCC certificates may carry an EU cybersecurity certification mark, indicating the assurance level achieved. This provides visual recognition for procurement teams.

Monitoring

NCCAs must perform ongoing compliance monitoring - not just certify-and-forget. This includes market surveillance and the ability to challenge or revoke certificates.

Impact on existing CC certificates

Existing Common Criteria certificates issued by national schemes remain valid. The EUCC does not retroactively invalidate BSI, ANSSI, or other national certificates.

However:

• New evaluations conducted under the EUCC framework will follow EUCC rules for issuance, maintenance, and validity
• National schemes may continue to operate in parallel for products that do not need EU-wide EUCC certification
• Over time, procurement requirements within the EU may increasingly reference EUCC certificates specifically, rather than generic CC certificates

Who is affected

Vendors seeking certification

If you sell IT products in the EU and your customers require CC certification, you will increasingly need to consider the EUCC pathway. This is especially true if your products fall under other EU regulations (Cyber Resilience Act, NIS2) that may mandate or reference EUCC certification.

Procurement teams

EU government procurement will likely shift toward requiring EUCC certificates. Understanding the difference between “substantial” and “high” assurance levels - and how they map to existing EAL levels - will be important for writing accurate procurement requirements.

Evaluation labs

ITSEFs operating in the EU must be accredited as CABs under the EUCC to issue “substantial” level certificates. This adds new accreditation requirements beyond existing ISO 17025 and CC scheme recognition.

Compliance teams

If you track CC certifications for compliance purposes, EUCC introduces a new certificate type to monitor. Products may hold both a traditional national CC certificate and a EUCC certificate, or transition from one to the other.

Relationship to other EU regulation

The EUCC does not exist in isolation. It is part of a broader EU cybersecurity regulatory framework:

• Cyber Resilience Act (CRA) - Mandates cybersecurity requirements for products with digital elements sold in the EU. The CRA may reference EUCC as a presumption-of-conformity pathway.
• NIS2 Directive - Requires essential and important entities to use cybersecurity-certified products where available. EUCC certification may satisfy these requirements.
• EU Cybersecurity Act - The parent regulation that establishes the framework for EU certification schemes. The EUCC is the first scheme adopted under it; others (for cloud services, for example) may follow.

Tracking EUCC and CC certifications

As the EUCC rolls out alongside existing national CC schemes, tracking the certification landscape becomes more complex. Products may hold certificates from different frameworks, and understanding which certificates are active, expiring, or superseded requires monitoring multiple sources.

NenkinTracker already tracks certifications from EUCC and major national CC schemes including BSI, ANSSI, NIAP, and others. As the EUCC matures, we will continue expanding our coverage.

Start tracking certifications for free to stay current on both EUCC and traditional CC certificates.

See also

• Certification Schemes Overview — EUCC in context with the national schemes it sits alongside.
• What is Common Criteria? — the CC framework EUCC is built on top of.
• Common Criteria Schemes by Country — deeper look at the national schemes that remain in play under EUCC.
• Common Criteria Certification Process Explained — how a traditional CC evaluation flows, for comparison.

Common Criteria certifications are issued by national scheme bodies around the world. While all schemes evaluate against the same standard (ISO/IEC 15408) using the same methodology (CEM), they differ in size, focus, administrative processes, and the types of products they commonly certify.

This guide covers the major CC schemes, what makes each one distinctive, and how they participate in mutual recognition through the CCRA.

CCRA membership

The Common Criteria Recognition Arrangement has two types of members:

• Certificate Authorizing members can both issue and consume CC certificates. These are nations with active evaluation schemes.
• Certificate Consuming members accept certificates from authorizing nations but do not run their own evaluation scheme.

As of 2024, 31 nations participate in the CCRA. The certificate-authorizing members operate the schemes described below.

Major certificate-authorizing schemes

BSI - Germany

Bundesamt für Sicherheit in der Informationstechnik

BSI is one of the two largest CC schemes globally by volume of certificates issued. It is particularly strong in smart card, secure microcontroller, and hardware security module (HSM) certifications.

Key characteristics:

• Certifies at all EAL levels, with significant activity at EAL4+ and EAL5+ for smart card platforms
• Home scheme for major European chip manufacturers (Infineon, NXP) and smart card vendors (Giesecke+Devrient, IDEMIA)
• Operates under German IT security law and is part of the Federal Ministry of the Interior
• Known for thorough technical evaluations, particularly in the hardware security domain
• Publishes certifications and certification reports on the BSI website and the CC Portal

Common product types: Smart cards, secure elements, HSMs, operating systems, network devices, payment terminals

ANSSI - France

Agence nationale de la sécurité des systèmes d’information

ANSSI operates the French CC scheme and is a major certifier, particularly for defense, government, and high-assurance products.

Key characteristics:

• Strong tradition in formal methods and higher-EAL evaluations
• Certifies products for French government and defense use
• Qualification alongside certification - ANSSI maintains a “qualified products” list (Produits Qualifiés) for products that meet additional French government security requirements beyond CC
• Active participant in EUCC development as the French NCCA
• Publishes certifications on the ANSSI website (Certifications de Sécurité)

Common product types: Encryption products, secure communications, smart cards, firewalls, operating systems, government IT infrastructure

NIAP - United States

National Information Assurance Partnership

NIAP operates the US CC scheme and has taken a distinctive approach: since 2014, NIAP has required all evaluations to conform to approved Protection Profiles rather than allowing vendor-defined EAL targets.

Key characteristics:

• PP-based evaluations only - vendors must conform to a NIAP-approved Protection Profile; standalone EAL evaluations are not accepted
• Maintains an extensive library of collaborative Protection Profiles (cPPs) and NIAP PPs covering product categories from firewalls to mobile devices
• Products Compliant List (PCL) - the official list of NIAP-validated products, often referenced in US government procurement
• Evaluations performed by NIAP-accredited Common Criteria Testing Laboratories (CCTLs) in the US
• Strong alignment with US government procurement requirements (DoD, federal civilian agencies)

Common product types: Network devices (firewalls, VPN gateways, routers), operating systems, mobile devices, application software, virtualization platforms

CCCS - Canada

Canadian Centre for Cyber Security

CCCS (formerly CSE - Communications Security Establishment) operates Canada’s CC scheme, closely aligned with NIAP’s PP-based approach.

Key characteristics:

• Participates in CMVP (Cryptographic Module Validation Program) alongside NIST for FIPS 140 validations
• PP-based evaluations aligned with NIAP’s approach
• Smaller volume than BSI or ANSSI but produces high-quality evaluations
• Evaluations performed by accredited Canadian evaluation facilities

OCSI - Italy

Organismo di Certificazione della Sicurezza Informatica

OCSI operates the Italian CC scheme, active in digital identity, electronic signature, and payment product certifications.

Key characteristics:

• Certifies products for Italian and EU government use
• Strong in electronic identity (eID) and digital signature products
• Active participant in EUCC as the Italian NCCA
• Growing volume of certifications in recent years

CCN - Spain

Centro Criptológico Nacional

CCN operates the Spanish CC scheme, focused on products for Spanish government and defense use.

Key characteristics:

• Maintains the STIC (Sistemas de las Tecnologías de la Información y las Comunicaciones) catalog of certified products
• Strong focus on encryption and secure communications for government
• Evaluations conducted by Spanish accredited labs

NSCIB - Netherlands

Netherlands Scheme for Certification in the area of IT Security

NSCIB is a well-regarded European scheme with significant smart card and payment terminal certification activity.

Key characteristics:

• Home scheme for NXP Semiconductors and several major smart card evaluation labs
• Operated by TUV Rheinland Nederland
• Strong in smart card, secure element, and payment device certifications

JISEC - Japan

Japan Information Technology Security Evaluation and Certification Scheme

JISEC operates the Japanese CC scheme, managed by IPA (Information-technology Promotion Agency).

Key characteristics:

• Certifies products for Japanese government procurement
• Cooperates with Asian CCRA members
• Publishes certifications in both Japanese and English

Other notable schemes

Country	Scheme	Notable focus
South Korea	KECS	Government IT, encryption products
Australia	ASD	Defense and government products
India	STQC	Growing scheme, government IT
Sweden	FMV	Defense-focused
Norway	SERTIT	Government and defense
Singapore	CSA	Regional hub for Asian evaluations
Malaysia	CyberSecurity Malaysia	Regional evaluations
Turkey	TSE	Growing scheme

How schemes differ in practice

Evaluation focus

BSI and ANSSI are known for deep technical evaluations, particularly at higher EAL levels. NIAP focuses on practical, threat-relevant testing through Protection Profiles. Some smaller schemes may rely more heavily on the evaluation lab’s expertise.

Timeline

Processing times vary. BSI and ANSSI typically process certifications within weeks of evaluation completion. Other schemes may have longer administrative queues. NIAP has historically been relatively fast for PP-based evaluations.

Cost

Evaluation costs are primarily driven by lab fees, which vary by country and lab. Administrative fees charged by scheme bodies also vary - some schemes charge nominal fees, while others have significant certification fees.

Language

Most schemes accept documentation in English, but some may prefer or require documentation in the national language. BSI accepts German and English; ANSSI typically requires French for higher-assurance evaluations.

Tracking certifications across schemes

Monitoring the full CC certification landscape means tracking certificates from all of these schemes simultaneously. Each scheme publishes certifications on their own website, in their own format, and often with different metadata structures.

NenkinTracker aggregates certification data from all major CCRA member schemes into a unified view. Instead of checking BSI, ANSSI, NIAP, and other scheme websites individually, you get one dashboard with change detection and alerts.

Start tracking for free to see certifications across all schemes in one place.

See also

• Certification Schemes Overview — quick reference for the schemes covered here.
• What is Common Criteria? — the shared ISO/IEC 15408 framework all schemes evaluate against.
• EUCC: What the EU Cybersecurity Certification Scheme Means for Common Criteria — how EU-level certification sits alongside national schemes.
• Common Criteria vs FIPS 140-3: What’s the Difference? — how CC relates to the other main evaluation standard.

We are excited to launch the Nenkin blog. This is where we will share practical guides, industry news, and insights about Common Criteria certification tracking.

What to expect

Our content will focus on topics that matter to security, compliance, and procurement teams working with Common Criteria certified products:

• Guides - How to evaluate CC certified products, understand EAL levels, and navigate the certification landscape
• Industry news - Updates on certification schemes, new Protection Profiles, and regulatory changes like EUCC
• Best practices - Tips for streamlining CC compliance workflows and reducing manual tracking overhead

Why we are writing

Common Criteria is a complex domain with fragmented information spread across national scheme portals, ISO standards, and CCRA documentation. We want to make this knowledge more accessible and help teams make better decisions when working with CC certified products.

Stay updated

Check back regularly for new articles, or subscribe to our RSS feed to stay informed.

See also

• What is Common Criteria? — a solid starting point if you are new to CC.
• Common Criteria Certification Process Explained — how a certification actually gets issued.
• Guide to EAL Levels: What EAL2, EAL4, and EAL5+ Actually Mean — making sense of EAL1–EAL7 in procurement.
• EUCC: What the EU Cybersecurity Certification Scheme Means for Common Criteria — the biggest regulatory change in CC today.