Machine identity attestation in 2026 amounts to the work of knowing what every workload, every container, every service mesh identity, every machine credential, every certificate, every API token can do, who owns it, when it was last rotated, whether it sits still needed. Most enterprises in 2026 have not done this work. The 2026 guide covers the machine identity landscape, the attestation process, the tooling, the moves that work.
The typical enterprise in 2026 has 10-50x more machine identities than human identities, with the ratio running at 1000:1 or higher in the cloud native enterprises. The machine identities include the cloud workload identities (the AWS IAM Roles Anywhere, the Azure Managed Identity, the GCP Workload Identity Federation), the service mesh identities (the Istio, the Linkerd, the Consul), the container identities (the Kubernetes service accounts, the pod identities), the certificate based identities (the mTLS, the SPIFFE), the API tokens (the long lived, the short lived), the database credentials (the connection strings, the passwords in the config). The 2026 state of the machine identity amounts to a state where the machine identities outnumber the human identities by orders of magnitude, the tooling to manage the human identities has matured, the tooling to manage the machine identities sits immature.
Where the machine identities are
Four categories, in roughly that order of how much they account for. The first runs as the cloud workload identity category, with the cloud native workloads (the EC2 instances, the Lambda functions, the containers, the Kubernetes pods) all using the cloud provided identity, with the cloud provided identity provisioned automatically, with the cloud provided identity rotated automatically. The cloud workload identity category typically accounts for 30-40% of the machine identities. The second runs as the service identity category, with the service to service communication (the microservices, the API calls, the database connections) all using the service identity, with the service identity managed by the service mesh, with the service identity rotated automatically. The third runs as the certificate identity category, with the TLS certificates (the web server certificates, the API certificates, the internal certificates) all being the machine identities, with the certificate lifecycle managed by the certificate management tool, with the certificate rotation typically running at 90 day intervals. The fourth runs as the secret identity category, with the API keys, the database passwords, the connection strings, the secrets in the vault, all being the machine identities. The four categories together account for the typical enterprise machine identity footprint.
The 5 stage process for attestation
Five stages, in order of how to do them. The first runs as the discovery stage, where the security team runs the tool (the Venafi for the certificates, the CloudKnox for the cloud, the Akeyless for the secrets, the open source alternatives) that finds every machine identity. The discovery tool returns the list. The list runs as the starting point. The second runs as the owner assignment stage, where every machine identity gets a person assigned, with the person accountable for the identity, with the person who can answer the question “what does this identity do, who needs it, what sits its access.” The third runs as the purpose documentation stage, where the owner documents what the identity does, the access it has, the systems it touches, the last time it sat used. The fourth runs as the access review stage, where the owner reviews the access, removes what sits not needed, tightens what sits over privileged, applies the least privilege. The fifth runs as the rotation stage, where the credentials get rotated on a schedule, with the rotation tracked, with the rotation verified, with the rotation automated where possible. The 5 stage process runs as the process the typical enterprise has not done.
How to actually do it
Three moves if you are starting the machine identity attestation program. Pick the discovery tool that fits your environment (the cloud native IAM tools, the certificate management tools, the secrets management tools, the open source alternatives), run the tool, get the list. The list sits as the foundation. The list without the discovery amounts to a guess. Assign owners for the major machine identities, with the assignment provisional, with the assignment revisited in 90 days. The enterprise that assigns the owners gets the accountability, the accountability creates the work. Build the attestation as a recurring cycle rather than a one time project, with the cycle automated where possible, with the cycle running as a quarterly review. The 5 stage process on a recurring cycle amounts to the process that scales. The security leader who picks the tool, assigns the owners, and builds the recurring cycle stands as the leader who gets the machine identity attestation done.
The bottom line
Machine identity attestation in 2026 amounts to the work the typical enterprise has not done. The four categories (cloud workload, service, certificate, secret) account for the machine identity footprint. The 5 stage process (discovery, owner, purpose, access, rotation) defines the attestation. The security leader who picks the tool, assigns the owners, and builds the recurring cycle stands as the leader who gets the machine identity attestation done.
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.
