Workload identity
A workload identity represents software, such as an application, service, script, or container, when it authenticates and accesses other resources.
Software needs an identity too
A background job reading records or a deployment pipeline updating a service needs a way to authenticate and an authorization decision. Its identity represents the software doing that work, rather than an employee signing in interactively.
The terminology varies by platform. Microsoft Entra groups applications, service principals, and managed identities under workload identities. Device identities are a separate category: identifying a laptop is different from identifying the service running on it.
Identity is separate from its credential
A workload may authenticate with a secret, a certificate, or a platform-supported mechanism that avoids a stored long-lived secret. Google Cloud’s Workload Identity Federation, for example, lets external workloads exchange credentials from a trusted identity provider for short-lived access credentials. The trust configuration and resource permissions still determine what the workload can reach.
For an access review, trace the identity back to the software using it. Who owns the job? Who can change its code? Which resources can it reach? A familiar application name answers none of those questions on its own. Workflow approval shows why control of the code matters alongside control of credentials.