Common Criteria (ISO/IEC 15408) – Global IT Security Evaluation
1. Why Common Criteria matters now
Common Criteria (CC) is the globally recognised framework for evaluating and certifying the security of IT products, formally standardised as the ISO/IEC 15408 series with the companion evaluation methodology ISO/IEC 18045 (CC Part 1 § 1). Rather than prescribing a fixed set of security controls, CC provides a catalogue of security requirements and an assurance framework that lets vendors, customers, and evaluators agree on what will be protected and how thoroughly it will be assessed (CC Part 1 § 6.3).
For connected devices and embedded products, CC is most relevant when (CC Part 1 § 6.2):
- Customers or regulators require high assurance (e.g., secure elements, HSMs, gateways, smart cards, identity & access systems) (NIAP Product Compliant List).
- Certification is needed to access specific markets or procurement schemes that reference CC or its successors (e.g., national schemes, emerging EU certification under the Cybersecurity Act EUCC Scheme).
- Vendors want a structured way to define, implement, and evidence security requirements that can also support laws like the Cyber‑Resilience Act (CRA) or sectoral standards such as IEC 62443.
-
Common Criteria v3.1 R5 core documents (freely available):
- CC Part 1: Introduction and general model – CCPART1V3.1R5.pdf
- CC Part 2: Security functional components – CCPART2V3.1R5.pdf
- CC Part 3: Security assurance components – CCPART3V3.1R5.pdf
- CEM: Common Methodology for IT Security Evaluation – CEMV3.1R5.pdf
-
ISO/IEC 15408 – Evaluation criteria for IT security (normative, paywalled):
- Part 1: Introduction and general model (2022) – ISO/IEC 15408‑1:2022
- Part 2: Security functional components (2022) – ISO/IEC 15408‑2:2022
- Part 3: Security assurance components (2022) – ISO/IEC 15408‑3:2022
-
ISO/IEC 18045 – Evaluation criteria for IT security — Methodology for IT security evaluation:
- ISO/IEC 18045:2022 – Methodology for IT security evaluation
- ISO/IEC TR 15443‑1:2012 – Security assurance framework, Part 1: Introduction and concepts – Overview of IT security assurance concepts.
- ISO/IEC TR 15446:2017 – Guidance for the production of Protection Profiles and Security Targets – How to write CC Protection Profiles and Security Targets.
Timeline of key dates
| Year | Milestone | Why it matters |
|---|---|---|
| 1999–2005 | Early ISO/IEC 15408 & 18045 editions | Established CC and its methodology as the global IT security evaluation framework. |
| 2017 | CC v3.1 R5 and CEM v3.1 R5 | Latest public CC and evaluation methodology texts used by most national and regional schemes. |
| 2022 | ISO/IEC 15408‑1/‑2/‑3:2022 and ISO/IEC 18045:2022 | Updated ISO/IEC editions aligning CC with current practice; useful for clause‑level citations. |
Relationship to other standards & regulations
| Law / Standard | How it interacts with Common Criteria |
|---|---|
| Cyber‑Resilience Act (CRA) | CRA defines essential cybersecurity requirements for products with digital elements, while CC provides a structured way to specify and evidence those requirements for a given product. For high‑risk products (e.g., secure elements, gateways), a CC‑style ST and evaluation can support CRA conformity assessment, especially where EU cybersecurity certification schemes adopt CC concepts. |
| ETSI EN 303 645 | EN 303 645 defines a practical baseline for consumer IoT security. CC can be used to achieve higher assurance for particularly sensitive consumer devices (e.g., locks, security hubs) by formalising requirements and evidence; many EN 303 645 outcomes map naturally onto CC SFR families. |
| IEC 62443 Series | IEC 62443 focuses on industrial automation and control systems (OT). It and CC share common themes: secure development lifecycle, technical security functions, and assurance. In practice, 62443 may govern the overall system and lifecycle, while CC is used for high‑assurance components (e.g., secure gateways, controllers, secure elements) within that system. |
| NIST SP 800-218 (SSDF) & NIST IR 8259 Series | NIST’s Secure Software Development Framework (SSDF) and IoT baselines describe what good secure engineering looks like. CC’s SARs can be thought of as a more formalised, evaluation‑oriented expression of many of the same practices, especially around documentation, configuration management, testing, and vulnerability handling. |
2. Scope – When should you care about Common Criteria?
2.1 What Common Criteria covers
Common Criteria is focused on TOEs (Targets of Evaluation) – concrete IT products or systems that can be evaluated against an agreed Security Target (ST) (CC Part 1 § 2). Typical examples that matter for connected devices include:
- Secure components and roots of trust: secure elements, smart cards, trusted platform modules (TPMs), secure microcontrollers, hardware security modules (HSMs).
- Network and security appliances: VPN gateways, firewalls, industrial gateways, identity and access management systems.
- Embedded and IoT platforms: device operating systems, security‑critical middleware, and in some cases complete connected products, when high assurance is required.
Each TOE is evaluated against (CC Part 1 § 9):
- A Protection Profile (PP) – a reusable, standardised set of requirements for a class of products, or
- A Security Target (ST) – the vendor’s specific security problem definition and requirements for that individual product.
2.2 When Common Criteria is overkill
For many commodity consumer IoT products, laws and standards such as ETSI EN 303 645, PSTI, NIST IR 8259, or the Cyber‑Resilience Act provide sufficient direction without formal CC certification.
CC becomes disproportionately heavy when:
- The device has low risk, short lifetime, and no strong regulatory or market demand for formal certification.
- The cost and schedule impact of third‑party evaluation cannot be justified compared to lighter‑weight conformity assessment routes.
In those cases, CC is still useful as a design reference, but a full evaluation may not be appropriate.
3. Using Common Criteria Requirements in Product Design
From an engineering perspective, CC requirements split into (CC Part 1 § 6.1.1):
- Security Functional Requirements (SFRs) – what security features the product must provide.
- Security Assurance Requirements (SARs) – how much evidence is needed that those features are correctly implemented and effective.
This section shows how to translate major CC requirement themes into concrete engineering work, and where this handbook provides deeper implementation guidance.
3.1 Core functional requirement themes (SFRs)
| CC Theme (examples) | What it means in practice | Implementation Guides |
|---|---|---|
| Identification, authentication, and access control CC Part 2 § 12: FIA CC Part 2 § 13: FMT CC Part 2 § 11: FDP | Every actor (user, device, process) must be uniquely identified and authenticated; access to functions and data is controlled based on roles and least privilege; security‑relevant operations are policy‑driven and auditable. | Unique Device Identity Secure Configuration & Hardening Security Logging & Monitoring |
| Cryptography and secure communication CC Part 2 § 10: FCS | Cryptographic operations use approved algorithms and key sizes; keys are generated, stored, and destroyed securely; communications channels are protected (e.g., TLS, authenticated key exchange) with proper certificate and key management. | Key Provisioning & Storage Cryptography under the CRA |
| Software integrity, secure boot, and updates CC Part 2 § 15: FPT CC Part 2 § 11: FDP | The TOE verifies the integrity and authenticity of its code and configuration at boot; only authenticated, integrity‑protected updates are accepted; rollback and recovery strategies are defined and implemented. | Secure Boot Secure OTA Updates CI/CD Hardening |
| Audit and monitoring | Security‑relevant events (authentication, configuration changes, failures, a policy decision) are logged with sufficient detail; logs are protected from tampering and loss; authorised operators can review and export logs for analysis. | Security Logging & Monitoring |
| User data protection and privacy CC Part 2 § 11: FDP | Personal and sensitive data are protected at rest and in transit; only necessary data is collected and retained; secure deletion mechanisms are available for user data and secrets. | Data Privacy & Secure Deletion |
Design tip: Even if you never name FCS/FIA/FPT explicitly in your internal documentation, you can treat these themes as a checklist: each capability should be clearly specified, implemented, and testable.
3.2 Assurance requirements and engineering process (SARs)
CC’s assurance classes (ADV, AGD, ALC, ATE, AVA, etc.) are about the rigour of your engineering and verification process, not just features.
The table below maps key assurance expectations to concrete tasks in a secure‑by‑design lifecycle.
| Assurance Area (examples) | Engineering Tasks | Implementation Guides |
|---|---|---|
| Development documentation CC Part 3 § 13: ADV | Maintain clear architectural and design documentation: security architecture, trust boundaries, threat model, interface specifications, and data‑flow diagrams. Ensure that these artefacts are kept in sync with the implementation. | Threat Modeling User Documentation Guide |
| Guidance documentation CC Part 3 § 14: AGD | Produce and maintain administrator and user guidance explaining secure installation, configuration, operation, and decommissioning, including secure defaults and required environmental assumptions. | User Documentation Guide Secure Configuration & Hardening |
| Configuration management & lifecycle CC Part 3 § 15: ALC | Operate a disciplined secure development lifecycle (SDL): version control, change control, build reproducibility, access control on repos and signing keys, supplier management, and SBOM generation. | SBOM & VEX Workflows CI/CD Hardening Key Provisioning & Storage |
| Testing and evaluation CC Part 3 § 16: ATE | Plan and execute structured testing that covers functional security behaviour, robustness, negative testing, fuzzing, and regression; capture test cases and results as evaluation evidence. | Static & Dyanmic Analysis Patch Cadence |
| Vulnerability analysis and penetration testing CC Part 3 § 17: AVA | Run an ongoing vulnerability management process: intake, triage, remediation, and disclosure; perform internal and third‑party penetration testing commensurate with the targeted assurance level. | Vulnerability Disclosure Secure OTA Updates |
As your assurance level (e.g., EAL2 vs EAL4+) increases, evaluators expect more depth and formality in each of these areas, but the underlying engineering tasks remain recognisable as good modern secure‑development practice.
4. Assessment & Conformity
4.1 Understanding Evaluation Assurance Levels (EALs)
The "level" of a Common Criteria certificate is its Evaluation Assurance Level (EAL), from 1 (lowest) to 7 (highest). The EAL does not measure the security of the product itself, but rather the rigour and depth of the evaluation process (CC Part 3 § 8). A higher EAL means evaluators demanded more formal design documentation, more intrusive testing, and more robust evidence of correctness.
For connected devices, EALs 1 through 4 are the most relevant.
| Level | Summary | Typical Use Case for Connected Devices |
|---|---|---|
| EAL1 | Functionally Tested | Basic check against functional specs. Rarely used for security products but may be a starting point for legacy systems. |
| EAL2 | Structurally Tested | Requires some design information and "white-box" testing. Suitable for low-risk devices where some assurance is needed. |
| EAL3 | Methodically Tested and Checked | Requires more thorough documentation and testing, including development environment controls. Good for moderate-risk devices. |
| EAL4 | Methodically Designed, Tested, and Reviewed | The most common level for commercial high-security products. Requires a rigorous positive security model and penetration testing. |
| EAL5+ | Semiformally or Formally Verified | EAL5 and above are extremely rigorous and expensive, typically reserved for critical infrastructure, military, and high-risk ICs. |
4.2 The Evaluation Process
Common Criteria evaluations are typically performed by accredited third-party laboratories under the rules of a national or regional CC scheme (CEM § 8.1). At a high level, the steps are:
- Define the Security Target (ST) – The vendor describes the TOE, its environment, threats, assumptions, and chosen SFR/SAR set (often referencing a Protection Profile where one exists for the product class).
- Implement and document – Engineering teams build the product and produce the design, guidance, test, and lifecycle evidence required by the chosen assurance level.
- Independent evaluation – A CC lab analyses the ST, reviews design and process artefacts, repeats or re‑performs tests, and conducts vulnerability analysis and penetration testing according to ISO/IEC 18045.
- Certification – If the evaluation is successful, the scheme issues a certificate noting the TOE, its version, the applicable PPs, and the achieved EAL (or equivalent assurance claim).
For secure‑by‑design device teams, the most pragmatic way to use CC is often:
- Treat CC functional and assurance themes as a structured checklist during architecture and SDL design.
- Decide early whether you need formal certification; if not, you can still reuse CC requirements and artefact expectations to improve your engineering discipline and to support other laws (e.g., CRA, NIS 2, PSTI).