For many government and defense buyers, a Common Criteria certificate is not a nice-to-have. It is the price of entry. If your product cannot show one, the deal is often over before the conversation starts.
Here is the tension most vendors discover too late: Common Criteria sits on top of your cryptographic foundation. A weakness in your FIPS validation status does not stay contained. It can quietly become a Common Criteria problem, surfacing right when a lab starts probing your Security Target.
Common Criteria is adopted as ISO/IEC 15408:2022, the internationally recognized framework for evaluating IT product security. This guide walks through what it is, why it matters, how it maps to cryptography, how to prepare for audit, and how it connects back to FIPS 140-3.
What Common Criteria (ISO/IEC 15408) is
Common Criteria is a structured way to demonstrate that a defined product configuration, the Target of Evaluation, meets the specific security claims made about it, verified by an accredited third party rather than the vendor.
The mechanics are straightforward. Vendors specify security requirements in a Security Target, which is often built from a published Protection Profile. An accredited testing laboratory then independently verifies that the product actually meets those claims. Certificates issued under the Common Criteria Recognition Arrangement (CCRA) are mutually recognized across signatory nations, so a product avoids duplicate evaluations in every market it enters.
A few roles keep the system honest:
- National Certification Bodies issue certificates based on a lab’s evaluation: NIAP (operating the US CCEVS scheme), BSI in Germany, CCCS in Canada. Rules differ. NIAP accepts only Protection Profile-based evaluations, so an EAL-only Security Target is not a route into the US market.
- Accredited Testing Laboratories perform the evaluation against a product’s Security Target. The label is scheme-specific: CCTL in the US, CCEF in Canada, ITSEF in Germany and under the EUCC.
Who this applies to and where
Common Criteria is international in scope. The CCRA spans roughly 31 countries, the scheme is the Common Criteria Evaluation and Validation Scheme (CCEVS), administered by the National Information Assurance Partnership (NIAP) and operated by the NSA. Labs perform the evaluation; NIAP validates the result and issues the certificate.
It applies most directly to IT product vendors seeking evaluation against a published Protection Profile, including operating systems, network devices, database systems, mobile device management, email, VPN, and firewall products. National certification bodies and Accredited Testing Laboratories round out the ecosystem.
If you want to go to the primary sources, the ones that matter here are ISO/IEC 15408:2022 (Parts 1 through 5), NIAP-approved Protection Profiles such as the Network Device cPP and the Full Drive Encryption cPP, and NIAP Policy Letter #5, which coordinates Common Criteria cryptographic assurance activities with NIST’s CAVP and CMVP.
Why Common Criteria matters for cryptographic evaluation
The business case is blunt: for government and defense buyers worldwide, certification is frequently a literal procurement gate, not a matter of interpretation. Many national procurement rules cite it directly as a baseline requirement for categories like network devices, VPN gateways, and mobile device management platforms.
Requirements do differ by scheme. This guidance follows NIAP, the U.S. scheme. European schemes such as BSI and ANSSI apply their own cryptographic guidance rather than CAVP.
The cryptographic connection is what trips people up. Cryptography-specific Protection Profiles, and the Security Functional Requirements in the FCS class, commonly assume the underlying algorithms have already been validated through NIST’s Cryptographic Algorithm Validation Program (CAVP) or CMVP. NIAP Policy Letter #5 formalizes that relationship. A Common Criteria evaluation is not a substitute for CAVP or CMVP validation. It builds on top of it.
How Common Criteria maps to cryptography
ISO/IEC 15408 addresses cryptography through several interlocking control areas. Each one has a direct cryptographic implication. Some are supported by tooling; others are process obligations that sit with your development and compliance teams and cannot be bought.
| Control area | What it requires |
|---|---|
| Security Target cryptographic requirements (15408-2, Class FCS) | Specify the algorithms, key sizes, and operations the Target of Evaluation must implement, and how a lab will verify them. |
| Protection Profile conformance | Map cryptographic capabilities to the specific Protection Profile a product is evaluated against, prewired for the lab’s assurance activities. |
| Underlying CAVP/CMVP validation (NIAP Policy Letter #5) | Ensure the algorithms and modules referenced in the Security Target already hold current CAVP and CMVP validation before evaluation begins. |
| Configuration management over cryptographic components (15408-3, Class ALC) | Demonstrate configuration management and lifecycle controls over the cryptographic components inside the certified product boundary. |
| Assurance continuity after cryptographic changes (CCDB, NIAP) | Track algorithm updates and library patches against the certified baseline to decide when re-evaluation or an Assurance Continuity review is triggered. |
| Signed product releases ( FPT_TUD_EXT.1 and FPT_TUD_EXT.2, trusted update) | Cryptographically sign patches and updates so customers can verify a release still matches the evaluated baseline. |
The pattern across all six areas is the same: your cryptography has to be defined, validated, controlled, and traceable, not just present.
The FIPS dependency you cannot skip
This is the coupling that stalls evaluations. Because most Protection Profiles fold in cryptographic assurance activities that assume CAVP or CMVP-validated algorithms, a gap in FIPS validation status becomes a gap in Common Criteria evaluation.
Put plainly: a product cannot cleanly pass Common Criteria evaluation while its cryptographic module sits unvalidated or has slipped onto the CMVP Historical List. Existing certificates are not retroactively invalidated, but after that date a 140-2 certificate no longer supports new federal acquisitions, and current CMVP review times run well over a year. Most cPPs require current, active CAVP and CMVP validation to satisfy the FCS assurance activities, so a lapsed certificate can stall or block certification depending on the applicable Protection Profile.
There is a deadline attached to this risk. Modules still on FIPS 140-2 face the September 21, 2026 CMVP Historical List transition, which can undermine an existing certificate. If your evaluation depends on one of those modules, the migration clock is already running. (When the FIPS 140-3 chapter is published, this is the natural place to link to it for a deeper walkthrough.)
Common Criteria audit readiness: what assessors probe
Evaluators work on demonstrated evidence, not policy statements alone. Every Common Criteria evaluation runs through an accredited laboratory, with the scheme validating the result. There is no self-assessment path and no regulator-run alternative. The six areas below are what the lab and the validator probe. Treat them as a checklist:
- Security Target cryptographic accuracy. Does the Security Target accurately describe the algorithms, modes, and key sizes actually implemented in the shipping product?
- Underlying CAVP/CMVP status. Do the referenced algorithms and modules hold current, active CAVP and CMVP validation?
- Protection Profile assurance activity evidence. Is there test evidence for every cryptographic assurance activity in the applicable Protection Profile?
- Configuration management documentation. Does ALC-class documentation show control over the cryptographic components inside the evaluated boundary?
- Assurance continuity change tracking. Is there a process to decide when a library update or algorithm change triggers a review or a full re-evaluation?
- Patch signing and version matching. Are patches signed, and does the deployed version match what the certificate covers?
How Keyfactor can help
Pull the mapping together and a clear operating model emerges. AgileSec supports cryptographic discovery and assurance continuity. Keyfactor Command handles certificate and key lifecycle management. EJBCA delivers PKI built on validated modules. SignServer and Signum sign product releases.
There is a useful shortcut worth calling out. EJBCA ships with a Common Criteria certificate against the NIAP Protection Profile for Certification Authorities and appears on the CSfC Components List. That means the certificate authority function arrives pre-evaluated, rather than becoming yet another component inside your own evaluation scope.
The value is a continuous, evidence-ready view of the cryptography behind a certificate, instead of point-in-time scrambling in the weeks before an audit.
Conclusion and next steps
Common Criteria rewards vendors who treat cryptography as a governed, continuously evidenced foundation, and it exposes those who do not. The certificate at the end is really a byproduct of that discipline.
Start where the risk concentrates. Assess your cryptographic inventory and FIPS validation status well ahead of evaluation, confirm your Security Target matches what actually ships, and make sure every referenced module holds current, active validation. From there, map each control area to a repeatable process rather than a one-time audit sprint.
Ready to see how Keyfactor supports each Common Criteria control area? Request a Demo.
Got Common Criteria questions? We’ve got answers.
What is Common Criteria (ISO/IEC 15408)?
Common Criteria is the internationally recognized framework for evaluating IT product security, adopted as ISO/IEC 15408:2022. Vendors define requirements in a Security Target, and an accredited lab independently verifies that the product meets those claims.
What is a Security Target versus a Protection Profile?
A Security Target states the security requirements a specific product claims to meet, and it is often built from a published Protection Profile. A Protection Profile is a standardized set of requirements for a product category, such as the Network Device cPP or Full Drive Encryption cPP. Where a Protection Profile applies, the Security Target must claim exact conformance to it, meaning it cannot add or drop mandatory requirements.
Does Common Criteria replace FIPS 140-3 validation?
No. NIAP Policy Letter #5 makes clear that a Common Criteria evaluation is not a substitute for CAVP or CMVP validation. The underlying algorithms and modules should already hold current validation before evaluation begins.
Why do buyers require Common Criteria certification?
For government and defense buyers worldwide, certification is frequently a literal procurement gate. Many national procurement rules cite it directly as a baseline for categories like network devices, VPN gateways, and mobile device management platforms.
Are Common Criteria certificates recognized across countries?
Yes. Certificates issued under the Common Criteria Recognition Arrangement are mutually recognized across signatory nations, spanning roughly 31 countries, so vendors avoid duplicate evaluations in each market.
What do assessors look for in a Common Criteria evaluation?
Assessors focus on demonstrated evidence, including Security Target accuracy, active CAVP/CMVP status, Protection Profile assurance activity evidence, configuration management documentation, assurance continuity change tracking, and patch signing with version matching.
What happens to a certificate when we change cryptography?
Cryptographic changes are tracked against the certified baseline under the CCDB assurance continuity requirements and your scheme’s maintenance policy. . Depending on the change, this can trigger an Assurance Continuity review or a full re-evaluation.
How does the CMVP Historical List affect a Common Criteria certificate?
A product cannot cleanly pass evaluation while its cryptographic module sits unvalidated or has moved to the CMVP Historical List. Modules still on FIPS 140-2 face the September 21, 2026 transition, so plan migration ahead of that date.
