Skip to content
Nenkin
Sign inStart free trial

Security Target Review for Buyers: A Procurement Checklist

Summary: A Security Target review done at procurement time has different priorities than one done by an evaluator. The buyer is matching the document against a deployment, a contract, and a risk register, not against a methodology. This entry walks through each ST section from the buyer’s seat, names the patterns to flag, and shows a worked example of the kind of mismatch a procurement review can catch before signature.

Procurement teams that take a vendor’s Common Criteria, EUCC, SESIP, or PSA Certified claim at face value are buying a brochure. The certificate is a pointer; the Security Target is the document that defines what the certificate actually attests to. Reading the ST as a buyer means matching every claim, assumption, and exclusion against the real deployment before the contract is signed.

This entry is a checklist-style companion to the broader Common Criteria procurement guide. The procurement guide explains the landscape (lifecycle states, augmentations, contract clauses, mutual recognition). This entry zooms in on the document review itself. For a narrative walkthrough of the same exercise on a single ST, see Reading a Security Target as a buyer.

How a buyer reads an ST differently from an evaluator

An evaluator reads a Security Target to verify that the developer’s claims are internally consistent and that the assurance work to back them was performed. The buyer reads the same document with three different questions in mind.

  1. Does the certified configuration match what I am about to buy? SKU, firmware version, optional features, deployment shape.
  2. Do the environment assumptions hold in my environment? Physical security, trusted administrators, network topology, third-party services.
  3. Do the security claims cover the risks I am procuring against? Threats addressed, SFRs included, augmentations on the assurance package.

A buyer-side review is not pass or fail against the methodology. It is gap analysis against a specification. Every finding feeds either a clarifying question to the vendor, a risk on the procurement risk register, or a contract clause that has to be in writing before signature.

The certificate itself is a small part of this exercise. How to read a Common Criteria certificate covers the certificate-side reading; an EUCC-specific walk-through is in Anatomy of an EUCC certificate. Both feed the section-by-section ST review below.

Section-by-section walkthrough

The ST sections below follow the ISO/IEC 15408 Part 1 ordering. See the Security Target entry for the structural reference.

TOE introduction and identification

What the reviewer is checking: the exact product configuration that the evaluation tested. Vendor name, product name, SKU or part number, firmware or software version, hardware revisions, any model variants. Where a product family is involved, the ST should be explicit about which family members are inside the TOE and which are not.

Common gotchas:

  • The TOE references a version number that the vendor’s price list does not sell anymore (only a newer or older version is offered).
  • The TOE includes a hardware revision number that the procurement specification omits, leaving room for the vendor to ship a different revision under the same SKU.
  • The product family table covers several variants but the TOE applies only to one, and the variant offered in the bid is not the one evaluated.
  • Optional accessory modules are listed in the introduction but excluded from the TOE later in the document.

Procurement action: write the TOE identifier verbatim into the procurement specification, and require the vendor to deliver against it.

Conformance claims

What the reviewer is checking: which Common Criteria version the ST conforms to, which assurance package it claims (EAL or its scheme equivalent), and any Protection Profile or SESIP profile claimed. Conformance to a published Protection Profile is significant: a PP-conformant ST inherits a community-agreed requirement set rather than relying entirely on vendor-written claims.

Common gotchas:

  • The conformance claim is to an outdated CC version that the buyer’s tender criteria do not recognise.
  • The PP is claimed in a form that allows vendor refinements that materially weaken the inherited requirements (look for unusually broad assignments and selections).
  • The EAL is stated without augmentations, but augmentations were genuinely earned (or vice versa, augmentations are claimed but the evaluation did not perform them).
  • A composite assurance package is claimed without the underlying component certificates being currently valid. The CC certificate validity entry covers how to verify each layer.

Procurement action: extract the conformance claim verbatim and match against the procurement specification. Note any augmentation differences against peer products.

Security problem definition

What the reviewer is checking: the threats the TOE addresses, the organisational security policies (OSPs) it enforces, and the assumptions about the environment in which it is deployed. The assumptions are the part of the ST most often overlooked at procurement time and the part most often violated in real deployments.

Common gotchas:

  • A.PHYSICAL or equivalent: the ST assumes the product is in a physically protected location. The buyer plans to ship it to a remote site with no physical access control.
  • A.ADMIN or equivalent: the ST assumes trusted, competent administrators. The buyer has a managed-service-provider model where the operating administrator is not the buyer’s employee.
  • A.NETWORK or equivalent: the ST assumes the TOE is deployed on an isolated management network. The buyer plans to deploy on a flat shared network.
  • A threat the buyer cares about (for example, a specific supply-chain or insider threat) is not in the threat list, meaning the evaluation did not test the product’s defences against it.
  • OSPs are stated in terms the buyer’s organisation does not implement, leaving the TOE relying on a control the buyer does not actually run.

Procurement action: list each assumption and OSP and write next to it whether the buyer’s deployment satisfies it. Any “no” is a deployment risk that needs a mitigation, a workaround, or a contract clause.

Security objectives

What the reviewer is checking: the goals the TOE achieves and the goals the operational environment must achieve. The objectives bridge the threats and assumptions to the SFRs. Reading them is a cross-check that the threats listed actually map to functional behaviour the TOE provides.

Common gotchas:

  • Environment objectives carry a heavy share of the security argument (the TOE depends on the environment to do most of the security work). This is legitimate, but the buyer needs to verify that the environment provides those controls in reality.
  • Threats listed in the security problem definition are addressed only by environment objectives, not by TOE objectives. The TOE itself does not defend against them.
  • The objective rationale is thin: threats and assumptions are listed but the mapping back to objectives is sparse, suggesting the security argument has gaps.

Procurement action: trace each threat that matters to the buyer through to a TOE-side objective. If it lands only on the environment, treat it as a deployment commitment, not a product claim.

Security requirements: SFRs and SARs

What the reviewer is checking: the Security Functional Requirements the TOE implements and the Security Assurance Requirements the evaluation met. The SFRs are drawn from CC Part 2 and tailored through assignments, selections, refinements, and iterations. The SARs correspond to the EAL package plus any augmentations.

Common gotchas:

  • An SFR family the buyer expects to see (for example, FAU_GEN for audit, or FCS_COP for cryptographic operations) is absent. The TOE may not implement that capability inside the evaluated scope.
  • An SFR is present but its assignment is broad (for example, “the TOE shall provide the following cryptographic operations: [those listed in the documentation]”), leaving the operational meaning unbounded.
  • A refinement weakens an SFR rather than strengthens it (refinements should narrow or sharpen the requirement; one that loosens it is a flag).
  • Augmentations the buyer cares about (AVA_VAN.5 for high attack potential, ALC_DVS.2 for development security, ALC_FLR for flaw remediation) are missing.
  • The vulnerability assessment SAR (AVA_VAN.x) is lower than the threat model warrants.

Procurement action: map the procurement specification’s must-have security functions to specific SFRs. Note assignments that look open-ended. Confirm augmentation levels against peer products.

TOE summary specification

What the reviewer is checking: how the TOE implements each SFR. This is where the ST translates from requirements language into product behaviour, and where two superficially similar STs diverge most visibly.

Common gotchas:

  • The implementation description for a critical SFR is a single sentence, suggesting the evaluator did not probe deeply or the developer did not document well.
  • Cryptographic SFRs reference algorithms or key sizes that the buyer’s policy no longer permits.
  • The summary mentions components, libraries, or sub-systems that suggest dependencies on third-party software not covered by the certificate.
  • The TOE summary names features by marketing name rather than by technical identifier, making it hard to verify against the delivered product.

Procurement action: spot-check the implementation descriptions for the SFRs that matter most. If anything reads as marketing rather than technical, ask the vendor for a clarification in writing.

Patterns to flag

A buyer-side review tends to catch a recurring set of patterns. Each one has a corresponding remediation path; flagging them is the start of a vendor conversation, not the end of one.

TOE-SKU mismatch

The TOE in the ST is a different product, model, firmware, or hardware revision than the one in the bid. Remediation: require the bid to be amended to the certified configuration, or document a re-evaluation commitment in the contract.

Scope narrowing

The TOE matches the SKU, but the evaluated scope inside the product is smaller than the product as a whole. Remediation: confirm in writing which parts of the product are inside the assurance perimeter and which are outside; allocate compensating controls for the outside parts.

Augmentation gap

A buyer specification says “EAL4+” without naming the augmentations; the candidate’s ST claims EAL4 without augmentations or with weaker ones than peer candidates. Remediation: tighten the procurement specification to name the augmentations expected (for example, “EAL4 augmented by ALC_DVS.2 and AVA_VAN.5”), and re-bid if no candidate meets it.

Assumed-environment mismatch

The ST’s assumptions about physical security, trusted administrators, or network topology do not hold in the buyer’s deployment. Remediation: either change the deployment to satisfy the assumption, or accept the assumption is unsatisfied and add the missing control on the buyer side with documented rationale.

Composite dependency gap

The certificate sits on top of an underlying certificate (java card platform, IoT root of trust, secure element) whose own certificate is archived, expired, or not currently valid. Remediation: require the vendor to demonstrate the entire chain is current at signature, with contract clauses that trigger re-evaluation if any layer lapses.

Worked example

A hypothetical EAL4-claimed firewall is offered into a public-sector tender. The bid response cites the certificate identifier and the product name. The procurement reviewer pulls the published Security Target and works through it.

In the TOE introduction, the certified firmware is version 5.2.1. The vendor’s price list offers 5.4.x; 5.2.1 is no longer in active distribution. First finding: TOE-SKU mismatch on firmware version. The reviewer asks the vendor whether 5.4.x has been processed through maintenance against the certificate.

In the security problem definition, an assumption named A.MGMT_ISOLATED states the TOE management interface is reachable only from an isolated management network. The buyer’s environment uses a flat operations network. Second finding: assumed-environment mismatch. The reviewer notes the assumption and adds it to the risk register.

In the conformance claims, the assurance package is “EAL4”. The peer candidate from another vendor claims “EAL4 augmented by ALC_FLR.2 and AVA_VAN.4”. Third finding: augmentation gap. The peer’s vulnerability assessment is at moderate attack potential; this candidate’s is at the EAL4 baseline (enhanced-basic). For a perimeter firewall facing the public internet, the moderate level is materially closer to the threat model.

In the TOE summary specification, a high-availability clustering feature heavily advertised in the bid’s data sheet is not listed in any SFR implementation. Fourth finding: scope narrowing. The HA clustering is outside the TOE. If the deployment depends on it, the assurance claim does not extend there.

The reviewer’s memo to the procurement lead does not say “reject the bid”. It lists the four findings, the remediations available for each, and the procurement-team decision points. The buyer can ask for a maintenance update to 5.4.x, accept the management-network assumption as a deployment constraint, weight augmentations explicitly in scoring, and confirm HA clustering is compensated by another control.

That is what a buyer-side ST review produces. Not a verdict, but a structured set of findings and remediations that can survive an internal audit, an incident review, or a procurement challenge. Definitions for the acronyms above (TOE, SFR, SAR, AVA_VAN, ALC_FLR, ALC_DVS) are collected in the glossary.

Working with an independent reviewer

For high-value or high-assurance procurements, an independent advisor can pressure-test the Security Target review and the procurement specification before signature. The advisor sits buyer-side, does not take vendor referral fees, and writes findings attributable to a named person. Nenkin Procurement Advisory provides this on a buyer-only basis; the firm explicitly does not represent both sides of a single transaction.

Frequently asked questions

Why should a buyer read the Security Target rather than the certificate?
The certificate is a short attestation that an evaluation took place. It points at the Security Target for the actual claims. The Security Target is where the Target of Evaluation is identified, the environment assumptions are stated, the Security Functional Requirements are listed, and any augmentations are spelled out. Two products with similar certificate headlines can have very different Security Targets; a buyer who only reads the certificate cannot tell them apart.
What is the single most important section of an ST for a procurement reviewer?
TOE identification. It names the exact configuration that was evaluated, including SKU, firmware version, and any hardware revisions or build identifiers. If the TOE does not match the product the vendor is offering, the rest of the ST does not apply to the deployment. Every other check (scope, assumptions, SFRs, augmentations) is conditional on this one matching first.
How long does a thorough buyer-side ST review take?
Reviewing one Security Target end to end against a real procurement specification typically takes a half day to two days, depending on length, conformance claims, and how many composite dependencies the ST inherits. A multi-candidate tender with five Security Targets to compare can occupy a reviewer for one to three weeks once cross-reading and mismatch documentation are included.
What is the difference between a TOE-SKU mismatch and a scope narrowing?
A TOE-SKU mismatch is when the certified configuration is not the configuration being sold (different model number, different firmware, different hardware revision). A scope narrowing is when the certified configuration matches the SKU, but the TOE boundary inside the ST is smaller than the product as a whole (for example, the certified scope covers the cryptographic module but not the management interface). Both are common, both are recoverable in negotiation if caught early, but they require different remediation.
Is reading the ST enough, or does a buyer also need to read the evaluation technical report?
The Security Target is the authoritative public document and is what a procurement specification should be matched against. The evaluation technical report contains the laboratory's findings and is not generally published; copies can sometimes be obtained under non-disclosure for high-value procurements. For most procurement exercises the published ST, the certificate, the certification report, and any maintenance reports are sufficient. Only escalate to the technical report when a candidate is shortlisted and unresolved questions remain.
What if the Security Target is short and lacks detail?
A thin Security Target is itself a finding. Modern STs under Common Criteria, EUCC, SESIP, and PSA Certified are detailed documents; an ST that fits in a few pages typically means the TOE is narrow, the assurance level is low, or both. Note the length, compare it to peer products in the same category, and raise it as a question with the vendor. A short ST is not by itself disqualifying, but it should be explained.