3 things I learnt about Common Criteria

Russell Yap

Contents

In a world where cyber threats are ever-evolving and security is of utmost importance, have you ever wondered how you can trust your security appliances to protect you? Meet Common Criteria, an internationally recognized certification that evaluates products through a strict and rigorous process to ensure they meet the highest security standards.

Products that are Common Criteria certified up to Evaluation Assurance Level 2 (EAL2) in one country will be mutually accepted by all countries that recognise the Common Criteria brand. This facilitates seamless cross-border trade and trust in the product's quality and safety. As of October 2025, the Common Criteria Recognition Arrangement (CCRA) includes 31 member countries (see Fig 1.) that mutually recognize each other's Common Criteria certificates.

Fig 1. Member countries in CCRA in 2025

The Common Criteria does not joke when it comes to their stringent certification process. The standard has evolved to include a catalogue of at least a hundred components (Security Functional Requirements) to describe security features needed in products and seven tiers of increasing guarantee (Evaluation Assurance Level) to meet the security assurance of the products’ functionality. Failing any of the components during the evaluation process fails the Common Criteria certification.

Here are three things I learned from the past four months of writing a Common Criteria Security Target for pQCee:

Difference between Security Target and Protection Profile                      

The first step in writing a Common Criteria certification is identifying the appropriate Protection Profile (PP), followed by writing the Security Target (ST). To find the right PP, you scour through a list of available PPs (current count of 220+ active PPs) to find one that best fits your product. Once the appropriate PP is identified, the next step is to develop the Security Target, which outlines how your specific product meets the security requirements defined in the PP. To avoid confusion on what is the difference, the distinct differences are described below.

The Protection Profile (PP) is a general document that outlines the security requirements for a category of products, such as firewalls, smart cards, or encryption software. It acts as a blueprint, created by experts or groups, to standardize security features across similar products and ensure they meet certain pre-approved requirements.

The Security Target (ST), in contrast, is specific to an individual product. It describes how the product meets the security requirements declared within the Common Criteria framework. The PP can be optionally utilised as a reference point to aid in the formation of the ST. In CC terms, this is also known as an “ST complying to a PP”.

In other words, the Protection Profile sets the standard for a category, while the Security Target details how an individual product meets those standards. For example, the Protection Profile for Firewall Systems outlines the general security requirements for firewalls, such as filtering and intrusion detection. The Security Target for a specific firewall then details how a particular firewall product implements those requirements, including the specific filtering techniques and security protocols it uses to protect network traffic.

Difference between Security Target and Target of Evaluation

Following the Security Target (ST), the Target of Evaluation (TOE) comes into play. The TOE represents the actual product or system that is being evaluated for security. It is essentially the scope of the evaluation, detailing what specific part of the product or system is under review. The ST includes various scenarios that users can select from, and these scenarios help define the boundaries and objectives of the TOE evaluation. These scenarios may dictate how the product should perform in specific environments or against particular security threats.

The purpose of the TOE is to clearly define what is being assessed during the evaluation process. It ensures that the product's security features are appropriately tested within a specific context, providing a focused evaluation of its effectiveness against potential risks or vulnerabilities. By clearly specifying the TOE, both the developer and the evaluator can align on what aspects of the product need to meet the predefined security standards set out in the Security Target.

Is Common Criteria ready for quantum?

The European Telecommunications Standards Institute (ETSI) is developing a Protection Profile for the QKD system - ETSI GS QKD 024. This is a proposed Protection Profile under the Common Criteria framework specifically for the Key Processing Module (KPM) in Quantum Key Distribution (QKD) networks. It builds upon the earlier GS QKD 016, which was certified by Germany’s BSI at EAL4 (augmented by AVA_VAN.5 and ALC_DVS.2, see Table 1.), and extends security standardization to the trusted-node layer that processes, stores, and distributes keys from QKD modules to higher systems like Key Management Systems and cryptographic devices.

Assurance class Assurance components
AVA: Vulnerability assessment AVA_VAN.5 Advanced methodical vulnerability analysis
ALC: Life-cycle support ALC_DVS.2 Sufficiency of security measures

Table 1. Detail of Assurance Classes

GS QKD 024 aims to define the security objectives, functional requirements, and evaluation boundaries for the KPM, ensuring secure key handling, access control, and interface protection in multi-node QKD networks. Currently, it is a newly proposed ETSI work item with a target stable draft by March 2027 and final approval expected by September 2027, marking a critical step toward comprehensive, modular certification of quantum communication infrastructure within existing Common Criteria frameworks.

Despite this progress, classical security features, such as Elliptic Curve Digital Signature Algorithm (ECDSA), are still essential. It is important to note that for instance, the U.S. Commercial National Security Algorithm (CNSA) Suite 2.0 requires the replacing of older algorithms, including ECDSA, with quantum-resistant ones such as ML-KEM and ML-DSA, designed to withstand attacks from future quantum computers. However, to obtain Common Criteria certification today, products are required to implement ECDSA as part of their security framework.

Final words

Common Criteria plays a crucial role behind the scenes in ensuring the security of the products we use every day. With its rigorous certification process, which takes several months to complete, Common Criteria guarantees that products meet the baseline security standards.

Fig 2. Common Criteria Logo

So, the next time you see a product that carries the Common Criteria logo (see Fig 2.), you can rest assured knowing it has undergone thorough testing and validation to protect you from evolving cyber threats.

Author

Russell Yap

Russell is a Software Engineer intern at pQCee. His favourite quote is from Sun Tzu Art of War “The Battle is won before it is fought”. He was a previous NS SWE wannabe engrossed in beating the “rat race” amongst his peers. Today actively fighting daily to survive at university with his main adversary being discrete mathematics. He likes Shiba Inus.


Be first to comment
Leave a reply