Common Criteria (ISO/IEC 15408): IT security eval
Guide · Common Criteria
Common Criteria for Information Technology Security Evaluation, standardised since 1999 under ISO/IEC 15408 and its companion methodology ISO/IEC 18045 (Common Evaluation Methodology, CEM), provide the international framework for evaluating the security of IT products. Born from the convergence of the US Trusted Computer System Evaluation Criteria, the European Information Technology Security Evaluation Criteria and the Canadian Trusted Computer Product Evaluation Criteria during the 1990s, the standard organises a shared vocabulary of requirements (Security Functional Requirements and Security Assurance Requirements), an assurance scale graded from EAL 1 to EAL 7, and an international mechanism for mutual recognition of certificates. This guide sets out the structure of the standard, the evaluation cycle, the assurance levels, the mechanics of CCRA and SOG-IS MRA recognition, the national schemes, the positioning of the European EUCC scheme and the interaction with related cybersecurity frameworks (CRA, RED 3.3, EN 303 645).
Origins and normative status
Section titled “Origins and normative status”The need for a formal IT security evaluation framework dates back to the 1980s with the US Department of Defense publication of the Trusted Computer System Evaluation Criteria (TCSEC, the Orange Book, 1985), oriented towards operating systems and trust classes C1 to A1. Western Europe developed its own framework in parallel, the Information Technology Security Evaluation Criteria (ITSEC, 1991), led by France, Germany, the United Kingdom and the Netherlands, and Canada released the Canadian Trusted Computer Product Evaluation Criteria (CTCPEC, 1993).
The fragmentation rapidly reached its limits: a product certified under TCSEC could not reuse its evaluation under ITSEC or CTCPEC. From 1993 onwards a joint working group merged the three corpora into a single framework, published in 1996 as Common Criteria version 1.0. Version 2.0 appeared in 1998 and the framework was standardised as ISO/IEC 15408 in 1999. It went through three major revisions (2.x, 3.x, 4.x) before the 2022 revision which restructures the standard into five parts and harmonises terminology.
The current edition, ISO/IEC 15408:2022, comprises:
- Part 1, Introduction and general model: fundamental concepts, evaluation cycle, structure of Protection Profiles and Security Targets.
- Part 2, Security functional components: catalogue of Security Functional Requirements (SFR), grouped into classes (FAU audit, FCO communication, FCS cryptographic support, FDP user data protection, FIA identification and authentication, FMT security management, FPR privacy, FPT protection of the TSF, FRU resource utilisation, FTA TOE access, FTP trusted path and channels).
- Part 3, Security assurance components: catalogue of Security Assurance Requirements (SAR), grouped into classes (ADV development, AGD guidance documents, ALC life-cycle support, ASE security target evaluation, ATE tests, AVA vulnerability assessment, ACO composition).
- Part 4, Framework for the specification of evaluation methods and activities: meta-framework for schemes.
- Part 5, Pre-defined packages of security requirements: pre-defined packages, including the Evaluation Assurance Levels.
The Common Evaluation Methodology (CEM), standardised as ISO/IEC 18045:2022, describes how an evaluator practically applies part 3 to a given product. It is the reference document for accredited laboratories.
Objects of evaluation: TOE, TSF, ST, PP
Section titled “Objects of evaluation: TOE, TSF, ST, PP”Common Criteria define a precise vocabulary that must be settled before approaching the evaluation mechanics.
Target of Evaluation (TOE)
Section titled “Target of Evaluation (TOE)”The TOE is the object being evaluated. It may be a hardware component (smart card, secure microcontroller, HSM module, cryptographic processor), software (operating system, hypervisor, database), firmware, or a combination. The exact boundary of the TOE is decisive: it fixes what is evaluated and what is not. An over-scoped TOE burdens the project without benefit; an under-scoped TOE leaves attack surfaces outside the evaluation and weakens the value of the certificate.
TOE Security Functionality (TSF)
Section titled “TOE Security Functionality (TSF)”The TSF designates the set of security functions implemented in the TOE, that is the technical countermeasures that realise the security functional requirements. The TSF is the direct object of testing, design analysis and vulnerability analysis.
Security Target (ST)
Section titled “Security Target (ST)”The Security Target is the principal document of the procedure. It describes:
- The TOE and its operational environment.
- The threats, organisational security policies and assumptions about the environment.
- The security objectives (for the TOE and its environment).
- The selected Security Functional Requirements (with refinements and iterations where appropriate).
- The Security Assurance Requirements, generally reduced to an EAL package with possible augmentations.
- The TOE summary specification and the rationale linking threats, objectives and requirements.
The ST may claim conformance to one or more PPs: this is called strict conformance or demonstrable conformance depending on the alignment required. The quality of the ST directly conditions the duration and cost of the evaluation.
Protection Profile (PP)
Section titled “Protection Profile (PP)”The Protection Profile is a generic specification of the security requirements for a class of products, written independently of any implementation. A PP defines the threats, objectives and expected SFRs and SARs, without designating a particular product. Several STs may claim conformance to the same PP, which facilitates comparison between products and reduces duplicated effort.
collaborative Protection Profile (cPP)
Section titled “collaborative Protection Profile (cPP)”The cPP is a variant of the PP elaborated jointly by several national schemes within an international Technical Community (for example the iTC Network Devices, iTC Smartcards). The cPP frames evaluations for a technical category and, since the CCRA reform of 2014, conditions mutual recognition above EAL 2 + ALC_FLR. For a manufacturer, the existence of an applicable cPP is a strong positive signal: it reduces the redaction uncertainty of the ST and guarantees international acceptance of the certificate.
Diagram of relationships
Section titled “Diagram of relationships”| Level | Document | Product-specific | Role |
|---|---|---|---|
| Normative framework | ISO/IEC 15408 (parts 1 to 5) + ISO/IEC 18045 (CEM) | No | Defines the grammar and the methodology |
| Product category | Protection Profile (PP) or collaborative PP (cPP) | No | Specifies requirements for a class |
| Product | Security Target (ST) | Yes | Describes the TOE and its security functions |
| Implementation | Target of Evaluation (TOE) | Yes | The actual hardware or software product evaluated |
| Evaluated functions | TOE Security Functionality (TSF) | Yes | Subset of the TOE realising the SFRs |
Assurance scale: EAL 1 to EAL 7
Section titled “Assurance scale: EAL 1 to EAL 7”Evaluation Assurance Levels are pre-defined packages of Security Assurance Requirements. They do not measure the intrinsic security of a product but the confidence that can be placed in its evaluation, depending on the depth and rigour of the analyses performed.
| EAL | Title | Synthetic description | Typical use cases |
|---|---|---|---|
| EAL 1 | Functionally tested | Functional analysis, limited independent testing | Commercial products where the mere existence of an evaluation is sufficient |
| EAL 2 | Structurally tested | Independent testing, high-level design analysis, vulnerability review | General IT products with moderate requirements, CCRA cap in the absence of a cPP |
| EAL 3 | Methodically tested and checked | Design documentation, covert channel analysis, development environment controls | Commercial products with more serious requirements |
| EAL 4 | Methodically designed, tested, and reviewed | Detailed design, subset of source code analysed, extended ALC controls | The highest level economically achievable for a general commercial product, frequent for operating systems, databases, firewalls |
| EAL 5 | Semiformally designed and tested | Semi-formal design, deep vulnerability analysis, partial formal TSF modelling | Smart cards, secure microcontrollers, certain specialised operating systems |
| EAL 6 | Semiformally verified design and tested | Semi-formal verification, exhaustive structural testing of the TSF | Critical security components (high-assurance smart cards, HSMs) |
| EAL 7 | Formally verified design and tested | Full formal modelling of the TSF, mathematical verification | Very small high-criticality TOEs (cryptographic modules, parts of a secure kernel) |
Augmentations and EAL+
Section titled “Augmentations and EAL+”An EAL level may be augmented with additional SARs beyond the standard package. The most frequent augmentation is ALC_FLR (Flaw Remediation), which adds a formal flaw remediation requirement. The usual practical names:
- EAL 4+: EAL 4 augmented with at least one higher component, most often ALC_FLR.2 or ALC_FLR.3, sometimes AVA_VAN.5 (high-potential vulnerability analysis).
- EAL 5+: EAL 5 with AVA_VAN.5 systematically applied for smart cards and HSMs.
The vast majority of commercial certificates issued worldwide sit in the EAL 2 to EAL 5+ band. EAL 6 and EAL 7 remain the preserve of very specific components or subsystems, because of the cost of formal verification.
Evaluation cycle
Section titled “Evaluation cycle”A Common Criteria evaluation mobilises four actors: the sponsor (usually the manufacturer), the developer, the evaluation laboratory (ITSEF in European terminology, CCTL in American terminology) and the Certification Body of the national scheme. The typical flow is as follows.
- Scoping and scheme selection. The sponsor chooses the national certification scheme (ANSSI in France, BSI in Germany, NIAP in the United States, etc.) based on the target market, the preferred laboratory and the applicable cPP.
- Laboratory selection. The ITSEF/CCTL must be accredited for the target scheme and for the technical category of the TOE. A tripartite contract is signed between sponsor, laboratory and scheme.
- Security Target drafting. Critical step. The ST is reviewed by the scheme before evaluation activities begin (ASE step).
- Evaluation activities. The laboratory applies the CEM to the selected SARs: ADV (design), AGD (user documentation), ALC (life cycle), ATE (functional tests), AVA (vulnerability analysis), possibly ACO (composition).
- Technical reports. The laboratory produces intermediate Evaluation Technical Reports reviewed by the Certification Body.
- Certification decision. The Certification Body issues the certificate (public Certification Report and public Security Target) and lists the product on the scheme portal.
- Maintenance and re-evaluation. The certificate may be maintained through assurance continuity (minor/major changes), or followed by re-evaluation for a new product version.
The duration of an evaluation depends on the assurance level, the complexity of the TOE and the documentary maturity of the sponsor. An EAL 4+ evaluation of an already-deployed product typically takes several quarters; an EAL 5+ evaluation of a smart card mobilises several person-years on the laboratory side.
International recognition: CCRA and SOG-IS MRA
Section titled “International recognition: CCRA and SOG-IS MRA”Common Criteria would have limited reach without a mutual recognition mechanism. Two instruments coexist.
Common Criteria Recognition Arrangement (CCRA)
Section titled “Common Criteria Recognition Arrangement (CCRA)”The CCRA is an international agreement signed between participating states. It distinguishes two statuses: Certificate Authorizing Members (states that issue recognised certificates) and Certificate Consuming Members (states that recognise certificates without issuing them). The Common Criteria portal publishes the up-to-date list of members.
The 2014 CCRA reform substantially modified the mechanism: general recognition now only applies to certificates up to EAL 2 augmented with ALC_FLR; above that level, recognition is only guaranteed for evaluations carried out within the framework of a cPP valid for the product category. In the absence of an applicable cPP, an EAL 4+ certificate remains valid on the issuing territory but does not automatically engage the other signatories.
SOG-IS MRA
Section titled “SOG-IS MRA”The Senior Officials Group Information Systems Security Mutual Recognition Agreement is a more restricted European arrangement but more permissive on assurance levels. Its members (essentially EU and EFTA states) mutually recognise certificates up to EAL 7 for the technical domains formally covered by SOG-IS, and up to EAL 4 for other domains.
The SOG-IS technical domains historically number two:
- Smart Cards and Similar Devices (smart cards and similar devices: eUICC, secure elements, secure tokens).
- Hardware Devices with Security Boxes (hardware devices with security boxes, including certain HSMs and digital tachographs).
The SOG-IS MRA has long served as the high-assurance recognition regime in Europe. Its scope is now being progressively absorbed by EUCC (see dedicated section).
CCRA vs SOG-IS MRA comparison
Section titled “CCRA vs SOG-IS MRA comparison”| Characteristic | CCRA | SOG-IS MRA |
|---|---|---|
| Geographic scope | International | European (EU and EFTA) |
| General recognition cap | EAL 2 + ALC_FLR | EAL 4 outside technical domains, EAL 7 within technical domains |
| Condition above the cap | Evaluation conforming to a cPP | Membership of the recognised technical domain |
| Formally recognised technical domains | iTC Technical Communities lists, evolving | Smart Cards and Similar Devices, Hardware Devices with Security Boxes |
| Outlook | Stable, evolutions through iTC cPPs | Progressively absorbed by EUCC within the EU perimeter |
National schemes
Section titled “National schemes”Common Criteria is implemented in each signatory country through a national certification scheme. The scheme designates the Certification Body, accredits the laboratories, publishes procedural guides and issues the certificates. The most active schemes worldwide:
| State or region | Scheme | Authority | CCRA status |
|---|---|---|---|
| France | Certification Criteres Communs | ANSSI | Certificate Authorizing Member |
| Germany | German CC Scheme | BSI (Bundesamt fur Sicherheit in der Informationstechnik) | Certificate Authorizing Member |
| Netherlands | NSCIB | TUV Rheinland Nederland (under NCTV oversight) | Certificate Authorizing Member |
| Spain | Organismo de Certificacion | Centro Criptologico Nacional (CCN) | Certificate Authorizing Member |
| Italy | OCSI | Organismo di Certificazione della Sicurezza Informatica | Certificate Authorizing Member |
| United States | NIAP CCEVS | National Information Assurance Partnership / NSA | Certificate Authorizing Member |
| Canada | Canadian CCS | Communications Security Establishment (CSE) | Certificate Authorizing Member |
| Japan | JISEC | IPA (Information-technology Promotion Agency) | Certificate Authorizing Member |
| South Korea | KCMVP / KCC | NIS (National Intelligence Service) | Certificate Authorizing Member |
| United Kingdom | NCSC CC Scheme | National Cyber Security Centre | Certificate Authorizing Member |
| Sweden | CSEC | FMV (Forsvarets Materielverk) | Certificate Authorizing Member |
The Common Criteria portal maintains an up-to-date list of members and their status.
French case: ANSSI and Visa de Securite
Section titled “French case: ANSSI and Visa de Securite”In France, ANSSI issues CC certificates under the Visa de Securite label. The Visa de Securite covers two distinct schemes:
- The Certification Criteres Communs (CC), corresponding to the ISO/IEC 15408 framework described in this guide.
- The CSPN (Certification de Securite de Premier Niveau), a rapid black-box and grey-box evaluation specific to the French context, typically lasting around two months and outside the CCRA perimeter. See the CSPN ANSSI guide for the detailed comparison.
The choice between CC and CSPN depends on the required assurance level, the available budget and the geographic scope. CSPN suits a national first-level confidence need; CC becomes mandatory when international recognition or a high EAL is required by the end customer or the market.
EUCC: the European transposition under the Cybersecurity Act
Section titled “EUCC: the European transposition under the Cybersecurity Act”Regulation (EU) 2019/881 Cybersecurity Act established a European cybersecurity certification framework, whose first operational realisation is the EUCC scheme (European Common Criteria-based cybersecurity certification scheme), adopted by Implementing Regulation (EU) 2024/482.
EUCC reuses ISO/IEC 15408 and ISO/IEC 18045 as its technical base. It introduces three European assurance levels (basic, substantial, high) mapped onto the CC EALs:
- basic: EAL 1 to EAL 2.
- substantial: EAL 3 to EAL 4.
- high: EAL 5 to EAL 7, and explicitly the technical domains inherited from SOG-IS.
The national cybersecurity certification authority (NCCA) issues certificates on behalf of the Union; ENISA keeps the central register. In France, ANSSI carries out the NCCA function and issues EUCC certificates.
EUCC progressively absorbs the existing national certificates and the CC branch of SOG-IS. Pre-EUCC national CC certificates remain valid until their expiry, but new applications in France and other Member States are progressively switching to EUCC for the covered categories.
The future CRA regulation (EU) 2024/2847 explicitly recognises EUCC certificates as a presumption of conformity to all or part of the essential requirements in its annex I, without making CC certification mandatory. See the Cyber Resilience Act guide for the articulation mechanics.
Classic pitfalls of a Common Criteria project
Section titled “Classic pitfalls of a Common Criteria project”The experience of laboratories and schemes highlights recurring errors that any sponsor should anticipate.
| Pitfall | Manifestation | Mitigation |
|---|---|---|
| Over-scoped TOE | Inclusion of non-security functions that burden ADV and ATE without strengthening the certificate value | Define a minimal TOE strictly covering the target TSF |
| Late ST drafting | The laboratory cannot start activities until the ST is validated, the schedule slips | Invest early in the ST, ideally in parallel with product design |
| No applicable cPP | CCRA recognition limited to EAL 2 + ALC_FLR, bespoke ST to defend before the scheme | Verify the existence of a cPP at project kickoff, follow the relevant iTCs for the target category |
| Underestimating ALC | The ALC requirements (life cycle, configuration management, secure delivery) demand industrial documentation often missing | Launch ALC compliance from scoping, anticipate site audits |
| Wrong laboratory choice | The laboratory is not accredited for the technical domain or the target scheme | Verify accreditation and references before signature |
| Architecture unsuited to verification | A TSF intertwined with the rest of the product makes separation and analysis very hard | Design the TSF as an identified subsystem with explicit interfaces |
| Underestimating duration | A full EAL 4+ evaluation cycle mobilises several quarters minimum, more for EAL 5+ | Anchor the evaluation in the product roadmap very early |
Community and conferences
Section titled “Community and conferences”The International Common Criteria Conference (ICCC) brings together schemes, laboratories, sponsors and end users every year. It is the main forum for discussing the evolution of the standard, of cPPs and of Technical Communities. The iTCs (international Technical Communities) are the working groups in charge of producing cPPs for specific technical domains (Network Devices, Dedicated Security Components, Hardcopy Devices, Mobile Devices, Smart Cards, etc.). The Common Criteria portal lists the active iTCs.
For a manufacturer preparing for certification, monitoring the publications of relevant iTCs, reading the public Certification Reports on the portal and consulting the national scheme early are useful reflexes. See the spilma glossary for normalised definitions of CC vocabulary (TOE, TSF, PP, ST, cPP, EAL, SFR, SAR, CEM, ITSEF, CCTL, CCRA, SOG-IS, EUCC, NCCA).
See also
Section titled “See also”- DO-326A and ED-202A: avionics cybersecurity airworthiness
- PSA Certified: Arm-led IoT security baseline
- SESIP: IoT platform security evaluation methodology
- TPM 2.0 and TCG hardware security
- FIPS 140-3: cryptographic module validation
- CSPN and ANSSI Visa: French cybersec certification
- CMMC and UK Cyber Essentials: defense cyber baselines
Synthesis
Section titled “Synthesis”Common Criteria, standardised under ISO/IEC 15408 and supported by the CEM methodology (ISO/IEC 18045), remain in 2026 the international reference for formal IT security evaluation. The framework rests on a stable vocabulary (TOE, TSF, ST, PP, cPP), an assurance scale graded from EAL 1 to EAL 7 with augmentations, and a two-tier international recognition regime (CCRA up to EAL 2 + ALC_FLR or cPP above that level; SOG-IS MRA up to EAL 7 within the technical domains). The progressive rollout of EUCC under the European Cybersecurity Act consolidates the CC branch of the European certification landscape and offers a bridge of presumption of conformity towards the CRA regulation for the products that fall within its scope.
Sources & references
- Common Criteria Portal, official CC v3.1 / CC 2022 documents and certified product lists , Common Criteria Maintenance Board www.commoncriteriaportal.org/
- ISO/IEC 15408 (all parts), Information security, cybersecurity and privacy protection, Evaluation criteria for IT security , ISO/IEC www.iso.org/standard/72891.html
- Common Criteria Recognition Arrangement (CCRA), text and member list , Common Criteria Maintenance Board www.commoncriteriaportal.org/ccra/
- SOG-IS Mutual Recognition Agreement, official portal and technical domains , Senior Officials Group Information Systems Security www.sogis.eu/
- Regulation (EU) 2019/881 Cybersecurity Act, legal basis of the EUCC scheme , EUR-Lex eur-lex.europa.eu/eli/reg/2019/881/oj
- Implementing Regulation (EU) 2024/482 establishing the EUCC scheme , EUR-Lex eur-lex.europa.eu/eli/reg_impl/2024/482/oj
- ANSSI, Common Criteria and Visa de Securite page , ANSSI cyber.gouv.fr/produits-certifies