Common Criteria Certification Process Explained
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.
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.