Security teams should treat Common Criteria as a rigorous assurance process, not a marketing badge. Define the security target clearly, scope the target of evaluation precisely, and map the product to the relevant NIAP protection profile. Certification succeeds only when the product meets every required functional condition and passes independent lab testing against that profile.
What Common Criteria certification actually tests
common criteria is an assurance framework for a specific product and a specific evaluation boundary. Security teams need to start with the Security Target and the Target of Evaluation, then confirm that the claimed functions are precise, testable, and aligned to the right NIAP protection profile. If the scope is vague, the certification effort usually fails on definition before it fails on testing.
That matters because Common Criteria is not a general statement that a product is “secure.” It is an evidence-driven claim that the evaluated configuration meets the selected functional and assurance requirements. For government-facing products, the practical question is whether the product can satisfy the exact profile, deployment assumptions, and evidence expectations without relying on undocumented features or implementation shortcuts.
Teams should also separate product design from certification packaging. A product can be technically sound and still be a poor Common Criteria candidate if the release train, boundary definition, or supported operating mode does not match the evaluation model. A clean certification effort depends on freezing the version, configuration, and interfaces that are actually being assessed.
How to scope the evaluation so it can pass
Scoping should be the first engineering task, not the last compliance task. Define exactly what is inside the evaluated boundary, what is excluded, and which security functions are claimed. Then map those claims to the relevant protection profile and make sure every required security objective is implemented and observable in the product.
The most common failure point is overclaiming. If the product claims cryptographic protection, authentication, role enforcement, secure management, or audit capability, the implementation and the test evidence must support those claims consistently across the evaluated configuration. Common Criteria labs are looking for a coherent story: requirements, design, implementation, and test artefacts must all line up.
Government buyers and assessors also expect discipline around dependencies. If the product relies on external services, admin tooling, platform controls, or deployment assumptions, those dependencies need to be explicit. Otherwise, the certification may look complete on paper while hiding control gaps in the real deployment path.
What security teams need to build into the certification plan
A successful program treats certification as an evidence supply chain. Teams should collect design specifications, implementation details, test plans, configuration guidance, and assurance artefacts early, then keep them consistent as the product changes. Certification work becomes much easier when the product team can show that the evaluated build is reproducible and that the security claims are stable across releases.
Independent testing is not just a final gate, it is a design constraint. Teams should expect scrutiny of boundary definitions, secure defaults, management interfaces, trust assumptions, and failure behaviour. Products that are easy to deploy but hard to explain usually create the most friction, because evaluators need to understand how the evaluated configuration resists misuse as well as how it performs under normal conditions.
For practitioners who want a broader identity and governance lens around products that handle credentials, access paths, or administrative control, NHIMG’s IAM and IGA Basics is a useful companion, and government-facing product teams that need to think about lifecycle, rotation, and offboarding can also benefit from the NHI Lifecycle Management Guide. For product assurance and attack-path context, the MITRE ATT&CK Enterprise Matrix helps teams think about what attackers would try against the evaluated boundary.
Risk and Threat Considerations
Common Criteria failures are often caused by boundary confusion, unsupported claims, or weak documentation rather than by the product’s core functionality. For government-facing products, the risk is that a rushed certification effort produces a narrow certificate that does not meaningfully reflect the deployed system, which can create false confidence for buyers and auditors.
Failure mechanism: The product is evaluated in one configuration, but deployed in another, or it claims security properties that are not fully implemented in the evaluated build. That gap can expose the product to misconfiguration, bypass, or control failure even though the certificate appears valid.
Impact: Procurement decisions may rely on an assurance result that does not match real operational risk, and remediation becomes harder after deployment because the certified scope is already locked to a different technical baseline.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | Common Criteria depends on defined test evidence for security claims. |
| SC-13 — Cryptographic Protection | Government-facing products often claim cryptographic functions that must be evidenced in evaluation. | |
| CM-6 — Configuration Settings | Certification hinges on a fixed evaluated configuration and reproducible secure settings. | |
| Recommendation — Align product test evidence to the evaluated security claims and preserve traceability. Verify the evaluated configuration implements the claimed cryptographic protections. Lock the evaluated build and document the exact configuration baseline. | ||
| ISO/IEC 27001:2022 | A.8.29 — Security testing in development and acceptance | Common Criteria is an assurance process requiring structured security testing evidence. |
| A.8.9 — Configuration management | The evaluated configuration must be controlled to keep certification meaningful. | |
| Recommendation — Require test evidence that demonstrates the evaluated security requirements are met. Control the certified build, settings, and deployment baseline as a managed configuration. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Common Criteria success depends on stable secure configuration and deployment consistency. |
| CIS-17 — Incident Response Management | Assurance claims should be backed by evidence that the product can be assessed and defended if issues emerge. | |
| Recommendation — Harden and standardize the certified configuration before evaluation and release. Keep response evidence and escalation paths ready for certification findings or deltas. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Government products often need evaluated claims around protected data handling. |
| PR.AA-05 — Identity management, authentication and access control are enforced | Many evaluated products rely on access control claims that must be explicit and testable. | |
| Recommendation — Show that the evaluated product protects stored data in the certified configuration. Document and test the exact identity and access controls inside the evaluation boundary. | ||
Practitioner Guidance
What to prioritise: Freeze the evaluated version and boundary early, then force every security claim to be traceable to an implemented and testable feature. If a claim cannot be evidenced cleanly, remove it from scope rather than trying to defend it later in the lab.
What to verify: Confirm that the deployment guidance, admin interfaces, cryptographic settings, and update path all match the evaluated configuration. If the government customer will run the product differently, treat that as a separate assurance question, not as a minor implementation detail.
Practitioner takeaway: Common Criteria works best when engineering, product, and compliance teams treat it as controlled assurance of a narrowly defined product state, not as a broad statement of trustworthiness.
