A machine identity is how a thing proves it is that thing. A workload presents a certificate, a pod assumes a cloud role, a CI job exchanges its own signed token for a short-lived credential. No secret sits in a file, and nothing needs an administrator to create an account.
The term comes from infrastructure security, and it is narrower than the phrase most identity products use. A machine identity is one kind of non-human identity, and it is not a service account, though the three words get used as if they were interchangeable.
NON-HUMAN IDENTITY (the umbrella: anything that acts without a person) +---------------------------------------------------------------------+ | | | MACHINE / WORKLOAD IDENTITY SERVICE ACCOUNT | | the thing proves what it is an account a process signs | | - X.509 cert, SPIFFE ID in with | | - cloud role assumed by a pod - a username and a secret | | - short-lived, issued on demand - long-lived, usually | | infrastructure security's word IT and app admin's word | | | | API KEY / TOKEN OAUTH GRANT AI AGENT | | a credential, no account delegated human decides at | | access runtime | +---------------------------------------------------------------------+ for a SaaS-first company at 300 people: the right-hand column is the whole problem; the left-hand column matters when you run your own services
What is the difference between the three terms?
| Non-human identity | Machine identity | Service account | |
|---|---|---|---|
| What it covers | Anything that acts without a person | A workload or device proving what it is | An account a process signs into |
| Typical credential | Anything: a password, a key, a token, a grant | An X.509 certificate, a SPIFFE ID, an assumed role | A password, key or token, usually long-lived |
| Who issues it | Whoever created the thing | The platform, at runtime | An administrator, once |
| Lifetime | Whatever nobody changed | Minutes to hours | Years |
| Who owns the problem | IT and security | The platform team | IT and application admins |
| Where it fails | No owner, no expiry, no review | Expiry nobody tracked, trust misconfigured | The secret in the password manager |
Why the fix differs
The distinction matters because the fix is different. A machine identity problem is solved by using the platform's issuance mechanism, so the work is configuration and it lands on the team that owns the platform. A service account problem is solved by governance: an owner, a scope, an expiry and a review, none of which any issuance mechanism supplies. Buying a tool for the first will not touch the second, and the two problems fail on different clocks. A misconfigured workload identity fails immediately and loudly, because the service cannot authenticate. An ungoverned service account fails silently for years, which is why one shows up in an incident channel and the other shows up in an audit finding.
Where the two words came from
Machine identity is vocabulary from infrastructure security, where the objects are certificates, meshes and public key infrastructure, and the recurring failure is an expiry nobody tracked taking a service offline. Service account is vocabulary from IT administration, where the objects are accounts in a directory or an application, and the recurring failure is standing privilege with no owner. NIST SP 800-207 bridges the two by treating non-person entities as subjects in their own right. Such a subject authenticates on every request and is authorized against policy, rather than trusted because of where it sits on the network. The bridge is conceptual, and in practice the two populations are still administered by different teams using different tools.
How does a workload identity work in practice?
Three shapes cover most of it, and none of them stores a secret.
A role assumed at runtime
The cloud platform knows which workload is running, so the workload asks for a credential and gets one scoped to a role, valid for minutes. On Kubernetes this is the service-account-to-role mapping the cloud providers document, such as IAM roles for service accounts on managed clusters, and the pod never holds a key.
Federation from another issuer
A CI system, a cloud or an identity provider signs a token asserting what the job is, the target platform trusts that issuer for a specific role, and the credential is minted per run. Workload identity federation is the name the cloud providers give this pattern. The trust configuration is its whole control surface. A wildcard in the subject condition grants the role to every job in the repository rather than to the one job intended.
OIDC with JWT doesnt need any long lived tokens. For example, I can safely grant gitlab the ability to push a container to ECR just using a short-lived token that gitlab itself issues.
A certificate issued by a mesh or a CA
Each service gets an identity document and a short-lived certificate, renewed automatically, and services authenticate each other with it. SPIFFE is the open standard for this, and a service mesh is the usual way it arrives.
The reason to prefer any of the three is not elegance. It is that a departure stops being an event:
Basically, there are no permanent keys for anything. Slightly annoying to have to wrap some clis in scripts that generate the short-lived token, but it feels really magical to have services securely calling each other without any explicit keys or password to even store in our vault.
When should a mid-market company care?
It depends on what the company runs, and being honest about that is more useful than a maturity model. Three cases cover almost every mid-market stack.
The company runs its own services
Machine identity is then the platform team's answer to secrets in configuration files, and the mechanism should be whatever the cloud provider already offers rather than a key in a vault. The decision is usually made once, when the first service needs to call the second, and it is far cheaper to make correctly at that point than to unwind later. The evidence an auditor eventually asks for is the issuance and trust configuration rather than a list of credentials, because there is no list: the credentials existed for minutes.
The company is mostly SaaS
The population that causes findings is then service accounts, API keys, OAuth grants and agents inside applications. Certificates are not the problem, and a machine identity product will not see any of it, because none of those objects is a workload proving what it is. The relevant question for this company is not how credentials are issued. It is who owns each identity that already exists and what happens to it when that person leaves.
The company is both
This is the common case at 300 people, and it produces two populations, two owners and two mechanisms. The risk lives in the seam between them. A workload that reaches a SaaS application does so with a credential from the second population. That credential is usually an API key held in the platform team's secret store, unknown to whoever governs the application it reaches. Anything that crosses the boundary needs a single owner recorded on both sides, or it belongs to nobody twice over.
What does governing the two populations look like?
The properties are the same and the mechanisms differ, which is the whole point of keeping the words apart.
What holds for both populations
Four properties decide whether either population is governed: a named owner, a scope no wider than the job, an expiry that arrives without anyone remembering it, and a review that someone with standing actually performs. Neither population is exempt from any of the four. What changes is where each property is enforced and what the evidence for it looks like.
| Workloads | SaaS non-human identities | |
|---|---|---|
| Owner | The team that deploys the service | A named person, recorded when the identity is created |
| Credential | Issued at runtime, minutes long | Rotated, or replaced by a short-lived token where the application allows it |
| Scope | The role the workload assumes | The permissions inside the application |
| Expiry | Automatic, per request | A date on which it is re-justified |
| Review | The issuance policy and trust configuration | The identity itself, routed to its owner beside the people |
| Inventory | The mesh or cloud console | Every application's own account and token lists |
Why the split matters when buying
The inventory row is the one that decides tooling. A platform that governs workloads reads a mesh or a cloud control plane, which is a small number of well-structured sources. A platform that governs the SaaS population reads every application separately, including the applications with no provisioning interface, which is a large number of badly structured ones. No product does both well today, and a company that assumes otherwise ends up with two thirds of its non-human identities in neither system.
Iden governs the SaaS half of this picture: the service accounts, integration users, tokens, grants and agents inside applications, each with an owner and a place in the review, listed on the Identities screen beside the people. Certificates and cluster workload identities stay with the platform that issues them, which is the right home for them, and the boundary is worth stating rather than blurring. The feature behind it is Service accounts, API keys and agents.
433 Identitäten, 321 davon human, 112 nicht. cc_github und das MCP-Token stehen in derselben Tabelle wie Amy Lee, mit denselben Spalten und denselben Offboarding-Zuständen.
How does SCIM treat machine identities?
It does not model them at all, in either population.
Why a directory never sees a workload
SCIM provisions users and groups from a directory into applications, and a workload is neither. A certificate is issued by a certificate authority, and an assumed role is granted by a cloud control plane at the moment of the request. An application's integration user is created inside that application by an administrator. None of the three passes through the identity provider, so none of them appears in the directory that SCIM synchronises. That is why the identity provider's user count is never the identity count.
What the inventory looks like instead
Two inventories are needed, and they are built by different means. The workload inventory comes from the issuing system, and its useful column is expiry, because an untracked certificate expiry is an outage rather than a finding. The SaaS inventory comes from reading each application's own account and token lists, and its useful column is owner. The failure mode there is an identity that outlives the person who understood what it was for. Finding non-human identities therefore means reading each system rather than querying one, and accepting that the two halves of the answer arrive in different shapes.