What is Common Criteria?
Common Criteria is an international framework for independently evaluating the security claims of information technology products. It aligns with the ISO/IEC 15408 series of international standards for IT security evaluation and provides a consistent way to define security requirements and assess whether a product meets them.
A Common Criteria evaluation does not assign a general security score to a product. Instead, it examines a defined product or component against documented security requirements and assurance activities. The resulting certification helps buyers understand what was evaluated, which security claims were assessed, and how rigorously those claims were examined.
This can be particularly important when selecting technology for government, regulated, or high-assurance environments. Common Criteria certification provides evidence about a defined evaluation scope rather than a blanket assessment of every product or deployment from a vendor.
Learn more about how Common Criteria relates to FIPS 140-3, ISO/IEC 27001, and other frameworks in Security Certifications and Standards.
What Is ISO/IEC 15408?
ISO/IEC 15408, Information security, cybersecurity and privacy protection — Evaluation criteria for IT security, is the international standard that aligns with the Common Criteria framework.
The current edition, ISO/IEC 15408:2026, has five parts:
- Part 1: Introduction and general model
- Part 2: Security functional components
- Part 3: Security assurance components
- Part 4: Framework for specifying evaluation methods and activities
- Part 5: Pre-defined packages of security requirements, including the Evaluation Assurance Levels
“Common Criteria” is the widely used name. ISO/IEC 15408 is the formal standard reference.
The Core Language of Common Criteria Compliance
Common Criteria uses several terms to describe what is being evaluated, what the product is expected to do, and how assurance in those claims is established.
- Target of Evaluation (TOE): The product, system, component, or defined portion of a product being evaluated.
- Security Target (ST): The product-specific document that defines the TOE, its security requirements, and the claims being submitted for evaluation.
- Protection Profile (PP): An implementation-independent set of security requirements for a category of products.
- Security Functional Requirements (SFRs): Requirements that define the security functions the TOE is expected to provide.
- Security Assurance Requirements (SARs): Requirements used to establish confidence that the TOE satisfies its stated security requirements.
- Evaluation Assurance Level (EAL): A predefined package of assurance requirements that indicates the depth and rigor of an evaluation.
The TOE establishes the evaluation boundary, while the Security Target documents product-specific claims. An applicable Protection Profile can provide common requirements for a product category. SFRs define required security behavior, and SARs establish how to evaluate that behavior.
The Common Criteria Portal provides the official specifications and supporting documentation.
What Are the Common Criteria Evaluation Assurance Levels?
Common Criteria defines seven predefined Evaluation Assurance Levels, from EAL1 through EAL7. As the levels increase, so do the scope, depth, and rigor of the assurance activities involved in the evaluation.
An EAL is not a security ranking. Two products can be evaluated at the same level while providing different security functions or addressing different risks.
| EAL | Assurance Focus |
|---|---|
| EAL1 | Functionally tested: Provides a basic level of independently evaluated assurance, including independent testing of security functionality. |
| EAL2 | Structurally tested: Adds developer design information, testing evidence, and vulnerability analysis. |
| EAL3 | Methodically tested and checked: Expands testing, development evidence, configuration management, and other assurance activities. |
| EAL4 | Methodically designed, tested, and reviewed: Requires more detailed design evidence, testing, vulnerability analysis, and development controls. |
| EAL5 | Semi-formally designed and tested: Adds greater design formality and more rigorous development and evaluation activities. |
| EAL6 | Semi-formally verified design and tested: Applies more extensive verification and analysis for products requiring high levels of assurance. |
| EAL7 | Formally verified design and tested: Uses the most rigorous predefined EAL package, including extensive formal analysis and verification. |
The appropriate EAL depends on the product and the requirements governing its use. A higher EAL can require significantly more evaluation effort, but the highest available level is not automatically necessary for every enterprise environment.
What Does It Take to Be Common Criteria Certified?
The details vary by certification scheme and product, but the process generally includes four stages.
- Define the TOE and security claims: The developer or sponsor establishes the evaluation boundary and prepares a Security Target describing the product and its security requirements.
- Identify applicable requirements: The evaluation identifies the relevant functional and assurance requirements and, where applicable, conformance to a Protection Profile.
- Complete the independent evaluation: An approved evaluation facility examines the TOE and supporting evidence using Common Criteria and the applicable evaluation methodology. This can include documentation review, independent testing, and vulnerability analysis.
- Complete certification review: The certification body reviews the evaluation results and can issue a certificate when the applicable requirements have been satisfied.
For buyers, the certificate is only part of the evidence. The Security Target and supporting certification documentation identify what was evaluated, the assurance claim, any applicable Protection Profile, and the conditions covered by the evaluation.
For HSMs used by trust service providers, EN 419 221-5 is one example of a Protection Profile that establishes common security requirements for a product category.
Entrust nShield HSMs and Common Criteria
Hardware security modules provide protected environments for cryptographic key generation, protection, and processing. Common Criteria certification can provide independent assurance for HSMs used in regulated or high-assurance environments.
Entrust nShield 5s is certified to Common Criteria EAL4+, augmented with additional assurance requirements, against the EN 419 221-5 Protection Profile for cryptographic modules used by trust service providers. Entrust nShield 5c supports Common Criteria configurations using certified nShield 5s firmware.
The certification is also relevant to eIDAS use cases. The certified nShield configuration can form the basis of remote-signing systems designed to meet applicable qualified electronic signature and seal requirements.
Organizations with a specific certification requirement should review current Entrust certification documentation to confirm that the product and evaluated configuration match the needs of the deployment.
Explore Entrust nShield HSMs or review current Common Criteria certification information.
Common Criteria FAQs
What Does EAL4+ Mean?
EAL4+ means an evaluation uses the EAL4 assurance package with specified additional assurance requirements. The “+” does not represent a separate level between EAL4 and EAL5.
The additional requirements depend on the certification. For Entrust nShield 5s, EAL4 is augmented with AVA_VAN.5, which addresses advanced methodical vulnerability analysis, and ALC_FLR.2, which addresses flaw reporting procedures.
What EAL Is Required for Enterprise Security?
There is no single Evaluation Assurance Level required for every enterprise environment. The appropriate level depends on the technology, intended use, threat environment, applicable Protection Profile, and any procurement, customer, regulatory, or contractual requirements.
Organizations should start with the requirements that apply to the deployment rather than selecting the highest available EAL by default. The product's Security Target and certification documentation can then help determine whether the evaluated claims and assurance level match those requirements.
What Is the Difference Between Common Criteria and FIPS 140-3?
Common Criteria and FIPS 140-3 address different security-assurance needs.
Common Criteria can evaluate a defined IT product or component against specified security functional and assurance requirements. The scope depends on the Target of Evaluation, Security Target, applicable Protection Profile, and assurance requirements used in the evaluation.
FIPS 140-3 focuses specifically on cryptographic modules. It establishes security requirements for those modules, which are tested by accredited laboratories and validated through the Cryptographic Module Validation Program.
For HSM buyers, both may matter. Common Criteria can provide assurance against defined product-security requirements and an applicable Protection Profile, while FIPS 140-3 provides validation against cryptographic-module requirements. The relevant certification or validation depends on the requirements of the deployment.
Learn more about FIPS 140-3 requirements and validation.
How Long Does Common Criteria Certification Take?
Timelines vary widely. Many evaluations take from several months to more than a year. The main factors are:
- EAL and assurance requirements: Higher levels need more analysis and testing.
- TOE complexity: More complex products take longer to test and evaluate.
- Documentation readiness: Complete, high-quality developer evidence reduces delays.
- Protection Profile conformance: Claiming conformance to a Protection Profile shapes the requirements and the testing.
- Lab and scheme capacity: How available the evaluation facility and certification body are.
A pre-evaluation readiness review can find gaps early and help keep the formal evaluation on schedule.
What Is EUCC?
EUCC is the EU-wide cybersecurity certification scheme based on Common Criteria. It came into force in February 2025 and provides a common approach to certifying ICT products across EU member states.
Ready to get started? Reach out to our team today.
Legislative and regulatory requirements can vary by jurisdiction, industry, product, and use case and may change over time. The information provided on this page is for general informational purposes only and reflects our understanding as of the date of publication. It does not constitute, and should not be relied upon as, legal, regulatory, or compliance advice. You should consult your own legal, compliance, or regulatory advisors regarding any questions or requirements that may apply to your business.