Organisations implement Common Criteria Certification by selecting products with the assurance level and security target they actually need, then validating that the evaluated configuration matches their deployment. They should track version changes, required settings, and operational constraints, because using a product outside its certified configuration can invalidate the assurance claim.
What Common Criteria actually certifies
common criteria Certification is product assurance, not a blanket approval of an entire vendor or environment. It evaluates a specific product, under a stated version and configuration, against a defined Security Target and assurance level. The practical question for buyers is whether the certified claim aligns with the exact deployment you intend to run, including features enabled, roles assigned, and the operating assumptions in the evaluated configuration.
That distinction matters because certification is only meaningful when the product is used as evaluated. If an organisation changes the version, turns on unsupported features, or deploys the product in a different way from the certified setup, the assurance argument may no longer hold. For implementation teams, the real work is translating the certificate into a controlled configuration baseline and keeping that baseline visible over time, with change management tied to the evaluated scope.
For procurement and architecture teams, Common Criteria is best treated as an evidence-backed filter. It helps narrow product selection when assurance requirements are formal, but it does not replace local security testing, integration review, or operational hardening. The certificate answers a narrower question than “is this secure in my environment?” and the deployment owner still has to answer the latter.
How to implement it without losing the assurance claim
Start by matching the certificate to the use case. The most important checks are the product identity, the exact version, the Security Target, the assurance level, and the stated evaluated configuration. If the vendor documentation does not clearly describe how to run the product within that boundary, treat the certificate as incomplete for your purposes and ask for the supporting guidance before procurement.
Then build the certified configuration into your deployment process. Configuration management should record the settings, modules, integrations, and environmental constraints that were part of the evaluation, so operators can detect drift before it becomes a compliance or assurance problem. In practice, this means the certificate needs to become a living reference in change control, not a PDF filed after purchase. Many organisations pair that discipline with broader IAM and IGA Basics so ownership, entitlement, and change approval stay visible as the product is introduced and maintained.
Operational ownership matters as much as technical fit. Someone needs to own version tracking, approved settings, exception handling, and the decision to revalidate when the product is patched or reconfigured. If the evaluated configuration depends on a small set of deployment assumptions, the strongest control is to make those assumptions explicit in runbooks and release gates, then review them whenever the product changes materially.
What breaks certification in day-to-day operations
The most common failure mode is configuration drift. Teams often buy a certified product, deploy it with local defaults, and gradually add integrations or features that were not part of the evaluated configuration. At that point, the organisation may still have a product certificate, but not necessarily a certified deployment. This is why version control, change approval, and documented operational constraints are central to maintaining the value of the assurance claim.
A second failure mode is treating certification as a substitute for lifecycle governance. Certificates do not manage themselves, and they do not prevent stale versions, unsupported add-ons, or forgotten exceptions. Organisations should map certificate maintenance to their normal control processes for inventory, review, and remediation, and they should keep watch for the same kinds of drift that make access certification fail to close the loop. The same governance discipline is often explained in Access Reviews and Certification Guide, because assurance is lost when the reviewed state and the real state diverge.
Third-party evidence can also be misread. A certificate is only useful if the product version and deployment path are still current. If the product has moved on, the organisation may need a fresh review or an updated assurance statement rather than assuming the original result still covers the live system.
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 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.8.9 — Configuration Management | Common Criteria deployments depend on preserving the evaluated configuration. |
| A.8.8 — Management of Technical Vulnerabilities | Version changes can invalidate the assurance claim and require revalidation. | |
| Recommendation — Control and document certified settings so deployed products stay within the evaluated scope. Track product versions and assess changes before assuming the certification still applies. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | The evaluated configuration functions as a security baseline that must be maintained. |
| CM-6 — Configuration Settings | Common Criteria depends on approved settings matching the evaluation conditions. | |
| Recommendation — Establish and preserve the certified baseline as the authoritative deployment configuration. Enforce the certified settings and block unsupported configuration changes. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Certified products must remain in a secure, known-good configuration to retain assurance value. |
| Recommendation — Standardise the approved configuration and monitor for drift from it. | ||
Practitioner Guidance
What to verify: Confirm the certificate covers the exact product version and the exact configuration you intend to deploy. If the operational baseline is broader than the evaluated configuration, treat the gap as an open risk, not an administrative detail.
What to prioritise: Prioritise the controls that preserve the evaluated state, version pinning, approved configuration, change control, and evidence of revalidation after meaningful updates. Those controls are what keep the assurance claim credible in production.
Common mistake: Do not equate “certified product” with “certified deployment.” The assurance value collapses if teams enable unsupported features, absorb undocumented changes, or lose track of which version was actually assessed.
Practitioner takeaway: Common Criteria is only as strong as the organisation’s discipline in running the product exactly as evaluated, so the key implementation task is governance over drift, not just buying the right certificate.