Evaluation Assurance Level
The Evaluation Assurance Level (EAL) is a predefined numerical rating within the Common Criteria for Information Technology Security Evaluation (CC), an international standard (ISO/IEC 15408) that specifies a framework for assessing the security functions and assurance of IT products and systems.[1][2] EALs represent points on a hierarchical assurance scale, ranging from EAL1 to EAL7, where each level defines a package of assurance requirements that increase in depth, rigor, and scope to verify that the product's security claims are met.[3][4] The CC framework, managed under the Common Criteria Recognition Arrangement (CCRA) by participating nations, enables independent evaluation laboratories to test products against Protection Profiles or Security Targets, culminating in certification at a specific EAL.[5][6] EAL1 provides basic functional testing for straightforward security needs, while progressively higher levels—such as EAL2 (structural testing with basic design review), EAL3 (methodical testing and configuration management), and EAL4 (methodical design, testing, and review)—demand more extensive evidence of development processes, vulnerability analysis, and independent verification.[7][8] EAL5 through EAL7 incorporate advanced techniques like semi-formal or formal design verification and comprehensive testing, typically reserved for high-risk environments like government or critical infrastructure systems.[3][9] EAL certifications assure consumers and acquirers of a product's security reliability, with mutual recognition up to EAL4 under the CCRA, facilitating global trade while promoting consistent evaluation methodologies.[5][10] However, EAL does not directly measure a product's inherent security strength but rather the thoroughness of its evaluation, emphasizing that higher levels often require significant developer investment in documentation and testing.[11][8]Overview
Definition and Purpose
The Evaluation Assurance Level (EAL) is a numerical grade ranging from 1 to 7 assigned to an IT product upon completion of a security evaluation under the Common Criteria framework, signifying the rigor and depth of testing and verification conducted to confirm the product's security properties.[12] It constitutes a predefined package of security assurance requirements (SARs) drawn from Common Criteria Part 3, providing a standardized metric for the confidence that the product correctly implements its specified security functional requirements (SFRs).[2] The purpose of EALs is to establish a graduated scale for gauging the trustworthiness of IT products against their security requirements, enabling organizations to make informed decisions during procurement and to conduct effective risk assessments in environments where security is paramount.[2] By delineating levels of evaluation effort, EALs help quantify the potential for undetected vulnerabilities or flaws, thereby supporting the selection of products that align with specific threat models and operational needs.[12] At their core, EALs rely on assurance components outlined in Common Criteria Part 3, which include families such as development (ADV) for design and implementation evidence, guidance (AGD) for operational documentation, life-cycle support (ALC) for configuration and remediation processes, testing (ATE) for coverage and depth verification, and vulnerability assessment (AVA) for flaw identification.[12] These components emphasize the systematic collection of evidence—ranging from functional specifications and test results to detailed architectural analyses—as well as escalating testing depths from basic subsystem checks to full implementation representation, complemented by vulnerability analyses that progress from basic surveys to advanced penetration testing against high attack potentials.[12] EALs balance functional security, which defines the intended security behaviors of the product, with assurance, which evaluates the reliability of those behaviors through progressive increases in scrutiny and evidence demands, ensuring greater confidence in the product's security without expanding its functional scope.[12] The Common Criteria provides the overarching international standard for these evaluations, harmonizing practices across participating nations.[2]Relation to Common Criteria
The Common Criteria (CC), internationally standardized as ISO/IEC 15408, provides a framework for evaluating the security of information technology products and systems. In its current iteration, CC:2022, the standard is divided into five parts. Part 1 offers an introduction and general model, establishing the foundational concepts, terminology, and evaluation principles. Part 2 defines security functional requirements, cataloging the specific security functionalities that products must demonstrate. Part 3 outlines security assurance requirements, which include predefined assurance packages such as the Evaluation Assurance Levels (EALs). Part 4 specifies the framework for evaluation methods and procedures, guiding how assurance requirements are assessed. Part 5 provides pre-defined packages of security requirements to support consistent evaluations.[2][13] Within the Common Criteria, Evaluation Assurance Levels serve as a core subset of the assurance packages detailed in Part 3, offering a standardized grading scale for the rigor of security evaluations. Product vendors incorporate an EAL by selecting it as the target assurance package when developing a Protection Profile (PP)—a reusable template of security requirements—or a Security Target (ST), which tailors requirements to a specific product. This selection ensures that the evaluation addresses both functional security needs from Part 2 and the corresponding assurance activities from the chosen EAL.[12][3] The evaluation process under Common Criteria involves independent, certified laboratories that conduct testing and analysis in accordance with the Common Evaluation Methodology (CEM, ISO/IEC 18045). Vendors submit their product, along with the PP or ST specifying the target EAL, to an accredited lab for assessment. National certification schemes oversee this process; for example, the National Information Assurance Partnership (NIAP) in the United States accredits Common Criteria Testing Laboratories (CCTLs) and validates evaluation results to ensure compliance with scheme-specific policies. Successful evaluations culminate in the issuance of a CC certificate by the national scheme, affirming the product's adherence to the specified EAL.[14][15] As of November 2025, the active version of Common Criteria remains CC:2022 Revision 1, following the ongoing transition from CC version 3.1 Revision 5, initiated in 2022 with key deadlines through 2027; this version maintains the traditional structure of seven EALs (EAL1 through EAL7) without alteration, alongside new assurance packages for enhanced flexibility. Ongoing maintenance by the Common Criteria Development Board ensures alignment with evolving security needs, with certifications like those issued in 2025 explicitly referencing CC:2022.[16][17]History and Development
Origins in Predecessor Standards
The Evaluation Assurance Levels (EALs) within the Common Criteria framework trace their roots to several national and regional IT security evaluation standards developed in the 1980s and early 1990s, which established foundational concepts of assurance through graduated levels of testing, design verification, and documentation rigor.[18] These predecessors addressed the growing need for standardized assessments of computer system security amid increasing reliance on IT for sensitive applications, particularly in government and defense sectors.[19] In the United States, the Trusted Computer System Evaluation Criteria (TCSEC), commonly known as the Orange Book, was first issued in 1983 by the National Computer Security Center under the National Security Agency and updated in 1985 by the Department of Defense. TCSEC defined four divisions of security protection—D (minimal), C (discretionary), B (mandatory), and A (verified)—with seven hierarchical classes from D to A1, where higher classes demanded progressively rigorous evidence of secure design, such as formal verification models and extensive testing to ensure protection against unauthorized disclosure.[20] This class-based structure directly influenced the escalating assurance requirements in later EALs, emphasizing comprehensive life-cycle evaluation from design to operation.[19] Europe's Information Technology Security Evaluation Criteria (ITSEC) emerged in 1990, jointly developed by France, Germany, the Netherlands, and the United Kingdom to harmonize national approaches.[21] Unlike TCSEC's integrated classes, ITSEC innovated by separating security functionality (rated F1 to F10 based on features like identification and audit) from assurance (levels E1 to E6, ranging from basic testing at E1 to structured construction and vulnerability analysis at E6), allowing flexible combinations that better accommodated diverse product types and international interoperability.[21] This decoupling of functionality and assurance became a core principle in the EAL framework, enabling evaluations focused on implementation confidence independent of feature scope.[18] Canada's Trusted Computer Product Evaluation Criteria (CTCPEC), published in 1993 by the Communications Security Establishment, built on TCSEC while incorporating ITSEC elements, such as explicit separation of functional and assurance requirements across levels A1 to D, with added emphasis on commercial off-the-shelf products and lifecycle management.[19] These standards collectively highlighted the limitations of fragmented national criteria, which often required redundant evaluations for products entering multiple markets, motivating international collaboration.[18] The push for unification arose from the need to streamline global trade in secure IT products by eliminating duplicate certifications and fostering mutual recognition among governments.[19] In June 1993, sponsoring organizations from the TCSEC, ITSEC, CTCPEC, and French Critères de Sécurité des Systèmes d'Information (CSSI) initiated development of a harmonized standard, culminating in the first version of the Common Criteria as ISO/IEC 15408 in 1999.[19] This unification integrated the rigor of TCSEC classes, ITSEC's separation model, and CTCPEC's practical adaptations into the EALs, providing a single international benchmark for assurance.[18]Evolution of the Common Criteria Framework
The Common Criteria (CC) framework was first published as version 1.0 in 1996, establishing a standardized approach to IT security evaluation that harmonized disparate national standards into a unified international model, with the ISO/IEC 15408 standard adopting version 2.1 in 1999. This initial version introduced the concept of Protection Profiles (PPs), which allow stakeholders to define reusable sets of security requirements for specific product types, promoting consistency across evaluations. Concurrently, the framework shifted toward modular assurance packages, enabling evaluators to select and combine assurance components tailored to the target's security needs rather than rigid, predefined levels, thereby enhancing flexibility while maintaining rigor in assessing security functions and vulnerabilities.[22] Subsequent revisions refined these foundations, with CC version 3.1 released in 2007 to streamline evaluation processes and reduce redundancies. Key updates included CC 3.1 Revision 4 in September 2012, which expanded the assurance component catalog by adding extended components for advanced threats, such as enhanced vulnerability analysis and testing methodologies. Further, CC 3.1 Revision 5, published in April 2017, incorporated minor clarifications to evaluation guidance without altering the core Evaluation Assurance Levels (EALs). In November 2022, CC version 2022 (CC v2022 Release 1) was published as the current version, introducing updates to assurance components, new families for contemporary threats like quantum-resistant cryptography, and better support for emerging technologies such as AI/ML security; new evaluations must use CC v2022 starting July 2024, with transitional use of CC 3.1 permitted until December 2027 for compliant Security Targets. These evolutions emphasized practical improvements, such as better support for iterative development and evidence collection, to balance assurance depth with evaluation efficiency.[4][23][2] The framework's international adoption was bolstered by the Common Criteria Recognition Arrangement (CCRA), established in 1999 among founding members including Canada, France, Germany, the United Kingdom, and the United States, to facilitate mutual acceptance of evaluation results up to EAL4, covering a broad range of commercial products while reserving higher levels for specialized national needs. A 2014 revision to the CCRA, effective from 2017, reaffirmed and refined limitations to mutual recognition for EAL1 through EAL4 (or equivalent assurance packages up to AVA_VAN.3 when based on collaborative Protection Profiles), citing the escalating costs and complexity of higher-level evaluations, which often exceed practical benefits for most IT products. This focus on lower to mid-level assurances has driven broader participation.[24] Adaptations under the CCRA have addressed emerging technologies, with collaborative efforts yielding extensions for cloud computing and Internet of Things (IoT) security. For instance, the CC in the Cloud (CCitC) guidance, developed through international working groups and first publicly released in February 2024 (version 1.1.1 as of 2025), provides methodologies for evaluating virtualized environments and multi-tenant systems, ensuring assurance continuity in dynamic cloud deployments. Similarly, specialized PPs for IoT devices, such as the IoT Secure Communications Module Protection Profile released in December 2019, incorporate components for constrained environments, including secure boot and remote attestation, to mitigate risks like unauthorized access in resource-limited ecosystems. These developments reflect the framework's responsiveness to technological evolution while preserving core assurance principles.[25][26]Assurance Levels
EAL1: Functionally Tested
EAL1, or Evaluation Assurance Level 1, represents the most basic level of assurance in the Common Criteria framework, providing evidence that the target of evaluation (TOE) functions as specified in its functional requirements. It is applicable in circumstances where some confidence in correct operation is desired, but the threats to security are not considered serious, such as in low-risk environments involving the protection of personal data. This level requires a limited Security Target (ST) that states only the security functional requirements (SFRs) without deriving them from specific threats or organizational security policies.[3] The assurance package for EAL1 consists of key components including ADV_FSP.1 (Basic functional specification), ATE_IND.1 (Independent testing – conformance), and AVA_VAN.1 (Vulnerability survey). Under ADV_FSP.1, the developer must provide a functional specification that describes the TOE security functions (TSF) and their external interfaces in sufficient detail to allow understanding of how the SFRs are realized. This specification serves as the basis for subsequent testing but does not involve any analysis of the TOE's internal design or structure. ATE_IND.1 mandates independent testing by the evaluator to confirm conformance to the functional specification. AVA_VAN.1 requires a search of public domain sources to identify potential vulnerabilities in the TOE, assessing whether any known issues could lead to exploitable weaknesses under stated assumptions, though it does not include active penetration testing or advanced analysis.[3] The testing scope at EAL1 is confined to functional verification, where the evaluator independently tests the TOE against the SFRs to confirm that the TOE security functionality behaves as documented. No design analysis, structural examination, or configuration management beyond basic documentation is required, emphasizing a straightforward demonstration of intended functions rather than rigorous scrutiny of implementation details. This approach ensures minimal expenditure of time and resources, allowing evaluations to proceed with limited developer assistance if needed.[3] Evidence requirements for EAL1 include the limited ST, the functional and interface specification from ADV_FSP.1, test results from ATE_IND.1, and the vulnerability survey report from AVA_VAN.1, along with basic guidance documentation for secure operation. There is no mandate for independent penetration testing, as the vulnerability assessment relies solely on publicly available information. Typically, EAL1 is suited for consumer software or systems in low-risk settings, such as basic personal information protection tools, where the shortest evaluation durations apply due to the limited scope. Higher EALs build upon this foundation by incorporating greater rigor in design and testing. Under CC:2022, all EALs include ASE components for ST evaluation, and certifications typically conform to Protection Profiles at the specified EAL.[3]EAL2: Structurally Tested
EAL2, known as Structurally Tested, builds on the functional testing of EAL1 by incorporating a review of the target's structure to provide moderate assurance of security functionality implementation. This level requires the developer to supply design information, test documentation, and evidence demonstrating that the target of evaluation (TOE) operates as specified, while evaluators perform independent testing to confirm coverage and basic vulnerability resistance. It is designed for scenarios where the developer cooperates fully but extensive redesign or formal analysis is not feasible, offering a cost-effective step up in rigor for products facing moderate threats.[3] The core assurance components for EAL2 include ADV_FSP.2 (Security-enforcing functional specification), which mandates a detailed, informal specification tracing security functional requirements (SFRs) to the TOE's interfaces, including parameters, error handling, and high-level design of security mechanisms. ATE_COV.1 (Evidence of coverage) requires developers to provide test evidence showing that security functions are exercised through the TOE's interfaces, ensuring partial coverage of the functional specification via developer-conducted tests. AVA_VAN.2 (Vulnerability analysis) involves a developer assessment of potential weaknesses, considering basic attack potential from public sources, supplemented by evaluator penetration testing to identify exploitable flaws. These components emphasize structural elements absent in EAL1, such as a basic TOE design description under ADV_TDS.1, which reviews the security-relevant code structure, subsystems, and interfaces for consistency with the functional specification. Additionally, developer testing occurs with some independence under ATE_IND.2, where tests are performed at the developer's site but reviewed by evaluators.[3] Evidence requirements under EAL2 include configuration management via ALC_CMC.2, which ensures a system for identifying, controlling, and tracking configuration items to maintain TOE integrity across versions, and ALC_DEL.1, mandating documented procedures for secure delivery to end-users, verifying authenticity and preventing tampering during distribution. These life-cycle controls support traceability without the methodical rigor of higher levels.[3] EAL2 is typically applied to general commercial products and network devices in medium-risk environments, such as firewalls or routers handling enterprise traffic, where moderate assurance suffices for off-the-shelf software or legacy systems without high-threat exposure. For instance, products like Juniper Networks routers and Cisco Catalyst switches have been certified at EAL2 for secure network operations. This level balances development effort and evaluation time, typically taking 6 to 12 months at a cost of $200,000 to $500,000 depending on the TOE scope and evaluation lab, making it suitable for applications requiring structured testing over basic functionality alone.[27][28][29][30]EAL3: Methodically Tested and Checked
Evaluation Assurance Level 3 (EAL3), known as "Methodically Tested and Checked," extends the structural testing of EAL2 by incorporating systematic configuration management and depth in testing to enhance reliability in development processes.[3] This level targets moderate assurance for IT products, emphasizing thorough investigation without extensive re-engineering, making it suitable for environments where security is important but not mission-critical.[3] The core assurance components of EAL3 include ALC_CMC.3 for systematic configuration management, which requires developers to establish a configuration management system covering the target of evaluation (TOE) implementation representation with authorization controls to track changes and versions.[3] ATE_DPT.1 addresses depth testing by mandating that developers provide test documentation based on the TOE design, enabling evaluators to perform independent tests of the TOE security functions (TSF) at a basic design level.[3] Although ADV_IMP.1 for implementation representation is typically associated with higher levels, EAL3 incorporates elements of implementation review through related development components like ADV_TDS.2, ensuring the architectural design supports methodical verification.[3] Key features of EAL3 center on a methodical review of the implementation, achieved through developer-provided evidence of testing aligned with functional specifications and TOE design, supplemented by selective evaluator confirmation.[3] Independent vulnerability analysis is conducted under AVA_VAN.2, where evaluators assess the TOE's resistance to attackers with basic capabilities, using provided specifications, designs, and guidance documentation to identify potential weaknesses.[3] This analysis demonstrates that no residual vulnerabilities allow unauthorized access or disruption beyond expected threats in controlled settings.[3] EAL3 is typically applied to operational systems in controlled environments, such as enterprise software for network security or data management, where moderate assurance suffices for deployment in organizational settings without extreme risks. Evidence requirements include procedures for flaw remediation, often augmented via ALC_FLR components, mandating developers to define processes for identifying, reporting, and correcting security flaws with timely updates and distribution mechanisms.[27] Basics of a secure development environment are ensured through ALC_DVS.1, requiring identification of measures to protect the development process from unauthorized interference, and ALC_DEL.1, which outlines secure delivery procedures to maintain TOE integrity post-development.[3]| Assurance Component | Focus Area | Key Requirement |
|---|---|---|
| ALC_CMC.3 | Systematic Configuration | Authorization controls and traceability for TOE changes[3] |
| ATE_DPT.1 | Depth Testing | Design-based testing documentation and independent verification[3] |
| AVA_VAN.2 | Vulnerability Analysis | Demonstration of resistance to basic attacks via provided evidence[3] |