Notifications
Clear all
Topic starter
02/06/2026 6:53 pm
TL;DR: Curity’s how-to library centers on OAuth, API security, and workload identity patterns such as phantom token flows, SPIFFE and SPIRE integration, and hardened client credentials, showing where implementation detail still determines control strength. The editorial lesson is that identity governance fails at the seams between protocols, runtime trust, and operational discipline.
NHIMG editorial — based on content published by Curity: how-tos and recipes for working with the Curity Identity Server
Questions worth separating out
Q: How should security teams implement phantom token patterns for APIs?
A: Teams should place token validation at a trusted edge and use opaque tokens that are only meaningful inside that boundary.
Q: Why do service account secrets create persistent NHI risk?
A: Service account secrets create persistent risk because they tend to outlive the workload, the owner, and the original use case.
Q: What breaks when workload identity is only partially adopted?
A: Partial adoption leaves gaps between attested workloads and legacy access paths.
Practitioner guidance
- Implement phantom token mediation for API access Place opaque access tokens at the edge and require a trusted boundary to resolve them before a backend service can act on them.
- Adopt workload identity for service-to-service calls Move service accounts and client credentials toward SPIFFE-style workload identity or equivalent runtime-bound credentials.
- Align Kubernetes credentials with pod lifecycles Eliminate static long-lived secrets where a pod-specific identity can be issued and retired with the workload.
As workloads become more ephemeral, the programme question shifts from whether a token exists to whether it can still be used after the workload has changed, moved, or terminated?
👉 Read Curity's how-to collection on API security, SPIFFE, and phantom tokens →
Explore further
02/06/2026 7:06 pm
API security recipes are governance documents in disguise. A how-to on phantom tokens, workload identity, or hardened client credentials is really a set of decisions about trust boundaries, lifecycle, and revocation. If those decisions are inconsistent, the enterprise ends up with identity controls that look modern but behave like static secrets. Practitioners should read these recipes as operating models, not implementation notes.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which is why lifecycle controls remain a baseline requirement.
A question worth separating out:
Q: How do teams know whether ephemeral credentials are actually reducing risk?
A: Look for shorter credential lifetimes, fewer static secrets, and faster revocation after workload termination. If identities persist after the pod, job, or client is gone, the environment still has standing access. Effective programmes can show that credentials disappear on schedule and that access paths do not remain usable after offboarding.
👉 Read our full editorial: Curity’s recipes show where API identity controls still need work
