The Common Criteria (CC) is an international standard for evaluating the security properties of IT products and systems, formally published as ISO/IEC 15408. It defines a structured framework for specifying security requirements, outlines the methodology for assessing whether those requirements are met, and sets rules for the oversight of these evaluations.

Governments and organizations worldwide use the CC to assess and certify the security of information technology products. In many cases, compliance with the Common Criteria is a prerequisite for procurement.

For more information or to obtain the standard, visit: https://www.commoncriteriaportal.org.

The most widely adopted mutual recognition framework is the Common Criteria Recognition Arrangement (CCRA). As of this writing, signatory nations include: Australia, Austria, Canada, Czech Republic, Denmark, Ethiopia, Finland, France, Germany, Greece, Hungary, India, Indonesia, Israel, Italy, Japan, Republic of Korea, Malaysia, the Netherlands, New Zealand, Norway, Pakistan, Poland, Qatar, Singapore, Spain, Sweden, Turkey, the United Kingdom, and the United States.

The official and up-to-date list of CCRA participants is maintained at:

https://www.commoncriteriaportal.org/ccra/members/index.cfm.

‍

Other recognition frameworks also exist:

• SOG-IS Mutual Recognition Agreement – Within Europe, SOG-IS allows mutual recognition among its members, often supporting higher assurance levels than CCRA.
• EUCC – The European Union Cybersecurity Certification Scheme based on Common Criteria, developed under the EU Cybersecurity Act, will provide an EU-wide CC-based certification framework. Once fully operational, EUCC will harmonize and replace certain national arrangements within the EU, offering a standardized recognition path for CC-based evaluations across all EU Member States.
• Bilateral agreements – Some countries maintain one-to-one recognition agreements.
• Independent use – Certain nations (e.g., China) and organizations may adopt and apply the ISO/IEC 15408 standard without participating in formal recognition schemes.

There are three parties involved in the CC evaluation process:

1. Vendor or Sponsor. The vendor/developer engages an accredited laboratory and submits their product and associated evidence for evaluation.

2. Laboratory. The laboratory performs the evaluation and reports evaluation results to the scheme. Evaluation is iterative in nature and the vendor is able to address findings during the evaluation.

3. Scheme. Certificate authorizing schemes (also known as a certification body) issue CC certificates and perform certification/validation oversight of the laboratory. Each scheme has its own policies with regard to how the CC is used in that country and what products may be accepted into evaluation

The following provides a high-level overview of what gets evaluated:

‍

Documents defining the evaluation:

Security Target evaluation. Evaluation of the Security Target (ST) - a claims document that specifies the security functions under evaluation and the security assurance requirements being met.

Protection Profile evaluation. Evaluation of the Protection Profile (PP) - an implementation-independent statement of security needs for a technology type.

‍

The product (technically called a Target of Evaluation (TOE). These evaluations can include:

• Development Evaluation. Involves a thorough review of design, architecture, functional specification etc. documents, which can range from a simple interface specification to comprehensive layers of detailed design documentation and even source code examination, depending on the level of assurance required.
• Guidance evaluation. Examination of the product’s guidance materials, including any CC-specific documentation such as secure installation guides, to ensure users can correctly configure the evaluated version of the product..
• Life-cycle evaluation. Evaluation of configuration management practices, delivery procedures and vulnerability or flaw remediation processes. At higher assurance levels this can also cover development environment security and on-site security audits..
• Functional testing. Re-execution of a sample of the developer’s functional tests, coupled with independent tests designed by the evaluators to verify that the security functions operate as described in the ST.
• Vulnerability analysis / Penetration testing. Identification of potential vulnerabilities and active attempts to exploit them, to confirm the TOE meets the claimed assurance level.

‍

Whether each of these activities is performed, and to what extent, depends on the specific assurance requirements stated in the Security Target.

A Security Target is the document that defines the Target of Evaluation (TOE), that is, the product configuration version, and scope of security functionality to be assessed. The CC allows the TOE to be all or part of a product or system. The Security Target is put together using CC constructs and includes a threat model, environmental assumptions, security objectives, security functional requirements and security assurance requirements. The ST is prepared by the vendor and may optionally claim conformance to one or more Protection Profiles (PP). Unlike a PP—typically created from the consumer’s perspective—the ST describes in detail how the product meets the defined security requirements.

‍

Examples of publicly available Security Targets can be found at: https://www.commoncriteriaportal.org/products/index.cfm .

A Protection Profile is an implementation-independent statement of security requirements for a particular type of technology. PPs are defined using CC constructs and often published by governments or industry bodies to guide procurement. Each PP specifies both functional and assurance requirements, which products aiming for CC certification can address.

A single product may conform to multiple PPs if relevant.

‍

A central repository of PPs is available at:

https://www.commoncriteriaportal.org/pps/index.cfm

A Collaborative Protection Profile (cPP) is a type of Protection Profile developed jointly by international technical communities and endorsed by multiple national CC schemes. The collaborative approach ensures that security requirements for a given technology are consistent, mutually recognized, and reflect international consensus. This process is coordinated via the Common Criteria Working Groups, with participation from government, industry, and academic experts.

‍

More information and a list of current cPPs can be found at:https://www.commoncriteriaportal.org/pps/collaborativePP.cfm?cpp=1&CFID=50449855&CFTOKEN=128d3f224a6fcbd2-9042B106-155D-00D0-0AA2F31A79DB3F05

An Evaluation Assurance Level (EAL) is one of several predefined sets of assurance requirements ranging from EAL1 (Functionally Tested) to EAL7 (Formally Verified Design and Tested). A Protection Profile or Security Target may reference an Evaluation Assurance Level (EAL), or, alternatively, describe a custom assurance package tailored to their requirements rather than using a predefined EAL.

A CC evaluation project typically lasts several months, but actual duration depends on many factors such as product complexity assurance claims and completeness of product documentation. An evaluation project includes product preparation (including necessary configuration and testing), documentation preparation by the vendor, engagement with an accredited evaluation laboratory, laboratory evaluation activities and finally certification by the Certification Body.

CC certification only applies to the configurations and versions specified by the certified Security Target. For example, if a certified product is updated from version 1.0 to 1.0.1, the original certificate does not automatically apply to the new version. Some certification schemes may offer longer certificate validity with update provisions, provided the changes are assessed and approved. In most cases, product changes are handled through the Assurance Continuity process.

Assurance Continuity allows minor, non-security-impacting changes to be appended to the existing CC certificate without a full re-evaluation. In cases where changes are security-relevant (and are classified as ‘major’), Assurance Continuity allows these changes to be rapidly evaluated through ‘re-evaluation’, which utilizes results from the original evaluation.

Note: Policies and implementation details for Assurance Continuity vary across national schemes.

Further details about the Assurance Continuity program are included in the Common Criteria Recognition Arrangement (CCRA).

Supporting Documents at https://www.commoncriteriaportal.org/cc/index.cfm#supporting.

CC certified products have undergone a rigorous evaluation process performed by accredited third-party security labs in accordance with internationally accepted criteria and a government-managed framework. Specific advantages include:

• Product security functions have been verified and tested
• Independent evaluators have assessed the product for known vulnerabilities and attempted to exploit potential weaknesses.
• Development practices, configuration management, and vulnerability remediation processes have been reviewed for compliance.
• The product meets formal CC certification requirements often specified in government and regulated-industry procurement policies
• Certificates may be accepted internationally under agreements such as the Common Criteria Recognition Arrangement (CCRA) or, for EU markets, the EUCC scheme.

• EN 419 211-2 (Secure signature creation device - Part 2: Device with key generation)
• EN 419 211-3 (Secure signature creation device - Part 3: “Device with key import”)
• EN 419 211-4 (Secure signature creation device - Part 4: “Extension for device with key generation and trusted communication with certificate generation application”)
• EN 419 211-5 (Secure signature creation device - Part 5: “Cryptographic Module for Trust Services”)
• EN 419 211-6 (Secure signature creation device - Part 6: Extension for device with key import and trusted communication with signature creation application)
• EN 419 241-2 (Trustworthy Systems Supporting Server Signing Part 2: Protection Profile for QSCD for Server Signing)
• EN 419-221-5 (Protection profiles for TSP Cryptographic modules - Part 5 Cryptographic Module for Trust Services)
• Protection Profile For Application Software

Version 1.4, 2021-10-07

• Collaborative Protection Profile For Network Devices

Version 2.2e, 2020-03-23

• Functional Package For Transport Layer Security

Version 1.1, 2019-02-12

• Protection Profile for Certification Authorities

Version 2.1, 2018-12-01 (NIAP)

• Protection Profile Module For Stateful Traffic Filter Firewalls

Version 1.3, 2019-09-27

• Protection Profile For Mobile Device Fundamentals

Version 3.2, 2021-04-15

• CIMC PP

Certificate Issuing and Management Components Protection Profile, Version 1.5

• Protection Profile- Module For Private Network (VPN) Gateways,

Version 1.1, 2020-06-18

• General Purpose Operating Systems Protection Profile/ Mobile Device Fundamentals Protection Profile Extended Package (EP) Wireless Local Area Network (WLAN) Clients

Version 1.0, 2016-02-08

A Common Criteria (CC) certification provides independent assurance that an IT product meets defined security requirements at a specified Evaluation Assurance Level (EAL). Common Criteria certifications are one of the widely recognized, and internationally standardized information security solutions in the world. Thanks to the CCRA (Common Criteria Recognition Arrangement ) and further mutual agreements, the certified product owners are in the especial position, where marketing their product worldwide not only in compliance with expected information technology security requirements (which is a CC certification in the most cases when it comes to tenders), but the evidence of the product’s compliance of up to date international professional standards.

Such certifications are mainly requested by the developers. In case you are in the process of creating a new software or hardware product, you have probably come across the opportunity to secure your product to a certain level. Common Criteria evaluations are for those, who are already prepared for such IT security challenges or welcome the work which leads to a globally acceptable high-end security certification.

CCLab is accredited by the Italian OCSI (Organismo di Certificazione della Sicurezza Informatica) and also the Dutch TrustCB, which are part of the EUCC scheme.

• EN 419 211-2 (Secure signature creation device - Part 2: Device with key generation) / BSI-CC-PP-0059-2009-MA-01, Version 2.0.1

(Protection profiles for secure signature creation device – Part 2: “Device with Key Generation”)

‍

• EN 419 211-3 (Secure signature creation device - Part 3: “Device with key import”) / BSI-CC-PP-0075-2012, Version 2.0.1 (Protection profiles for secure signature creation device - Part 3: Device with key import)
• EN 419 211-4 (Secure signature creation device - Part 4: “Extension for device with key generation and trusted communication with certificate generation application”) / BSI-CC-PP-0071-2012, Version 2.0.1

(Protection profiles for secure signature creation device – Part 4: “Extension for device with key generation and trusted communication with certificate generation application”)

‍

• EN 419 211-5 (Secure signature creation device - Part 5: “Cryptographic Module for Trust Services”) / /BSI-CC-PP-0072-2012, Version 2.0.1
• (Protection profiles for secure signature creation device – Part 5: Extension for device with key generation and trusted communication with signature creation application)
• EN 419 211-6 (Secure signature creation device - Part 6: Extension for device with key import and trusted communication with signature creation application) / BSI-CC-PP-0076-2013, Version 2.0.1 (Protection profiles for secure signature creation device - Part 6: Extension for device with key import and trusted channel to signature creation application)
• EN 419 241-2 (Trustworthy Systems Supporting Server Signing Part 2: Protection Profile for QSCD for Server Signing)
• EN 419-221-5 (Protection profiles for TSP Cryptographic modules - Part 5 Cryptographic Module for Trust Services) 
• CIMC PP Certificate Issuing and Management Components Protection Profile, Version 1.5
• Protection Profile for Certification Authorities Version 2.1, 2018-12-01
• Collaborative Protection Profile For Network Devices, Version 2.2e, 2020-03-23
• Protection Profile Module For Stateful Traffic Filter Firewalls Version 1.3, 2019-09-27
• Protection Profile- Module For Private Network (VPN) Gateways, Version 1.1, 2020-06-18
• Protection Profile For Mobile Device Fundamentals, Version 3.2, 2021-04-15
• General Purpose Operating Systems Protection Profile/ Mobile Device Fundamentals Protection Profile Extended Package (EP) Wireless Local Area Network (WLAN) Clients, Version 1.0, 2016-02-08
• Protection Profile For Application Software, Version 1.4, 2021-10-07
• Functional Package For Transport Layer Security, Version 1.1, 2019-02-12