Common Criteria

What Common Criteria evaluates

Common Criteria is a structured way to assess whether an IT product’s security claims are supported by defined requirements, a testable evaluation target, and independent evidence. For practitioners, the value is not the label itself, but the discipline it imposes on claims, scope, and assurance.

It is often used to distinguish marketing statements from substantiated security properties. That matters because a product can be functionally useful and still leave important security questions unanswered if the security target, assumptions, or evaluation boundary are vague.

How Common Criteria evidence is organised

Common Criteria evaluations normally revolve around a security target, a target of evaluation, and a protection profile or similar requirement set. Those artefacts define what is being assessed, which security functions matter, and what assumptions the evaluation depends on.

That structure is useful because it forces clarity about the system boundary. A platform may be evaluated for a narrow set of claims, but that does not automatically mean every deployment, configuration, integration, or operational context shares the same assurance outcome.

For readers comparing certification claims, the Common Criteria Evaluation Guide explains the core terminology, conformance types, assurance levels, and how to read certificates without overstating what they prove.

Why Common Criteria matters in IAM and security procurement

In IAM and adjacent security decisions, Common Criteria helps buyers ask whether a platform’s authentication, access control, and administrative protections have been evaluated against explicit requirements rather than asserted informally. That is especially useful when vendors market strong security language but provide little evidence about how those claims were tested.

It also helps procurement teams compare products on a more disciplined basis. A certificate or evaluation report can support due diligence, but only if readers understand the exact evaluation scope, the assumptions behind it, and whether the claimed capabilities match the organisation’s intended use.

When the product is part of a regulated or assurance-driven environment, the surrounding certification scheme may matter as much as the evaluation itself. For example, the EU Cybersecurity Certification EUCC Guide shows how Common Criteria based certification is operationalised in the EU context.

What Common Criteria does not tell you

Common Criteria is not a universal guarantee that a product is secure in every deployment. It does not remove the need to review configuration, deployment architecture, integration choices, patching, identity governance, logging, or operational controls around the product.

It also does not replace broader control frameworks or incident-driven validation. A product can have a meaningful evaluation and still be misused, overprivileged, misconfigured, or deployed in ways that exceed the original assurance boundary.

That is why Common Criteria is best treated as one input to trust decisions, not the final word. In practice, it works alongside supplier assurance, operational security review, and evidence that the product is being used within the conditions the evaluation assumed.

Risk and Threat Considerations

Common Criteria risk is mostly a false-confidence problem: organisations may mistake a certification claim for proof that a product is secure in their own environment. The real exposure appears when the evaluation scope, assumptions, or deployment context do not match how the product is actually used.

Failure mechanism: An organisation accepts the certificate as broad assurance, then deploys the product outside the evaluated boundary or relies on capabilities that were never tested in the evaluated configuration.

Impact: Security gaps can persist in authentication, access enforcement, administrative control, or integration behaviour, leaving the organisation with a weaker posture than the assurance artefact suggests.

Practitioner Guidance

Why practitioners should care: Treat Common Criteria as evidence about a defined evaluation, not a blanket endorsement of the entire product or service. The practical question is whether the certificate and supporting documentation match your exact deployment model, trust assumptions, and security expectations.

Common misunderstanding: Many teams stop at the certificate number or assurance level and skip the underlying security target, scope, and assumptions. That misses the most important part of the review, namely whether the evaluated claim is the same claim you are relying on.

Practitioner takeaway: Read the evaluation artefacts before you rely on the label, because assurance is only meaningful when the scope, environment, and claimed security properties align.

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?