Notifications
Clear all
Topic starter
06/07/2026 9:43 am
TL;DR: Organizations still need clearer paths for non-human identities, workload identity, and federated authentication across Kubernetes, SPIFFE/SPIRE, and OAuth patterns, according to Curity. That reinforces a familiar NHI reality: governance only works when lifecycle, secrets, and workload trust are managed as one system, not as separate controls.
NHIMG editorial — based on content published by Curity: the site’s identity, authentication, and non-human identity guidance
Questions worth separating out
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.
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.
Q: How do workload identities change secrets management strategy?
A: They shift the goal from protecting static credentials to governing proof of workload identity.
Practitioner guidance
- Inventory every non-human identity path Map service accounts, API keys, certificates, workload tokens, and federation links across Kubernetes, CI/CD, and application tiers.
- 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.
- Set explicit rotation and offboarding rules Define rotation intervals, maximum token lifetime, and a documented offboarding workflow for every machine identity.
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.
👉 Read Curity’s guidance on non-human identities, SPIFFE, and workload identity →
NHI modernization gap in IAM: what Curity’s guidance signals?
Explore further
06/07/2026 9:59 am
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.
A few things that frame the scale:
- 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 question worth separating out:
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.
👉 Read our full editorial: Curity’s NHI guidance reflects the modernization gap in IAM
