4 MIN READ
Here is the work almost nobody has done. For every human identity in a modern enterprise there are dozens, often hundreds, of machine identities, and the inventory that exists in any one place sits as the exception rather than the rule. Workloads, containers, service mesh identities, machine credentials, certificates, API tokens, database passwords, all of them get created, used for a while, and forgotten. Most enterprises have no idea how many they have, who owns them, or which ones they can rotate without breaking something.
Most published estimates put the typical cloud native organisation at many times more machine identities than human ones, and the ratio often crosses 1000 to 1 inside the most aggressive Kubernetes shops. The categories matter because the tooling is different for each. Cloud workload identities (AWS IAM Roles Anywhere, Azure Managed Identity, GCP Workload Identity Federation) get provisioned and rotated automatically. Service mesh identities (Istio, Linkerd, Consul) get managed by the mesh. Certificate identities (mTLS, SPIFFE) get rotated on whatever schedule the cert management tool is set to. API tokens range from long lived and forgotten to short lived and clean. Database credentials tend to be the worst of the lot, often sitting in config files for years.
Where the machine identities live
Cloud workload identities tend to be the largest single bucket. EC2 instances, Lambda functions, containers, Kubernetes pods, all of them get an identity from the cloud, the cloud rotates it, and the only human interaction is when something breaks. Service identities come next, and they are the ones the service mesh is supposed to handle. The ones that fall outside the mesh are the ones that drift. Certificate identities follow. Web server TLS, internal API TLS, mTLS between services, all on a 90 day rotation if the cert tool is doing its job, and most cert tools are not. Secret identities are the fourth and usually the ugliest bucket. API keys, database passwords, connection strings, anything sitting in a vault. A meaningful share of these are stale, over privileged, or owned by a person who left the company two years ago.
The five stage process
Stage one is discovery. Run the tool that finds every machine identity in the environment. Venafi for certificates, CloudKnox for the cloud side, Akeyless for secrets, the open source alternatives for the parts the commercial tools miss. The output is a list, and the rest of the work can only start from it. Stage two is owner assignment. Every identity on the list gets a person, even if the person is wrong on the first pass. The owner is accountable for the access, the question of what the identity is for, and the date the work was last reviewed. Provisional ownership is fine for the first round. The point is to put a name on every row. Stage three is purpose documentation. The owner writes down what the identity does, what it touches, when it was last used, and whether it is still needed. Most rows in a real inventory are unused. The point of stage three is to find them. Stage four is access review. The owner tightens or removes what should not be there, applies least privilege, and fixes the over privileged ones the discovery tool flagged. The review is where the work pays off. Without it, the inventory is decoration. Stage five is rotation. Schedule is tracked, rotation is verified, and the parts that can be automated are automated. The first pass hurts. By the second pass, the cadence holds.
How to actually do it
Pick the discovery tool that fits the environment and run it. The tool returns the list, and without the list, the rest is guesswork. Assign owners for the major categories on day one, provisional is fine, revisit in 90 days. Run the five stage process on a quarterly cycle rather than as a one off project. The attestation that scales is the one that runs on a schedule. Run it once and it goes stale inside a year.
The bottom line
Run the discovery tool, name the owners, repeat it every quarter. The identity that has no name is the one that gets compromised in the breach nobody saw coming.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
