A security target is the vendor's explicit statement of the security functions and claims being evaluated. The target of evaluation is the actual product or component boundary under review. In practice, the security target describes what is being promised, while the target of evaluation defines exactly what the lab tests and certifies.
How Common Criteria Uses These Two Terms
In common criteria, the security target and the target of evaluation serve different jobs. The security target is the vendor-authored statement of security claims, assumptions, and functions that will be assessed. The target of evaluation is the specific product, component, or version boundary that the lab actually examines. That split keeps the promised security story separate from the thing being certified.
Practically, the security target is the specification document the evaluator checks for completeness and consistency. The target of evaluation is the scoped system, so versioning, included modules, and excluded functionality matter a great deal. A small boundary mismatch can change what is certified, what is merely described, and what a buyer can safely assume.
Why the Distinction Matters for Certification Scope
The difference matters because Common Criteria does not certify a vague product family in the abstract. It certifies a defined target of evaluation against the claims in the security target. If the documentation describes stronger functions than the evaluated boundary actually contains, the certification can overstate assurance. If the boundary is too narrow, the result may be technically valid but less useful for procurement or risk decisions.
This is also why evaluators care about assumptions, operational environment, and required external controls. Those items live in the security target and help explain what the certified boundary depends on. Buyers should read them as part of the security story, not as boilerplate. The certification result is only as meaningful as the match between the claims and the exact evaluated build.
For the Common Criteria overview and terminology, the official scheme documentation is the best starting point: Common Criteria Portal. For procurement language and certification context, the U.S. NIAP site is also useful: NIAP Common Criteria Evaluation and Validation Scheme.
What Evaluators and Buyers Should Check First
Two checks usually catch the most confusion. First, confirm the evaluated boundary exactly matches the version, configuration, and included components listed in the security target. Second, confirm the security claims in the security target are limited to that same boundary and do not rely on undeclared features or ambiguous packaging. In Common Criteria, precision about scope is not administrative detail, it is part of the assurance value.
Where products ship with optional modules, cloud dependencies, or managed services, the evaluation scope may be narrower than the commercial offering. That is normal, but it means the certification applies only to the evaluated configuration. If a deployment differs materially from the target of evaluation, the certificate should be treated as informational rather than automatically transferable.
Risk and Threat Considerations
The main risk is scope confusion. If the security target describes capabilities or protections that the target of evaluation does not actually include, purchasers may overestimate assurance and deploy outside the certified boundary. That creates a real trust gap even when the certificate itself is genuine.
Failure mechanism: The evaluated product boundary, version, or configuration diverges from the claims in the security target, so the assurance statement no longer describes what is being used in production.
Impact: Buyers may rely on certification for controls that were never tested in the deployed configuration, which can weaken procurement decisions, compliance evidence, and risk acceptance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | Common Criteria evaluation depends on defined claims and tested scope. |
| Recommendation — Validate the exact evaluated boundary and test evidence before accepting certification claims. | ||
| NIST CSF 2.0 | GV.OV-01 — Oversight of Security and Risk Management | Common Criteria is a governance and assurance signal requiring scope oversight. |
| Recommendation — Review certification scope against deployment reality before treating it as assurance. | ||
| ISO/IEC 27001:2022 | A.5.29 — Information security during disruption | Certification scope and assumptions must align with the operational environment used. |
| Recommendation — Confirm the certified configuration matches the operating environment you will run. | ||
Practitioner Guidance
What to verify: Check the exact product version, build, module list, and operating assumptions in the security target against the deployed system. If any of those differ, treat the certificate as covering only part of the deployment story.
Decision rule: If you are using certification for procurement or assurance, read the security target first, then compare it to the target of evaluation and to the real deployment. If the three do not align, escalate the difference before relying on the result.
Practitioner takeaway: The security target tells you what was promised, but the target of evaluation tells you what was actually tested, and that distinction determines how much assurance the certificate really gives.
Related resources from NHI Mgmt Group
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between human IAM controls and NHI governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
