Curity’s NHI guidance reflects the modernization gap in IAM

At a glance

What this is: This is Curity’s identity and security guidance hub, and its NHI sections underline how modern authentication now spans service accounts, workload identity, SPIFFE/SPIRE, and OAuth-based trust patterns.

Why it matters: It matters because IAM teams have to govern humans, workloads, and machine identities through the same lifecycle discipline, or end up with fragmented trust, weaker oversight, and inconsistent access controls.

👉 Read Curity’s guidance on non-human identities, SPIFFE, and workload identity

Context

Non-human identity governance now sits at the center of modern IAM because service accounts, workload identities, tokens, and certificates often outnumber human identities and are harder to see. Curity’s content hub points to that shift by grouping NHI, Kubernetes, SPIFFE, and OAuth topics together rather than treating them as separate problems.

For IAM and security architects, the real issue is not just authentication mechanics. It is whether identity programmes can manage provisioning, rotation, federation, and offboarding across machine identities with the same rigor they already expect for human access.

Key questions

Q: How should security teams govern service accounts and workload identities at scale?

A: Treat them as governed identities with owners, lifecycle dates, and explicit retirement criteria. The practical control set is inventory, least privilege, rotation, and offboarding. Without all four, machine identities persist far beyond their intended purpose and become silent trust anchors across pipelines, applications, and infrastructure.

Q: Why do non-human identities create more governance risk than teams expect?

A: Because they are often created quickly, copied into multiple systems, and left active after the business need changes. The problem is not just exposure, but persistence. When service accounts and tokens outlive ownership, they become standing access that is hard to detect and harder to revoke.

Q: How do workload identities change secrets management strategy?

A: They shift the goal from protecting static credentials to governing proof of workload identity. That means tighter audience control, shorter-lived assertions, stronger federation boundaries, and fewer reusable secrets in code or pipelines. The strategy changes from storage protection to identity trust design.

Q: What should IAM teams do when Kubernetes, SPIFFE, and OAuth all meet in one programme?

A: Use one governance model for ownership, entitlement scope, and lifecycle control across all three. The systems differ technically, but the accountability questions are the same: who owns the identity, what can it reach, and when is it retired? Consistency matters more than platform-specific customisation.

Technical breakdown

Workload identity in Kubernetes and SPIFFE

Workload identity replaces shared or long-lived secrets with cryptographic identity tied to the running workload. In Kubernetes, that often means service accounts, projected tokens, and federation into systems like SPIFFE and SPIRE so workloads can prove who they are without static credentials. The architectural goal is narrower trust boundaries and less reliance on manually managed secrets. The hard part is consistency across clusters, environments, and downstream services, where one missed integration can turn a clean identity model into fallback credential sprawl.

Practical implication: map every workload trust path and remove any place where Kubernetes identities fall back to reusable secrets.

OAuth and token trust for non-human identities

OAuth and OpenID Connect patterns are often used to authorize machine access, but NHI governance changes the risk profile because tokens can be copied, replayed, or over-scoped if issuance rules are weak. Client credentials, token exchange, and revocation controls become central when the subject is a workload or automation process rather than a person. The key architectural question is not only whether the token is valid, but whether its audience, lifespan, and privileges match the exact operational purpose of that identity.

Practical implication: review machine-to-machine token lifetimes, audience restrictions, and revocation handling as first-class governance controls.

Lifecycle control for service accounts and secrets

NHI lifecycle management covers provisioning, rotation, offboarding, and visibility for identities that do not behave like humans but still create accountability gaps when left unmanaged. Service accounts and API keys tend to persist beyond their intended use, especially when ownership moves, environments change, or integrations are deprecated. That creates hidden standing access and makes remediation slower than the rate at which credentials are created. Mature governance treats these identities as assets with explicit owners, expiry expectations, and retirement paths.

Practical implication: require named ownership, rotation policy, and offboarding criteria for every service account and secret.

Threat narrative

Attacker objective: The attacker seeks durable trusted access through machine identities so they can operate inside normal authentication flows without triggering obvious human-login defenses.

1. entry: access begins through exposed or over-trusted machine credentials, often inside code, pipelines, or workload configuration.
2. escalation: the attacker moves from a single credential to broader service access when tokens, roles, or certificates carry more privilege than the workload needs.
3. impact: the compromised non-human identity enables lateral movement, data access, or downstream abuse through trusted automation paths.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Curity’s topic structure reflects the real governance shift: IAM is no longer a human-only discipline. The presence of NHI, Kubernetes, SPIFFE, and OAuth material in one navigation model shows how workload identity, federation, and secrets management now converge in the same operational programme. That convergence matters because the control failures are shared across humans and machines, even if the execution model is different. Practitioners should treat identity architecture as one system with multiple actor types, not as separate silos.

Non-human identity sprawl is the field’s hidden control debt. Service accounts, API keys, and workload tokens are easy to create and hard to retire, which means ownership breaks down long before an incident appears. The practical issue is not just that secrets exist, but that they persist beyond the business function that created them. That makes lifecycle governance the real differentiator between managed machine access and accumulated risk.

Workload identity removes shared-secret dependence, but it does not remove governance responsibility. SPIFFE-style identity and Kubernetes-native authentication reduce exposure windows, yet they also demand disciplined trust boundaries, metadata hygiene, and downstream authorization review. The operational benefit is stronger provenance, but only when teams know exactly which workload is allowed to speak for which system. Practitioners should see workload identity as a governance upgrade, not an automatic security outcome.

NHI governance fails when access is treated as a configuration choice instead of an identity lifecycle decision. That assumption was designed for stable systems and predictable ownership. It breaks when service accounts, tokens, and certificates are created by pipelines, reused across environments, or inherited by integrations that no one actively maintains. The implication is that access review alone is not enough if the underlying identity can outlive the team or workflow that created it.

Identity blast radius: the real risk is not secret exposure alone, but the number of systems that trust a compromised machine identity by default. A single workload credential can become a pivot into APIs, pipelines, or data stores when privilege boundaries are too coarse. That is why NHI governance has to be measured by the trust surface it creates, not just by the inventory it keeps. Practitioners should reduce the number of systems that automatically accept the same identity proof.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing how slowly machine-identity exposure is often remediated.
• A practical next step is to pair lifecycle control with the NHI Lifecycle Management Guide so ownership, rotation, and offboarding are tied to one governed process.

What this signals

Identity teams should expect NHI governance to become a platform design issue, not just a policy issue. As Kubernetes, SPIFFE, and OAuth converge in production, the control failure is often the trust boundary between systems rather than the authenticator itself. Programmes that cannot trace ownership and expiry across machine identities will struggle to contain blast radius when one credential is exposed.

The strongest signal in this space is whether your environment can retire a workload identity as cleanly as it can create one. If offboarding is manual, delayed, or ownerless, the programme is already carrying identity debt that will show up as access sprawl later.

With NHIMG research showing that 97% of NHIs carry excessive privileges, the governance gap is structural. Teams should prepare for tighter review of machine entitlements, shorter credential lifetimes, and better mapping between platform identity and business ownership.

For practitioners

• Inventory every non-human identity path Map service accounts, API keys, certificates, workload tokens, and federation links across Kubernetes, CI/CD, and application tiers. Record the owner, purpose, issuing system, and retirement trigger for each one.
• Separate workload identity from reusable secrets Prefer cryptographic workload identity where the platform supports it, and remove static credentials from code, configs, and pipeline variables wherever possible. Use the migration as an opportunity to eliminate fallback authentication paths.
• Set explicit rotation and offboarding rules Define rotation intervals, maximum token lifetime, and a documented offboarding workflow for every machine identity. Tie revocation to ownership changes, integration deprecation, and environment retirement, not just to incident response.
• Review trust boundaries after federation changes Reassess what each federated token can reach after adding SPIFFE, OIDC, or workload identity integrations. Confirm audience restrictions, token exchange scope, and downstream authorization before expanding adoption.

Key takeaways

• Curity’s NHI and workload-identity content reflects a broader IAM shift: machine identities now need lifecycle governance, not just authentication plumbing.
• NHI risk is amplified by excess privilege and persistence, especially when service accounts and secrets outlive the integrations that created them.
• Practitioners should treat inventory, rotation, offboarding, and federation boundaries as one governance programme across Kubernetes, SPIFFE, and OAuth.

Key terms

• Workload Identity: A workload identity is a cryptographic or platform-issued identity used by software instead of a human user. It lets services authenticate to other services without sharing a long-lived password or key, but it still needs ownership, scope control, and retirement rules.
• Service Account: A service account is a non-human identity assigned to an application, process, or automation task. It is often used for machine-to-machine access, and the governance challenge is that it can persist longer than the workload it was created for unless lifecycle controls are enforced.
• Federated Authentication: Federated authentication allows one identity system to trust assertions from another rather than creating local credentials everywhere. In NHI programmes, it reduces duplication, but it also concentrates trust, so audience restrictions, token lifetime, and downstream authorization become critical.

What's in the full article

Curity's full article set covers the operational detail this post intentionally leaves for the source:

• Step-by-step configuration guidance for authenticating workloads with Kubernetes service accounts and SPIFFE.
• Implementation notes for integrating OIDC and OAuth patterns into machine identity flows.
• Product documentation covering deployment, token handling, and platform-specific setup choices.
• Operational guidance for advanced identity integrations and authentication actions.

👉 Curity’s full site covers the implementation detail behind Kubernetes, OAuth, and NHI identity flows.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.