Secretless Azure workload identity and token exchange with tokenex

At a glance

What this is: This is a technical walkthrough of secretless Azure workload access that shows how external identity federation can replace stored secrets with short-lived cloud credentials.

Why it matters: It matters because IAM teams need to govern how non-human identities authenticate and authorise without depending on long-lived client secrets, especially in multi-cloud and CI/CD environments.

By the numbers:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Riptides' guide to secretless Azure access with tokenex

Context

Secretless workload access is not the same as credential-free access. The primary problem is that many cloud and CI/CD environments still depend on long-lived secrets, stored keys, and environment variables that survive well beyond the session that created them. For non-human identities, that creates persistent attack surface where identity proofing, token exchange, and authorization are too often treated as one step.

In this model, the workload proves identity through an external OIDC issuer, and the cloud provider decides what the workload can do through its own native authorization boundary. That separation is the right direction for NHI governance, but it also means teams must govern federation trust, token lifetime, and privilege scope as distinct controls rather than assuming a secretless label solves the problem by itself.

Key questions

Q: How should security teams replace long-lived cloud secrets for workload access?

A: Use federated workload identity so the workload proves its identity with an external token and receives a short-lived native cloud credential in return. Keep the secret out of code, images, and environment variables, then govern the trust binding and the resulting role scope separately. The key control is whether the workload can authenticate without leaving a reusable secret behind.

Q: Why do short-lived credentials reduce workload compromise risk?

A: Short-lived credentials reduce risk because they narrow the replay window and limit what an attacker can reuse after runtime access is obtained. If the credential expires quickly and never lands on disk, compromise becomes harder to turn into persistent access. That said, short life alone is not enough if role scope is too broad or refresh is uncontrolled.

Q: What breaks when federated identity trust is misconfigured?

A: Authentication breaks first, because the cloud provider will not exchange the external token unless the issuer, subject, and audience bindings match exactly. Even when exchange succeeds, access still fails if the identity is not granted the right role at the right scope. This is why trust setup and authorization scope must be governed as separate controls.

Q: How do teams know whether secretless access is actually working?

A: Look for the absence of durable secrets and the presence of controlled token exchange. Workloads should authenticate without client secrets stored in files, images, or environment variables, and access should be granted only through scoped native authorization. If tokens are still recoverable or long-lived artifacts remain, the model is only partially implemented.

Technical breakdown

Federated workload identity and token exchange

Federated workload identity replaces embedded cloud credentials with an exchange flow. A workload presents an identity token from an external OIDC provider, and the cloud platform issues a native access token if the issuer, subject, audience, and federated trust configuration all match. This is not passwordless in the human sense. It is a trust translation layer that turns external identity into platform-native authorization. The important technical shift is that the workload never needs to store a reusable cloud secret, but it still depends on strict binding between the external token and the cloud identity object.

Practical implication: validate federated trust bindings as part of NHI onboarding, not after deployment.

Short-lived credentials and ephemerality

Short-lived credentials change the value of compromise. If an attacker reaches runtime execution, the goal is often credential harvesting from files, configs, or environment variables. A secretless model removes those persistent artifacts and replaces them with in-memory tokens that expire quickly and are scoped to the issuing platform's authorization model. That reduces replay windows and limits post-compromise reuse. The security gain comes from removing credential persistence, not from making the workload harder to execute. Ephemerality only helps when tokens are actually short-lived, refresh is controlled, and the original identity assertion cannot be reused elsewhere.

Practical implication: align token TTL, refresh behaviour, and scope with the workload's real operating window.

Native authorization boundaries in Azure RBAC

The final authorization decision still belongs to the cloud platform. In Azure, the User-Assigned Managed Identity becomes the authorization primitive, while Azure RBAC determines whether the workload can read resources, call APIs, or operate within a scope. That means federation solves authentication transport, not privilege design. A successful token exchange can still fail with AuthorizationFailed if the managed identity has not been granted the correct role at the correct scope. Native policy enforcement is the control boundary that prevents a valid token from becoming overbroad access.

Practical implication: treat role assignment scope as the last-mile control for secretless workload access.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secret persistence, not just secret exposure, is the governing flaw that secretless models address. The article shows that the real problem is not simply whether a credential exists, but whether it remains extractable and reusable after runtime access is gained. Short-lived token exchange removes the persistent artefacts that make workload compromise durable. The practitioner conclusion is that credential persistence should be treated as a design defect, not an operational inconvenience.

Federated identity only works when trust establishment is governed as a first-class control. External issuer, subject, and audience binding define whether a workload can exchange identity for access at all. That means federation errors become identity failures, not application bugs, and they sit squarely in NHI governance. The practitioner conclusion is that trust configuration must be reviewed with the same discipline as role assignment.

Role scope, not token issuance, remains the decisive authorisation boundary. The Azure example makes clear that a valid token can still be rejected or over-permit depending on RBAC scope. Secretless authentication reduces the attack surface, but it does not collapse least privilege into the token exchange step. The practitioner conclusion is to separate identity proof, token exchange, and authorization review in governance workflows.

Runtime credential exchange is the named concept that best captures this model: identity arrives, credentials do not persist. That distinction matters because secretless architectures are often misread as a full security control when they are actually an identity transport pattern with ephemeral outputs. The practitioner conclusion is that teams should measure whether the environment still leaves durable credential artefacts behind after federation is enabled.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories and are 13% more likely to be categorised as critical than code-based leaks.
• For a broader control view, the Guide to the Secret Sprawl Challenge explains how exposure moves across code, chat, and ticketing systems.

What this signals

Secretless workload access will keep gaining traction because the old assumption no longer holds: credentials can be treated as durable governance objects. The programme impact is that identity teams will need to manage federation trust, token lifetime, and native authorization as separate lifecycle controls rather than folding them into one cloud pattern.

Identity persistence debt: any environment that still depends on reusable secrets is accumulating operational risk that grows each time credentials are copied, cached, or manually rotated. Teams should expect more pressure to remove static artifacts from CI/CD, containers, and configuration layers, especially where external identity providers are already available.

The practical signal is that cloud authorisation reviews will need to move closer to runtime. If a workload can obtain a token, the remaining question is whether the scope is narrow enough to survive compromise, which is why alignment to the OWASP Non-Human Identity Top 10 and SPIFFE workload identity specification is becoming more operational than theoretical.

For practitioners

• Inventory persistent credential paths Map where client secrets, access keys, and tokens still live in CI systems, container images, config files, and environment variables. Prioritise the paths that would be reachable if a workload were executed by an attacker at runtime.
• Separate trust binding from role assignment Review federated identity configuration and Azure RBAC as two different controls. One determines whether the external token can be exchanged, and the other determines what the resulting identity can actually do.
• Shorten the useful life of every workload token Set token lifetimes and refresh behaviour so that compromised credentials expire before they can be reused broadly. Match TTL to the minimum task window instead of using generic cloud defaults.
• Audit workload onboarding for federation trust drift Check whether issuer, subject, and audience values still match the intended workload identity after application changes, environment moves, or tenant changes. Drift in these fields creates silent access failure or unintended access paths.

Key takeaways

• Secretless access reduces the harm of compromise by removing persistent credential artefacts, but it does not remove the need for governed trust and scope.
• The strongest evidence in the article is the separation of identity exchange from native authorization, which is exactly where NHI programmes need clearer control boundaries.
• Teams that still rely on static secrets in cloud workloads should treat federation and short-lived tokens as a governance redesign, not just a tooling swap.

Key terms

• Federated Workload Identity: A method of proving a workload's identity through an external issuer and exchanging that proof for a platform-native credential. It removes the need to embed reusable cloud secrets, but it still requires strict trust binding and authorization scoping to be secure.
• Short-Lived Credential: A credential that expires quickly and is intended to exist only for the minimum time needed to complete a task. In workload identity, short-lived credentials reduce replay value and limit post-compromise abuse, but they do not replace proper role design or revocation controls.
• User-Assigned Managed Identity: A cloud identity object that can be assigned to workloads and used as an authorization boundary in Azure. It lets the platform enforce access through native policies and role assignments rather than through stored application secrets.

Deepen your knowledge

Federated workload identity, token exchange, and short-lived cloud credentials are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are replacing stored secrets with secretless access patterns, it is worth exploring.

This post draws on content published by Riptides: Secretless Azure access with tokenex and federated identity via User-Assigned Managed Identity. Read the original.