Common CriteriaEdit

Common Criteria (CC) is an internationally recognized framework for evaluating the security properties of information technology products and systems. It provides a structured, repeatable process for specifying security requirements, testing those requirements, and certifying that a product meets a defined level of assurance. The framework is anchored in a standard published as ISO/IEC 15408 and operates under the umbrella of the Common Criteria Recognition Arrangement, an international agreement that enables mutual recognition of evaluations across signatory nations.

At the heart of CC are three core concepts: Protection Profiles (PP), which define generic security requirements for a class of products; Security Targets (ST), which describe the security objectives and requirements for a specific product; and Evaluation Assurance Levels (EAL), which offer a graded scale of assurance from basic to high. In practice, a vendor maps the product to an ST, possibly leveraging existing PP guidance, and an independent body evaluates the product against those criteria. When evaluation is complete, a certificate is issued and, thanks to mutual recognition within the CCRA, the product is accepted by other signatories with comparable confidence.

CC has become a cornerstone of procurement in many government and critical infrastructure sectors. It is especially important for products that handle sensitive data, cryptographic operations, or access control. The framework is designed to reduce risk for buyers by providing a credible, auditable assurance path and to lower barriers to international sale by offering a common acceptance standard across borders.

History and scope

Common Criteria emerged from collaboration among multiple governments as a pragmatic response to the proliferation of disparate security testing regimes. Over time, it evolved into an international standard that teams from defense, energy, finance, and public administration rely on when selecting and deploying security-relevant technology. The CC framework guides developers and evaluators alike through a shared language for describing security functionality and evaluating that functionality in real-world environments.

The scope of CC covers a broad set of security properties, including access control, data confidentiality, integrity, authenticity, and resistance to various threat vectors. It is not just about finding “bugs” in software; it is about demonstrating to customers and regulators that a system design, implementation, and testing process collectively meet a defensible security baseline. The CC approach emphasizes evidence, traceability, and repeatability, with publicly available criteria that can be reused across products and project lifecycles. See also Security Target and Protection Profile for related concepts.

Core concepts

Protection Profile: A generic, reusable specification of security requirements for a class of products or systems.
Security Target: The specific security requirements and objectives for a particular product, organization, or TOE (Target of Evaluation).
Target of Evaluation: The product or system being evaluated.
Evaluation Assurance Level (EAL): A graded scale (EAL1 through EAL7) that signals the level of assurance achieved by the evaluation.
Common Criteria Recognition Arrangement: The international agreement that enables cross-signature acceptance of evaluations among participating nations.
Certification Bodies and evaluation laboratories: Independent entities that conduct assessments and issue certification decisions consistent with CC rules.

How the evaluation works

A vendor defines an ST for the TOE, aligning it with relevant PP guidance where appropriate.
An independent evaluation laboratory tests the TOE against the ST, compiling evidence of design, implementation, and security testing.
A Certification Body reviews the evaluation results and issues a certificate if the TOE meets the stated criteria at the claimed EAL.
Signatories under the CCRA recognize and rely on each other’s certificates, enabling broader market access and reduced duplicative testing.

The process is designed to be transparent and repeatable. It provides a common framework for documenting security claims, validating that claims are technically grounded, and presenting evidence that auditors, buyers, and regulators can review. See also Security Evaluation for broader context about how assurance work fits into risk management and governance.

Adoption and governance

Numerous governments and private sector buyers require or prefer CC-based evaluations for high-assurance products. The framework has become especially influential in defense procurement, critical infrastructure protection, financial services, and sectors where public trust in security mechanisms matters. Signatories to the Common Criteria Recognition Arrangement include jurisdictions in North America, Europe, Asia, and Oceania, which helps create a practical, cross-border market for certified products.

From a policy perspective, CC is often viewed as a pragmatic alternative to broader, more burdensome security mandates. It offers a legally and technically grounded method for demonstrating due diligence in security engineering without declaring a one-size-fits-all regulatory regime. The framework also supports international trade by reducing the need for country-specific re-testing and by providing a credible, common security language for buyers and vendors. See also ISO/IEC 15408 for the formal standardization angle and Information security for the broader context.

Controversies and debates

Cost, time, and small-entity barriers: Critics argue that achieving CC certification can be expensive and time-consuming, potentially privileging larger vendors with the resources to navigate the process. The result can be higher entry costs for niche products or for SMEs, which can impact competition. Proponents respond that the investment buys a credible, transferable badge of trust that can accelerate procurement and reduce post-deployment risk.
Alignment with rapid development: In fast-moving domains such as cloud services, DevOps, or AI-enabled solutions, the need for frequent updates clashes with long, formal evaluation cycles. Critics say CC should adapt to more agile assurance models or offer streamlined paths for iterative development. Supporters contend that CC already accommodates updates through re-certification cycles and evolving Protection Profiles, while ensuring that baseline security remains verifiable.
Innovation versus standardization: A tension exists between the value of standard security baselines and the risk of stifling innovation. Some argue that an overemphasis on certification can incentivize “checklist” security rather than secure-by-design engineering. Defenders of CC emphasize that well-run CC programs encourage secure design choices and provide a clear route for responsible disclosure and improvement.
Global access and reciprocity: While CCRA aims to facilitate mutual recognition, the geopolitics of technology transfer can complicate access to markets for non-signatory regions or for products that rely on technology restricted by export controls. Advocates argue that CC remains a pragmatic, market-tested way to demonstrate security across borders, while critics push for broader participation and more flexible recognition rules.
Real-world effectiveness versus certification: Certification demonstrates that a product met a defined set of controls at a point in time, but it cannot guarantee immunity against all future threats or misconfigurations. Critics stress the need for ongoing assurance, monitoring, and transparency about product updates. Proponents maintain that CC’s formal process, combined with ongoing governance and cross-border recognition, offers a robust baseline for risk management.