Common Criteria EAL5+

What EAL5+ Means in Common Criteria

Common Criteria EAL5+ sits in the higher-assurance range of the Common Criteria family. It signals that a product or system has been evaluated to a strong assurance baseline, and that additional evaluation work beyond the standard EAL5 package was performed for the specific target of evaluation. The “plus” matters because it means the result is not just the stock level.

Practically, EAL5+ is about confidence in the assurance case rather than a blanket statement that a product is intrinsically secure. The value of the rating depends on the exact scope of the evaluation, the security target, the evaluated configuration, and the assumptions the certificate makes about deployment and operation. It is best read as evidence of rigorous assessment, not as a universal security guarantee.

How Common Criteria Assurances Are Interpreted

Common Criteria evaluates security properties through a structured process that ties together the product definition, the claimed security functions, and the evidence submitted by the vendor and evaluator. EALs describe the depth of assurance activities, such as design review, testing, and vulnerability analysis, but they do not on their own define the full security profile of the product. The certificate is only meaningful when read with the security target and the certificate scope.

That is why one EAL5+ certificate cannot be assumed to be equivalent to another. The “plus” may reflect extra assurance components, but those additions vary by evaluation. For readers comparing products, the key question is not only “What EAL was achieved?” but also “What exact configuration, assurance claims, and augmentations were actually evaluated?”

This is the reason Common Criteria certificates are often used in procurement, regulated environments, and high-assurance systems. They help buyers compare claims in a disciplined way, especially where the stakes include platform trust, embedded security, or controlled deployment baselines. For a practical overview of the scheme and its terminology, see the Common Criteria Evaluation Guide.

Why EAL5+ Matters for Procurement and Trust Decisions

EAL5+ is most useful when organisations need evidence that a product has been subjected to substantial independent scrutiny. That includes environments where the consequences of product failure are high, where procurement rules require formal assurance, or where a certificate is used to support trust in a security-critical component. It can also help distinguish products that have only been self-asserted from those with externally evaluated assurance claims.

The same label can be misunderstood, however, if it is treated as a proxy for suitability in every context. A highly assured product can still be badly configured, deployed outside its evaluated scope, or paired with weak operational controls. In other words, EAL5+ improves confidence in the evaluated claims, but it does not replace secure deployment, configuration management, patching, or operational monitoring.

Where the certificate is tied to European certification schemes, the surrounding scheme rules and assurance levels become part of the interpretation. Readers comparing Common Criteria and EU certification terminology should check whether the certificate references a national scheme, a mutual-recognition arrangement, or an EU-level certification route. The EU Cybersecurity Certification EUCC Guide explains how those scheme-level details affect interpretation and vendor obligations.

Reading the “Plus” in EAL5+

The plus sign is easy to overread. It does not mean “better than EAL5 in every way,” and it does not have a fixed universal meaning across all certificates beyond indicating that the evaluation extends past the base package. What the augmentation actually is, and why it was added, should be taken from the certificate evidence and the evaluation documentation, not inferred from the shorthand alone.

For practitioners, the useful habit is to translate the shorthand back into the underlying certificate artefacts: the security target, the evaluated configuration, the assurance activities, and any augmentations or vulnerability analysis results. That is where the real answer lies. If the product will be used in a broader assurance or audit context, such as third-party trust reporting, you may also need to reconcile the certificate with other evidence sets and control expectations, including supporting documentation such as an SOC 2 Guide.

Risk and Threat Considerations

EAL5+ can create false confidence if teams assume the label alone closes security risk. The main exposure is scope drift: a product may be deployed in ways that differ from the evaluated configuration, leaving gaps between the certificate and the real operating environment.

Failure mechanism: Buyers or operators treat the assurance level as a blanket security endorsement, while actual risk comes from misconfiguration, unsupported integrations, weak operational controls, or deployment outside the evaluated scope.

Impact: The organisation may inherit a trusted component with unseen attack surface, weakened assurance, or control gaps that only become visible after an incident, audit, or certification review.

Practitioner Guidance

Why practitioners should care: Use EAL5+ as an assurance input, not a procurement shortcut. The certificate is most valuable when you can align it with the exact product version, configuration, and use case being deployed.

Common misunderstanding: Teams often assume that a high EAL means the product is secure in any deployment. In reality, the evaluation only supports the specific claims and scope that were assessed, so operational controls still matter.

Practitioner takeaway: Read the certificate, security target, and scope together before treating EAL5+ as evidence of fit for purpose.

Related resources from NHI Mgmt Group

• How should IAM teams use certifications like Common Criteria and ENS Alto?
• Why do FIPS and Common Criteria matter to identity and access teams?
• How should security teams prepare cryptography for a Common Criteria evaluation?
• Why can a gap in FIPS validation block Common Criteria certification?