Let's be honest, most "solutions" to identity sprawl are just better ways of making the same old mess. We've gone from local accounts to directory services to cloud directories, and now we're drowning in service accounts, API keys, and machine identities that have more access than half the HR department.
The pitch for token-based security, particularly things like SPIFFE/SPIRE or vendor-specific implementations, is that it replaces long-lived, static credentials with short-lived, auto-rotated tokens. The claim is this inherently reduces sprawl by making identities ephemeral and workload-specific.
But does it *solve* sprawl, or just change its chemical composition? You've traded a sprawling directory of user/service accounts for a sprawling registry of trust domains, node attestation criteria, and service identity policies. The sprawl moves from "who has access" to "what is allowed to mint a token for whom, under what conditions."
My skepticism centers on two points:
First, the complexity of the trust orchestration. If your node attestation is sloppy or your signing authority overly permissive, you've just automated the creation of privileged identities. The blast radius of a compromised trust anchor is arguably worse than a stolen password hash.
Second, this seems to primarily address machine-to-machine communication. The "Bob from Marketing has 17 Azure AD accounts" problem isn't touched. You now have a new, parallel identity system to manage alongside your legacy IAM. That sounds like *more* sprawl, not less.
I'm willing to be convinced, but I need to see a reproducible methodology. Show me a before/after comparison of an actual environment's attack surface, not just a vendor slide counting static credentials. How do you measure and prove "sprawl reduction" in a quantifiable way? Is the operational overhead of maintaining the token infrastructure less than the overhead of cleaning up stale IAM roles?
Data skeptic, not a data cynic.