How to Read a Common Criteria Security Target as a Buyer (Not an Evaluator)

The vendor brochure says “EAL4 certified”. The certificate the vendor attached confirms it: EAL4, valid, in date, identifier resolves cleanly in the issuing scheme’s registry. Procurement signs off, the product gets purchased, and eighteen months later an auditor asks a question that nobody on the buyer side ever thought to ask. The cloud management plane the operations team enabled on day one is not part of the certified configuration. The certificate’s claims, read strictly, do not apply to how the product is actually deployed.

This is not an unusual outcome. It is the default outcome when the buyer never read the Security Target.

Why buyers read STs differently from evaluators

The Security Target is the central document in any Common Criteria evaluation. The vendor writes it (often with a consultant or the evaluation lab in support), the lab reviews it, and the certification body approves it before any evaluation work begins. The ST defines what is being evaluated and what claims the evaluation must support. The certificate at the end of the process is, in effect, an attestation that the claims in the ST were tested and held up.

An evaluator reads the ST in one direction: against the Common Criteria standard itself. Are the threats well-formed? Do the security objectives trace back to the threats and assumptions? Do the Security Functional Requirements implement the objectives? Is the conformance claim consistent and complete? The evaluator is checking that the document is internally coherent and that the evaluation activities it implies can actually be performed.

A buyer reads the ST in the opposite direction: against a specific deployment. Does the Target of Evaluation match the SKU on the quote? Do the environmental assumptions match the site this product is going to live on? Are the threats listed in the ST the threats actually being procured against, and what about the threats the ST does not list?

Both readings are valid. They ask different questions of the same document. If you have a deadline to recommend buy or no-buy, you need the buyer reading. The evaluator reading has already happened, by definition. That is what the certificate attests to.

TOE identification: match the certified configuration to the SKU you are buying

The first substantive section of any ST identifies the Target of Evaluation. The TOE is the part of the product the certificate covers; it is rarely the entire product the vendor sells.

Read the TOE identification with the vendor’s quote in your other hand. You are checking four things.

1. The product name as evaluated. Is it the same product family as the SKU on the quote, or a sibling product with a similar name? Vendors run product lines with shared branding and meaningfully different evaluated scopes. Treat the brand as a hint, not as proof.
2. The version or firmware revision. A certificate for firmware 2.4 does not, by itself, cover firmware 3.0. If the vendor is offering you the newer version, look for a maintenance report that extends assurance, or a re-evaluation that produced a fresh certificate.
3. The hardware platform. Many evaluations are scoped to a single hardware revision or to a defined list of revisions. A regional variant, an OEM-branded reseller version, or a redesigned mainboard can fall outside the scope.
4. The configuration. STs often describe the certified configuration as a specific set of enabled features and disabled features. If the configuration you plan to deploy differs, the certificate may not apply to it.

The TOE is described in two layers: a physical scope (which components, files, hardware modules sit inside the boundary) and a logical scope (which security functions are covered). Read both. A TOE described as “the cryptographic engine in firmware version 2.4 running on hardware revision A, with the local-administration interface enabled and the remote-management interface disabled” is a much narrower thing than the product on the data sheet.

This is the section where most buyer-side mismatches surface. It is also the section vendors are least likely to flag in a sales conversation, because the natural sales motion is to talk about the product, not about the carve-out.

Security problem definition: read assumptions and threats against your deployment

The security problem definition is a three-part section: the threats the TOE counters, the organisational security policies the TOE enforces, and the assumptions the TOE makes about its environment.

For a buyer, the assumptions are usually the most consequential of the three. They are written as if the TOE is being deployed in an idealised environment, and they are sometimes surprisingly demanding. Typical assumptions include physical security at the deployment site, trusted administrators, network isolation from untrusted networks, an authentication infrastructure of a stated type, and a host operating system at a stated patch level. If any of these assumptions fail in your deployment, the certificate’s claims do not apply to your installation. The product may still work, and may still be secure in a practical sense, but the certificate is no longer evidence of that.

The threats are the second thing to read. The certificate defends against the threats the ST lists, evaluated to the rigour of the chosen assurance package. Threats the ST does not list are out of scope by construction. If your threat model includes an attacker the ST does not consider (a malicious insider, a supply-chain compromise, a network-attached attacker when the ST assumes physical isolation), the certificate is silent on that risk. Silence is not denial, but it is not coverage either.

The organisational security policies are usually less interesting at procurement time, because they describe behavioural rules the deployment must enforce rather than attacker capabilities. Read them, but they rarely change a buy or no-buy decision on their own.

The honest test for this section is to read the assumptions and threats out loud against your actual deployment architecture. If you find yourself silently translating (“well, we do not exactly have a trusted administrator, but Alice is fine”) you have already found the mismatch.

Conformance claims: which CC version, which PP, which augmentations

The conformance claims section is short. It carries four pieces of information that change the assurance picture materially.

First, the Common Criteria version. CC:2022, CC:3.1 Revision 5, or one of the earlier revisions. The version affects which assurance components apply and how they are interpreted. Most current evaluations are on CC:2022 or CC:3.1R5.

Second, the Protection Profile conformance claim, if any. If the ST claims conformance to a PP, the ST inherits that PP’s requirements, and the certificate is comparable to any other certificate against the same PP. If the ST is “ST-only” with no PP claim, the requirement set is bespoke and cross-vendor comparison is harder. PP-conformant certificates are the apples-to-apples case; ST-only certificates each need to be read on their own terms.

Third, the assurance package: the EAL and any augmentations. EAL4 alone is not the same product as EAL4 augmented by AVA_VAN.5 and ALC_DVS.2. The augmentations are listed by their full component identifier in the conformance claim, and they change what the evaluation actually tested. AVA_VAN.5 vulnerability assessment against a high-attack-potential attacker is a categorically different activity from AVA_VAN.3 against an enhanced-basic attacker. Two products both advertised as “EAL4+” can have very different evaluation rigour behind them.

Fourth, look at what is missing. If the buyer specification asks for a particular augmentation (ALC_FLR for flaw remediation commitments, ALC_DVS for development security, AVA_VAN at a specified level) and the conformance claim does not include it, the certificate does not cover what the specification asked for. This sounds obvious. It is also the most common gap in cross-vendor comparison matrices, because the headline EAL is what gets copied into the matrix and the augmentations get truncated to ”+”.

A worked example: the cloud-managed perimeter firewall

Consider a hypothetical EAL4-augmented network firewall from an established vendor. The certificate is in date, the issuing scheme is a CCRA Certificate Authorizing scheme, and the augmentation set looks credible (ALC_DVS.2 and AVA_VAN.4). The buyer is a public-sector integrator looking for a firewall to sit at the perimeter of a regulated environment, with cloud-based central management because the deployment spans twelve sites across the country.

The certificate page is reassuring. The Security Target tells a different story.

The TOE identification scopes the evaluation to the firewall appliance running a specific firmware version, configured in standalone mode without the cloud management plane. The ST is explicit: “The cloud management interface is excluded from the TOE and is not within the scope of this evaluation.” The security problem definition assumes that management traffic is “performed locally by a trusted administrator through the appliance console or the local web UI.” The listed threats include network-attached attackers against the data plane; they do not include attackers against a cloud management plane that the ST has placed outside the scope.

The product the buyer plans to deploy has the cloud management plane enabled on day one, because the deployment is multi-site and local administration of each box is operationally impractical. The certificate, read strictly, covers a configuration the buyer is not using. The vendor’s marketing material does not flag this; the brochure says “EAL4-certified” and lists “centralised cloud management” two lines below. Both statements are true. Together, in the absence of the ST reading, they are misleading.

This is what the buyer reading of the ST surfaces. It is not a defect in the certificate (the certificate is valid for what it covers) and it is not necessarily a deal-breaker (the buyer may decide the unevaluated cloud management plane is acceptable risk, with compensating controls, perhaps locked down to a dedicated management VLAN with mutual TLS and offline credential rotation). But the decision needs to be made on the basis of what the ST actually says, not on the basis of the brochure.

The same shape of mismatch shows up in other categories. A smart card or secure IC ST may scope the evaluation to the chip’s secure element while leaving the host-side personalisation tooling out of scope. A SESIP or PSA-certified IoT platform may certify the bootloader and runtime while excluding the cloud back-end the device connects to. An eIDAS Qualified Signature Creation Device may carve out the signature creation function and leave the surrounding application stack to the integrator. The category changes; the structural pattern does not. The glossary entries for TOE, SFR, and SAR are worth a re-read at this point if any of these terms have gone hazy.

The closing argument: read the ST before signature, not after

The certificate is a pointer. The Certification Report is a summary. The Security Target is the document that defines the scope of what was evaluated, and it is the only document in the package with the level of detail a contract can reference. Procurement contracts for certified products typically cite a certificate identifier and a Security Target version. Anything outside the ST is, contractually, not part of what the vendor delivered as certified.

Reading the ST is a few hours of work. It is the cheapest piece of procurement due diligence available, and it is the part an auditor (or, eventually, a post-incident reviewer) will ask whether you did. The vendor cannot read the ST for you, because the vendor is the party whose claims are being checked. The lab cannot read it for you either; the lab’s job ended at the certificate.

If you have a Security Target in front of you and a deadline to recommend buy or no-buy, the four-section reading above is the buyer’s path through it. TOE identification against the SKU. Security problem definition against the deployment. Conformance claims against the specification. TOE summary specification against the implementation details that matter to your use case. That is the procurement read. Everything else in the document is structural overhead aimed at the evaluator, and you can skim it.

For supporting context, the Common Criteria procurement guide lists the broader red-flag set; the sibling Security Target Review for Buyers checklist sits one level more detailed; and the How to Read a Common Criteria Certificate field guide covers the one-page document the ST sits behind. If you are also comparing EAL claims across vendors, the EAL4 vs EAL4+ piece explains why the plus sign on its own carries no information, and the twelve procurement red flags post collects the wider set of patterns to test for in a vendor bid.

How NenkinTracker helps you see this

NenkinTracker indexes the published Security Target for every certificate it ingests, across Common Criteria, EUCC, SESIP, PSA, EMVCo, ESA, and MIFARE, and tracks document version history when an ST is updated as part of a maintenance procedure or re-evaluation. That means when you start a buyer-side review, the ST is one click from the certificate page rather than buried in a national scheme’s portal and a per-vendor PDF archive. For a side-by-side comparison of two candidates’ STs, that is the difference between an afternoon’s work and a week of document hunting.

For high-value or high-assurance procurements, the same review benefits from an independent advisor who can pressure-test the vendor’s certificate claim before signature, sit through the ST with you, and write a recommendation attributable to a named person. Nenkin Technologies AS offers procurement advisory on this basis: buyer-side only, no vendor referral fees, with specialty in smart cards and secure ICs, network and telecom infrastructure, IoT platforms (SESIP, PSA), mobile and payment, TEEs, and eIDAS Qualified Signature Creation Devices. The practice is led by a former Technical Manager of Norway’s Common Criteria scheme (2012 to 2018, in CCDB, SOG-IS JIWG, and ISO/IEC SC 27/WG3), now working under the Dutch scheme through Scandicert AS, with more than 20 years on the certifier and CAB side of the table. If you have an ST on your desk and a procurement deadline, that is the engagement to ask about.