Security Target (ST): Common Criteria Document Type

A Security Target (ST) is the central document in a Common Criteria (ISO/IEC 15408) evaluation. It defines what the product claims to do, what threats it counters, and what the evaluator must check. Every certified product has a published Security Target that establishes the precise scope of its certificate.

Summary: A Security Target is a vendor-written document describing a specific product’s security claims. It defines the boundary of the evaluation, lists the threats addressed, and states the security functional requirements (SFRs) the product satisfies.

ST versus PP

The two foundational documents in Common Criteria are easy to confuse:

A Protection Profile (PP) is a vendor-independent template of security requirements for a category of products (firewalls, smart cards, operating systems). It says “any product in this category should meet these requirements”.
A Security Target (ST) is a product-specific document that describes one vendor’s actual product and what it claims to satisfy. It may claim conformance to a PP, in which case the ST inherits the PP’s requirements; or it may stand alone with a custom set of requirements.

In short, a PP is “what a product of this type should do”; an ST is “what this specific product does”.

Structure of a Security Target

ISO/IEC 15408 Part 1 specifies the required ST structure. A typical ST contains the following sections, in this order:

ST introduction: identifies the ST and the Target of Evaluation (TOE), provides an overview of the product.
Conformance claims: states which version of Common Criteria the ST conforms to, and whether the ST claims conformance to one or more Protection Profiles.
Security problem definition: lists the threats the TOE counters, the organisational security policies it enforces, and the assumptions about its environment.
Security objectives: states the security goals for the TOE and for the operational environment, traceable to the threats and assumptions above.
Security requirements: lists the Security Functional Requirements (SFRs) the TOE implements and the Security Assurance Requirements (SARs) the evaluation must meet (typically corresponding to a chosen EAL).
TOE summary specification: explains how the TOE implements the SFRs.

Some schemes and Protection Profiles add additional sections for traceability matrices, glossary terms, or scheme-specific declarations.

What the TOE boundary means

The Target of Evaluation (TOE) is the part of the product that the certificate covers. The TOE is rarely identical to the entire product as shipped: it usually excludes operational environment components such as the host operating system, network infrastructure, or external authentication systems. Anything outside the TOE boundary is not guaranteed by the certificate.

ST writers typically describe the TOE boundary with both:

A physical scope: which components, files, or hardware modules are inside the boundary; and
A logical scope: which security functions are covered, such as access control, audit, cryptographic operation, and data protection.

Reading the TOE description carefully is the single most important step when evaluating whether a certificate applies to a use case. A product certified for “the cryptographic engine in firmware version 2.4 running on hardware revision A” does not by itself cover the same product running newer firmware or different hardware.

SFRs and the Common Criteria functional catalogue

The Security Functional Requirements (SFRs) in an ST are drawn from Common Criteria Part 2, the functional components catalogue. Each SFR has a structured identifier such as FCS_COP.1 (Cryptographic Operation) or FAU_GEN.1 (Audit data generation). An ST may include the SFR verbatim from Part 2, or it may apply allowed operations such as assignment, selection, refinement, or iteration to tailor the requirement to the product.

The full catalogue is large, with families covering audit, communication, cryptographic support, user data protection, identification and authentication, security management, privacy, TOE access, and trusted path / channels. ST authors typically pick a subset that matches the product’s security functions and the threats listed in the security problem definition.

How to find a Security Target

Every certified product’s Security Target is published as part of the certificate package by the issuing scheme. National scheme registries link to the ST PDF directly from the certificate page. The Common Criteria Portal lists STs for CCRA-recognised certifications; EUCC, SESIP, and other schemes publish through their own registries.

NenkinTracker archives the published Security Target for every indexed product and tracks document version history when an ST is updated as part of a maintenance procedure or re-evaluation.

Frequently asked questions

What is a Security Target in Common Criteria?

A Security Target (ST) is a vendor-written document that defines what a specific product claims to do under Common Criteria evaluation. It identifies the Target of Evaluation, lists the threats addressed, states the Security Functional Requirements the product satisfies, and declares the assurance level the evaluation must meet. The ST is the central document that establishes the precise scope of a product's certificate.

What is the difference between a Security Target and a Protection Profile?

A Protection Profile is vendor-independent: it defines what any product in a category should do (firewalls, smart cards, operating systems). A Security Target is product-specific: it describes one vendor's actual product and what it claims to satisfy. An ST may claim conformance to a PP, in which case it inherits the PP's requirements; or it may stand alone with a custom requirement set.

What sections does a Security Target contain?

ISO/IEC 15408 Part 1 specifies six required sections, in order: ST introduction (identifying the TOE and overview), conformance claims (CC version and any PP claimed), security problem definition (threats, policies, assumptions), security objectives (goals for the TOE and environment), security requirements (the SFRs and SARs the TOE must meet), and TOE summary specification (how the TOE implements the SFRs).

What is an SFR in a Security Target?

SFR stands for Security Functional Requirement. SFRs are drawn from Common Criteria Part 2, the functional components catalogue, and have structured identifiers such as FCS_COP.1 (Cryptographic Operation) or FAU_GEN.1 (Audit data generation). They state the security behaviours the product must implement. ST authors can include SFRs verbatim or apply allowed operations (assignment, selection, refinement, iteration) to tailor them to the product.

What is the TOE in a Security Target?

TOE stands for Target of Evaluation, the part of the product that the certificate covers. The TOE is rarely the entire product as shipped: it usually excludes operational environment components such as the host operating system, network infrastructure, or external authentication services. Anything outside the TOE boundary is not guaranteed by the certificate, which makes reading the TOE description the single most important step before relying on a CC certificate.

Where can I find a product's Security Target?

Every certified product's Security Target is published as part of the certificate package by the issuing scheme. National scheme registries link to the ST PDF directly from the certificate page. The Common Criteria Portal lists STs for CCRA-recognised certifications, and EUCC, SESIP, and other schemes publish through their own registries. NenkinTracker also archives and tracks version history for every Security Target it indexes.