What breaks when teams treat certificates or tokens as if they were identities?

Why This Matters for Security Teams

Teams break more than authentication when they treat certificates or tokens as identities. A certificate or bearer token can prove that a request is cryptographically valid, but it does not by itself prove who owns the workload, whether the workload is still authorised, or whether the credential is scoped to the current task. That gap matters because attackers often target the credential layer first, then move through systems that assume the credential is the identity. NIST’s Cybersecurity Framework 2.0 still frames identity as a control objective, not just a secret to protect.

In NHI programs, the operational failure is usually subtle: a token is issued, copied into a pipeline, reused across services, and then treated as an enduring trust anchor long after the original context has changed. NHIMG research on the Guide to the Secret Sprawl Challenge shows how quickly credentials spread outside their intended boundary, while the Salesloft OAuth token breach is a reminder that a valid token can still become a high-impact access path when governance is weak. In practice, many security teams encounter the trust failure only after a token has already been reused in an unexpected place, rather than through intentional identity design.

How It Works in Practice

The practical fix is to separate authentication proof from identity governance. Certificates and tokens should be treated as credentials that bind a request to a workload, not as the identity itself. A stronger model combines cryptographic proof, workload attestation, short-lived issuance, and runtime policy checks. That is why current guidance increasingly points toward workload identity systems such as SPIFFE, where the identity primitive is the workload and the credential is just one expression of that identity. For broader governance context, the Ultimate Guide to NHIs is useful for distinguishing identity lifecycle from secret lifecycle.

• Issue credentials just in time, with a narrow TTL tied to a specific task or session.
• Bind tokens or certificates to a workload identity and environment context, not only to a service name.
• Evaluate access at request time using policy-as-code, so scope changes can be enforced immediately.
• Revoke on completion or anomaly, rather than waiting for a static rotation window.
• Separate credential storage from identity records so compromise of one does not imply durable trust.

This matters because long-lived credentials create false continuity. A certificate can still be valid while the workload has changed ownership, the deployment path has been cloned, or the token has been copied into logs, tickets, or chat. Current best practice is evolving toward runtime attestation and contextual authorisation, but there is no universal standard for this yet. NIST’s identity guidance and the emerging NHI body of work both point in the same direction: prove the workload, scope the action, and minimise credential lifetime. Where organisations skip attestation, a valid token can outlive the workload it was meant to represent, especially in CI/CD, multi-tenant automation, and agent-driven toolchains.

Common Variations and Edge Cases

Tighter credential controls often increase operational overhead, requiring organisations to balance least privilege against deployment speed and automation complexity. That tradeoff becomes visible in environments with service meshes, ephemeral containers, federated clouds, or autonomous agents that fan out across multiple tools. In those settings, a single static certificate or token often seems convenient, but convenience usually hides an accountability gap.

Guidance is strongest where identities are machine-to-machine and the environment can support frequent renewal. It is weaker where legacy apps expect static secrets, where tokens are embedded in vendor integrations, or where teams still rely on manual approval for credential changes. NHIMG’s reporting on the JetBrains GitHub plugin token exposure and the Sisense breach illustrates how quickly exposure turns into lateral movement when credentials are treated as durable identity. The main edge case is emergency access: if break-glass tokens must remain long-lived, they need exceptional controls, stronger monitoring, and explicit post-use revocation. Otherwise, the environment drifts back to credential sprawl with better branding but the same risk.

Related resources from NHI Mgmt Group

• Should organisations treat certificates and tokens like other non-human identities?
• What are the implications of using OAuth tokens in third-party integrations?
• How should security teams authenticate AI agents in enterprise environments?
• What makes OAuth tokens risky in NHI environments?