Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
A Professional Technical Analysis of IEC 15408-2-09: Security Functional Components for Common Criteria Evaluations
Exploring the taxonomy, application, and compliance requirements of the ISO/IEC 15408-2:2014 (IEC 15408-2-09) catalog for defining IT product security functionality.
Scope and Foundational Role of IEC 15408-2-09
ISO/IEC 15408-2:2014, commonly identified by the framework reference IEC 15408-2-09, serves as the definitive catalogue of standardised Security Functional Requirements (SFRs) within the Common Criteria (CC) framework. Formally titled “Information technology — Security techniques — Evaluation criteria for IT security — Part 2: Security functional components,” this standard provides the essential building blocks for constructing the functional security posture of a Target of Evaluation (TOE).
The primary objective of IEC 15408-2-09 is to establish a structured, hierarchical taxonomy of security functions. By defining a precise vocabulary of Classes, Families, Components, and Elements, it enables vendors, evaluators, and certification bodies to communicate security specifications unambiguously. This common language is the cornerstone of the Common Criteria Recognition Arrangement (CCRA), facilitating the cross-border acceptance of certificates and reducing market barriers for evaluated security products.
Technical Taxonomy: Classes, Families, and Components
The SFRs defined in IEC 15408-2-09 are organized into a strict hierarchy that descends from abstract security goals down to atomic, verifiable requirements. The top tier is the Class, which groups families based on a broad security focus, such as audit or identification. Each class is subdivided into Families sharing a specific security objective. Families contain Components, which represent a specific set of security requirements that can be selected and evaluated. Each component is further broken down into Elements, which are the smallest, indivisible security requirements.
Major Security Functional Classes
Tip for Evaluators: While the hierarchy of Class > Family > Component > Element is strictly enforced, the most critical unit of selection for a Security Target (ST) author is the Component. Understanding the internal dependencies of each component is essential for building a logically consistent security model.
| Class Identifier | Class Name | Example Family (Components) |
|---|---|---|
| FAU | Security Audit | FAU_GEN (Security audit data generation), FAU_SAR (Security audit review) |
| FCS | Cryptographic Support | FCS_CKM (Cryptographic key management), FCS_COP (Cryptographic operation) |
| FDP | User Data Protection | FDP_ACC (Access control policy), FDP_UCT (User data confidentiality export) |
| FIA | Identification and Authentication | FIA_AFL (Authentication failures), FIA_USB (User-subject binding) |
| FMT | Security Management | FMT_MTD (Management of TSF data), FMT_SMF (Specification of Management Functions) |
| FPT | Protection of the TSF | FPT_FLS (Fail secure), FPT_TST (TSF self-test) |
| FTA | TOE Access | FTA_SSL (Session locking), FTA_TSE (TOE session establishment) |
Table 1: Primary SFR classes defined in IEC 15408-2-09. Each class provides the foundational vocabulary required to express the complete security functionality of a TOE in a Protection Profile (PP) or Security Target (ST).
Application, Customization, and Operations in Security Targets
When implementing IEC 15408-2-09, authors of Security Targets are not merely copying text from the standard; they are required to apply four specific operations to tailor the components to their specific TOE. The precise application of these operations is a major focus of the evaluation.
- Iteration: Using the same component multiple times for different policies or mechanisms (e.g., FDP_ACC.1 for two distinct access control policies).
- Assignment: Filling in an open parameter from the standard, such as specifying a specific cryptographic algorithm or a password length.
- Selection: Choosing one or more items from a predefined list provided in the component (e.g., selecting AES-128 or AES-256).
- Refinement: Adding extra detail to a requirement to clarify its application. Refinement must never contradict the intent of the component.
Critical Compliance Note: The misuse of the Refinement operation is a common source of evaluation findings. Refinements must strictly add detail or clarify ambiguity without narrowing the scope of the standard requirement. An invalid refinement can void the conformance claim to the component.
Furthermore, the standard mandates that every component dependency must be explicitly satisfied. For example, selecting the component FCS_COP.1 (Cryptographic operation) creates an immediate dependency on FCS_CKM.1 (Cryptographic key generation) or FCS_CKM.4 (Cryptographic key destruction). These dependency links must be clearly documented in the ST’s SFR rationale.
Compliance, Conformance, and Certification Notes
Compliance with IEC 15408-2-09 is verified during the formal Common Criteria evaluation. A TOE is deemed “CC Part 2 conformant” if its Security Target correctly selects, iterates, assigns, and refines the functional components defined in this standard without contradiction. It is important to distinguish the 2014 edition from its 2008 predecessor. The 2014 edition introduced significant clarifications to the FCS class, aligning it with contemporary cryptographic standards such as Elliptic Curve Cryptography and updated key derivation methods.
Benefits of Adoption: Products built against a well-structured set of SFRs from IEC 15408-2-09 benefit from streamlined evaluations and enhanced global market acceptance. A coherent SFR selection allows for easier recertification across different national schemes, reducing long-term compliance costs.
National certification schemes (such as NIAP in the USA and BSI in Germany) may publish specific interpretive guidance or add national requirements, but the core hierarchy and selection logic of IEC 15408-2-09 remains the universal benchmark. When collaborating with accredited laboratories, it is imperative to ensure that the Security Target explicitly lists the source of every SFR component, including the edition of the standard.
Avoid This Mistake: Relying on pre-2014 drafts of SFR catalogues can lead to evaluation findings regarding deprecated requirements. Always verify that your SFR selection is sourced directly from the IEC 15408-2-09 edition (ISO/IEC 15408-2:2014) to ensure compliance with the latest threat modeling and cryptographic expectations.
In conclusion, IEC 15408-2-09 provides the rigorous, structured language required to define security functionality in the Common Criteria ecosystem. Mastery of its taxonomy, operations, and dependency rules is essential for any organization pursuing formal IT security certification.
Frequently Asked Questions
Q: What is the primary purpose of IEC 15408-2-09?
A: The standard provides a comprehensive catalogue of Security Functional Requirements (SFRs). Its purpose is to standardize the language used to describe “what” a Target of Evaluation (TOE) must do to secure its assets, enabling consistent, comparable, and mutually recognizable security evaluations across international borders.
A: The standard provides a comprehensive catalogue of Security Functional Requirements (SFRs). Its purpose is to standardize the language used to describe “what” a Target of Evaluation (TOE) must do to secure its assets, enabling consistent, comparable, and mutually recognizable security evaluations across international borders.
Q: How does IEC 15408-2-09 relate to Protection Profiles (PPs)?
A: Protection Profiles define a standard set of security requirements for a specific type of product (e.g., a firewall, database, or smart card). They rely entirely on the SFRs from IEC 15408-2-09 to define the functional requirements. A PP must explicitly cite the standard and can only use operations (Selection, Assignment) authorized by it.
A: Protection Profiles define a standard set of security requirements for a specific type of product (e.g., a firewall, database, or smart card). They rely entirely on the SFRs from IEC 15408-2-09 to define the functional requirements. A PP must explicitly cite the standard and can only use operations (Selection, Assignment) authorized by it.
Q: What happens if an SFR dependency is unmet in a Security Target?
A: Every component in the standard includes a “Dependencies” field. During evaluation, the laboratory rigorously checks that for every SFR selected, all its dependent components are present. An unmet dependency is considered a critical finding and will prevent the Security Target from being certified until it is resolved by selecting the missing component or providing a formal rationale.
A: Every component in the standard includes a “Dependencies” field. During evaluation, the laboratory rigorously checks that for every SFR selected, all its dependent components are present. An unmet dependency is considered a critical finding and will prevent the Security Target from being certified until it is resolved by selecting the missing component or providing a formal rationale.
Published 2026. This article provides a technical overview of IEC 15408-2-09 (ISO/IEC 15408-2:2014) and is intended for educational and professional reference within the IT security evaluation ecosystem.