Workload identity vs secrets: When to use each

Asking whether to adopt workload identity or a secrets manager is the wrong question. You can't fully replace one with the other.

Workload identity eliminates the need for long-lived credentials for cloud-native services authenticating with cloud providers. Secrets managers govern credentials that cannot be eliminated, such as API keys, database passwords, and credentials for services that do not support federated identity.

Not only do they govern different types of credentials, but they can also work together to create a more secure authentication workflow. This article explains the distinction between workload identity and secrets management. By the end, you'll have a clear decision framework for determining which security mechanism governs which credential type, along with concrete guidance on how to combine them.

What workload identity is

Workload identity is the mechanism that assigns a cryptographic identity to a software workload without storing a long-lived credential. That identity is derived from runtime attributes that a workload presents to a platform in exchange for time-bound, tightly scoped access tokens. The platform, which is usually a cloud provider such as AWS, Azure, or GCP, or a cloud-native tool like Kubernetes, verifies workload attributes (such as namespace, service account, and instance metadata) at runtime to enable the federated exchange. It is important to note that federation only provides cryptographic proof of what the workload is, not what it knows.

How workload identity federation works

Think of a scenario in which identity federation occurs between a workload like a payment microservice pod running in a Kubernetes cluster (its host platform) and a target service, such as a GCP storage API. In an OpenID Connect (OIDC) federation flow, a trust relationship is first established between the host platform and the target service by configuring the target service to trust the platform's identity issuer.

During federation, the workload presents a JSON Web Token (JWT) (which contains claims about its attributes) that was issued by its host platform. The target service then validates the token against that trusted issuer and grants short-lived access. This process closely aligns with the broader zero-trust guidance of NIST Special Publication (SP) 800-207A, which highlights Secure Production Identity Framework for Everyone (SPIFFE) as a standards-based approach for establishing and verifying workload identities. The goal is that, regardless of the implementation, the workload's identity must be verified before access is granted.

What workload identity eliminates

Workload identity management removes the need to use cloud service account keys and eliminates the risky pattern of baking credentials directly into configurations such as deployment manifests, Dockerfiles, environment variables, or code repositories. In May 2026, the NHI management group highlighted that 96% of organizations store secrets outside of secrets managers in vulnerable locations; workload identity federation eliminates this failure mode. It essentially solves the secret-zero bootstrap problem for cloud-native services. For example, an application running on an Amazon EC2 instance would historically require an AWS access key to establish trust with other AWS services. Instead, workload identity shifts trust to a cryptographically verified identity relationship.

Workload identity reduces reliance on long-lived credentials, improving the security posture of cloud-native systems. However, static credentials remain in some workflows, and that's where secrets management has a role to play.

What secrets management does

Secrets management governs credentials that lie outside the boundaries of workload identity. These secrets cannot be replaced by a cryptographic identity and therefore need a security governance layer to oversee their lifecycle.

What workload identity cannot replace

A core architecture of workload identity is that systems seeking to participate in federated trust must support the evaluation of workload runtime metadata. So, naturally, workload identity cannot replace secrets for systems that lack that capability. These secrets include API keys for third-party providers such as Stripe, Twilio, and SendGrid; credentials for on-premises databases such as SQL Server and Oracle; and webhook secrets or shared tokens used by partner integrations such as Shopify. Referring to this class of credentials, Aembit highlighted in a blog post that, "The credentials have to exist, so the question is how tightly you can manage their lifecycle." This is what a secrets manager answers.

What a secrets manager adds

To oversee the safe creation, usage, and expiration of these secrets, a secrets manager handles:

• Centralized storage: Eliminates secrets sprawl by managing all persistent credentials securely at rest in a single place, enabling centralized security policies
• Automated rotation: Coordinates scheduled secret updates without downtime
• Per-access audit logging: Provides an immutable, forensic audit trail to track secret access and usage patterns
• Fine-grained role-based access control (RBAC): Restricts human users and non-human identities to only the necessary permissions and secrets they need

Understanding the roles of workload identity and secrets managers helps you decide when to use each or when you need both.

When to use workload identity

To decide when to use workload identity, ask yourself one question: Do the target resource and workload host platform support OIDC or SPIFFE trust configuration? The workload must run on a platform that issues a verifiable identity, and the target resource must be able to verify that identity. This usually covers cloud-native services authenticating to cloud providers, Kubernetes pods authenticating to cluster resources, and CI/CD pipelines authenticating to cloud providers via OIDC.

Cloud-native workloads and cloud provider resources

Cloud providers can serve as identity providers by assigning managed identities, so developers don't have to manage credentials. In AWS, workloads running on EC2 or Lambda authenticate with other AWS services, such as S3 or DynamoDB, using identity and access management (IAM) execution roles. Google Cloud workloads leverage native service account bindings to authenticate to GCP resources. Azure services use Microsoft Entra Workload ID to grant their cloud-native applications automatic access to Azure resources. Each cloud provider implements workload identity through its own native identity model.

Kubernetes workloads

Standard service account tokens used within Kubernetes are static and can persist on disk indefinitely. Pods authenticating to internal cluster resources (like the Kubernetes API server) or outward to cloud provider services can instead do so via workload identity. No need to store cloud keys or service accounts within native Kubernetes Secret objects. Those credentials are often mounted as files within a pod's filesystem and can be accessed if the pod is compromised.

CI/CD pipelines authenticating to cloud providers

Pipelines, such as GitHub Actions runners or GitLab CI jobs, that try to interact with cloud providers can mint short-lived OIDC tokens during execution. They can use these tokens to securely access resources and authenticate with providers without storing credentials.

When secrets management is still required

Workload identity reduces the scope of what needs to be stored. It does not eliminate the need for secrets management. Any credential issued by a third party or legacy system that can't be converted to a federated identity requires a secrets manager. And that category can be seen across various production environments.

Third-party API credentials

SaaS providers like Stripe, Twilio, Datadog, and SendGrid sit outside the cloud provider's trust domain. These vendors do not support OIDC or SPIFFE-based workload identity federation, so they issue static strings. These strings need to be securely stored and programmatically managed.

On-premises databases and legacy services

Most legacy mainframes (such as SAP ECC6.0 and IBM mainframes), on-premises databases, and vintage SQL servers predate modern federated identity capabilities. These systems speak and understand connection strings, usernames, and passwords, so they require management. While secrets managers provide dynamic secrets features that replace long-lived credentials with short-lived credentials, they do not eliminate the need for credentials altogether. A database, for example, would still require credentials for authentication; a secrets manager only automates their orchestration.

Multi-cloud and cross-boundary integrations

Core cloud resource integrations (like AWS Lambda to GCP storage) can federate. However, in complex multi-cloud environments, where you may have a CI/CD pipeline handling a mixture of OIDC-capable cloud APIs and non-OIDC services, you can't rely on a single cloud provider's native identity mechanism. A secrets manager can act as the connective tissue that securely supplies the remaining static credentials.

The table below serves as a quick decision framework for determining when to use workload identity and when secrets management remains necessary.

Doppler is a secrets manager that can be used in areas where a secrets management solution is still required. It centralizes credentials that workload identity cannot reach and applies rotation and audit controls to them.

Doppler also allows you to scope access to specific secrets rather than granting broad access across an entire environment to both human and machine identities. Scoped access is even more critical now that AI agents can assume identities to carry out tasks on behalf of humans.

How AI agents change the calculation

The inclusion of AI agents in workflows is making the boundary between workload identity and secrets management increasingly important. AI agents that hold long-lived credentials create the same blast-radius risks as any overprivileged identity. A blog post on DEV Community about agents' unchecked access sparked the following comment: "The 'one big API key the agent holds' pattern is a disaster waiting to happen: it's a long-lived secret with broad scope that can leak, can't be attributed to a specific action, and gives a compromised agent the keys to everything."

This is a growing concern that deserves attention. Gartner predicted that 40 percent of enterprise apps will feature task-specific AI agents by the end of 2026, each one requiring its own identity, scoped access, and audit trail. The solution is not choosing one mechanism over the other. For example, an AI agent calling AWS and Stripe separately would require workload identity for AWS and a secrets manager to securely manage Stripe API credentials. As AI agents become more common, providing secure, time-bound, and scoped access is increasingly a shared responsibility between workload identity and secrets management.

Using workload identity and secrets management together

A standard production environment typically combines cloud-native resources with third-party or legacy systems. Both credential-handling mechanisms are actively used in such environments. So you see, workload identity and secrets management really aren't competing entities. They are meant to be used additively.

The combined pattern

The obvious pattern is to use both for their separate concerns: workload identity handles cloud provider authentication, and a secrets manager handles the remaining credentials. But workload identity can also play a part in retrieving secrets from a secrets manager.

A pipeline that needs to sync secrets from a secrets manager would traditionally require a static service token for the manager. Instead, using workload identity, the pipeline can mint a signed JWT for the manager to validate. The secrets manager uses metadata embedded in the token, such as repository, branch, workflow, namespace, or service account claims, to scope and restrict which secrets are returned, rather than broadly exposing all secrets to the pipeline. This same combination pattern can be used across Kubernetes and cloud environments when interacting with secrets managers.

What Doppler adds to this architecture

Doppler enables this combination pattern by being able to support native OIDC workload identity federation across cloud-native workflows and CI/CD pipelines. It integrates with workload identity by scoping secret access to specific identities and service configurations. For example, in a Kubernetes cluster, you can use the Doppler Kubernetes Operator and configure a trusted identity inside Doppler to pin the target cluster's issuer URL and map specific subject strings.

These identity mappings also have activity history records in Doppler to track usage and support automated rotation workflows for the underlying static secrets. To use Doppler with your workload identities, get started for free.

Next steps

You now understand what workload identity is, when it applies, and the categories of credentials where secrets management remains necessary. Audit your credential inventory, apply workload identity to cloud-native workloads first, then use a secrets manager for the remaining classes of credentials.

Doppler covers the second half of that plan. It holds the credentials workload identity can't reach, applies scoping, rotation, and audit logging to them, and connects to your workloads over OIDC so pipelines and clusters authenticate with their own identity instead of a stored token. Start free or talk to our team about your setup.