Common Criteria in 2026: How Global Security Certification Adapts to Modern Cyber Threats
Common Criteria in 2026: How global security certification adapts to modern cyber threats
Common Criteria is one of those standards that gets described as "widely recognized" so often that the phrase has stopped meaning much. But the recognition is real: 31 countries have signed onto the CCRA (Common Criteria Recognition Arrangement), and a CC certificate issued under one participating scheme is accepted in all the others without retesting. For a vendor selling security products internationally, that is genuinely useful. One process, one certificate, no parallel evaluations in each market.
The question worth asking in 2026 is whether the process itself has kept pace with the threat environment it is supposed to address.
What CC actually evaluates
Common Criteria, formally standardized as ISO/IEC 15408, does not certify that a product is "secure." A CC certificate says that specific security functions, defined in a Security Target, have been independently evaluated against defined assurance requirements to a specified level of rigor.
That distinction matters more now than it did five years ago. The CC evaluation methodology accounts for today's threat actors through attack potential analysis: evaluators do not just check that controls exist, they assess whether a realistic attacker with the relevant skills, knowledge, and resources could defeat them. The depth of that analysis is what separates EAL3 from EAL6. In 2026, with fuzzing frameworks, side-channel tooling, and AI-assisted vulnerability discovery all lowering the bar for moderately capable attackers, that depth carries more weight than it used to.
The EAL levels in practical terms
Evaluation Assurance Levels run from EAL1 to EAL7. Most commercial products sit between EAL2 and EAL4+. Here is what those numbers actually represent:
EAL1 to EAL3: Limited to moderate independent testing. No source code review required. EAL3 introduces systematic testing and checks on the development environment. Under EUCC, this range maps to Substantial assurance.
EAL4: Where most serious security products land. Requires full vulnerability analysis at AVA_VAN.3 and independent penetration testing against an attacker with moderate attack potential. This is the EUCC High assurance entry point. Most smartcard and HSM certifications sit here or above.
EAL5 to EAL7: Formal design models, strict development controls, and evaluation against high attack potential. Long, expensive, and almost exclusively used in government or defense contexts.
Choosing the wrong level is a common and expensive mistake. As explained in our article Understanding EUCC Assurance Levels: What "Substantial" and "High" Really Mean for ICT Security, over-engineering at High when Substantial fits the risk profile wastes resources. Under-scoping at Substantial when a product handles critical functions creates a certification gap that will surface during market surveillance.
Source: Magnific
Where CC sits in 2026's certification environment
CC does not exist alone. In Europe, the EUCC brought CC into EU law in February 2025. Products certified at the Substantial level (EAL1 to EAL3, with AVA_VAN.1 or AVA_VAN.2) or High level (EAL4 to EAL7, with AVA_VAN.3 or higher) benefit from a presumption of conformity with Cyber Resilience Act requirements. That linkage makes the assurance level decision more consequential than it was under the old national schemes. Getting it wrong affects more than the certificate.
Outside Europe, the CCRA network continues to provide international recognition across Japan (JISEC), the United States (NIAP), Canada, Australia, South Korea, and others. One certificate, recognized across 31 countries, remains the practical value of CC for internationally traded security products.
The risk profile of the product's intended deployment should drive the assurance level decision, not the vendor's ambition or budget constraints. For a detailed technical breakdown of how EUCC assurance levels map onto CC requirements, see our article Mapping EUCC to Common Criteria: A Technical Overview of Assurance Levels and Evaluation Requirements.
The certification lifecycle and what CC2022 changed
CC2022 (which replaced CCv3.1 Rev 5) strengthened lifecycle requirements. Lifecycle evidence now includes documentation of patch management processes, vulnerability disclosure procedures, and configuration management practices. An evaluator reviewing a product at EAL4 will look at whether the developer has credible processes for identifying and responding to post-certification vulnerabilities, not just whether the current version passes testing.
A CC certificate says the product met the assurance requirements at evaluation time. It does not say the product is still at that level today. Vendors who treat the certificate as the end of the security work, rather than one milestone in an ongoing process, are misreading what they have achieved. A product built with security as a design constraint tends to produce cleaner evaluation evidence, shorter timelines, and more defensible answers when evaluators probe for residual vulnerabilities. As covered in our article Implementing EUCC: What High-Assurance Certification Requires Beyond Traditional Common Criteria Approaches, the shift to CC2022 lifecycle requirements is one of the most significant practical changes for teams going through certification today.
What product teams should actually do
The most common question from teams starting CC certification is some version of: "What EAL do we need?" That is usually the wrong starting point. Begin with the product's intended use and the threat profile of that deployment context. What kind of attacker is realistic? What does the procurement requirement or regulatory framework specify? Those answers narrow the EAL decision quickly.
Documentation quality makes the biggest practical difference. The Security Target has to accurately describe what the product claims to resist. The design documentation has to be complete and internally consistent. Gaps produce evaluation findings that require rework, and rework extends timelines. Pre-evaluation work with an experienced lab surfaces those gaps before the formal clock starts running.
How QIMA CCLab can help you achieve your goals
CCLab is an accredited IT Security Evaluation Facility (ITSEF) operating under TrustCB in the EUCC scheme. We have been running Common Criteria evaluations since 2013, making us the first accredited CC laboratory in Eastern Europe and Hungary's only CC lab.
Common Criteria Evaluation: EAL4+ evaluation projects completed within four months using our agile methodology. Pre-evaluation services are also available to identify documentation and design gaps before formal evaluation begins.
Common Criteria Consultancy: We help product teams build the Security Target, design evidence, test documentation, and lifecycle management materials required for evaluation, across both EUCC and CCRA national scheme certifications.
Cybersecurity Evaluation: For teams not yet at the CC certification stage, we offer penetration testing and vulnerability assessment grounded in the same CC-based methodology, covering hardware, software, and firmware.
FAQ
What is Common Criteria?
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.
Who recognizes CC certificates?
The most widely adopted mutual recognition framework is the Common Criteria Recognition Arrangement (CCRA), with signatories including Australia, Canada, France, Germany, Japan, the Republic of Korea, the Netherlands, the United Kingdom, the United States, and many others. Within Europe, the EUCC provides an EU-wide CC-based certification framework under the EU Cybersecurity Act, which will harmonize and replace certain national arrangements across all EU Member States.
What is the CC evaluation process?
There are three parties involved. The vendor or sponsor engages an accredited laboratory and submits the product and associated evidence for evaluation. The laboratory performs the evaluation and reports results to the scheme; evaluation is iterative and the vendor can address findings during the process. The scheme (certification body) issues CC certificates and performs oversight of the laboratory. Each scheme has its own policies regarding how the CC is applied and which products may be accepted.
What is an Evaluation Assurance Level?
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 EAL, or alternatively describe a custom assurance package tailored to specific requirements rather than using a predefined EAL.
How long does evaluation take?
A CC evaluation project typically lasts several months, but actual duration depends on many factors including product complexity, assurance claims, and the completeness of product documentation. An evaluation project includes product preparation, documentation preparation by the vendor, engagement with an accredited evaluation laboratory, laboratory evaluation activities, and finally certification by the certification body.
What happens when a certified product changes?
CC certification only applies to the configurations and versions specified by the certified Security Target. If a certified product is updated, the original certificate does not automatically apply to the new version. Some certification schemes 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, which allows minor non-security-impacting changes without a full re-evaluation.
Related Articles
