A Security Target is the formal statement of what a product claims to protect, how it is intended to be used, and which threats it is expected to resist. In certification contexts, it becomes the contract between the vendor, evaluator, and purchaser for understanding assurance scope and limitations.
Expanded Definition
A Security Target is the formal assurance statement that describes what a product claims to protect, the intended operational environment, and the threats or misuse cases it is designed to resist. In certification settings, it helps evaluators and purchasers understand the boundary of the claim rather than assuming the product is universally secure.
In NHI and agentic AI contexts, the idea is especially useful because the security claim often depends on how an identity, secret, token, or control plane is actually deployed. Definitions vary across vendors when products blend policy, runtime enforcement, and telemetry, so the Security Target should be read as scope, not marketing language. It is most meaningful when paired with control expectations from the NIST Cybersecurity Framework 2.0 and when the product’s claims can be mapped to a clearly bounded use case.
The most common misapplication is treating the Security Target as proof of general security, which occurs when buyers extend a narrow certification claim to deployments, integrations, and identities that were never evaluated.
Examples and Use Cases
Implementing Security Target rigorously often introduces scope constraints, requiring organisations to weigh assurance clarity against the flexibility of broad deployment claims.
- A security buyer reviews a certificate management platform’s Security Target to confirm whether API key rotation, logging, and admin access are inside the evaluated boundary.
- A procurement team compares two NHI tools and uses the Security Target to see whether third-party OAuth visibility is a claimed capability or merely an optional integration.
- An evaluator checks whether an agent platform’s claim covers tool invocation guardrails, prompt injection resistance, and secrets handling, or only basic authentication.
- A governance lead uses the Security Target to separate what the product guarantees from what still depends on the customer’s IAM, PAM, or zero trust architecture.
- For broader NHI lifecycle context, teams often pair certification reading with the Ultimate Guide to NHIs, then validate the stated claim against the actual deployment model.
In practice, a Security Target is most valuable when the product is being introduced into a high-assurance environment, especially where the difference between evaluated features and optional features changes the residual risk.
Why It Matters in NHI Security
Security Targets matter because NHI failures often begin with assumptions about protection that were never actually part of the product claim. If a service account manager, secrets vault, or agent runtime is certified or assessed under a limited scope, the surrounding ecosystem can still leak credentials, over-privilege identities, or bypass intended controls. That is why NHIMG’s research shows that 97% of NHIs carry excessive privileges, 71% are not rotated within recommended time frames, and 96% of organisations store secrets outside of secrets managers in vulnerable locations. A Security Target helps decision-makers ask where the boundary really is before an incident forces that question.
It also supports governance conversations after exposure, when teams need to explain whether the failure was in the product, the integration, or the operating model. For control alignment, the concept maps well to NIST Cybersecurity Framework 2.0 because both emphasize defined scope, risk treatment, and measurable protection claims. Organisations typically encounter the practical importance of a Security Target only after a breach, failed audit, or disputed vendor claim, at which point the document becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.SC-1 | Security Target scope depends on defining suppliers, systems, and trust boundaries. |
| NIST SP 800-63 | Identity assurance guidance helps interpret claims about authenticators and credential handling. | |
| NIST AI RMF | AI risk management depends on clearly stated system boundaries and intended use. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | NHI security requires clear boundaries for secrets, service accounts, and authorization scope. |
Document product scope and dependencies before accepting any security claim or certification result.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
