The Target of Evaluation is the specific system, product, or component boundary that the lab reviews during certification. It defines exactly what is in scope for testing and assurance assessment. Clear scope is essential because only the identified target receives Common Criteria evaluation and certification.
What the Target of Evaluation Defines
The Target of Evaluation, or TOE, is the exact product, system, or component boundary that a certification lab assesses. It tells evaluators what is included, what is excluded, and where assurance claims stop. In Common Criteria work, that boundary is not a formality, it is the object being tested.
A TOE can be a single application, a platform, a hardware device, a firmware image, or a tightly defined combination of components. The important point is that the scope must be explicit enough for the lab to test the claimed security functions against the claimed environment. If the boundary is vague, the certification result becomes difficult to interpret and easy to overstate.
Why the Boundary Matters in Certification
The TOE boundary is the foundation for the security target, test evidence, and evaluation depth. It determines which interfaces, features, dependencies, and assumptions are part of the assurance case. That means the same product can produce very different evaluation outcomes depending on what the vendor includes in scope.
This is also why TOE definition affects comparability. Two products may both be Common Criteria certified, but if one includes only a narrow module and the other includes an integrated platform, the resulting assurance claims are not directly equivalent. Readers should treat the TOE as the certification lens, not as a generic label for the whole vendor offering.
The idea is closely aligned with how certification frameworks separate the evaluated component from the surrounding environment. For background on the broader assurance model, NIST Cybersecurity Framework 2.0 is useful for understanding how governance, protection, detection, and recovery differ from product-level evaluation.
What Must Be Clearly In or Out of Scope
A well-formed TOE description normally identifies the evaluated functions, the trusted boundary, external dependencies, and the assumptions the evaluation relies on. It may also describe excluded modules, administrative interfaces, cryptographic components, and operational prerequisites. Those exclusions are not cosmetic, they define the limits of the certification claim.
Boundary discipline is especially important when a product depends on external services, APIs, identity providers, or optional modules. If the security claim depends on something outside the TOE, that dependency must be visible in the evaluation narrative. Otherwise, buyers and auditors may assume the certification covers more than it actually does.
The boundary concept also echoes other security disciplines that depend on precise scope. For example, resource scoping in authentication and authorization standards relies on the same principle of naming exactly what a token or control applies to, which is why RFC 8707: Resource Indicators for OAuth 2.0 is a useful adjacent reference for audience restriction and target specificity.
How Practitioners Should Read and Use TOE Language
Practitioners should read the TOE as a statement about assurance scope, not as a marketing description of the full product. The question is not “does the vendor have a secure product”, but “what exactly was evaluated, under what assumptions, and with what exclusions”. That distinction is central when comparing certificates, planning procurement, or reviewing compliance evidence.
Clear TOE wording also helps prevent scope creep during certification planning. If teams expand the boundary late in the process, they often expand the test surface, evidence burden, and dependency review as well. If they shrink it too far, the certificate may be technically valid but operationally less useful to buyers who need confidence in the broader deployment.
For assurance-heavy environments, it is useful to compare TOE wording with surrounding control expectations. NIST SP 800-53 Rev 5 Security and Privacy Controls provides a broader control lens, while the TOE remains the narrower certification object.
Common Misunderstandings About TOE Scope
A common misunderstanding is to assume the TOE is the same thing as the entire vendor product line or deployment estate. In practice, it is often much smaller and more exact. Another mistake is to treat certification as a blanket endorsement of every feature, integration, or operating mode associated with the product name.
That misunderstanding matters because certification language can be precise while procurement language is broad. If stakeholders do not check the TOE boundary carefully, they may assume protection for components that were never evaluated. The safest reading is always to map the certificate back to the evaluated boundary, the evaluated version, and the assumptions documented in the security target.
In modern systems, that discipline helps avoid overclaiming assurance for adjacent cloud, API, or operational components. The TOE is only as strong as the boundary that defines it, and the certification value comes from that clarity rather than from breadth.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | TOE scope depends on the system boundary and assumptions the organization defines. |
| GV.SC-01 — Supply Chain Risk Management Strategy | TOE scope often depends on included components and excluded dependencies. | |
| PR.DS-01 — Data-at-Rest Data is Protected | A TOE may include protections that are only valid within the evaluated boundary. | |
| Recommendation — Define the evaluated boundary and document which product capabilities are inside scope. Map external dependencies and excluded components before claiming assurance for the TOE. Verify that any data-protection claim matches the exact evaluated component boundary. | ||
| NIST SP 800-53 Rev 5 | PL-2 — System and Communications Protection Policy and Procedures | TOE definition is a scope and boundary decision that must be documented for evaluation. |
| SA-15 — Development Process, Standards, and Tools | Certification scope must align with the product configuration and artifacts actually evaluated. | |
| Recommendation — Document the system boundary and assumptions that define the evaluated target. Control the evaluated version and configuration so the certification evidence stays consistent. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | TOE scope depends on identifying the exact assets and components under evaluation. |
| A.5.31 — Legal, statutory, regulatory and contractual requirements | Certification claims and scope must remain aligned with the contractual assurance boundaries. | |
| Recommendation — Record the evaluated components precisely so the certification boundary is unambiguous. Check that the certification scope matches the claims made to buyers and assessors. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | TOE depends on a defined architecture boundary and included security functions. |
| Recommendation — Define the evaluated architecture boundary before mapping security requirements to the product. | ||
Related resources from NHI Mgmt Group
- What is the difference between a security target and a target of evaluation in Common Criteria?
- Why do AI agents require continuous access evaluation?
- What is the difference between static access control and continuous access evaluation?
- When should teams move from target-phase controls to advanced OT Zero Trust controls?
