Common Criteria

Expanded Definition

Common Criteria is an international product evaluation standard used to assess whether a technology’s security properties match a defined target of evaluation. In NHI and IAM contexts, it helps distinguish claims such as encryption support, access enforcement, or auditability from evidence that those controls have actually been implemented and tested.

Unlike general compliance checklists, Common Criteria focuses on a specific product, its security objectives, and the assurance level achieved through independent evaluation. That makes it useful when choosing platforms that will store, issue, broker, or validate secrets, certificates, and machine identities. It is often discussed alongside NIST SP 800-53 Rev 5 Security and Privacy Controls, but the two are not interchangeable: NIST 800-53 defines organisational controls, while Common Criteria evaluates a product against a stated security target.

Definitions vary across vendors when they describe “Common Criteria certified” as a blanket trust signal. In practice, the evaluation scope, version, and assurance level matter more than the logo. The most common misapplication is treating any certification as proof that a product is secure for every deployment, which occurs when buyers ignore the evaluated configuration and assume all features were assessed.

Examples and Use Cases

Implementing Common Criteria rigorously often introduces procurement and validation overhead, requiring organisations to weigh stronger assurance against slower selection cycles and tighter deployment constraints.

• A team evaluating a secrets vault reviews the Common Criteria protection profile to confirm key storage, access mediation, and tamper resistance claims before deployment.
• A platform handling service account credentials is selected only after its evaluated configuration is compared with the intended production architecture, not just the marketing feature list.
• A government or regulated enterprise uses Common Criteria evidence to reduce ambiguity when comparing identity brokers, hardware security modules, or authentication appliances.
• Security architects pair product evaluation with organisational controls from NIST SP 800-53 Rev 5 Security and Privacy Controls to ensure the platform and the operating model both support least privilege.
• Readers of the Ultimate Guide to NHIs can map evaluation evidence to practical NHI questions such as secret storage, rotation support, and revocation behaviour.

For NHI programs, Common Criteria is most useful when the question is not “does the vendor say it is secure?” but “can the product’s security claims be substantiated for the exact use case being adopted?”

Why It Matters in NHI Security

Common Criteria matters because NHI platforms often become trust anchors for machine credentials, token issuance, and policy enforcement. If the underlying product cannot defend its claims, downstream controls such as rotation, vaulting, and access gating may fail in ways that are hard to see until an incident. NHIMG notes that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, which makes evidence-based product selection especially important when platforms are meant to reduce risk rather than add it. The Ultimate Guide to NHIs also shows that 79% of organisations have experienced secrets leaks, 77% of which caused tangible damage, underscoring why product assurance cannot be left to branding.

For security leaders, the practical value of Common Criteria is that it creates a disciplined way to challenge vague assurances about “secure by design” identity tooling. It supports defensible procurement, clearer audit evidence, and better alignment between technical claims and operational reality. That becomes especially relevant where evaluations must complement broader governance expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls and similar assurance regimes. Organisations typically encounter the cost of weak product assurance only after a vault exposure, token abuse, or credential compromise, at which point Common Criteria becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the most common mistake organisations make with NHI credential management?
• What was the common factor in the Snowflake, BeyondTrust, OmniGPT, and DeepSeek breaches?
• What are common vulnerabilities associated with service accounts in AI deployments?
• What common vulnerabilities do cloud applications face with OAuth tokens?