Use workload identity when no human should be in the loop, such as CI runners, automation jobs, or service-to-service tasks. In those cases, neither PKCE nor device flow is the right pattern because the objective is not interactive user authentication. Workload identity avoids forcing a browser-mediated flow onto a non-interactive workload.
When workload identity is the better choice
Use workload identity whenever the actor is a non-interactive workload rather than a person. That includes CI runners, scheduled automation, service-to-service calls, and infrastructure tasks that need a bounded, machine-native trust relationship. In those cases, the control objective is to authenticate the workload itself, not to emulate a human login flow.
That distinction matters because user-based CLI authentication is built around an interactive person with a browser, MFA, and a session lifecycle. Workload identity replaces that with a workload-bound credential path, usually backed by trust establishment, attestation, or federation. The result is cleaner authorization, fewer long-lived secrets, and less operational friction for automation at scale.
Workload identity is also the right answer when the same automation must run in multiple environments or clouds. A Cloud Workload Identity Guide is useful here because the core design goal is to avoid static keys while still letting workloads obtain short-lived access in a controlled way. If the task can be expressed as machine-to-machine access, that is usually a stronger fit than issuing a user token and hoping the workflow stays non-interactive.
Why user-based CLI auth breaks down for automation
User-based CLI flows are acceptable when a person is actually present, for example during ad hoc administration or local developer work. They become brittle when the execution context is ephemeral, headless, or repeated thousands of times. Browser redirects, device approval, and token refresh logic all assume a human can stop and interact at the right moment.
For automation, that assumption creates failure modes that are easy to miss. A runner may expire mid-job, a scheduled task may block on a prompt, or an operator may copy credentials into a pipeline just to make the job work. The more the process depends on human intervention, the more it drifts toward brittle exception handling instead of a reliable machine control.
For the protocol layer behind these decisions, the SPIFFE workload identity specification is a clear external reference because it formalises workload identity, SVIDs, trust bundles, and attestation for service-to-service trust. That model fits the exact problem better than a user-oriented CLI session because it gives the workload an identity that is native to its runtime context.
What to use instead and how to decide
Use workload identity when the access path must be non-interactive, short-lived, and attributable to a specific workload instance or workload class. Use user-based CLI auth only when the human operator is the real security principal and the workflow tolerates interactive authentication. If a job would fail without a browser or manual approval step, it is usually a sign that the wrong authentication pattern is being used.
In practice, the strongest indicator is whether the action should survive human absence. If the task is automation, deployment, backup, integration, or service orchestration, the identity should belong to the workload and the permissions should reflect that narrow purpose. If the task is exploratory or operator-driven, user authentication may still be appropriate, but the CLI should not be repurposed as the primary automation channel.
NHIMG’s NHI Authentication Guide is relevant when you need to compare workload-native authentication patterns such as workload identity federation, mTLS, client credentials, or certificate-based approaches. The practical question is not which flow is fashionable, but which one preserves least privilege and avoids embedding user identity into a machine process.
Risk and Threat Considerations
The main risk is credential misuse caused by forcing human auth patterns onto non-human execution. When teams fall back to copied tokens, shared secrets, or a logged-in developer session, the automation inherits human blast radius and the secret becomes easier to steal, reuse, or leave behind after the job ends.
Failure mechanism: A workload that should authenticate independently instead borrows a user session or a long-lived secret, which creates excessive privilege, poor traceability, and a larger compromise path if the credential is exposed.
Impact: An attacker who reaches the pipeline, runner, or integration point can reuse that credential to move from one automated task to a wider set of systems, turning a single job into a durable access foothold.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Workload identity is a service-to-service authentication problem. |
| IA-5 — Authenticator Management | The question turns on avoiding long-lived secrets and choosing the right credential lifecycle. | |
| AC-6 — Least Privilege | Workload identity should narrow access to the automation's actual task. | |
| Recommendation — Use IA-9 to authenticate workloads with service-native credentials instead of user sessions. Manage workload authenticators with short-lived, revocable credentials and rotation. Apply AC-6 to scope workload permissions to the minimum required. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | User-based CLI auth in automation often leads to exposed or copied credentials. |
| NHI-07 — Long-Lived Secrets | The answer recommends short-lived workload credentials over persistent user tokens. | |
| NHI-05 — Overprivileged NHI | Workload identity must avoid inheriting broad user permissions. | |
| Recommendation — Eliminate exposed secrets from automation and replace them with workload-native auth. Replace long-lived credentials with short-lived workload tokens wherever possible. Restrict workload access so automation cannot exceed its task scope. | ||
Practitioner Guidance
What to verify: Confirm that the workload has a stable trust anchor, a defined owner, and a bounded permission set before removing user-based CLI auth. If you cannot explain who or what the workload is, you do not yet have a safe identity design.
What to measure: Track how many automation paths still depend on interactive sign-in, manually copied tokens, or shared user accounts. Any increase in those patterns is usually a sign that the platform is solving access convenience at the expense of control.
Common mistake: Treating a user token as a shortcut for CI or service automation. That often works first and fails later, when the token expires, the account is rotated, or the blast radius becomes unacceptably broad.
Practitioner takeaway: If no human decision is required at execution time, the identity should be workload-native, short-lived, and narrowly scoped, not a user login repurposed for automation.
Related resources from NHI Mgmt Group
- When should organisations use per-user scoping instead of workload-only identity for agents?
- Should organisations use workload identity instead of request-based JIT for AI agents?
- When should organisations use SPIFFE-style workload identity instead of long-lived secrets?
- When should organisations use identity-based authentication instead of API keys for Azure OpenAI access?