Common Criteria Glossary

This glossary defines the vocabulary of Common Criteria (ISO/IEC 15408) evaluations as applied in CC:2022 and the schemes NenkinTracker tracks. Entries link to fuller wiki pages where available and to the canonical CC portal for the authoritative text.

For a narrative introduction, start with What is Common Criteria?. For evaluation rigor, see EAL Levels. For product-category requirements, see Protection Profiles.

Core framework

Common Criteria (CC): The international standard for evaluating IT security products, published as ISO/IEC 15408. It defines a language for stating security requirements, a method for demonstrating they are met, and a grading scale for evaluation rigor.
ISO/IEC 15408: The formal ISO publication of the Common Criteria standard. Parts 1 to 3 define the general model, Security Functional Requirements (SFRs), and Security Assurance Requirements (SARs) respectively; Part 4 and Part 5 cover evaluation methodology specification and pre-defined packages.
CC:2022: The current major release of the Common Criteria, aligned with ISO/IEC 15408:2022. It restructures the standard into five parts and introduces new components such as Part 4 methodology and Part 5 pre-defined packages.
CEM: The Common Methodology for Information Technology Security Evaluation, published as ISO/IEC 18045. CEM tells evaluators how to perform the work units that demonstrate a TOE meets each assurance requirement.

TOE, Security Target, and Protection Profile

Target of Evaluation (TOE): The product, component, or system that is being evaluated under Common Criteria. A TOE is not the whole product shipped to customers — it is precisely the scope defined in the Security Target.
Security Target (ST): A vendor-written document that specifies the security problem a TOE addresses, the security objectives, and the SFRs and SARs claimed. The ST is the contract between the vendor and the evaluator.
Protection Profile (PP): An implementation-independent set of security requirements for a category of products, such as network devices or full-disk encryption. A PP lets procurers and evaluators reuse a community-vetted problem statement instead of drafting their own.
collaborative Protection Profile (cPP): A Protection Profile developed by an international Technical Community (iTC) under the CCRA. cPPs are the preferred form for mutual recognition because they represent multi-nation consensus on what an evaluation should check.
PP-Module: An optional extension to a Base PP, defining additional SFRs for a specific feature or deployment variant. PP-Modules let a base protection profile accommodate add-ons (e.g., VPN for firewalls) without forking the PP itself.
PP-Configuration: A declared bundle of a Base PP and one or more PP-Modules. Vendors claim conformance to a specific PP-Configuration, telling evaluators which modules are in scope.

Assurance and rigor

Evaluation Assurance Level (EAL): A numerical grade from 1 to 7 that bundles a predefined set of SARs. A higher EAL means more thorough evaluation work; it does not directly mean the product is more secure.
Augmented EAL: An EAL rating that includes additional SARs beyond the baseline of that level, written with a trailing plus (e.g., EAL4+). Typical augmentations are AVA_VAN.5 for enhanced vulnerability analysis or ALC_FLR for flaw remediation.
Security Functional Requirement (SFR): A requirement stated in the standardized language of ISO/IEC 15408-2 that describes a behavior the TOE must exhibit, such as access control, auditing, or cryptographic operation. SFRs are what the TOE does.
Security Assurance Requirement (SAR): A requirement from ISO/IEC 15408-3 that describes evidence and evaluator activities needed to trust that the TOE correctly implements its SFRs. SARs are how the TOE is checked.
TOE Security Functionality (TSF): The combined hardware, software, and firmware of the TOE that must be relied on to enforce the SFRs. Everything outside the TSF is out of scope for trust decisions.
TSF Interface (TSFI): Any interface through which an external entity can interact with the TSF. TSFIs are the attack surface that evaluators must analyze for vulnerabilities.
Strength of Function (SOF): A legacy CC concept describing the minimum effort required to defeat a probabilistic or permutational security mechanism (e.g., a PIN). CC:2022 largely replaces SOF with AVA_VAN attack potential ratings.
Attack Potential: An AVA_VAN metric that grades the resources an attacker would need to exploit a TOE: Basic, Enhanced-Basic, Moderate, High, and Beyond High. It considers time, expertise, knowledge of the TOE, access, and equipment.

Security problem definition

Security Problem Definition (SPD): The section of a PP or ST that states the threats, Organizational Security Policies (OSPs), and assumptions defining the security problem the TOE is expected to solve.
Organizational Security Policy (OSP): A rule, procedure, or guideline imposed by the organization that operates the TOE. OSPs appear in the Security Problem Definition alongside threats and assumptions.
Assumption: A statement in the Security Problem Definition about the operational environment that is taken as true (e.g., physical protection of the TOE). If an assumption fails in deployment, the certification’s conclusions may not hold.
Threat: An adverse action in the Security Problem Definition that an attacker might perform against a TOE asset. Threats drive the security objectives and ultimately the SFRs.
Security Objective: A concise statement of intent describing how a threat is countered, a policy is enforced, or an assumption is upheld. Objectives bridge the Security Problem Definition and the formal requirements.
Operational Environment: Everything outside the TOE that the TOE depends on for secure operation, such as the host OS, physical facility, personnel, or network. Objectives for the operational environment are distinct from objectives for the TOE.

Schemes and recognition

ITSEF: IT Security Evaluation Facility: a commercial laboratory accredited by a national scheme to perform Common Criteria evaluations. ITSEFs author the Evaluation Technical Report and recommend certification.
Certification Body (CB): A national scheme authority that oversees ITSEFs, validates evaluation results, and issues the certificate. BSI, ANSSI, NIAP, and CCCS are examples of CBs.
CCRA: The Common Criteria Recognition Arrangement, a multilateral treaty under which member nations accept each other’s certificates up to agreed assurance levels. CCRA recognition is capped at EAL2 plus the ALC_FLR family for non-cPP evaluations.
SOG-IS: The Senior Officials Group Information Systems Security Mutual Recognition Agreement, a European arrangement that previously recognized high-EAL certifications up to EAL7 for specific technical domains such as smart cards. SOG-IS is being phased out in favor of EUCC.
EUCC: The European Union Common Criteria-based cybersecurity certification scheme, adopted under the EU Cybersecurity Act. EUCC replaces SOG-IS for EU member states and defines assurance levels “substantial” and “high”.
SESIP: Security Evaluation Standard for IoT Platforms, published by GlobalPlatform. SESIP offers lighter-weight assurance levels (SESIP 1 through 5) tailored to connected devices, reusing CC concepts and methodology.
PSA Certified: A security certification programme run by Arm and ecosystem partners for IoT chips, software, and devices. PSA Certified Level 1 is questionnaire-based, while Levels 2 through 4 involve laboratory evaluation, with Level 4 incorporating SESIP.
EMVCo: A consortium owned by American Express, Discover, JCB, Mastercard, UnionPay, and Visa. EMVCo operates security evaluation programmes for payment terminals, smart cards, and mobile payments using its own methodology.
MIFARE: A family of contactless smart card ICs from NXP Semiconductors, widely used in transit, access, and loyalty systems. Individual MIFARE products are evaluated under CC at high EALs against smart card Protection Profiles.
ESA: The European Space Agency, which operates security evaluation activities for space system components. In the NenkinTracker context, “ESA” refers to that programme’s certificates tracked alongside commercial CC schemes.
Certificate Authorizing Scheme: A CCRA member scheme that is authorized to issue certificates recognized by other members. Authorizing schemes operate their own ITSEFs and certification bodies.
Certificate Consuming Scheme: A CCRA member that recognizes certificates issued by authorizing schemes but does not issue its own. Consuming schemes rely on authorizing members’ evaluations.
Technical Community (iTC): An international working group under the CCRA responsible for drafting and maintaining collaborative Protection Profiles for a specific technology area, such as network devices or dedicated security components.
Supporting Document (SD): A mandatory or informative companion to a PP or cPP that provides additional evaluation activities, attack methods, or refinements. SDs are cited from cPPs and carry normative weight in evaluations.

Evaluation evidence

Evaluation Technical Report (ETR): The evaluator-authored report documenting all work units performed and the verdicts reached. The ETR is submitted to the certification body and is typically confidential, though certificates and ST excerpts are published.
Certification Report: The public document issued by a certification body summarizing the evaluation outcome, identifying the TOE, and listing assurance components met. Certification reports are the canonical source of record for a CC certificate.

SAR classes

ACM (class): In older CC versions, the Configuration Management class of SARs. In CC:2022 this content is covered by ALC_CMC and ALC_CMS, which address configuration management capabilities and scope.
ALC (class): Life-Cycle Support: the SAR class covering configuration management, delivery, development security, flaw remediation, life-cycle definition, and tools/techniques used by the developer.
ADV (class): Development: the SAR class covering design documentation including functional specification, TOE design, security architecture, implementation representation, and internal structure.
AVA (class): Vulnerability Assessment: the SAR class covering evaluator-driven penetration testing and vulnerability analysis. AVA_VAN is the single family in the class and drives AVA effort level.
ATE (class): Tests: the SAR class covering developer functional testing, test coverage, test depth, and independent evaluator testing. ATE ensures both the developer and the evaluator have tested the TSF.
AGD (class): Guidance Documents: the SAR class covering operational user guidance and preparative procedures, ensuring that administrators and users can deploy and use the TOE securely.
APE / ASE: Protection Profile Evaluation (APE) and Security Target Evaluation (ASE): SAR classes that evaluate the PP or ST document itself for internal consistency, completeness, and correctness before TOE evaluation begins.
ACO: Composition: the SAR class used when evaluating a TOE built from multiple already-evaluated components (e.g., an application on top of a certified OS). ACO establishes that the composite preserves the guarantees of its parts.

SFR operations and authoring

Extended Component: An SFR or SAR defined outside the Part 2/Part 3 catalogues, introduced in the ST or PP to cover requirements not met by standard components. Extended components require rationale and formal definition.
Refinement: An authorized tailoring of a standard SFR or SAR that narrows or adds detail without removing requirements. Refinements must not weaken the original component.
Iteration: The reuse of the same SFR in an ST to cover different assets, modes, or roles. Iterated SFRs are given distinguishing identifiers (e.g., FDP_ACC.1/Data vs FDP_ACC.1/Admin).
Assignment: An operation on an SFR where the ST author fills in a specific parameter (such as a list of users or a timeout). Assignments produce a concrete, testable statement from a parameterized component.
Selection: An operation on an SFR where the ST author chooses one or more options from a predefined list, for example selecting which hash algorithms the TOE implements from those allowed by the PP.
Conformance Claim: The ST or PP statement identifying which CC version, which PP(s), and which assurance package the document claims conformance to. Conformance can be “strict” or “demonstrable” under CC rules.
Exact Conformance: A stricter conformance mode used by NIAP-style PPs, requiring the ST to include exactly the SFRs the PP specifies, with no additions beyond those the PP explicitly permits.
Assurance Package: A named, reusable set of SARs such as EAL4 or a custom bundle defined in CC:2022 Part 5. Packages let authors refer to a standard rigor level without enumerating components.
Assurance Continuity: A maintenance process for keeping an existing certificate valid after minor TOE changes. Impact analyses and maintenance reports extend a certificate without requiring full re-evaluation.
Site Certification: CC certification of a developer’s production site rather than a product, attesting that the site’s processes meet ALC requirements. Site certificates are reusable across multiple product evaluations.