If you're managing infrastructure at scale, you already know the problem. Every automated workload, like CI/CD pipelines and Ansible job, needs access to secrets, credentials, and protected resources. And for years we’ve used the same solution: create a service account, generate an API key, inject it into an environment variable, and hope it doesn’t get compromised.
That approach doesn't scale. If you have 500 workloads, you have 500 API keys to rotate, protect, and audit. Each one is a static credential sitting on disk, waiting to become your next incident. The API key becomes secret zero; a skeleton key that, if compromised, unlocks everything behind it.
Today, we're changing that with Workload Identity for Automation, which is now available in Okta Privileged Access.
From possession to attestation
The core shift is simple: we leverage trust through identity. Okta Privileged Access authenticates a workload's native identity from a trusted source like GCP, GitHub Actions, or CircleCI, instead of giving it a static key. This trust is established via a new configuration in OPA called a Workload Connection.
Here's how it works:
- The workload gets a passport. Your workload requests a signed JSON Web Token (JWT) from its native platform—GCP Workload Identity, GitHub Actions OIDC, GitLab CI, CircleCI, or any compliant identity provider.
- OPA validates the passport. The workload presents the JWT to OPA, which validates it against a pre-configured Workload Connection (which the Admin sets up in OPA) – establishing a trust relationship between OPA and the external identity provider.
- OPA grants access. Once verified, OPA issues a short-lived access token. The workload uses it to retrieve secrets, passwords, or SSH certificates. No static credential ever touches the workload's configuration.
The result: No agents to deploy. No keys to rotate. No Secret Zero.
What you can do today
This initial release focuses on machine-to-machine SSH access. A workload authenticates to OPA and receives an ephemeral SSH client certificate, allowing it to SSH from one system to another. For example, Ansible running on a GCP VM executing tasks on remote Linux systems.
This isn't just about protecting the target with short-lived certificates. It's about securing the access path itself. By leveraging the VM's native JWT, you eliminate the need to bootstrap Ansible with a static PAM API key. The automation engine never possesses a long-lived credential.
Here’s a short demo video
What’s coming next1
This release is Phase 1 of OPA's non-human identity strategy. The roadmap includes support for additional authentication mechanisms (AWS STS, Kubernetes), SDKs and sidecars for secrets consumption, a dedicated high-concurrency token exchange endpoint, and a path toward fully dynamic, just-in-time ephemeral credentials.
The maturity model we're building toward: zero static credentials on disk, identity verified by the platform, secrets that expire in minutes, and no standing privilege.
Get started
Workload Identity for Automation is now generally available in Okta Privileged Access. If you're already an OPA customer, you can start configuring Workload Connections today.
To get started, visit Okta Privileged Access documentation.
1 Any products, features, functionalities, certifications, authorizations or attestations referenced but not not currently available or have not yet been obtained or are not currently maintained may not be delivered or obtained on time or at all. Product roadmaps do not represent a commitment, obligation or promise to deliver any product, feature, functionality, certification or attestation and you should not rely on them to make purchase decisions. Okta may decline to make any product feature, functionality, or decline to pursue or maintain any certification, authorization or attestation in its sole discretion.
These materials are intended for general informational purposes only and are not intended to be legal, privacy, security, compliance, or business advice. © Okta and its affiliates 2026.
