ISO/IEC 15408 Common Criteria

ISO/IEC 15408, better known as the Common Criteria (CC), is a leading international standard for evaluating and certifying the security of information technology.

The standard gives you a structured and recognized framework for assessing the security properties of IT products and systems. Its weight in Europe shows in the European Common Criteria-based cybersecurity certification scheme (EUCC), which builds on it under the EU Cybersecurity Act. The Common Criteria therefore play a central role in harmonizing and strengthening cybersecurity at European level.

This page explains how the Common Criteria are structured and how they are applied in practice. It covers the 2022 revision, the link to the Cybersecurity Act, and the core concepts of protection profiles, security targets, and evaluation assurance levels. It then walks through the evaluation process and the roles of evaluation labs and certification bodies.

Contents
  1. How ISO/IEC 15408 and the Common Criteria relate
  2. Structure of the Common Criteria
  3. How the Common Criteria and the Common Evaluation Methodology fit together
  4. What changed in the 2022 version
  5. Common Criteria and the EUCC scheme under the EU Cybersecurity Act
  6. Building blocks: protection profile, security target, and target of evaluation
    1. Target of evaluation
    2. Protection profile
    3. Security target
    4. How the building blocks work together
  7. Security analysis and specification in the Common Criteria
    1. Security problem definition
    2. Security functional requirements
    3. Security assurance requirements
    4. Evaluation assurance levels
    5. How the elements relate
  8. The evaluation process
  9. Evaluation labs and certification bodies

How ISO/IEC 15408 and the Common Criteria relate

ISO/IEC 15408 and the Common Criteria show how a specialized standard can be integrated into the international standards system. The Common Criteria were first developed as a standalone standard for evaluating and certifying IT security. In 1999 they were adopted into the ISO/IEC family and published as ISO/IEC 15408. This made the CC an internationally recognized standard and broadened their acceptance and use worldwide. Since then, the standard has been called both “Common Criteria” and “ISO/IEC 15408”. Both names refer to the same content and are often used interchangeably.

The CC are maintained and developed jointly by the international Common Criteria community and ISO/IEC JTC 1/SC 27 (Information security, cybersecurity and privacy protection). Both communities coordinate changes and updates, which keeps the standard improving. New versions are published both as CC documents and as ISO/IEC standards. The ISO/IEC versions must be purchased, while the CC documents are often available free of charge. In addition, the Common Evaluation Methodology (CEM) was standardized as ISO/IEC 18045, creating a uniform framework for evaluation and certification.

You can download the current version of the Common Criteria free of charge from the Common Criteria Portal. It holds all relevant documents, including the main parts of the CC and the associated methodologies. The corresponding ISO/IEC standards can also be obtained free of charge, which makes access much easier.

Structure of the Common Criteria

The five parts of ISO/IEC 15408 and ISO/IEC 18045 (CEM) together form a complete framework for specifying, developing, and evaluating IT security products. Parts 1 to 5 of ISO/IEC 15408 define the requirements and structures. The CEM provides the methodology needed to carry out evaluations in practice.

ISO/IEC 15408-1: Introduction and general model

This part gives an overview of the CC and defines the basic concepts, principles, and terminology. It explains the evaluation process and the evaluation results, and how the different parts of the CC relate to each other.

ISO/IEC 15408-2: Security functional components

This part contains a detailed catalog of standardized security functional requirements. You use it to specify security functions precisely in protection profiles (PP) and security targets (ST). The requirements are organized into classes, families, and components, and can be adapted and extended for specific products or systems.

ISO/IEC 15408-3: Security assurance components

This part contains a full catalog of security assurance requirements. It defines measures for assessing whether security functions are implemented correctly. It also specifies requirements for development, testing, and delivery processes.

ISO/IEC 15408-4: Framework for the specification of evaluation methods and activities

This part lays the foundation for developing consistent and reproducible evaluation methods. It defines their structure and content, so that specific methods can be developed for different technology areas.

ISO/IEC 15408-5: Pre-defined packages of security requirements

This part contains ready-made sets of security requirements. It also defines the evaluation assurance levels (EAL1 to EAL7), which stand for different depths of evaluation. These packages and EALs make it easier to write protection profiles and security targets. They provide frequently needed combinations of requirements and define standardized assurance levels.

How the Common Criteria and the Common Evaluation Methodology fit together

ISO/IEC 18045, also known as the Common Evaluation Methodology (CEM), complements the five parts of the Common Criteria by describing how evaluations are actually carried out. In detail:

  • The CEM builds directly on the concepts and principles defined in Part 1 and makes them concrete for practical use.
  • For the functional and assurance requirements specified in Parts 2 and 3, the CEM provides detailed evaluation procedures and techniques. It tells evaluators how to verify these requirements in practice.
  • The CEM implements the framework for evaluation methods defined in Part 4 by providing a standardized methodology for CC evaluations.
  • For products that use the pre-defined packages in Part 5, the CEM gives specific guidance on carrying out the evaluation efficiently.

The CEM is the bridge between the security requirements specified in the Common Criteria and their verification in practice. It ensures that CC evaluations are consistent, traceable, and comparable.

What changed in the 2022 version

The 2022 update of the Common Criteria, that is, ISO/IEC 15408 and ISO/IEC 18045 (CEM), brought several substantial changes. These are the main ones compared with the previous version:

  • The structure of the standard was fundamentally revised. ISO/IEC 15408 now has five parts instead of three. The new Part 4 introduces a framework for specifying evaluation methods, and Part 5 contains pre-defined packages of security requirements. This extension is meant to make the standard more widely applicable and more flexible.
  • A main focus of the revision was modernization and adaptation to current technologies and threat scenarios. This shows in updated and new security functional requirements that better reflect modern IT environments.
  • The assurance requirements were also revised to make evaluation more efficient and to better meet the needs of the different stakeholders. Some requirements were simplified, and new concepts were introduced for assessing the security of complex systems.
  • The update put more emphasis on practice. The new versions focus more on practical applicability and on carrying out evaluations efficiently. One example is the pre-defined packages of security requirements in Part 5, which are meant to make it easier to write protection profiles and security targets.
  • The evaluation methodology in ISO/IEC 18045 (CEM) was adapted to keep pace with the changes in ISO/IEC 15408. This ensures that the new requirements and concepts are applied consistently during evaluation.
  • Compatibility with other relevant standards and regulations was improved, so that the standard fits better into existing certification frameworks such as the EUCC scheme.

Overall, the changes aim to make the standard more flexible, more efficient, and better suited to current IT security challenges, while keeping the basic principles of the Common Criteria. The revision reflects the effort to keep pace with rapid developments in IT security and to keep the standard useful for evaluating and certifying IT security products.

Common Criteria and the EUCC scheme under the EU Cybersecurity Act

The EUCC (European Common Criteria-based cybersecurity certification scheme) is a certification scheme developed under the EU Cybersecurity Act. It is based on the Common Criteria and aims to enable uniform certification of ICT products and protection profiles across the EU.

The main points of the link between the two:

  • Harmonization: The EUCC scheme uses the CC as its basis to establish uniform certification across the EU.
  • Adaptation: It adapts the CC to the specific requirements and objectives of the EU.
  • Simplification: The scheme aims to simplify the certification process and make it more accessible and efficient.
  • Mutual recognition: It promotes the mutual recognition of certificates within the EU.
  • Assurance levels: The EUCC scheme has two assurance levels, “substantial” and “high”. They depend on the AVA_VAN level of the CC evaluation: “substantial” corresponds to AVA_VAN 1 or 2, and “high” to AVA_VAN 3 to 5 (Article 4 of Commission Implementing Regulation (EU) 2024/482).

Through this link, the Common Criteria become part of the EU's legal and regulatory framework, which strengthens and unifies cybersecurity in Europe.

In the EU context, a common question is when the Common Criteria make sense and when the EUCC scheme actually becomes relevant. If you want to place your products on that map, a short orientation call can help.

Book a call

Building blocks: protection profile, security target, and target of evaluation

Three concepts are at the center of every Common Criteria evaluation: the target of evaluation (TOE), the protection profile (PP), and the security target (ST). These building blocks are the basis for a structured and comparable security assessment of IT products and systems.

Target of evaluation

The target of evaluation (TOE) is the IT product or system being evaluated. It can be software, hardware, or a combination of both. The TOE contains the specific security functions that are assessed in the evaluation.

Protection profile

A protection profile (PP) is an implementation-independent set of security requirements for a particular category of TOE. It defines general security objectives and requirements for a type of product without referring to a specific product. User groups or public authorities often write PPs to set standardized security requirements for certain product classes. PPs serve as a reference for developers and evaluators and make security evaluations more comparable.

Security target

The security target (ST), by contrast, is an implementation-specific description of the security properties of a specific TOE. It contains detailed security objectives, functional and assurance requirements, and a description of the TOE's security functions. An ST can refer to one or more PPs and must show how the TOE meets the requirements defined in them.

How the building blocks work together

The three building blocks are closely linked. An ST can be based on one or more PPs and makes their general requirements concrete for the specific TOE. The evaluation checks whether the TOE meets the security requirements defined in the ST. If the ST is based on a PP, conformity with the PP is checked as well.

Using these building blocks promotes standardized and reusable security requirements. PPs let customers set standardized requirements for IT products. Manufacturers can develop their products (TOEs) accordingly and document this in their STs. This structured approach supports the evaluation process. It also makes it easier to compare and select IT security products on the market.

Security analysis and specification in the Common Criteria

The Common Criteria offer a structured approach to analyzing and specifying the security of IT products and systems. The process follows a logical chain from defining the problem to the concrete implementation and its verification. The main elements of this chain are the security problem definition (SPD), the security objectives, the security functional requirements (SFRs), and the security assurance requirements (SARs).

Diagram: the security problem definition consists of threats, organizational security policies, and assumptions. Threats and policies lead to the security objectives for the TOE, and all three lead to the security objectives for the operational environment. The security objectives for the TOE lead to the security functional requirements. Security assurance requirements are shown separately.

Security problem definition

The starting point is the security problem definition (SPD). It describes the security problem to be solved by identifying potential threats, relevant organizational security policies, and assumptions about the operational environment. Based on the SPD, you formulate the security objectives, which describe how the identified security problem will be addressed. These objectives are defined both for the target of evaluation (TOE) itself and for its operational environment.

Security functional requirements

The security functional requirements (SFRs) turn the security objectives into specific functional requirements for the TOE. They state what the product must do in terms of security. SFRs cover areas such as access control, authentication, audit, and cryptography. The security target (ST) specifies them in detail. They are often taken from a protection profile (PP) or adapted to the specific needs of the TOE.

Security assurance requirements

The security assurance requirements (SARs) set how deeply and how rigorously the implementation of the security functions is examined during the evaluation. They define the depth and scope of the evaluation and include requirements for development documentation, testing, vulnerability analysis, and lifecycle support. SARs therefore determine the level of confidence in the correct implementation of the SFRs.

Evaluation assurance levels

Evaluation assurance levels (EALs) were introduced to make it easier to select and apply SARs. EALs are predefined packages of SARs that represent different levels of assurance. They range from EAL1 (functionally tested) to EAL7 (formally verified design and tested). Higher EALs require more extensive and rigorous evaluation, but they also cost more and take more effort. EAL packages provide consistent sets of requirements for different assurance levels, which makes evaluations easier to compare.

How the elements relate

The elements are closely linked. SFRs and SARs are specified in the ST and form the basis for evaluating the TOE. The choice of EAL affects the scope and depth with which the SFRs are examined. The evaluation checks whether the TOE meets the SFRs and whether this has been demonstrated in line with the SARs.

This structured approach lets the Common Criteria evaluate IT security in a way that is flexible but still standardized. SFRs define the required functionality, SARs set the depth of evaluation, and EALs provide standardized assurance levels. Together, they allow a complete and comparable assessment of the security of IT products and systems.

The evaluation process

The standard evaluation process starts with the manufacturer of the product to be evaluated (the TOE) writing a security target (ST). The ST defines the security objectives and functions of the TOE. Optionally, the ST can be based on one or more protection profiles (PPs), which set general security requirements for a product class. PPs are not mandatory, but they can make evaluations more comparable and standardized.

The evaluator first checks the ST for completeness and consistency. The TOE is then evaluated against the requirements defined in the ST. This includes reviewing the documentation, testing the security functions, and assessing the development and delivery processes. The evaluator writes an evaluation report, which a certification body then reviews.

A composite evaluation covers a complex product made up of several components, some of which have already been certified separately. The process is similar to the standard one. It also considers the interactions between the components and reuses the results of earlier evaluations. This reduces effort and avoids duplicate work.

In both cases, the ST is the reference for the evaluation. Where PPs are used, they serve as the basis for the ST and ensure conformity with the interests of the PP authors. In the end, the evaluation checks whether the TOE meets the security requirements defined in the ST and, indirectly, in the referenced PPs.

Evaluation labs and certification bodies

Evaluation labs and certification bodies play a central role in the Common Criteria process. They carry out and validate the security evaluations. Their cooperation ensures that IT products and systems are evaluated independently, thoroughly, and in a standardized way.

The evaluation labs carry out the actual evaluation of the target of evaluation (TOE). They review the security target (ST) and the manufacturer's documentation, test the TOE's security functions, and write the evaluation report. They work closely with the manufacturer to clarify questions and obtain additional information. To ensure their independence and competence, evaluation labs must be accredited.

Examples of evaluation labs, in alphabetical order:

Certification bodies oversee the CC process and assure its quality. They monitor the evaluation, review the work of the evaluation labs, and issue the final certificate. They also ensure compliance with national and international standards and represent their country in the Common Criteria Recognition Arrangement (CCRA). In some cases, they also accredit evaluation labs.

Examples of well-known certification bodies:

The interaction between evaluation labs and certification bodies is essential to the CC process. The labs do the detailed technical work, and the certification bodies oversee the process and assure its quality.

A typical sequence looks like this. A manufacturer commissions an accredited evaluation lab to evaluate its product. The lab carries out the evaluation and submits its report to the certification body. The certification body reviews the report, may ask questions or request additional tests, and issues the CC certificate if the evaluation is successful.

This system ensures that the security of IT products and systems is assessed independently, thoroughly, and in a standardized way. It helps build trust in evaluated products and allows certificates to be recognized internationally under the CCRA.

The Common Criteria are a powerful but demanding tool for assessing product security, especially in combination with the CRA and the EUCC. If you want to find out whether and how a CC evaluation makes sense for your products, a no-obligation call is a good place to start.

Book a call

Choosing a CRA consultant? Here is how to find the right one.

Get the guide

Book a call

Send us your request. Together we will look at where your company stands, which questions are still open, and what the sensible next steps are.

For information on how we process your data, see our privacy policy.

Guide: How to choose the right CRA consultant

CRA consulting offers are hard to compare. One provider delivers only a gap analysis, another also supports the technical implementation, and both call themselves “CRA consultants.” If you ask the wrong questions, you end up paying for services you don't need, or you find out halfway through the project that key expertise is missing.

Our guide shows manufacturers what really matters when choosing a provider, from the expertise you need to the right pricing model and the 20 questions you should ask every provider.

What the guide covers:

  • the seven areas of expertise a complete CRA implementation requires
  • four support models depending on your in-house capacity and expertise
  • 20 specific questions for your next provider meeting
  • a red flag card for spotting warning signs quickly
  • a scoring sheet with rating guidance for a structured comparison of providers

Download it for free

Newsletter

For information on how we process your data, see our privacy policy.

Free templates: CRA reporting process

Prepare your company for the reporting obligations under the Cyber Resilience Act. You get process descriptions and templates tested in practice for:

  • reporting actively exploited vulnerabilities
  • reporting severe incidents
  • the required early warning notifications, notifications, and final reports
  • clear responsibilities, escalation paths, and deadlines

Enter your contact details and we will email you the files.

Newsletter

For information on how we process your data, see our privacy policy.

Free template: Risk assessment according to EN 50742

We use this template in our consulting projects for systematic threat assessment. You get an Excel template with:

  • a structured threat assessment for your machinery
  • a systematic way to determine safety-related security levels (SRSL)
  • documentation of vulnerabilities and protective measures

Enter your contact details and you will receive the template within minutes.

Newsletter

For information on how we process your data, see our privacy policy.

Free template: SBOM

We use this template in our consulting projects to meet the CRA requirements for the software bill of materials.

Enter your contact details and you will receive the template within minutes.

Newsletter

For information on how we process your data, see our privacy policy.

Free template: Vulnerability disclosure policy

We use this template in our consulting projects to meet the CRA requirements for vulnerability handling. You get a Word template with:

  • a structure based on EN 40000-1-3
  • predefined sections for reporting channels, response times, and responsibilities
  • safe harbor clauses for security researchers

Enter your contact details and you will receive the template within minutes.

Newsletter

For information on how we process your data, see our privacy policy.