Common Criteria (ISO/IEC 15408) / IC3S

Introduction: The Common Criteria (ISO/IEC 15408) and the Indian IC3S Scheme

The Common Criteria for Information Technology Security Evaluation, formally standardised as ISO/IEC 15408, is the world's most widely adopted framework for the independent, third-party security evaluation and certification of IT products. It provides a rigorous, repeatable and internationally mutually-recognised methodology for specifying security requirements, implementing them within a product, and having an accredited laboratory verify that those requirements have genuinely been met. Where compliance frameworks such as ISO/IEC 27001 or PCI DSS assess an organisation's management system, Common Criteria evaluates the security assurance of a specific product or a specific version of a product, known as the Target of Evaluation (TOE).

In India, Common Criteria evaluation is delivered through the Indian Common Criteria Certification Scheme (IC3S), operated by the Standardisation Testing and Quality Certification (STQC) Directorate under the Ministry of Electronics and Information Technology (MeitY). STQC is the Certification Body (CB) and India is a Certificate Authorising Participant of the Common Criteria Recognition Arrangement (CCRA), meaning certificates issued under IC3S are recognised across the CCRA member nations up to Evaluation Assurance Level (EAL) 2 and for evaluations conducted against certified collaborative Protection Profiles (cPPs). This guide is written for two audiences simultaneously: the developer or product/sponsor team preparing a product for evaluation, and the evaluator/assessor or procurement officer who must judge whether an evaluation has been conducted correctly and whether a certificate is fit for their assurance needs.

What is Common Criteria?

Common Criteria is an assurance framework, not a checklist of mandatory security features. It is built around a deliberate separation between two independent variables: what security a product claims to provide (its functional requirements) and how much confidence you can place in those claims (its assurance requirements). This separation is the conceptual heart of the standard and is worth internalising before any evaluation project begins.

The standard emerged in the mid-1990s from the harmonisation of earlier national schemes - the United States TCSEC (the 'Orange Book'), the European ITSEC and the Canadian CTCPEC - into a single international criteria set, first published as ISO/IEC 15408 in 1999 and revised repeatedly since, with a substantial restructuring into a five-part standard in the 2022 edition. The accompanying Common Evaluation Methodology was standardised as ISO/IEC 18045. Together they underpin the Common Criteria Recognition Arrangement, under which member nations agree to recognise each other's certificates within defined bounds, so that a product evaluated once can be trusted across many markets rather than being re-tested in each. This one-evaluation, many-markets economy is the core commercial value proposition of Common Criteria for product vendors.

Security functional requirements (SFRs) are drawn from ISO/IEC 15408 Part 2 and describe the security behaviour a product must exhibit, for example cryptographic operation, access control, audit generation or trusted-path establishment. Security assurance requirements (SARs) are drawn from Part 3 and describe the depth and rigour of the evidence and testing used to gain confidence that the SFRs are correctly and completely implemented, for example design documentation, source-code analysis, penetration testing and configuration-management discipline. A predefined bundle of SARs forms an Evaluation Assurance Level (EAL1 through EAL7).

The evaluation always concerns a precisely bounded Target of Evaluation (TOE): a defined product, in a defined configuration, at a defined version, running in a defined operational environment with stated assumptions. The security claims are captured in a Security Target (ST), an auditable document that binds the TOE to a threat model, security objectives, SFRs and SARs. Where a class of products shares a common security problem, a Protection Profile (PP) expresses an implementation-independent set of requirements that many products can claim conformance to; collaborative Protection Profiles (cPPs) developed by international technical communities (iTCs) are the modern basis for mutual recognition.

A vital consequence of this model is that a Common Criteria certificate is meaningful only when read together with its Security Target. The certificate tells you that a named laboratory verified, to a stated level of rigour, that a named product met the SFRs claimed in its ST while operating under the assumptions in that ST. It does not tell you the product is 'secure' in the abstract, nor does it warrant behaviour outside the evaluated configuration. Consumers and procurement officers who treat the EAL number as a standalone quality grade routinely misjudge assurance; mature buyers read the TOE boundary, the assumptions and the claimed PP before relying on any certificate. This discipline is precisely what distinguishes Common Criteria from marketing-led security labelling schemes.

The framework is also deliberately technology-neutral. The same catalogue of SFRs and SARs applies whether the TOE is a smart-card chip, a firewall appliance, a database engine, a hardware security module or a piece of virtualisation software. Product-category specificity is layered on top through Protection Profiles: the Network Device cPP, firewall and VPN cPPs, the smart-card and secure-element PPs, operating-system PPs and application PPs each translate the generic catalogue into a concrete, testable baseline for their domain. This layered design lets Common Criteria remain stable across decades of technology change while still delivering directly comparable evaluations within a product class.

• Target of Evaluation (TOE): the exact product, version and configuration being evaluated.
• Security Target (ST): the sponsor's implementation-specific security specification and evaluation basis.
• Protection Profile (PP / cPP): an implementation-independent, reusable statement of requirements for a product category.
• Security Functional Requirements (SFRs): Part 2 catalogue of what the product must do.
• Security Assurance Requirements (SARs): Part 3 catalogue of how thoroughly it is verified.
• Evaluation Assurance Level (EAL 1-7): a predefined, internally consistent package of SARs.
• Common Evaluation Methodology (CEM / ISO/IEC 18045): the mandatory methodology evaluators must follow.
• Certificate: issued by the Certification Body (STQC under IC3S) after a successful evaluation by an accredited laboratory.

Who must comply with, or benefit from, Common Criteria?

Common Criteria is rarely a blanket legal mandate; it is typically a procurement requirement, a market-access requirement or a sector regulation. Governments impose it on the products they buy for sensitive systems; payment and identity schemes impose it on the secure hardware that underpins them; and regulated industries increasingly reference it as evidence of independently verified product assurance. Understanding which driver applies to you determines whether a full standalone evaluation, a PP/cPP conformance claim, or an existing certificate reuse is the right route. The following table summarises who is driven towards a CC certificate and why.

Structure of Common Criteria

ISO/IEC 15408 is organised into parts, and within Parts 2 and 3 into hierarchically named classes, families, components and elements. A class is a broad grouping (e.g. cryptographic support), a family refines it (e.g. cryptographic key management), a component is a specific selectable requirement with dependencies and hierarchy, and an element is the smallest indivisible statement. Requirements are cited by a compact identifier: a three-letter class prefix, a three-letter family suffix, and a component number, for example FCS_COP.1 (Functional-Cryptographic Support-Cryptographic Operation, component 1) or ADV_FSP.4 (Assurance-Development-Functional Specification, component 4).

Two properties of this catalogue matter greatly in practice. First, components carry dependencies: selecting one SFR frequently obliges you to select others (for example, a cryptographic-operation requirement depends on key generation, key destruction and often audit), and an incomplete dependency chain is one of the most frequent Security Target defects. Second, many components contain assignments and selections - author-completed parameters such as the specific algorithm, key length or list of auditable events - which turn the generic requirement into a precise, testable claim. Evaluators verify both that dependencies are satisfied or justifiably not, and that every assignment and selection has been made and is consistent with the rest of the ST. Understanding this identifier-and-parameter grammar is essential to reading any Security Target or Protection Profile fluently.

Master assessment checklist - class by class

This is the operational core of the guide. It enumerates every functional and assurance class, giving the evaluator concrete verification points and the sponsor/developer the typical evidence expected. For an actual evaluation the applicable subset of SFRs is fixed by the Security Target or claimed Protection Profile, and the applicable SARs are fixed by the claimed EAL or cPP assurance package. Use these tables to structure evidence collection and gap analysis.

A practical way to use this section is to run it as a two-pass exercise. In the first pass, the product team maps every claimed SFR in the Security Target to the relevant functional class below and confirms that a design artefact and a test case exist for each; any class row with no corresponding claim is either legitimately out of scope or a sign of an incomplete ST. In the second pass, the team walks every assurance class and confirms that the evidence at the claimed EAL exists at the required rigour, not merely in outline. Evaluators perform the mirror image of this exercise, sampling the same rows and probing for the boundary between what the developer asserts and what the evidence actually demonstrates. Treating the functional classes and the assurance classes as two coordinated coverage matrices is the single most effective way to avoid late-stage Observation Reports.

FAU - Security audit

FCO - Communication

FCS - Cryptographic support

FDP - User data protection

FIA - Identification and authentication

FMT - Security management

FPR - Privacy

FPT - Protection of the TSF

FRU - Resource utilisation

FTA - TOE access

FTP - Trusted path/channels

ASE / APE - Security Target and Protection Profile evaluation

ADV - Development

AGD - Guidance documents

ALC - Life-cycle support

ATE - Tests

AVA - Vulnerability assessment

ACO - Composition (where applicable)

Scoping the Target of Evaluation

Scoping is the single most consequential decision in a CC project, because it fixes cost, timeline and the value of the resulting certificate. The TOE boundary must be drawn deliberately: everything inside is evaluated, everything outside becomes an operational-environment assumption that consumers must satisfy. A certificate whose scope excludes the features a buyer actually cares about provides little real assurance, so both sponsor and evaluator must scrutinise the boundary.

Each assumption pushed into the operational environment is, in effect, a transfer of responsibility from the developer to the deployer. An assumption that 'administrators are trusted and competent', or that 'the TOE is physically protected', or that 'a supporting IT environment provides a secure time source', simplifies the evaluation but obliges the customer to make that assumption true. Well-scoped evaluations keep the security-relevant behaviour that customers depend on inside the boundary and reserve assumptions for genuinely environmental factors. When a Protection Profile or cPP applies, much of this scoping discipline is pre-decided by the technical community, which is one of the strongest arguments for claiming PP conformance rather than crafting a bespoke Security Target: the boundary, threats and assumptions have already been debated and agreed by domain experts, and the resulting certificate is directly comparable with competitors evaluated against the same profile.

• Define the exact product, version, build and hardware/firmware baseline that constitutes the TOE.
• State the physical and logical boundary: which components, interfaces and services are inside versus outside.
• Record operational-environment assumptions (physical protection, trusted administrators, supporting IT) precisely, as each shifts risk to the consumer.
• Choose the conformance target: a claimed Protection Profile / cPP (preferred for mutual recognition) or a standalone Security Target with a chosen EAL.
• Confirm the evaluated configuration is a realistic, deployable configuration, not a stripped-down variant that no customer would use.
• Identify any excluded functionality and document why, so the certificate is not misread as covering it.
• Fix the cryptographic scheme and, where required, align to SOG-IS agreed cryptographic mechanisms.

Implementation approach - a phased programme

A Common Criteria evaluation is a structured project spanning the sponsor/developer, the accredited evaluation laboratory (ITSEF/CCTL) and the Certification Body. It is best run as a formal programme with a named evaluation manager on the sponsor side, because the effort is dominated by evidence production rather than by the product engineering itself. Experience shows that teams which start authoring the Security Target and building the evidence inventory early, in parallel with development, complete evaluation far faster than those who treat it as a post-development compliance exercise. The following phases describe a typical EAL2-EAL4 or cPP engagement; higher assurance levels add formal-methods and semiformal-design activities that materially lengthen phases 2 and 3.

Phase 1 - Feasibility and strategy

• Activities: decide business drivers, select PP/cPP or standalone ST, choose target assurance level, identify the accredited laboratory, engage the CB (STQC under IC3S) early.
• Deliverables: evaluation strategy note, assurance-level decision, laboratory engagement, high-level TOE boundary.

Phase 2 - Security Target and evidence planning

• Activities: author the Security Target (or PP conformance claim), define SFRs/SARs, build the security problem definition and rationale, plan the full evidence inventory.
• Deliverables: draft Security Target, SFR/SAR selection with dependency analysis, evidence plan and responsibility matrix.

Phase 3 - Development evidence production

• Activities: produce ADV (functional spec, architecture, design), AGD guidance, ALC configuration-management and life-cycle evidence, and developer ATE testing.
• Deliverables: design documentation set, administrator/user guidance, CM system and records, developer test suite with results.

Phase 4 - Evaluation and vulnerability assessment

• Activities: the ITSEF evaluates all deliverables per the CEM, performs independent testing (ATE_IND) and vulnerability analysis with penetration testing (AVA_VAN), and raises Observation Reports.
• Deliverables: Evaluation Technical Report (ETR), observation/finding resolutions, penetration test results.

Phase 5 - Certification and maintenance

• Activities: the CB reviews the ETR, issues the certificate and Certification Report, publishes to the CC portal, and the sponsor establishes assurance continuity for patches and new versions.
• Deliverables: CC certificate, public Certification Report, validated ST, and an assurance-continuity/maintenance plan for future updates.

Assurance levels - the EAL scoring model

Evaluation Assurance Levels are the predefined scoring scale of Common Criteria. Each EAL is an internally consistent package of SARs; higher levels demand more design detail, more rigorous testing and stronger resistance to attack. Crucially, a higher EAL means greater confidence, not necessarily more security features - a low-EAL product may implement strong functionality with modest assurance. An augmented EAL (denoted 'EAL4+') adds one or more SARs above the base package, most commonly a stronger AVA_VAN or ALC component; augmentation is the usual way smart-card and secure-element evaluations reach the resistance to high-attack-potential adversaries that their threat model demands. Under CCRA, mutual recognition is limited to EAL2 (and its assurance components) and to PP/cPP-based evaluations; higher-EAL recognition persists under regional arrangements such as SOG-IS in Europe.

The modern trajectory of Common Criteria is away from raw EAL numbers and towards Protection Profile and cPP conformance, because a cPP-based evaluation states exactly which threats were countered and which tests were run for a specific product class, whereas a bare EAL package leaves the functional claims entirely to the individual Security Target. For procurement, 'EAL4+ conformant to the Network Device cPP' is far more informative than 'EAL4+' alone, and it is directly comparable across vendors. Sponsors choosing a route should therefore ask first whether a suitable PP/cPP exists for their product category and default to it; a standalone ST with a chosen EAL is reserved for products with no applicable profile.

Assurance continuity deserves particular attention because a Common Criteria certificate is a point-in-time statement about a specific version, yet products change constantly. Under the scheme's maintenance procedures, minor changes with no security impact can be handled through an assurance-continuity or maintenance process that updates the certificate without a full re-evaluation, while significant changes to the TSF, the cryptographic scheme or the threat environment require re-evaluation. Sponsors who plan for this from the outset - by keeping the impact-analysis discipline, configuration management and evidence repository live after certification - can keep their certificate current at modest cost. Those who do not find that the certificate rapidly ceases to describe the shipping product, eroding the very assurance it was meant to provide. For buyers, checking the certificate date, the certified version and whether maintenance has been applied is as important as checking the EAL.

Assessment and audit approach

The evaluation lifecycle is defined by the Common Evaluation Methodology (ISO/IEC 18045), which prescribes the specific work units an evaluator must perform and the verdicts they must assign for each assurance component. This methodological standardisation is what makes results repeatable and mutually recognisable: two accredited laboratories evaluating the same product against the same ST should reach the same verdicts. Each work unit yields a pass, fail or inconclusive verdict, and an inconclusive or fail result triggers an Observation Report that the sponsor must resolve before the component can pass. The following ordered steps describe how an evaluation proceeds from initiation to certificate issuance under a scheme such as IC3S.

1. Initiate the evaluation: sponsor contracts an accredited ITSEF/CCTL and registers the project with the Certification Body (STQC).
2. Evaluate the Security Target (ASE) or Protection Profile (APE) to confirm the claims are sound before deeper work begins.
3. Assess development evidence (ADV) against the claimed assurance components for completeness and rigour.
4. Assess guidance (AGD) and life-cycle evidence (ALC), including configuration management, delivery and development security.
5. Analyse and independently execute tests (ATE): review coverage and depth, repeat sampled developer tests, run independent tests.
6. Perform vulnerability analysis and penetration testing (AVA_VAN) calibrated to the required attack potential.
7. Raise Observation Reports for deficiencies; the sponsor remediates and resubmits evidence.
8. Compile the Evaluation Technical Report (ETR) documenting all verdicts and rationale.
9. Certification Body reviews the ETR for methodological correctness and consistency across the scheme.
10. Issue the certificate and publish the Certification Report and validated Security Target to the Common Criteria portal.
11. Maintain assurance continuity: assess patches, minor changes and re-evaluation triggers over the product lifecycle.

Evidence request list

The following categorised inventory covers the evidence an ITSEF will request. Not all items apply at every EAL; the applicable subset is fixed by the claimed assurance package. A useful sponsor practice is to hold each item in a version-controlled evidence repository with a clear owner and a maturity status (draft, internally reviewed, evaluation-ready), so that the evaluation manager can report readiness objectively and the laboratory receives complete, consistent packages rather than a stream of partial drafts. Incomplete or inconsistent evidence is the leading cause of schedule slippage in real evaluations.

• Specification: Security Target (or PP conformance claim), TOE boundary description, SFR/SAR selection with dependency rationale.
• Design (ADV): functional specification and TSFI catalogue, security architecture description, TOE design decomposition, implementation representation/source (higher EALs).
• Guidance (AGD): administrator and user operational guidance, preparative/installation and secure-acceptance procedures.
• Life-cycle (ALC): configuration-management plan and records, item/configuration list, delivery procedures, development-site security documentation, life-cycle model, tool list, flaw-remediation procedure.
• Testing (ATE): test plans, test procedures, expected and actual results, coverage and depth analyses, test logs.
• Vulnerability (AVA): developer and public vulnerability analysis, penetration test plans and results, attack-potential calculations.
• Cryptographic: algorithm certificates, entropy analysis, key-management design, self-test and zeroisation evidence.
• Scheme/administrative: laboratory accreditation, evaluation contract, prior certificates for reused/base components (composition).

Roles and responsibilities

KPIs to track

• Evidence completeness: percentage of required ADV/AGD/ALC/ATE deliverables produced and accepted.
• Observation Report burden: number of ORs raised by the ITSEF and mean time to resolution.
• Schedule adherence: variance against the planned evaluation timeline per phase.
• Vulnerability findings: number of exploitable findings from AVA_VAN and their remediation status.
• Test pass rate: proportion of developer and independent test cases passing on first submission.
• Rework ratio: evidence items requiring resubmission versus total submitted.
• Assurance-continuity health: time to re-certify patches and versions under maintenance.
• Certificate scope quality: proportion of consumer-relevant functionality inside the TOE boundary.

Readiness checklist

• Business drivers and target assurance level (EAL or cPP) agreed and documented.
• Applicable Protection Profile / cPP identified, or a standalone Security Target scope decided.
• TOE boundary, version baseline and evaluated configuration fixed and realistic.
• Operational-environment assumptions and excluded functionality documented.
• Security Target drafted with SFRs, SARs, threat model and complete rationale.
• Development evidence (functional spec, architecture, design) available at the required rigour.
• Administrator and user guidance plus secure preparative procedures complete.
• Configuration management, delivery and development-security controls operating and evidenced.
• Developer functional test suite with coverage/depth analysis and documented results ready.
• Vulnerability analysis performed and cryptographic evidence (algorithm certs, entropy) assembled.
• Accredited ITSEF engaged and the Certification Body (STQC/IC3S) project registered.
• Assurance-continuity/maintenance plan defined for future patches and versions.

Common gaps and failure modes

• Over-narrow TOE scope that excludes management, update or crypto functions to reach an EAL cheaply, undermining the certificate's real value.
• Security Target rationale gaps: unsatisfied SFR dependencies or objectives that do not trace to the threat model.
• Weak security architecture (ADV_ARC) evidence for self-protection, domain separation and non-bypassability.
• Configuration management that fails to uniquely identify every TOE item or does not cover the whole build.
• Insufficient developer test coverage and depth, forcing extensive independent-testing rework.
• Underestimating vulnerability assessment: penetration testing scaled to the wrong attack potential for the claimed level.
• Guidance documents inconsistent with the evaluated configuration, so real deployments diverge from the certificate.
• Inadequate entropy/randomness or unapproved cryptographic mechanisms failing FCS requirements.
• Confusing EAL with security strength - assuming a higher EAL automatically means a more secure product.
• No assurance-continuity plan, so the certificate lapses in relevance the moment the product is patched.

Common Criteria mapped to other frameworks

Common Criteria sits within a wider assurance ecosystem and is most powerful when positioned correctly against neighbouring schemes. It answers the question 'has this specific product been independently verified to meet stated security requirements at a stated rigour?', whereas management-system standards answer 'does this organisation run its security processes well?' and secure-development frameworks answer 'does this team build software using sound practices?'. The three are complementary rather than substitutable, and sophisticated procurement stacks them: an ISO/IEC 27001-certified vendor, developing under NIST SSDF practices, shipping a Common Criteria-certified product, supplies assurance at the organisational, process and product layers simultaneously. The table below clarifies the relationships and, importantly, the distinctions that stop these frameworks from being conflated.

Frequently asked questions

Need help with Common Criteria?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.