Evaluation Assurance Level (EAL) is a rating that indicates how thoroughly a product has been evaluated against Common Criteria. Higher levels generally mean more rigorous testing and review of design, implementation, and evidence. Security teams should treat EAL as an assurance indicator, then still assess whether the product’s functions and configuration meet their own requirements.
What EAL tells you about Common Criteria assurance
EAL is not a product feature score, it is a shorthand for the depth of assurance work performed during a Common Criteria evaluation. That means the number helps you compare how much evidence, analysis, and testing went into the certification claim, but it does not prove the product is the best fit for your environment, threat model, or deployment pattern.
In practice, EAL is most useful as a signal about assurance rigor and review completeness. It becomes much less useful if teams treat the rating as a substitute for configuration review, architecture review, or operational validation.
What higher EAL levels usually mean in practice
Higher EALs generally imply more scrutiny of the design, implementation, and supporting evidence, but the practical meaning depends on what exactly was evaluated. A product can be evaluated to a high level while still leaving gaps in the way you deploy it, integrate it, or operate it.
That is why Common Criteria should be read as a bounded assurance statement, not as a universal security verdict. The result is strongest when the evaluated version, security target, assumptions, and operational environment closely match your own use case.
For identity and authentication products, this distinction matters because assurance about the component does not automatically translate into assurance about your whole access flow. If you want the underlying digital identity context, NIST SP 800-63 Digital Identity Guidelines explains how assurance level, authenticators, and federation choices fit into a broader access decision.
How to use EAL without over-trusting the label
The right way to use EAL is to treat it as one input to procurement and assurance, then verify the parts that matter most to your deployment. Check whether the certified scope matches the version you plan to run, whether the evaluated configuration is realistic, and whether any security-relevant settings are left to you to implement correctly.
That is especially important when the product depends on authentication strength, session handling, or administrative controls that sit outside the evaluated boundary. If you are assessing sign-in or credential mechanics as part of the deployment, NHIMG’s Workforce Identity Security Guide is a useful companion for understanding how assurance claims interact with real-world access controls.
EAL also should not be confused with resistance to every modern attack path. A product can satisfy an assurance target and still be weak if the surrounding environment permits weak recovery processes, poor privilege hygiene, or unsafe administrative access. For teams comparing strong authentication options, the Passwordless and Passkeys Guide helps translate assurance thinking into practical sign-in decisions.
Risk and Threat Considerations
The main risk is assuming that a higher EAL automatically means the product is secure in your environment. That mistake can leave teams exposed to misconfiguration, mismatched assumptions, weak integration controls, or an evaluated feature set that does not cover the paths an attacker is most likely to use.
Failure mechanism: Security teams accept the certification label as a stand-alone trust decision, then fail to validate the deployed configuration, the version actually installed, or the operational controls that were outside the evaluation boundary.
Impact: The organization may deploy a product that looks assured on paper while still exposing sensitive functions, weakening access control, or creating a false sense of certification-driven safety.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL — Authenticator Assurance Level | EAL is often interpreted alongside identity assurance and authenticator strength in deployment decisions. |
| Recommendation — Map assurance claims to the required authenticator and federation strength before approving access design. | ||
| ISO/IEC 27001:2022 | A.5.36 — Compliance with policies, rules and standards for information security | Common Criteria and EAL are assurance claims that support security governance and control verification. |
| Recommendation — Verify that certified scope and operational use match your security policy requirements. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | EAL reflects evaluation depth, which aligns with independent testing and evidence review. |
| CM-6 — Configuration Settings | EAL value depends on using the evaluated configuration, not only the certified product name. | |
| Recommendation — Require independent evaluation evidence that matches the deployed product and configuration. Enforce the evaluated configuration and review deviations before trusting the assurance level. | ||
Practitioner Guidance
What to verify: Confirm the certified product version, evaluated configuration, and security target before you rely on the EAL. If your deployment differs materially from the evaluated setup, treat the rating as informative rather than decisive.
Decision rule: If the product will protect sensitive data, privileged access, or externally exposed services, require the EAL claim to be paired with configuration validation and operational testing. If those controls are not feasible, lower the trust you place in the certification result.
What practitioners underestimate: EAL often answers “how much assurance was produced,” not “how well the product will resist your specific threat model.” The practical question is whether the certified evidence actually supports the way you intend to use the product.
Practitioner takeaway: Use EAL as a structured assurance signal, then make the final trust decision from the evaluated scope, the deployed configuration, and your own control checks, not from the rating alone.