ISO/IEC 15408 (Common Criteria): ISO/IEC 15408 – Tutorial (about 60 minutes)

ISO/IEC 15408, known worldwide as the Common Criteria, is the international standard for describing the security properties of an IT product precisely and having an independent laboratory check them. Product vendors use it to prove security claims to government and enterprise buyers, evaluation laboratories and national certification bodies use it to run evaluations, and buyers use its documents to decide whether a product fits their risks. After this tutorial you will be able to read a Security Target, explain what an evaluation assurance level does and does not tell you, plan the main steps of an evaluation, and judge what a "Common Criteria certified" claim really covers.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the standard is owned by ISO and IEC through joint technical committee JTC 1/SC 27 (Information security, cybersecurity and privacy protection). Its newest ISO edition is the five-part ISO/IEC 15408:2026 series (parts 15408-1 to 15408-5), published in April and May 2026 together with the companion evaluation methodology ISO/IEC 18045:2026. These replace the 2022 editions, which ISO has withdrawn. Certification practice has not yet moved to the 2026 text: the Common Criteria Recognition Arrangement (CCRA) still publishes, free of charge, "CC:2022 Revision 1" (November 2022, the same content as ISO/IEC 15408:2022) and CEM:2022 (the same content as ISO/IEC 18045:2022), with a mandatory errata and interpretations document (version 1.2 is the latest). CC:2022 replaced CC version 3.1 Revision 5 (2017): new evaluations against version 3.1 could only be started until 30 June 2024, and Security Targets that claim CC:2022 conformance on the basis of protection profiles certified under version 3.1 are accepted until 31 December 2027. This tutorial teaches the CC:2022 model that evaluations use today; the 2026 ISO edition keeps the same five-part structure, and the CCRA had announced no CC version or transition policy based on it. Verified 2026-10-29 against the Common Criteria Portal publications page, the foreword of CC:2022 Part 5 and national standards-body catalogue entries for the 2026 editions (the ISO catalogue itself could not be read automatically), so check the Common Criteria Portal for any newer CC version.

Who it is for: security engineers and product managers at companies that build security-relevant products (network devices, operating systems, smart cards, databases, mobile devices, cloud components); compliance and procurement staff who must buy or approve evaluated products; and testers or consultants who are considering work in an evaluation laboratory. Prerequisites: none beyond general IT literacy. Familiarity with basic security ideas such as authentication, encryption and audit logs helps but is not required, because every term is explained.

By the end of this tutorial:

You will be able to explain why the Common Criteria exist and what problem they solve for buyers and vendors.
You will be able to define the core vocabulary: TOE, TSF, Security Target, Protection Profile, SFR, SAR, package and EAL.
You will be able to describe the five parts of ISO/IEC 15408 and how the companion methodology ISO/IEC 18045 fits in.
You will be able to trace a security claim from a threat to a security objective to a functional requirement.
You will be able to outline the evaluation process, the roles involved and the documents it produces.
You will be able to interpret a certificate correctly, including its scope, assurance level and recognition limits.
You will be able to relate the Common Criteria to neighbouring schemes such as FIPS 140-3, IEC 62443 and the EU EUCC scheme.

Lesson 1 – Origins, purpose and scope

The problem: trusting a product you cannot inspect

Imagine you run security for a ministry and need to buy a firewall. Every vendor says its product is secure. You cannot read their source code, you do not have time to test every feature, and even if you did, you would not know whether you had tested the right things. The vendor faces the mirror image of this problem: it wants to sell to many governments, and each of them might ask for a different set of tests and documents. Both sides need a shared language for writing down security claims and a trusted, repeatable way to check those claims. That is exactly what ISO/IEC 15408 provides.

The standard does two jobs. First, it gives a structured catalogue of requirements so that a claim such as "administrators must log in before changing settings" is written in a precise, comparable form instead of marketing prose. Second, together with its methodology, it defines how an independent evaluator gathers evidence that the claims are true and that the product was built and delivered with appropriate care. The result is not a promise that the product has no weaknesses. It is a documented level of confidence, called assurance, that a specified version in a specified configuration meets a specified set of claims.

From national criteria to one international standard

Before the Common Criteria, several countries had their own evaluation criteria. The United States had the Trusted Computer System Evaluation Criteria (the "Orange Book"), several European countries had the Information Technology Security Evaluation Criteria (ITSEC), and Canada had its own criteria as well. A vendor selling internationally had to be evaluated several times. In the 1990s the government security agencies of Canada, France, Germany, the Netherlands, the United Kingdom and the United States combined these approaches into a single set of criteria. Version 1.0 appeared in the mid-1990s, version 2 followed later in that decade and was adopted by ISO and IEC as ISO/IEC 15408 in 1999. Version 3.1 was released in 2006 and revised several times up to Revision 5 in 2017.

CC:2022 marked a change in how the text is produced. Earlier versions were written by the participating government agencies and then adopted by ISO/IEC. The 2022 version was developed first as an ISO/IEC project and then republished by the CCRA. The content is the same; the difference is that the CCRA version is free to download from the Common Criteria Portal, while the ISO/IEC version is sold through ISO, IEC and national standards bodies. In 2026 ISO and IEC published a revised edition of all five parts and of ISO/IEC 18045. Until the CCRA adopts that text as a new CC version, evaluations under the arrangement continue to use CC:2022 and CEM:2022, so that is the version described in this tutorial.

What changed in CC:2022

The 2022 revision did not throw away the familiar model. It brought into the standard several practices that had grown up around version 3.1 in annexes, addenda and scheme rules. The most important changes are:

two new parts: Part 4, a framework for writing evaluation methods and evaluation activities, and Part 5, which collects the pre-defined assurance packages, including the seven evaluation assurance levels;
a new conformance type, exact conformance, which stops a product claim from going beyond the scope of the protection profile it claims;
"direct rationale" protection profiles, which replace the old low-assurance protection profiles;
multi-assurance evaluation, where different parts of the security functionality can be evaluated at different assurance;
a formal treatment of composition, so that results for one evaluated component (for example a chip) can be reused when evaluating a product built on top of it;
revised terminology and some new functional and assurance requirements.

Scope: what the standard covers and what it does not

ISO/IEC 15408 applies to IT products: hardware, firmware, software or a combination. It is not a management system standard like ISO/IEC 27001, so it does not certify an organisation or its processes as a whole. It does look at parts of the developer's process, such as configuration management and delivery, but only as evidence about one product. It also deliberately leaves some topics outside its scope: it does not define how to manage evaluation schemes, it does not tell a country how to accredit laboratories, it does not evaluate the mathematical strength of cryptographic algorithms, and it does not cover physical, personnel or administrative security measures of the user's organisation except as assumptions about the product's environment.

Lesson 2 – Key concepts and vocabulary

The Common Criteria have a vocabulary of their own, and most confusion comes from misreading it. The terms below are explained in plain words; the official definitions are in Part 1.

Target of evaluation (TOE) – the exact product, or part of a product, that is being evaluated, together with its guidance documents. It is defined by version, configuration and boundary, so "Router OS 9.4 on hardware models A and B, excluding the web dashboard" is a TOE, while "our router" is not.
TOE security functionality (TSF) – everything inside the TOE that must work correctly for the security requirements to hold: the code, hardware and firmware that enforce the claims.
Operational environment – everything around the TOE that it relies on but does not control, such as the underlying hardware for a software TOE, the network, and the people who administer it.
Security problem definition (SPD) – the statement of what the security functionality must deal with, made of three ingredients: threats, organisational security policies and assumptions.
Threat – an adverse action by a threat agent (an attacker, or sometimes a careless user) against an asset the TOE protects.
Organisational security policy (OSP) – a rule imposed by the organisation that will use the product, for example a requirement to display a warning banner at login or to use nationally approved cryptography.
Assumption – something taken as true about the operational environment, for example that the device is installed in a locked room or that administrators are trained and trustworthy.
Security objective – a statement of intent to counter the threats, enforce the policies and uphold the assumptions. Objectives are split into those for the TOE and those for the operational environment.
Security functional requirement (SFR) – a precise requirement on what the TSF must do, written using components from Part 2, such as generating audit records or authenticating users.
Security assurance requirement (SAR) – a requirement on the evidence and evaluator actions that show the SFRs are met, written using components from Part 3, such as testing, design description or vulnerability analysis.
Security Target (ST) – the document that states the security claims for one specific TOE: its description, SPD, objectives, SFRs, SARs and a summary of how the product meets the SFRs. It is the single most important document in an evaluation.
Protection Profile (PP) – a reusable, implementation-independent statement of security needs for a whole type of product, for example "network device" or "smart card". A vendor's ST can claim conformance to one or more PPs.
PP-Module and PP-Configuration – a PP-Module adds requirements for an optional technology to one or more base PPs; a PP-Configuration combines specific PPs and PP-Modules into one package that an ST can claim.
Package – a named set of SFRs or SARs that are often used together. Functional packages might describe a protocol; assurance packages describe a depth of evaluation.
Evaluation assurance level (EAL) – one of seven pre-defined assurance packages, from EAL1 to EAL7, each requiring more evidence and more rigorous evaluator work than the one below.
Augmentation – adding assurance components to a package beyond what it contains, shown with a plus sign, as in "EAL4+" or "EAL4 augmented with ALC_FLR.2".
Evaluation, evaluator and evaluation authority – the evaluation is the assessment of a PP, ST or TOE against the criteria; the evaluator is the accredited laboratory doing the work; the evaluation authority (often called the certification body or scheme) oversees the laboratories and issues certificates.
Sponsor and developer – the sponsor requests and pays for the evaluation; the developer builds the product and provides the evidence. Often they are the same company.

How the concepts link together

These terms form a chain of reasoning that runs through every PP and ST. The SPD says what problem exists. The security objectives say what will be done about it and who is responsible: the product or its environment. The SFRs translate the product objectives into precise, testable requirements. The SARs say how much evidence is needed to trust that the SFRs are met. Finally, the TOE summary specification explains how the product actually implements each SFR. At each step the author must give a rationale showing that nothing has been lost: every threat is countered, every objective is covered by requirements, and every requirement traces back to a reason.

Figure 1 – The chain of rationale in a Security Target, from the security problem to the evidence an evaluator checks.

Notice how assumptions flow mostly into objectives for the environment. If an ST assumes administrators are trustworthy, the product is not expected to defend against a malicious administrator, and the customer must provide that protection through hiring, training and supervision. Reading the assumptions section is therefore the fastest way to learn what a certificate leaves to you.

Lesson 3 – Structure of the standard

Five parts and a methodology

The standard is a set of documents, each with a clear job. The criteria parts say what can be required; the methodology says how an evaluator checks it.

Part 1 – Introduction and general model: the concepts, terms, the model of TOE and environment, how to write PPs, PP-Modules, PP-Configurations and STs, conformance types, packages, evaluation results, multi-assurance and composition.
Part 2 – Security functional components: the catalogue of functional building blocks used to write SFRs.
Part 3 – Security assurance components: the catalogue of assurance building blocks used to write SARs, including the criteria for evaluating PPs, PP-Configurations and STs.
Part 4 – Framework for the specification of evaluation methods and activities: rules for writing technology-specific evaluation activities derived from the general methodology. It does not contain such activities itself.
Part 5 – Pre-defined packages of security requirements: the evaluation assurance levels, the composed assurance packages and several other assurance packages.
ISO/IEC 18045 (CEM) – Methodology for IT security evaluation: the evaluator's rule book. It breaks each assurance component into numbered work units, each producing a pass, fail or inconclusive verdict.

Figure 2 – How the five parts of ISO/IEC 15408 and the ISO/IEC 18045 methodology feed the documents used in an evaluation.

The catalogue hierarchy: class, family, component, element

Parts 2 and 3 use the same four-level structure. A class groups requirements with a common broad focus. A family groups requirements within a class that share objectives but differ in emphasis or rigour. A component is the smallest selectable set and is what an author actually picks. An element is an individual requirement statement inside a component. Every item has a short identifier: the class "FIA" (identification and authentication) contains the family FIA_UAU (user authentication), whose component FIA_UAU.2 requires authentication before any other action, and that component contains element FIA_UAU.2.1. Assurance identifiers start with A, functional ones with F.

Components are written with gaps that the PP or ST author fills in through four permitted operations:

Assignment – supplying a value, such as the number of failed login attempts before lock-out.
Selection – choosing one or more options from a list given in the component.
Iteration – using the same component more than once with different values, for example one cryptographic operation for encryption and another for hashing.
Refinement – adding detail that narrows the requirement without weakening it.

Components can also have dependencies: some only make sense if another component is also included, and the author must either include it or justify why not. When nothing in the catalogue fits, an author may define an extended component, written in the same style and included in an "extended components definition" section of the PP or ST.

The functional classes (Part 2)

Part 2 has eleven classes. In short: FAU security audit; FCO communication (proof of origin and receipt); FCS cryptographic support; FDP user data protection (access control, information flow, integrity of stored data); FIA identification and authentication; FMT security management (roles, management functions, security attributes); FPR privacy (anonymity, pseudonymity, unlinkability, unobservability); FPT protection of the TSF (self-tests, secure failure, protection of TSF data, trusted update and similar); FRU resource utilisation (fault tolerance, priority, quotas); FTA TOE access (session locking, login banners, session limits); and FTP trusted path and channels.

The assurance classes (Part 3)

Part 3 groups assurance into classes that each look at the product from a different angle:

APE – evaluation of a Protection Profile; ACE – evaluation of a PP-Configuration; ASE – evaluation of a Security Target. These check that the claims documents are complete and consistent.
ADV development – design evidence such as the functional specification of interfaces, the TOE design, the security architecture and, at higher levels, the implementation representation (source code or hardware drawings).
AGD guidance documents – preparation procedures for installation and operational user guidance.
ALC life-cycle support – configuration management, delivery, development security, life-cycle definition, TOE development artefacts, tools and techniques, and flaw remediation (ALC_FLR).
ATE tests – coverage and depth of the developer's tests, plus independent testing by the evaluator.
AVA vulnerability assessment – the evaluator's search for exploitable weaknesses, from a survey of public information (AVA_VAN.1) to advanced methodical analysis (AVA_VAN.5). Each step up assumes a more capable attacker; the CEM rates attackers by attack potential (expertise, time, knowledge, access and equipment), on a scale from basic through enhanced-basic and moderate to high. AVA_VAN.1 and AVA_VAN.2 assume basic attackers, AVA_VAN.3 enhanced-basic, AVA_VAN.4 moderate and AVA_VAN.5 high.
ACO composition – assurance for a TOE made of components that have themselves been evaluated.

Pre-defined packages (Part 5)

Picking dozens of assurance components one by one would make products hard to compare, so Part 5 provides ready-made packages. The best known are the seven EALs. Each higher level includes everything below it and adds depth: more design detail, more test coverage, stronger development controls and a vulnerability analysis that assumes a more capable attacker.

Figure 3 – The seven evaluation assurance levels: each level contains the one below and demands deeper evidence and analysis.

As a rough guide: EAL1 suits cases where some confidence is useful but threats are not serious, and needs little developer co-operation. EAL2 adds a security architecture description, a basic design description, developer testing and a vulnerability analysis against basic attackers. EAL3 adds more test coverage and development environment controls. EAL4 is generally regarded as the highest level that is economically practical for an existing commercial product line, and it adds a look at part of the implementation representation and a vulnerability analysis against attackers with enhanced-basic attack potential. EAL5 to EAL7 require increasingly formal design descriptions, assume moderate (EAL5) or high (EAL6 and EAL7) attack potential, and are used mainly for specialised products such as smart card chips or high-assurance separation kernels, where the product is designed for evaluation from the start.

Part 5 also contains the composed assurance packages CAP-A, CAP-B and CAP-C for composed TOEs, a composite product package for products built on an evaluated base (such as an application on a certified chip), and packages for evaluating PPs and STs on their own, in both "standard" and "direct rationale" forms.

Conformance types

When an ST claims a PP, the PP decides how closely the ST must follow it. CC:2022 has three conformance types:

Strict conformance – the ST must include everything in the PP and may add further requirements; its claims must be at least as restrictive.
Demonstrable conformance – the ST may express things differently, provided it shows its solution is equivalent to or more restrictive than the PP's.
Exact conformance – the ST must contain exactly the PP's requirements, using only the options the PP itself permits; it cannot add unrelated claims. This makes evaluations of the same product type directly comparable and is used by collaborative PPs and several national schemes.

Lesson 4 – How it works in practice

The roles

Part 1 describes three main audiences, and in practice there are a few more actors:

Consumers or risk owners – the organisations that will use the product. They write or select PPs that state their needs, and they read STs and certification reports to decide whether a product fits.
Developers – the people who build the product, write the ST (often with consultants) and provide the design, test, guidance and life-cycle evidence.
Evaluators – staff of an evaluation laboratory, also called an IT security evaluation facility, accredited by a national body and licensed by a scheme.
Evaluation authority or certification body – a government or government-approved body that runs a national scheme, oversees evaluations, reviews the laboratory's findings and issues certificates.
PP authors – often government agencies, industry groups or international technical communities that write PPs for a product category.

The life cycle of an evaluation

An evaluation is a project, typically lasting several months or more, depending on the assurance level, the product's complexity and how well prepared the evidence is. The usual sequence is:

Decide the target market and scheme. Which customers require the certificate, and which scheme do they recognise? This decides whether you need a specific PP, an EAL, or both.
Choose the claims. Select the PP or PP-Configuration to claim, or decide on an EAL for a custom ST. Check whether the scheme requires particular evaluation activities.
Define the TOE boundary. State precisely which hardware models, software versions and configuration are in scope, which interfaces exist, and what is excluded.
Write the Security Target. Complete the SPD, objectives, SFRs with all operations filled in, SARs, and the TOE summary specification.
Prepare evidence. Depending on the SARs: functional specification, design documents, security architecture description, guidance, configuration management records, delivery procedures, developer test plans and results.
Contract a laboratory and register with the scheme. The scheme usually accepts the project formally and assigns a certifier to monitor it.
Evaluation work. The evaluators first check the ST (the ASE class) because everything else depends on it, then work through each assurance class using the CEM work units and any required evaluation activities. They run their own tests and a vulnerability analysis, including penetration testing where the assurance level requires it.
Observation reports and fixes. Problems found along the way are reported to the developer, who corrects documents or product. The evaluators re-check.
Evaluation technical report (ETR). The laboratory documents its verdicts and submits the report to the certification body.
Certification. The certification body reviews the work, publishes a certification report and issues the certificate. The product, ST and report are listed publicly, for example on the Common Criteria Portal.

Figure 4 – The main exchanges between developer, laboratory and certification body during a Common Criteria evaluation.

What a Security Target contains

Because the ST is the heart of everything, it helps to know its standard sections:

ST introduction – unique references for the ST and the TOE, a short TOE overview for buyers, and a fuller TOE description including the physical and logical boundary.
Conformance claims – the edition of the criteria used, any PPs, PP-Configurations or packages claimed, and the conformance type.
Security problem definition – threats, OSPs and assumptions.
Security objectives – for the TOE and for the operational environment, with a rationale tracing them to the SPD (or, in the direct rationale approach, a mapping straight from SFRs to the SPD).
Extended components definition – any components not taken from Parts 2 or 3.
Security requirements – SFRs and SARs with operations completed, plus rationales and dependency analysis.
TOE summary specification – how the product meets each SFR, in enough detail for a buyer to understand the mechanisms.

Evaluation activities and supporting documents

The CEM is generic: it describes what an evaluator must check for any product. For a product type with a well-known technology, generic checks can be too vague; two laboratories might test a TLS implementation very differently. Part 4 therefore provides a framework for writing evaluation activities, which are specific test and analysis steps derived from CEM work units and grouped into evaluation methods. Collaborative PPs usually come with a "supporting document" that contains these activities, so every laboratory tests the same things in the same way. This is the main reason exact conformance and evaluation activities go together: they make results repeatable and comparable.

After the certificate: assurance continuity

Products change. A certificate is for one version, so schemes offer assurance continuity. For minor changes, the developer submits an impact analysis and the certification body may issue a maintenance addendum that extends the certificate to the new version without a new evaluation. For major changes, a partial or full re-evaluation is needed. Separately, the assurance component ALC_FLR (flaw remediation) checks that the developer has procedures for receiving vulnerability reports, fixing flaws and telling users. ALC_FLR is not part of any EAL, which is why it is one of the most common augmentations.

Lesson 5 – Assessment, certification and compliance

Who can evaluate and certify

You cannot self-certify against the Common Criteria in any meaningful way. Certification happens inside a national evaluation scheme run by a government body or a body the government appoints. Laboratories are normally accredited for testing competence under ISO/IEC 17025 and then licensed by the scheme; certification bodies are commonly accredited under ISO/IEC 17065 or established by law. Examples of schemes include the US National Information Assurance Partnership (NIAP), Germany's BSI scheme, France's ANSSI scheme, the Canadian scheme run by the Canadian Centre for Cyber Security, and schemes in Japan, Korea, Spain, India, Singapore and other countries.

Mutual recognition: the CCRA

The reason a certificate from one country is valuable elsewhere is the Common Criteria Recognition Arrangement (CCRA). Members agree to recognise certificates issued by each other's certification bodies within agreed limits. There are two kinds of member: authorising members, which operate a scheme and issue certificates, and consuming members, which recognise certificates but do not issue them. On 2026-10-29 the CCRA listed 36 members: 18 authorising and 18 consuming.

The recognition has limits that matter. Under the 2014 arrangement, members recognise certificates for evaluations against collaborative Protection Profiles (cPPs), and for other evaluations only the assurance components up to EAL2 plus flaw remediation (ALC_FLR). A product certified at EAL4+ in one country is still certified at EAL4+, but other CCRA members are only obliged to recognise the EAL2-level part of that assurance. Higher assurance is recognised between some countries through other agreements.

Europe: SOG-IS and EUCC

In Europe, the SOG-IS mutual recognition agreement among several national schemes has long recognised certificates up to EAL4 in general, and higher levels in specific technical domains such as smart cards and similar devices. Building on that practice, the European Union adopted the European Common Criteria-based cybersecurity certification scheme (EUCC) under the EU Cybersecurity Act, through Commission Implementing Regulation (EU) 2024/482, which has applied since 27 February 2025. EUCC is voluntary unless other EU or national law makes it mandatory, uses ISO/IEC 15408 and ISO/IEC 18045 as its technical basis, and issues EU-wide certificates at two assurance levels named "substantial" and "high". The level is tied to the depth of vulnerability analysis: the regulation maps AVA_VAN.1 or 2 to substantial and AVA_VAN.3, 4 or 5 to high. EUCC also adds rules on vulnerability handling and certificate validity that go beyond the standard itself.

The United States: Protection Profile-based evaluation

NIAP, the US scheme, does not accept evaluations against EALs for new products. It evaluates only against NIAP-approved PPs (many of them cPPs), with exact conformance and the PP's evaluation activities, and lists results on its Product Compliant List. US national security systems policy requires evaluated products for many categories, which is why the scheme has such influence on vendors. The lesson: always check what the buyer's scheme accepts before you choose your claims.

Reading a certificate correctly

When someone says a product is "Common Criteria certified", ask four questions:

Which TOE? Check the exact version, hardware models and evaluated configuration in the certification report. A later version or a different configuration is not covered unless assurance continuity applies.
Which claims? Read the ST's conformance claims and SFRs. A high EAL with a narrow ST may cover less of what you care about than a lower EAL with a broad PP.
What assurance? The EAL or PP-defined SARs, and any augmentation, tell you the depth of evaluation, not the strength of the product's features.
What did it assume? The assumptions and objectives for the environment tell you what your organisation must provide.

Certificates are snapshots. New attack techniques appear after certification, and schemes limit how long certificates stay on the active list. Treat a certificate as strong evidence about one version at one point in time, not as a permanent guarantee.

Evaluating PPs

Protection Profiles can be evaluated and certified on their own using the APE class (and PP-Configurations using ACE). A certified PP has been checked for consistency and completeness, so STs that claim it start on solid ground. Packages, by contrast, are not evaluated separately; they are checked as part of the PP or ST that uses them.

Lesson 6 – Worked example: evaluating a VPN gateway

To tie the ideas together, follow a fictional mid-sized vendor, Harbourline Networks, through its first evaluation. Harbourline makes a firewall and VPN gateway appliance called Harbour Gate. Its sales team has lost two government tenders because the product had no Common Criteria certificate, and a large European bank has asked for one too.

Step 1 – Market and scheme

The government customers are in a country whose scheme follows the PP-based approach. The bank in Europe expects an EUCC certificate. Harbourline's security lead learns that a published collaborative PP for network devices exists, together with a PP-Module for VPN gateway functions, and the laboratory confirms that both certification bodies will accept an evaluation against them. She decides to claim the base PP plus the VPN PP-Module in a single PP-Configuration with exact conformance. That choice fixes most of the SFRs and SARs and brings ready-made evaluation activities with it.

Step 2 – Defining the TOE

Harbourline's first draft said the TOE was "Harbour Gate". The laboratory's pre-assessment pushed back: the TOE must be specific. The final definition is "Harbour Gate OS 7.2 running on appliance models HG-200 and HG-800, in the hardened configuration described in the evaluated configuration guide". The cloud management portal is excluded because it is a separate service the customer may not use; so are optional plug-ins. The physical boundary is the appliance; the logical boundary lists the interfaces: the administrative console, the HTTPS management interface, the VPN tunnels and the syslog export.

Step 3 – The security problem

Because the PP is claimed with exact conformance, the SPD comes from the PP, but the team still studies it to make sure the product fits. Typical threats in such a PP include attackers trying to gain administrative access over the network, intercepting or changing management and VPN traffic, installing modified firmware, and going unnoticed by tampering with logs. Typical assumptions include physical protection of the appliance, trusted and trained administrators, and no general-purpose software installed on the device. An OSP requires a configurable access banner. The security lead notes for the sales team that the "trusted administrator" assumption means the certificate does not cover insider abuse by administrators.

Step 4 – Requirements

The SFRs include audit generation (FAU), cryptographic key management and operations (FCS), identification and authentication of administrators (FIA), management functions and roles (FMT), self-tests and protection of stored secrets (FPT), session lock-out and banners (FTA), and trusted channels for management and log export (FTP). Some come from extended components defined in the PP, for example for verifying firmware updates before installation and for specific protocols such as TLS and IPsec. Harbourline's job is to complete every selection and assignment allowed by the PP: which TLS versions and cipher suites, which key sizes, how many failed logins trigger lock-out, which events are audited. Each choice must be something the product really does in the evaluated configuration.

The SARs are those required by the PP: an ST evaluation, a basic functional specification, guidance, configuration management and delivery, independent testing guided by the evaluation activities, and a vulnerability survey of public sources. Because exact conformance allows only the SFRs and SARs the PP specifies, Harbourline cannot simply add ALC_FLR to this ST. It still sets up a documented process for receiving, fixing and announcing vulnerabilities, because the EUCC scheme imposes vulnerability-handling duties on certificate holders and its government customers expect the same.

Step 5 – Evidence and the summary specification

The engineering team writes the TOE summary specification, explaining for each SFR which mechanism implements it: for example, firmware images are signed with an ECDSA key held at the build server, and the appliance verifies the signature before installing. They produce an administrator guide for the evaluated configuration, which turns out to be valuable for customers as well. Configuration management evidence shows how releases are built and labelled; delivery evidence shows how appliances and update files reach customers without tampering.

Step 6 – Evaluation

The laboratory starts with the ST and finds two issues: an SFR selection lists a cipher suite the product no longer supports, and the TOE description mentions the cloud portal in a way that suggests it is in scope. Both are fixed. During testing, the evaluators follow the evaluation activities to check protocol behaviour, including attempts to negotiate weak algorithms and malformed handshakes. They find that the HTTPS interface accepts an older protocol version when a hidden debug setting is enabled. Harbourline removes the setting from the evaluated configuration and documents it in the guidance. The vulnerability survey of public databases finds a known flaw in an open-source library; Harbourline patches it and the evaluators re-test.

Step 7 – Certification and afterwards

The laboratory sends its ETR to the certification body, which reviews it, asks a few questions and issues the certificate with a public certification report. Harbour Gate OS 7.2 now appears on the relevant product lists. Six months later, Harbourline releases version 7.3 with a small bug fix. It submits an impact analysis showing no changes to security functions, and the certification body issues a maintenance addendum. A year later, version 8.0 replaces the VPN engine; that change affects SFRs, so a re-evaluation is planned.

The buyer's side

A procurement officer at the ministry reviews the certification report. She confirms the evaluated version is the one being offered, notes the environment objectives (locked server rooms, vetted administrators, a separate log server), and checks that her own configuration standard matches the evaluated configuration guide. The certificate does not replace her own risk assessment; it gives her verified facts to feed into it.

Lesson 7 – Relationship to other standards and frameworks

The Common Criteria sit in a family of security standards. Some are companions, some overlap, and some are often required alongside them. Understanding the boundaries avoids buying or building the wrong evidence.

Figure 5 – ISO/IEC 15408 with its methodology, the schemes that apply it, and neighbouring standards that are often used alongside it.

Standard or scheme	What it covers	How it relates to ISO/IEC 15408
ISO/IEC 18045 (CEM)	The evaluation methodology: work units for each assurance component	The essential companion. ISO/IEC 15408 says what is evaluated; ISO/IEC 18045 says how evaluators check it.
FIPS 140-3 / ISO/IEC 19790	Security requirements and validation testing for cryptographic modules, run in North America by the Cryptographic Module Validation Program	Narrower and deeper on cryptography. Many products need both: a module validation for the crypto inside, and a CC evaluation for the product as a whole. CC evaluations often rely on the crypto validation.
ISO/IEC 27001	Certification of an organisation's information security management system	Certifies an organisation, not a product. A vendor may hold both; development security evidence for ALC can draw on ISMS practices but is checked separately.
IEC 62443-4-1 and 4-2	Secure development process and technical security requirements for industrial automation components	A sector-specific alternative for operational technology products, with its own security levels and certification programmes. Similar idea of product requirements, but a different catalogue and assessment model.
EUCC (Regulation (EU) 2024/482)	EU-wide cybersecurity certification of ICT products	A legal certification scheme built on ISO/IEC 15408 and 18045, adding EU rules on assurance levels, vulnerability handling and certificate management.
ISO/IEC TR 15446	Guidance on writing Protection Profiles and Security Targets	A helper document: explains how to draft the claims documents that ISO/IEC 15408 defines.

Two further relationships are worth noting. Secure development frameworks such as the NIST Secure Software Development Framework describe practices for building software safely; they produce good evidence for the ALC and ATE classes but do not themselves produce a certificate. And newer product security regulations, such as the EU Cyber Resilience Act, set obligations for products placed on the market; product evaluation schemes based on the Common Criteria may be one way to demonstrate some of those obligations, depending on how the regulation's harmonised standards and schemes develop.

Common pitfalls and best practices

Pitfalls

Treating the EAL as a security score. A higher EAL means deeper evaluation of the claims, not stronger features. Two products at the same EAL can have completely different SFRs.
Ignoring the TOE boundary. Buyers deploy a different version, enable excluded features or skip the evaluated configuration guide, and then assume the certificate still applies.
Choosing claims before checking the scheme. Vendors evaluate against an EAL with a custom ST, then discover the buyer's scheme only accepts specific PPs, or that recognition abroad stops at EAL2.
Writing the ST as marketing. Vague SFRs, missing assignments or features the product does not support in the evaluated configuration lead to long rounds of observation reports.
Starting evidence late. Design, guidance and configuration management evidence written after the fact is expensive and often inconsistent with the product.
Forgetting the assumptions. Organisations fail to provide the environment objectives (physical protection, trusted administrators, separate log servers) that the evaluation took for granted.
No plan for updates. A certificate quickly becomes stale if each release is not covered by maintenance or re-evaluation and flaws are not handled through a defined process.

Best practices

Start from the buyer. Identify which schemes, PPs and assurance levels your target customers accept before writing anything.
Prefer recognised Protection Profiles. Claiming a cPP or scheme-approved PP gives comparable results, wider recognition and ready-made evaluation activities.
Define a tight, honest TOE. Exclude what you cannot support, and make the evaluated configuration easy for customers to reproduce.
Do a gap analysis early. Map each SFR and SAR to existing product behaviour and documents; fix gaps in the product before the laboratory finds them.
Build evidence into the development process. Keep design documents, test records and build records current as part of normal engineering, so evaluation becomes a check rather than a rewrite.
Plan assurance continuity. Agree with the scheme how minor releases will be handled, and set up flaw remediation that meets ALC_FLR.
Read certificates in full. As a buyer, read the ST and certification report, especially the TOE description, assumptions and evaluated configuration.

Summary and key takeaways

ISO/IEC 15408 (the Common Criteria) is a language for writing product security claims plus a framework for independently evaluating them; evaluations today use CC:2022 Revision 1 (free from the CCRA, the same as ISO/IEC 15408:2022), while ISO's newest edition is the five-part 2026 series.
Every evaluation is about a precisely defined TOE: a specific version and configuration with a clear boundary.
The Security Target links the security problem (threats, policies, assumptions) to objectives, functional requirements and assurance requirements through explicit rationales.
Part 2 provides functional components (what the product does), Part 3 assurance components (how much evidence), Part 5 ready-made packages such as EAL1 to EAL7, and ISO/IEC 18045 the evaluator's methodology.
Protection Profiles describe needs for a product type; exact conformance and evaluation activities make evaluations of the same type comparable.
Certificates come from national schemes, are recognised across CCRA members within limits, and in the EU can be issued under EUCC.
An EAL measures depth of evaluation, not product strength; always read the scope, claims and assumptions.
Certificates are snapshots; assurance continuity and flaw remediation keep confidence current as products change.

Reflection questions

Think of a security product your organisation uses. How would you write its TOE boundary, and which features would you exclude? Why?
Pick one threat that matters for that product. Write it as a threat statement, then derive one security objective for the product and one for its environment.
A vendor tells you its product is "EAL4+". Which documents would you ask for, and what would you look for in each before trusting the claim for your use case?
Your company wants to sell a product to government buyers in two different regions. How would you decide between a PP-based evaluation and an EAL-based one?
Which parts of your current development process already produce evidence that an evaluator would need, and where are the biggest gaps?