Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesCommon Criteria Evaluation Assurance Levels (EAL1 through EAL7) are predefined packages of assurance requirements. A higher EAL means a more rigorous evaluation package—not an automatic guarantee that a product is more secure in every use. To judge a certificate, check what product and functions were evaluated, what security claims were made, and what evidence and testing the package required.
What an Evaluation Assurance Level means
The Common Criteria is implemented through the ISO/IEC 15408 family of standards. ISO/IEC 15408-1 sets out the evaluation model, including the Target of Evaluation (TOE), Protection Profiles (PPs), Security Targets (STs), conformance types and evaluation methods. ISO/IEC 15408-3 defines assurance components that can be assembled into predefined EALs and other packages. See ISO/IEC 15408-1 and ISO/IEC 15408-3.
An EAL is a package of assurance requirements applied to a defined TOE. The TOE is the specific product, system, or part of a system within the evaluation’s scope. A Security Target documents the security claims and scope for that evaluation. The certificate therefore does not amount to an unrestricted guarantee covering every product feature, configuration, deployment, or connected service.
What EAL1 through EAL7 require
ISO/IEC 15408-5 defines seven hierarchically ordered EAL packages. Assurance increases through added or more rigorous requirements, broader evidence, deeper testing, and more demanding vulnerability analysis. The official package names and practical emphasis are summarized below; the emphasis is not a substitute for the exact requirements in a certificate’s evaluation.
#1 Best Overall
| Level | Official package name | Practical emphasis |
|---|---|---|
| EAL1 | Functionally tested | Basic independent confidence for cases where threats are not considered serious. Includes functional and interface specifications, guidance, independent testing, and public-domain vulnerability searching. |
| EAL2 | Structurally tested | Adds developer design information and test results, independent testing, confirmation of selected developer tests, and vulnerability analysis. |
| EAL3 | Methodically tested and checked | Adds an architectural description and broader developer evidence. Intended to provide moderate independently assured security without substantial re-engineering. |
| EAL4 | Methodically designed, tested and reviewed | Adds a complete interface specification, basic modular design, review of an implementation subset, and more rigorous vulnerability analysis. Aimed at conventional commodity products needing moderate to high assurance. |
| EAL5 | Semi-formally designed and tested | Uses rigorous commercial development practices, modular design, fuller implementation evidence, and AVA_VAN.4 methodical vulnerability analysis. |
| EAL6 | Semi-formally verified design and tested | Targets high-value assets and high-risk situations. Adds formal modelling of selected security policies, semi-formal specifications and design, structured development, and resistance analysis for high attack potential. |
| EAL7 | Formally verified design and tested | For extremely high-risk situations. Requires formal or semi-formal design evidence, complete independent confirmation of developer testing, high-attack-potential vulnerability analysis, strong configuration and development controls, and secure-delivery evidence. Its extensive formal-analysis demands make it practical chiefly for tightly focused functionality. |
The official EAL7 objective says it is applicable to security TOEs for “extremely high-risk situations and/or where the high value of the assets justifies the higher costs.” That describes an intended use case, not universal security superiority. See the EAL package descriptions and objectives.
Does a higher EAL mean a product is more secure?
A higher EAL means the TOE was evaluated against a more demanding assurance package. It does not, on its own, show that the product has stronger security functions, addresses a particular threat better, or is more secure than a lower-EAL product in a specific deployment. The level speaks to the rigor and scope of assurance requirements; the Security Target says what was claimed and evaluated.
For a meaningful comparison, examine:
- TOE scope: Identify the exact product, version, components, and functions covered.
- Security Target: Read the documented security claims, assumptions, and boundaries of the evaluation.
- Assurance components: Check which assurance families and requirements are included, not just the EAL number.
- Evidence and testing: Compare developer evidence and the depth of independent testing.
- Vulnerability analysis: Consider the required analysis and attack potential addressed.
- Development controls: Check formalisation, configuration management, lifecycle, and delivery evidence relevant to the level.
ISO/IEC 15408-1 describes the evaluation model and TOE and Security Target concepts; the level packages and their components are set out in ISO/IEC 15408-5 and ISO/IEC 15408-3. See ISO/IEC 15408-1, ISO/IEC 15408-3, and ISO/IEC 15408-5.
What Common Criteria evaluates—and what it does not
The evaluation assesses a defined TOE against its documented security claims, using specified evaluation methods and assurance requirements. Depending on the package, the work can include reviewing design and development information, checking developer testing, conducting independent tests, and analysing vulnerabilities.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #3
An EAL certificate should not be read as a claim that every feature in a vendor’s wider product ecosystem was assessed, that the product is invulnerable, or that it remains secure regardless of configuration and use. The TOE boundary and Security Target are essential context for understanding what the evaluation establishes.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Which EAL should a product have?
There is no universally appropriate EAL. Select an assurance target based on the threats the product must withstand, the value of the assets it protects, the scope that can realistically be evaluated, and the evidence that can be produced. A higher level may add useful assurance for high-risk, high-value use, but its additional rigor and evidence demands need to be feasible and relevant to the TOE.
Quick Recap
Best Value
Rank #4
- For a specific product, start with the threat model and the assets at risk.
- Confirm that the TOE includes the product functions and components your deployment depends on.
- Read the Security Target and certificate details rather than relying on a headline EAL.
- Match the required assurance depth to the risk and the evidence available; do not choose a level for prestige alone.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
