What is a machine identity?

What counts as a machine identity?

The term comes from infrastructure and cryptography, not from IAM teams. A machine identity is whatever proves that a piece of hardware or software is what it claims to be. That proof is almost always a cryptographic credential: a certificate issued by a certificate authority, a key pair, or a signed token. When a browser trusts a web server, when one microservice calls another over mutual TLS, or when a build system signs an artifact, a machine identity is doing the work.

The category is broad because infrastructure is broad. It spans physical devices, virtual machines, containers that live for seconds, and the workloads and applications running on all of them.

How does machine identity relate to non-human identity?

Machine identity is the older, infrastructure-rooted term. It grew out of PKI, TLS, and SSH, and it centers on cryptographic material: certificates, keys, and the systems that issue and rotate them. Non-human identity, or NHI, is the newer umbrella. NHI covers everything that authenticates without a human typing a password, which includes machine identities but also service accounts, OAuth app registrations, API tokens, bots, and AI agents.

The practical distinction matters for ownership. Machine identity programs usually live with infrastructure and platform teams, because the pain shows up as expired certificates and broken TLS handshakes. NHI programs increasingly live with identity and security teams, because the pain shows up as ungoverned access. A workload certificate is both a machine identity and a non-human identity. A marketing team's OAuth integration is an NHI but would rarely be called a machine identity. The scale problem is shared: machine identities outnumber human identities 82 to 1 in the average organization, according to CyberArk's 2025 Identity Security Landscape.

Why is the certificate lifecycle so painful?

Every certificate is a countdown timer. It must be requested, issued, installed, monitored, renewed, and eventually revoked or retired. Miss a renewal and the machine does not degrade politely, it stops being trusted at all. CyberArk's 2025 State of Machine Identity Security Report found that 72% of organizations experienced at least one certificate-related outage in the past year.

The timers are also getting shorter. In April 2025 the CA/Browser Forum passed Ballot SC-081v3, which steps the maximum validity of public TLS certificates down from 398 days to 200 days as of March 15, 2026, then 100 days in March 2027, and 47 days by March 2029. A renewal process that a team could survive doing annually by hand becomes impossible at a 47-day cadence. Shorter lifetimes are good for security, since stolen or misissued certificates expire quickly, but they turn certificate automation from a nice-to-have into a requirement.

What are the main risks of unmanaged machine identities?

The risks split into two families: availability and compromise.

• Outages from expiry: an expired certificate on a load balancer or internal API takes down everything behind it, often during off-hours when the original owner is long gone.
• Unknown inventory: certificates and keys issued outside a central process, by ad hoc scripts or individual engineers, are invisible until they fail or get stolen.
• Stolen or leaked keys: a private key in a repo or a long-lived SSH key on a forgotten host lets an attacker impersonate the machine indefinitely.
• No assigned owner: when the engineer who requested a certificate leaves, renewal responsibility often leaves with them.
• Real-world compromise: 50% of security leaders reported incidents or breaches linked to compromised machine identities in the last year, per CyberArk's 2025 report.

How do you manage machine identities well?

Mature machine identity management follows a few consistent principles, regardless of which tools implement them.

• Build a complete inventory: you cannot rotate or renew what you do not know exists, so discovery across clouds, clusters, and data centers comes first.
• Automate issuance and renewal: protocols like ACME and workload identity frameworks like SPIFFE/SPIRE remove humans from the renewal loop entirely.
• Prefer short lifetimes: short-lived credentials shrink the window in which a stolen key is useful and force automation to exist.
• Assign ownership: every certificate and key needs a responsible team, not a responsible individual.
• Watch behavior at runtime: issuance controls say what a machine may do; only runtime observation shows what it actually does with its identity.

What does a machine identity compromise look like in practice?

What follows is a hypothetical composite of how these incidents typically unfold. A platform engineer wires up a nightly batch job that calls an internal payments API over mutual TLS. To keep deployment simple, the client certificate and its private key are baked into the container image. Months later that image lands in a registry misconfigured to allow anonymous pulls. An attacker scanning for exposed registries pulls the image, unpacks its layers, and finds the key sitting in /etc/certs, exactly where the Dockerfile left it.

From that point the attacker does not break anything. They present the certificate, the payments API validates the chain, and the connection is indistinguishable from the legitimate batch job. There is no MFA challenge, because machines do not do MFA. There is no impossible-travel alert, because most detection logic is tuned for humans. The certificate is valid for a year, so the access quietly persists through patch cycles and reorgs. And because the certificate was trusted by the whole internal CA domain rather than scoped to one service, the attacker can enumerate and reach most of the internal mesh while looking like routine service traffic.

Every step in that story is a control failure with a name: a private key stored in an image instead of a secrets manager, a year of validity instead of ephemeral credentials, domain-wide trust instead of narrow scoping, and nothing watching how the credential behaves after issuance. It is also not exotic. CyberArk's 2025 State of Machine Identity Security Report found that API keys and TLS certificates were the leading vectors in machine identity incidents, each exploited in 34% of cases.

How do you stand up a machine identity program from scratch?

Most organizations do not get to design this cleanly; they inherit thousands of certificates and keys issued over a decade by different teams. The sequence below works because each step makes the next one cheaper, and because it attacks outage risk and compromise risk at the same time.

• Discover before you decide: query every certificate authority, cloud account, and cluster you operate, check Certificate Transparency logs for certificates issued against your domains that you did not know about, and sweep hosts and repos for private keys. Treat this as the first stage of an ongoing NHI lifecycle, not a one-time audit.
• Bind every credential to an owning team: a certificate nobody owns is a future 2 a.m. outage. Record the owner, the system it serves, and the blast radius of its expiry in the same inventory.
• Automate the biggest outage sources first: put ACME in front of public-facing TLS so renewal happens without a human, then work inward. The CA/Browser Forum's move to 47-day maximum validity by March 2029 means anything still renewed by hand is already on borrowed time.
• Issue workload credentials at runtime: frameworks like SPIFFE and SPIRE, or the cloud providers' native workload identity, attest what a workload is and hand it a short-lived certificate on the spot, so nothing long-lived ever touches a repo or an image.
• Eliminate static cross-cloud keys: workload identity federation lets a workload in one cloud authenticate to another by exchanging its native identity token, removing the exported service account key entirely.
• Vault what cannot yet be ephemeral: legacy systems that require static keys should draw them from a token vault with automatic rotation, not from config files.
• Watch behavior after issuance: wire machine identity events into identity threat detection and response so a credential that starts authenticating from a new network path or at an unusual volume raises an alert, not just an expiry reminder.

How does a certificate actually prove identity?

The mechanics matter because they explain both the strengths and the failure modes. A machine generates a key pair and keeps the private half secret. It sends a certificate signing request containing the public key and its claimed identity to a certificate authority. The CA verifies the claim, signs the certificate, and from then on anyone who trusts the CA can verify the machine's identity by checking the signature chain. During a TLS handshake the machine also proves possession of the private key, which is what stops a copied certificate alone from being useful. In mutual TLS both sides do this, which is why mTLS is the machine half of a zero trust architecture: every connection is authenticated in both directions, regardless of network location.

The weak point is revocation. If a private key leaks, the CA can revoke the certificate, but revocation checking via CRLs and OCSP has always been unreliable in practice, and many clients fail open when the check does not complete. The industry's real answer is expiry: if certificates only live for days, a stolen one dies quickly whether or not revocation works. That is the security logic behind the shrinking lifetimes, and it is why short-lived credentials plus automation is the direction the whole field is converging on.

What are the most common machine identity mistakes?

The same handful of mistakes shows up in nearly every environment, and most of them are inherited habits rather than deliberate decisions.

• Tracking certificates in spreadsheets: 34% of organizations still rely on manual processes, per CyberArk's 2025 report, and the outage numbers show what that costs, with 45% of teams reporting certificate-related outages weekly, up from 12% in 2022.
• Sharing one wildcard certificate across dozens of services: it saves issuance work and means a single stolen key impersonates everything under the domain.
• Granting machine credentials human-sized privileges: CyberArk's 2025 Identity Security Landscape found 42% of machine identities have privileged or sensitive access. Machines rarely need standing privilege at all; zero standing privileges and just-in-time access apply to workloads as much as to admins.
• Solving TLS while ignoring everything else: a program that automates certificates but leaves API keys, SSH keys, and signing keys unmanaged has only covered the most visible slice of the population.
• Letting the inventory rot: discovery run once and never repeated turns into identity sprawl within a quarter, because machines are created continuously and nobody deprovisions what nobody remembers.
• Declaring victory at renewal automation: lifecycle automation prevents outages, but a certificate that renews perfectly can still be stolen and misused. Issuance hygiene without runtime observation is half a program.

Frequently asked questions

Related terms