Practical, source-referenced answers to common questions about Common Criteria (ISO/IEC 15408), Evaluation Assurance Levels, Protection Profiles, national certification schemes, the EUCC, and how NenkinTracker fits into procurement and compliance workflows. Each answer is short and self-contained so it can be cited directly.
Foundational questions about the Common Criteria standard itself — what it is, who maintains it, and how it differs from other security frameworks.
ISO/IEC 15408 is the formal name for the Common Criteria for Information Technology Security Evaluation. It is a three-part international standard (Part 1: Introduction and general model, Part 2: Security functional components, Part 3: Security assurance components) that defines a common framework for specifying and evaluating the security of IT products. See our Common Criteria overview for more.
Common Criteria is maintained by the Common Criteria Management Board (CCMB) and the Common Criteria Development Board (CCDB), with participation from national scheme bodies such as BSI, ANSSI, NIAP, and CCCS. The official specifications and methodology documents are published on the Common Criteria Portal at commoncriteriaportal.org.
Common Criteria evaluates the security of a specific IT product (a piece of hardware, firmware, or software), while ISO 27001 certifies an organization's information security management system. A vendor might hold ISO 27001 for its internal processes and separately certify individual products under Common Criteria. The two are complementary rather than substitutes.
A Target of Evaluation (TOE) is the specific product, subsystem, or configuration that is being evaluated under Common Criteria. The TOE boundary is defined in the Security Target and determines what is covered by the certificate and what lies outside its scope. Anything outside the TOE boundary is not guaranteed by the certification.
A Security Target (ST) is the central document in a Common Criteria evaluation. It describes the TOE, the threats it is designed to counter, the security objectives, and the Security Functional Requirements (SFRs) the product claims to implement. Every certified product has a published Security Target that defines the scope of its certificate.
The Common Evaluation Methodology (CEM), formally ISO/IEC 18045, is the companion standard to Common Criteria. It specifies how evaluators should perform assurance activities, what evidence they must gather, and how they should document findings. Together, CC and CEM ensure that evaluations are reproducible and comparable across labs and schemes.
The current release is Common Criteria version 2022 (CC:2022), which aligns with ISO/IEC 15408:2022. It replaces the long-running CC v3.1 release series but schemes and vendors are transitioning gradually, so both versions remain in active use for new evaluations and existing certificates.
In Common Criteria, certification is the act of issuing a certificate for a specific product evaluation, performed by a national scheme body. Accreditation is a separate process in which an authority confirms that an evaluation laboratory (ITSEF) is competent to carry out CC evaluations. A certified product has been evaluated by an accredited lab and certified by an authorizing scheme.
Questions about Evaluation Assurance Levels — what they measure, how to pick one, and how augmentation works.
Evaluation Assurance Levels run from EAL1 (functionally tested) through EAL7 (formally verified design and tested). Each step adds more rigorous analysis and evidence requirements. Most commercial certifications fall in the EAL2-EAL4 range; EAL5-EAL7 are rare and typically reserved for smart cards and secure microcontrollers. See our EAL reference.
No. EAL measures how thoroughly a product was evaluated, not how secure it is. A simple product at EAL4 and a complex product at EAL2 can offer equivalent real-world security for their respective use cases. The EAL tells you how much confidence you can place in the vendor's claims, not that the product is inherently safer.
EAL2 is the most common level globally and is the de facto baseline for general commercial IT products. EAL4 and EAL4+ are the next most common and dominate smart card, payment terminal, and hardware security module certifications. See our EAL guide for current distribution.
EAL4+ means a product was evaluated at EAL4 with one or more additional assurance components added on top of the base package. Common augmentations include AVA_VAN.5 (enhanced vulnerability analysis) and ALC_FLR.2 or ALC_FLR.3 (flaw remediation). The plus sign indicates augmentation; the Security Target lists exactly which components were added.
Under the CCRA, mutual recognition is generally limited to evaluations at EAL2 (or EAL4 for specific collaborative Protection Profiles). Higher EALs are typically recognised only within the national scheme that issued them, or bilaterally between schemes with specific agreements such as the SOG-IS Mutual Recognition Agreement in Europe.
Start with the threat environment and regulatory requirements you need to meet. If you are targeting US federal procurement, NIAP Protection Profile conformance generally matters more than a specific EAL. If you are targeting EU government or smart card markets, EAL4+ with AVA_VAN.5 is a common baseline. Talk to your intended scheme and ITSEF early to align expectations.
Costs and timelines vary widely by product complexity, EAL level, chosen scheme, and evaluator. In general, low-EAL evaluations of simple products can finish in several months, while higher-EAL evaluations of complex products can run well over a year. Vendors should budget for evaluator fees, certification fees, internal effort, and consulting support; treat published figures as rough indicators, not fixed prices.
Changes to a certified product are handled through CC assurance continuity: minor changes go through a Maintenance procedure that produces an updated Assurance Continuity Maintenance Report, while major changes require re-evaluation. Schemes publish their own guidance on what qualifies as minor versus major. Certificates eventually reach archive status when they are superseded or the assurance period ends.
Questions about Protection Profiles — the standardised security requirements used by procurement teams and vendors.
A Protection Profile (PP) is a reusable, vendor-independent set of security requirements for a category of IT products, such as network devices or full disk encryption software. It describes what a product must do to be considered secure for a given use case. Vendors demonstrate PP conformance by showing their Security Target meets every requirement in the PP. See our PP overview.
A Protection Profile is a generic, category-wide requirements document, while a Security Target is product-specific and written by the vendor for a particular TOE. A Security Target may claim conformance to one or more Protection Profiles, which means the product's requirements are at least as strong as those defined in the PP.
A collaborative Protection Profile (cPP) is developed by an international Technical Community (iTC) under the CCRA, with participation from multiple national schemes and industry stakeholders. cPPs are the preferred basis for CCRA mutual recognition and exist for categories including network devices, full disk encryption, dedicated security components, and application software.
Yes. Beginning in the early-to-mid 2010s (around 2014), NIAP (the US Common Criteria scheme) phased out stand-alone EAL-based evaluations and now requires every evaluation it certifies to conform to an approved Protection Profile. This shift moved US evaluations toward threat-relevant requirements per product category rather than arbitrary assurance level targets. See our schemes overview.
The Common Criteria Portal maintains the canonical index of collaborative Protection Profiles. National schemes also publish their own lists: NIAP maintains the largest national PP library at niap-ccevs.org, while BSI and ANSSI publish their national PPs on their respective scheme websites. Most PPs are freely downloadable PDFs.
Common PP-covered categories include network devices (firewalls, routers, VPN gateways), operating systems, application software, mobile devices, full disk encryption, multi-function printers, virtualization platforms, and enterprise mobility management. Smart cards and secure microcontrollers have their own long-standing industry PPs maintained by organisations such as EUROSMART and GlobalPlatform.
Protection Profiles are versioned and eventually superseded by newer revisions, but they do not expire in the same way individual certificates do. Scheme policies govern how long certifications against older PP versions remain recognised — typically new evaluations must use the current PP version, while existing certificates continue until the certificate itself reaches its own assurance period end.
Questions about the national bodies that issue Common Criteria certificates and how they recognise each other.
The Common Criteria Recognition Arrangement (CCRA) is a multilateral agreement under which member nations accept each other's Common Criteria certificates without re-evaluation, up to defined assurance levels. Membership is divided into Certificate Authorizing Participants (who issue certificates) and Certificate Consuming Participants (who accept them). As of the most recent CCRA roster, there are roughly 31 member nations.
Certificate-authorising CCRA members include Germany (BSI), France (ANSSI), the United States (NIAP), Canada (CCCS), the Netherlands (NSCIB), Italy (OCSI), Spain (CCN), Japan (JISEC), South Korea (KECS), Australia (ACSC/ASD), Sweden (CSEC), Turkey (TSE), and others. See our schemes by country guide for a detailed breakdown.
SOG-IS (Senior Officials Group - Information Systems Security) is a European mutual recognition arrangement that recognises Common Criteria certificates at higher assurance levels than the CCRA, including EAL4+ through EAL7 for specific technical domains such as smart cards and hardware devices with security boxes. SOG-IS membership is a subset of European countries (including non-EU states such as Norway) and is gradually being transitioned into the EUCC.
The Bundesamt für Sicherheit in der Informationstechnik (BSI) is Germany's federal cybersecurity agency and operates one of the largest CC certification bodies worldwide. BSI certifies a wide range of products including smart cards, HSMs, operating systems, and payment devices, and maintains detailed public records of every certificate it has issued.
The Agence nationale de la sécurité des systèmes d'information (ANSSI) runs France's national CC scheme and is particularly active in higher-assurance evaluations for government, defence, and secure hardware. ANSSI also publishes its own national Protection Profiles and qualification levels that apply on top of CC (CSPN, Qualification standard/renforcée/élémentaire).
The National Information Assurance Partnership (NIAP) manages the US Common Criteria scheme under the oversight of the NSA. NIAP requires all evaluations it certifies to conform to an approved Protection Profile and maintains the Product Compliant List (PCL) of validated products. NIAP certificates are typically a precondition for federal procurement of commercial IT security products.
All CCRA schemes evaluate against the same Common Criteria standard and the Common Evaluation Methodology, so the core requirements are identical. Differences lie in national priorities — which PPs are accepted, what assurance levels are commonly issued, and what supplementary national qualifications exist. These differences matter when choosing a scheme for a target market.
Questions about the EU Common Criteria-based Cybersecurity Certification Scheme and its relationship to existing national schemes.
The EUCC is the European Union Common Criteria-based Cybersecurity Certification Scheme. It is the first EU-wide cybersecurity certification scheme adopted under the EU Cybersecurity Act (Regulation 2019/881) and was formally established by Commission Implementing Regulation (EU) 2024/482. It builds on ISO/IEC 15408 and the CEM but wraps them in an EU regulatory framework. See our EUCC guide.
The CCRA is an international mutual recognition arrangement between sovereign national schemes, operating by consensus without regulatory force. The EUCC is an EU regulation — it is binding law inside the EU, defines standardised assurance levels (substantial and high), and establishes a common governance model with ENISA and the national cybersecurity certification authorities (NCCAs) of EU member states.
The EUCC defines two assurance levels: substantial, which corresponds roughly to CC EAL1-EAL4 and is issued by accredited Conformity Assessment Bodies (CABs), and high, which covers EAL4+ and above and must be issued or approved by the national cybersecurity certification authority (NCCA). The precise mapping between EUCC level and CC assurance is defined through AVA_VAN vulnerability-analysis components per Commission Implementing Regulation (EU) 2024/482, not through EAL alone. Protection Profile conformance is expected at the high level.
Existing national CC certificates remain valid until their own expiry dates; the EUCC does not retroactively invalidate them. Going forward, new evaluations in the EU are expected to be issued as EUCC certificates under the harmonised framework, while some national schemes may continue to issue national certificates in parallel during the transition.
The Cyber Resilience Act (CRA) imposes cybersecurity requirements on products with digital elements placed on the EU market. EUCC certificates can be used to demonstrate presumption of conformity with some of those CRA requirements, though the Commission is still developing the exact mapping via implementing acts. In practice, holding an EUCC high certificate is expected to reduce CRA assessment burden for critical product categories.
EUCC certification itself is voluntary under the EU Cybersecurity Act. However, specific EU regulations — such as the CRA for critical product classes, NIS2 for certain essential and important entities, and sector-specific frameworks — may require or favour EUCC-certified products. Check the regulation that applies to your market segment.
Questions about the practical steps of getting a product certified.
Typical evaluations run from several months for low-EAL, well-scoped products to more than a year for higher-EAL or complex products. Key factors include scope of the TOE, quality of Security Target and evidence, evaluator workload, and scheme certification queue. For a step-by-step walk-through, see our certification process guide.
An ITSEF (IT Security Evaluation Facility) is an accredited commercial or government laboratory that performs Common Criteria evaluations. ITSEFs are sometimes called Commercial Evaluation Facilities (CEFs) or, under EUCC terminology, Conformity Assessment Bodies (CABs). Each ITSEF is accredited by a national accreditation body and approved by one or more schemes.
At minimum, vendors produce a Security Target, design documentation (functional specification, TOE design, security architecture), lifecycle documentation, guidance documents, and test evidence. Higher EALs require additional deliverables such as semiformal or formal models. The ITSEF issues Observation Reports when evidence is insufficient and produces an Evaluation Technical Report at the end.
Re-evaluation is needed when a product changes in ways that go beyond the assurance continuity maintenance process — for example, significant architectural changes, new security-relevant features, or a different TOE boundary. Scheme-specific guidance defines the thresholds, and vendors should consult their scheme and ITSEF early in any major development cycle.
An Evaluation Technical Report (ETR) is the detailed internal report produced by the ITSEF describing how it performed each assurance activity and the verdicts it reached. The ETR is submitted to the scheme body as the basis for certification decisions. The ETR itself is not public, but its findings are summarised in the public Certification Report.
A Certification Report is the public document issued by the scheme body when a certificate is granted. It summarises the TOE, the assurance components evaluated, the evaluation verdicts, operational guidance, and limitations of the certificate. Certification Reports, alongside the Security Target, are the primary public artefacts of a certified product and are tracked in NenkinTracker.
Questions about using Common Criteria certifications in RFPs, regulated procurement, and internal compliance evidence.
Good RFP language specifies both functional and assurance requirements. For example: "Product shall be certified under Common Criteria to the Network Device collaborative Protection Profile (NDcPP) v2.2e at EAL2 or equivalent, issued by a CCRA Certificate Authorizing Participant." Specifying a Protection Profile is more precise than a bare EAL. See our PP page.
For many US National Security Systems (NSS) and specific product categories, NSTISSP No. 11 / CNSSP No. 11 requires NIAP-validated or CC-certified products from CCRA member schemes. Civilian agency requirements vary by agency and program. In practice, a NIAP Protection Profile-conformant certificate on the Product Compliant List is the strongest evidence for US federal contexts.
There is no single EU-wide mandate, but sector-specific regulations and national rules often reference Common Criteria — particularly for government ICT, payment systems, identity cards, and classified information handling. Under the Cybersecurity Act, EUCC certificates are becoming the preferred evidence for regulated product categories in the EU.
The payments industry uses Common Criteria as the evaluation basis for smart cards, HSMs, payment terminals, and secure elements. Industry-specific Protection Profiles from organisations such as EMVCo, GlobalPlatform, and PCI SSC extend CC with payment-specific requirements. Card schemes typically require CC certification against these PPs as a precondition for brand approval.
Yes, indirectly. CC certificates, Security Targets, and Certification Reports can be attached as evidence that the technology components used in an organisation's systems have been independently evaluated. This supports controls related to supplier assurance, technology selection, and secure configuration in ISO 27001 Annex A and the SOC 2 Trust Services Criteria.
Common Criteria provides independent, third-party evidence that a product was evaluated against a defined Security Target, which is useful for vendor risk assessments and supplier due diligence. It does not replace SBOM, vulnerability management, or other supply chain controls, but complements them by giving procurement teams a published baseline to reference. NenkinTracker for compliance helps teams track these artefacts.
An archived certificate is no longer listed as active on a scheme's certified product list, typically because the assurance continuity maintenance period has ended, the product has been withdrawn, or a newer certificate has replaced it. The original evaluation record remains publicly available for reference, but procurement teams usually require an active certificate for new purchases.
Questions about how NenkinTracker sources, structures, and surfaces Common Criteria data.
NenkinTracker aggregates data from the Common Criteria Portal and from national scheme portals including BSI, ANSSI, NIAP, CCCS, OCSI, NSCIB, JISEC, KECS, and others. All ingested data links back to the canonical source. See our data coverage page for the current source list.
NenkinTracker re-ingests source data on a regular schedule and uses content-hash change detection to identify new, updated, and removed certificates. Users following a product receive notifications when relevant changes are detected. The dashboard shows the most recent ingestion timestamp per source.
NenkinTracker tracks and versions the official PDF documents published by national schemes — Security Targets, Certification Reports, Maintenance Reports, and Protection Profiles — so that teams can see when a scheme publishes a new version. Documents are de-duplicated by SHA-256 content hash and always link back to the canonical source.
Notifications fire when a followed product or vendor has a new certification issued, an existing certificate is updated (new version, maintenance, re-evaluation), a certificate transitions to archived status, a linked document changes, or a new CVE is published that affects a followed product. Users can scope notifications per list.
Yes. NenkinTracker supports audit-ready evidence export so teams can attach certification metadata, source URLs, version history, and document hashes to audit and compliance deliverables. Export format and scope depend on the subscription tier.
Programmatic access is available on Professional and Enterprise tiers, intended for integration with internal GRC, procurement, and vulnerability management systems. Full access details are shared on request — contact us via the contact page.
NenkinTracker is primarily offered as a hosted SaaS product so that customers benefit from continuous data ingestion without operating infrastructure. Dedicated deployment arrangements are considered on a case-by-case basis for Enterprise and public-sector customers — contact us to discuss.
Questions about subscriptions, trials, and which features come in which tier.
Yes. NenkinTracker has a free tier that lets you try the platform and follow a limited number of products and vendors. Higher tiers unlock broader follow limits, export features, longer history, and API access. See the pricing page for current details.
Yes, paid tiers can be trialled before committing to a subscription. Trial length, scope, and tier availability are described on the pricing page and may evolve over time; the pricing page is always the canonical source.
Higher tiers increase the number of products and vendors you can follow, unlock features such as advanced export, extended change history, team and role management, and API access, and include additional support. The free tier is suitable for individual practitioners; paid tiers are designed for teams in procurement, compliance, and product security.
Individual researchers, practitioners, students, and small teams evaluating the platform. The free tier is deliberately usable for real monitoring of a handful of products and vendors, so the value proposition is visible without a contract.
Yes, paid tiers support team accounts with shared lists and role-based access so that product security, procurement, and compliance teams can collaborate on the same set of tracked products. Enterprise tiers add SSO and organisation-level controls.