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.