Machine Identity

What a machine identity is

A machine identity is what a non-human actor uses to prove who it is to another non-human actor. Where a human uses a username and a password (plus MFA), a machine uses cryptographic material: a private key with a matching certificate, an API key, a SPIFFE ID, or a signed JWT. Every TLS handshake between two services, every mutual authentication between an IoT device and a cloud broker, every workload calling a secrets manager, uses a machine identity.

The category has expanded far beyond what most PKI programs were designed for. It now includes:

Industry analysts have started calling this whole space "non-human identity" (NHI) and estimate that machine identities now outnumber human identities in a typical enterprise by 45:1 or more.

Why it matters

Every breach investigation eventually gets to the same question: which credential did the attacker use, and where did they get it? Increasingly the answer is a machine identity — a leaked service account key, a stolen kubeconfig, an over-privileged CI/CD token committed to a public repo. Human identity has decades of hardening (SSO, MFA, conditional access, insider threat programs). Machine identity has, until recently, been an afterthought.

The specific problems machine-identity programs are trying to solve:

• Sprawl. Nobody knows how many certificates, keys, and tokens are in production. Discovery projects routinely find 3-10x more certificates than the CMDB expected.
• Silent expiry. A cert expires, a service goes down. Root cause investigations often trace outages to certs that nobody knew existed, issued by teams that no longer exist.
• Over-privilege. Service accounts and API keys are often granted broad access "just to make it work" and never reviewed.
• Rotation is manual and rare. In many organizations, machine credentials rotate on a multi-year cycle — or never. Human passwords rotate more often.
• Provenance is unclear. When something authenticates as svc-payments-prod, is that really the payments service, or a compromised host running as it?

Machine identity management is the discipline of solving these systematically: know what identities exist, issue them via automated protocols, keep lifetimes short, rotate continuously, and prove provenance cryptographically.

The lifecycle

A machine identity has the same six-stage lifecycle regardless of form factor:

1. Provisioning. The workload requests an identity, ideally proving something about itself first — a Kubernetes service account token, a TPM attestation, a cloud instance profile, an OIDC assertion from CI.
2. Issuance. An issuing authority (CA, SPIRE server, OIDC provider) grants the credential based on policy.
3. Distribution. The credential lands in a location the workload can use — a mounted volume, memory, a TPM slot, an environment variable (worst option).
4. Use. The workload presents the credential to authenticate to peers.
5. Rotation. Before expiry, the workload requests a fresh credential and cuts over.
6. Revocation and decommissioning. When the workload retires, its identity is revoked and audit trails preserved.

Every stage can be automated. The mark of maturity is that a human is never in the critical path.

Common misconceptions

"Machine identity is just PKI." PKI is one implementation. SPIFFE/SPIRE, cloud instance identities, OIDC federation, SSH certificates, and API keys are all machine identities too. Modern platforms have to speak all of them.

"Long-lived certificates are fine for internal machines." They are not. The industry is moving hard in the other direction — Let's Encrypt at 45 days, browser policies heading toward 47-day public certs, SPIFFE SVIDs measured in hours. The reason: every hour a stolen credential stays valid is a hour an attacker can use it.

"If we vault the keys, we are covered." Vaults protect keys at rest. They do nothing about the credential in use — the workload still holds a copy in memory, still uses it to authenticate, still gets breached and hands it over. Short lifetimes plus hardware-rooted binding (TPM, enclave) do more for security than any vault.

"Discovery is a one-time project." Certificate and key sprawl regenerates constantly — every new deployment, every new team, every new SaaS vendor adds identities. Discovery has to run continuously, not as a Q3 initiative.

"We can treat all machine identities the same." A production database's certificate and a batch job's temporary token have different criticality, different lifetimes, different rotation strategies, and different blast radii. Governance frameworks that lump them together do not scale.

How TigerTrust handles machine identity

TigerTrust treats machine identity as a first-class problem across three planes: discovery (find every cert, key, and workload identity across cloud, Kubernetes, and on-prem), lifecycle automation (issue, rotate, and revoke via ACME, EST, SPIFFE, and cloud-native integrations), and hardware-rooted assurance (bind identities to TPMs where the risk profile demands it). The platform's TPM 2.0 attestation flow, DevID (IEEE 802.1AR) support, and SPIFFE-compatible issuance all feed into a single inventory so you can answer "who owns identity X, when does it expire, and how do we rotate it" in one place.

Related reading

• SPIFFE and SPIRE specifications — the reference model for workload identity.
• IEEE 802.1AR — the standard for device identity via IDevID/LDevID.
• IETF EST (RFC 7030) and ACME (RFC 8555) — the two dominant automated issuance protocols.