Skip to main content
Digital Compliance Bureau
Promotional banner ad for the Penetration Testing Report Kit
Category: Audit & Certification

Common Criteria

Also known as: CC, CC-series, ISO/IEC 15408, Common Criteria for Information Technology Security Evaluation
Simply put

Common Criteria is an international standard, formally published as ISO/IEC 15408, used to evaluate the security features and trustworthiness of information technology products. It provides a common framework so that buyers, developers, and evaluators can describe and test what security a product is meant to provide and how thoroughly that has been checked. It is a voluntary standard rather than a law, though its results may be required under certain government or contractual procurement arrangements.

Formal definition

Common Criteria (CC), formally designated ISO/IEC 15408, is an international standard and associated certification scheme for evaluating the security functionality and assurance of IT products. Within its framework, security needs are expressed as Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs), and evaluations establish a corresponding Evaluation Assurance Level reflecting the rigor of the assessment. It is a voluntary product-security standard rather than binding regulation, and while it supports a model of mutual recognition of certification results across participating parties, its specific applicability, recognized scope, and current version should be verified against the latest authoritative CC and ISO/IEC 15408 texts. The standard defines a framework and criteria for evaluation; it is distinct from any single jurisdiction's legal mandate, and its use in a given context (for example, government or critical-infrastructure procurement) depends on contractual or policy requirements rather than the standard itself.

Why it matters

Common Criteria matters because it provides a shared, structured language for describing and verifying the security of IT products, allowing buyers, developers, and independent evaluators to work from a common reference rather than ad hoc or vendor-defined claims. For organizations procuring security-sensitive technology, a Common Criteria evaluation offers a documented basis for assessing what security a product is intended to provide and how rigorously that has been checked, which can reduce reliance on unverified marketing assertions. This is particularly significant in contexts such as government or critical-infrastructure procurement, where evaluation results may be required under contractual or policy terms.

It is important to keep Common Criteria in proper perspective: it is a voluntary product-security standard, not a law. A Common Criteria certificate is not the same as regulatory compliance, and being certified does not by itself satisfy obligations under any particular jurisdiction's legal regime. Its relevance in a given situation flows from procurement requirements, contracts, or organizational policy rather than from the standard carrying legal force on its own.

Because Common Criteria supports a model of mutual recognition across participating parties, a certification issued under the scheme may be accepted by multiple procurement authorities, which can reduce duplicative evaluation effort. However, the recognized scope of any certificate, the assurance level it reflects, and the current version of the standard all vary and should be verified against the latest authoritative Common Criteria and ISO/IEC 15408 texts rather than assumed.

Who it's relevant to

Procurement and vendor management teams
Teams sourcing security-sensitive IT products—especially for government or critical-infrastructure use—may encounter Common Criteria certification as a contractual or policy requirement. A certificate can serve as documented evidence of what security a product is intended to provide and how rigorously it was evaluated, but teams should confirm the certificate's recognized scope and assurance level rather than treating certification as blanket assurance.
Product developers and security engineers
Developers building IT products for markets where Common Criteria is expected use the framework to express intended security behavior as Security Functional Requirements and to plan for the assurance activities implied by Security Assurance Requirements. Understanding how these requirements map to an Evaluation Assurance Level helps in scoping the effort and evidence a target evaluation would demand.
Evaluators and testing laboratories
Independent evaluators apply the Common Criteria framework and criteria to assess a product's security functionality and the depth of assurance, working within the associated certification scheme. Their work establishes the assurance level a product's evaluation reflects and depends on the current authoritative standard version.
Compliance officers and legal counsel
Those advising on obligations should note that Common Criteria is a voluntary standard, not binding regulation, and that certification is distinct from legal or regulatory compliance. Where a certificate is required, that requirement generally arises from procurement rules, contracts, or organizational policy; whether a given certification satisfies a specific obligation is a fact-specific matter requiring professional judgment and verification against current authoritative sources.

Inside CC

Evaluation Assurance Level (EAL)
A graded scale expressing the depth and rigor of the evaluation performed against a target of evaluation. Higher levels reflect more extensive testing and analysis, but the level indicates the assurance of the evaluation process rather than an inherent measure of how secure a product is in absolute terms.
Target of Evaluation (TOE)
The specific product, system, or component—together with its defined configuration and documentation—that is submitted for evaluation. Assurance claims apply only to the TOE as defined, not to the vendor's product line as a whole or to deployments outside the evaluated configuration.
Protection Profile (PP)
An implementation-independent statement of security requirements for a category of products, typically drafted to reflect the needs of a particular user community or use case. Products may be evaluated for conformance to one or more Protection Profiles.
Security Target (ST)
An implementation-dependent document that defines the security requirements and claims for a specific TOE, forming the basis against which that TOE is actually evaluated. The ST may claim conformance to one or more Protection Profiles.
Security Functional Requirements (SFRs)
The catalog of standardized requirements describing the security behavior a TOE is expected to provide, selected and instantiated within a Protection Profile or Security Target.
Security Assurance Requirements (SARs)
The standardized requirements describing the activities and evidence needed to gain confidence that the security functions are correctly implemented, which underpin the assigned assurance level.

Common questions

Answers to the questions practitioners most commonly ask about CC.

Does a Common Criteria certification mean a product is secure for any use?
No. A Common Criteria certification indicates that a specific product configuration (the Target of Evaluation) was evaluated against a defined set of security functional and assurance requirements, as captured in its Security Target and, where applicable, a Protection Profile. It does not certify that the product is secure in an absolute sense, nor for uses or configurations outside the evaluated scope. The evaluated version, configuration, and operating assumptions matter; deploying the product differently may fall outside what was assessed. Common Criteria is a voluntary standards-based scheme (ISO/IEC 15408), not a regulation, and certification should be read together with the associated Security Target rather than treated as a blanket assurance.
Is a higher Evaluation Assurance Level (EAL) always better and does it mean stronger security?
Not necessarily. An EAL expresses the depth and rigor of the evaluation performed, not the strength or breadth of the security functionality itself. Two products at the same EAL may implement very different security functions, and a product at a higher EAL is not automatically 'more secure' than one at a lower EAL if their Security Targets address different requirements. The appropriate assurance level generally depends on the intended use, risk profile, and, in some cases, procurement or sector expectations. Many modern evaluations rely on Protection Profiles rather than EALs alone, so comparisons based on EAL numbers in isolation can be misleading.
How should we scope a Common Criteria evaluation for our product?
Scope is defined by the Target of Evaluation (TOE) and documented in the Security Target, which specifies the product version, configuration, security functions to be evaluated, and the assumptions about the operating environment. Where a relevant Protection Profile exists, evaluation against it is often expected in certain markets. Scoping decisions typically balance the functions that need assurance against evaluation cost and timeline. Because features and configurations outside the TOE are not covered, organizations should scope deliberately and revisit scope if the product changes. Verify current scheme expectations with your chosen certification body, as practices and available Protection Profiles evolve.
Will a Common Criteria certificate obtained in one country be recognized elsewhere?
Recognition depends on the applicable mutual recognition arrangements and the assurance level or Protection Profile involved. Arrangements among participating nations may provide mutual recognition up to certain assurance levels or for evaluations against agreed Protection Profiles, but recognition is not universal and terms differ by jurisdiction and over time. Certificates issued outside the scope of an arrangement, or above the recognized level, may not be accepted by another country's scheme or procurement process. Confirm the current recognition status and any national-scheme requirements against the authoritative sources for the relevant jurisdictions before relying on cross-border acceptance.
How does a Common Criteria certificate interact with product changes and updates after certification?
A certificate applies to the specific evaluated version and configuration of the TOE. Subsequent changes—such as patches, new releases, or configuration differences—may fall outside the certified scope. Certification schemes generally provide assurance-continuity or maintenance processes to address changes without a full re-evaluation in some cases, but eligibility and requirements vary by scheme and by the nature of the change. Organizations relying on certified products should track which version and configuration were certified and confirm how updates affect certification status. Check the current maintenance procedures with the relevant certification body, as these arrangements are periodically revised.
How does Common Criteria relate to other frameworks such as ISO/IEC 27001 or regulatory compliance obligations?
Common Criteria evaluates the security properties of a specific product or IT component, whereas ISO/IEC 27001 addresses an organization's information security management system, and regulatory obligations impose legally binding requirements on entities. These are distinct in object and effect: a product certification is not a substitute for organizational security management or for meeting legal duties, and it does not by itself demonstrate regulatory compliance unless a specific law or contract references it. In practice, a Common Criteria–certified product may support broader assurance or procurement objectives, but its role should be assessed alongside applicable standards and legal requirements, with professional judgment applied to the specific context.

Common misconceptions

A Common Criteria certificate is a legal requirement that products must satisfy to be sold.
Common Criteria is an internationally recognized evaluation standard, not a regulation in itself. It becomes mandatory only where a specific jurisdiction, sector, or procurement contract incorporates it as a requirement—for example in certain government or defense procurement contexts. In most commercial settings it remains voluntary, and readers should verify whether any applicable rule references it.
A higher Evaluation Assurance Level means the product is more secure than one with a lower level.
The EAL reflects the rigor and depth of the evaluation activities, not an absolute measure of a product's security. A product at a higher level has been examined more thoroughly, but a lower-level product addressing a well-scoped threat model may be more appropriate for a given use. Comparing levels across products with different Security Targets can be misleading.
A certified product remains certified and secure regardless of how it is configured or updated.
Certification applies to the specific Target of Evaluation in its defined, evaluated configuration and version. Deploying the product differently, applying patches, or moving to a new release can fall outside the scope of the original certificate. Certificates and the underlying scheme are also revised over time, so the applicable version should be verified.

Best practices

Confirm whether Common Criteria certification is actually required for your context—by regulation, sector rule, or contract—before treating it as an obligation, since it is generally a voluntary standard rather than binding law.
Read the Security Target and any claimed Protection Profile, not just the assurance level, to understand exactly what security functions were evaluated and against which threat model.
Verify that the evaluated configuration and product version match what you intend to deploy, and treat deployments outside the evaluated scope as unassured.
Interpret the Evaluation Assurance Level as a statement about evaluation rigor, and avoid using it alone to rank the relative security of different products.
Check the current status and validity of any certificate against the relevant certification body or scheme, since certificates, versions, and mutual-recognition arrangements change over time.
Engage qualified security and compliance professionals to judge whether a given certified product meets your specific requirements, as suitability is fact-specific.
Promotional banner for the Pentest Readiness checklist download