Common Criteria for Information Technology Security Evaluation (CC:2022)

Why does it matter?

A Common Criteria certificate is how a security product proves its claims to government buyers in many countries at once. The CCRA's stated purpose is that IT products and Protection Profiles which earn a CC certificate can be procured or used without the need for further evaluation, which removes the cost of repeating the same evaluation in each market.

Key benefits include:

• One evaluation, recognized in many countries

Certificates issued by an authorizing scheme are recognized by all signatories of the CCRA, which lists 18 authorizing and 18 consuming members on the CC Portal.

• A shared vocabulary for security claims

Security functional requirements in Part 2 and security assurance requirements in Part 3 let a vendor state exactly what the product does and how deeply it was checked.

• Graded assurance

Part 5 defines seven evaluation assurance levels, from EAL1 (functionally tested) to EAL7 (formally verified design and tested), plus composed assurance packages for products built from certified parts.

• Comparable results from licensed laboratories

Evaluations are performed by competent, independent licensed laboratories using the common evaluation methodology, so results from different countries follow the same method.

• Technology-specific rules

CCRA supporting documents set out how the criteria apply to specific technologies such as smart cards and full drive encryption, and the mandatory ones must be applied for a certificate to be mutually recognized.

How does it work?

CC:2022 has five parts: Part 1, Introduction and general model; Part 2, Security functional components; Part 3, Security assurance components; Part 4, Framework for the specification of evaluation methods and activities; and Part 5, Pre-defined packages of security requirements. Parts 4 and 5 are new in this edition. The companion Common Methodology for Information Technology Security Evaluation (CEM:2022) tells evaluators what to check for each assurance requirement.

An evaluation starts with the security problem definition for the target of evaluation (TOE): the threats it counters, the organizational security policies it enforces and the assumptions about its operational environment. The developer derives security objectives from that definition and expresses them as security functional requirements, then picks the assurance requirements or package the evaluation will be measured against. These statements form the Security Target. Where a buyer community has already defined the requirements for a product type, the Security Target claims conformance to that Protection Profile, and since CC:2022 an exact conformance claim keeps the evaluation within the scope of the profile.

The laboratory then evaluates the design documentation, guidance, life-cycle evidence, tests and vulnerability analysis the chosen assurance requirements call for, and the certification body reviews the evaluation and issues the certificate. Certificates and their Security Targets are published on the CC Portal's certified products list, and assurance continuity rules govern maintenance and re-evaluation after the product changes.

Teams that must keep Security Targets, evaluation evidence, protection profile claims and certificate dates in order across several products can track them in SmartSuite's Compliance Management solution, which centralizes policies, obligations, controls, testing, and evidence.

How does CC:2022 differ from CC v3.1 Revision 5?

CC v3.1 Revision 5 was published in 2017 and is the last revision of version 3.1. The CC:2022 foreword lists the changes, and the CCRA transition policy (CCMC-2023-04-001, April 20, 2023) sets the dates.

Two transition dates still apply in 2026: Security Targets conformant to CC:2022 that are based on Protection Profiles certified under CC v3.1 are accepted up to December 31, 2027, and re-evaluations and re-assessments based on CC v3.1 evaluations can be started for up to two years from the initial certification date. The CCRA also publishes errata and interpretations for CC:2022 and CEM:2022 (version 1.2 is current), and applying the latest published version is mandatory.

Key Elements

Target of evaluation (TOE)

The product, or part of a product, with its guidance, that the evaluation covers, together with its boundaries and operational environment.

Security problem definition

The threats, organizational security policies and assumptions from which the security objectives are derived.

Security functional requirements (SFRs)

Components from Part 2 that state what the TOE's security functions must do, such as audit, identification and authentication, or cryptographic support.

Security assurance requirements (SARs)

Components from Part 3 that state what evidence the developer provides and what the evaluator checks, grouped into classes such as development, guidance documents, life-cycle support, tests and vulnerability assessment.

Protection Profile (PP)

An implementation-independent statement of security needs for a type of product, written by a buyer community or technical community, which vendors' Security Targets can claim conformance to.

Security Target (ST)

The implementation-dependent statement for one product that the evaluation is performed against, published with the certificate.

Assurance packages

Pre-defined sets of assurance requirements in Part 5, including the seven evaluation assurance levels (EAL1 to EAL7) and the composed assurance packages CAP-A, CAP-B and CAP-C.

What does it cover?

The CC covers the security functionality of IT products and the assurance measures applied to them during a security evaluation, whether the product is hardware, firmware or software. It covers products and Protection Profiles rather than organizations: it does not certify a company's management system or operating controls, and the certificate applies to the evaluated configuration described in the Security Target. Evaluation of the cryptographic algorithms themselves and the administrative procedures of the organization using the product are outside its scope unless the Security Target places them inside the TOE.

What are its objectives?

The CC and the CCRA share one aim: confidence in the security of IT products that does not depend on where the evaluation was done.

Ensure that evaluations of IT products and Protection Profiles are performed to high and consistent standards.

Permit comparison between the results of independent security evaluations through a common set of requirements.

Improve the availability of evaluated, security-enhanced IT products and Protection Profiles.

Eliminate the burden of duplicating evaluations of IT products and Protection Profiles.

Continuously improve the efficiency and cost-effectiveness of evaluation and certification.

Give buyers a published Security Target and certificate they can check before procurement.

Framework in Context

The CC is maintained by the CCRA participants and the ISO/IEC committees together: the governmental organizations listed in the CC:2022 legal notice, including national security agencies of Australia, Canada, France, Germany, Japan, the Netherlands, New Zealand, the Republic of Korea, Spain, Sweden, the United Kingdom and the United States, hold the copyright jointly with ISO/IEC. The current Common Criteria Recognition Arrangement is dated July 2, 2014 and was ratified on September 8, 2014; a Management Committee of senior representatives from each signatory's country implements it. In the European Union, the CCRA has published a policy on the co-existence of the CCRA and the EU's Common Criteria-based certification scheme (EUCC), dated March 19, 2025. Product teams often pursue a CC certificate alongside FIPS 140-3 validation for the cryptographic modules inside the product, and alongside product security requirements such as IEC 62443-4-2 and the EU Cyber Resilience Act.

Common Framework Mappings

Common Criteria mappings help product security, compliance and procurement teams line up evaluated security functions and assurance evidence with the cryptographic, product security and management system frameworks their buyers also ask for.

Mapped frameworks include:

FIPS 140-3

EU CRA

IEC 62443-4-2

ISO 27001:2022

ISO/IEC 18045:2022 (CEM)

EUCC