Secretless Azure workload identity and token exchange with tokenex

At a glance

What this is: This article explains how secretless Azure access can exchange external OIDC identity tokens for short-lived cloud credentials through federated identity and a user-assigned managed identity.

Why it matters: It matters because IAM teams need to govern the trust boundary, token lifetime, and authorization model when workloads stop using stored secrets and start using federated credentials.

Context

Secretless access means workloads authenticate without storing long-lived secrets on disk, in config files, or in environment variables. In this model, a workload proves its identity externally, then the cloud platform issues short-lived credentials and enforces authorization natively.

For identity governance, the important change is not simply that secrets disappear. The control problem shifts to how federation is established, how managed identity scopes are constrained, and how quickly issued credentials lose value if runtime execution is compromised.

That makes the topic directly relevant to NHI governance and workload identity architecture. The article is a concrete example of replacing persistent credential custody with ephemeral, federated access.

Key questions

Q: What breaks when workloads still rely on copied secrets across clouds?

A: Secret-centric access breaks because revocation, rotation, and audit scope all depend on knowing every place the credential was copied. In multi-cloud estates, that means one leaked key can outlive the system that issued it. Federation avoids that failure mode by moving access to runtime identity verification rather than persistent secret handling.

Q: Why do federated workload identities reduce exposure compared with client secrets?

A: Federated workload identities reduce exposure because the credential is issued on demand, is short-lived, and is tied to a specific trust relationship rather than a reusable secret stored inside the workload. That narrows replay opportunities and removes common theft points such as configuration files and CI variables. The remaining risk is mis-scoped access, not secret persistence.

Q: How should teams verify that native authorization is actually limiting access?

A: Run the workload against an out-of-scope resource and confirm that Azure returns a denial rather than a fallback success path. That test shows whether RBAC and managed identity scope are doing the real work after authentication succeeds. If the workload can still read or write beyond its intended boundary, the control is too broad.

Q: Should organisations replace secret rotation with secretless federation for workloads?

A: When a workload can authenticate through federation and the platform supports native authorization, secretless access is usually a better control objective than perpetual rotation of long-lived secrets. Rotation still matters for legacy paths, but it does not remove the underlying persistence problem. The right decision is to prioritise elimination of reusable secrets where the trust model allows it.

Technical breakdown

How federated workload identity replaces stored cloud secrets

Federated workload identity separates authentication from authorization. An external identity provider asserts who the workload is, then Azure exchanges that assertion for a short-lived access token bound to a user-assigned managed identity. That differs from embedding a client secret, where the same credential can be copied, reused, and rotated manually. The important architectural point is that the workload never needs a reusable secret to reach Azure APIs. Instead, the trust relationship is expressed in federation settings, issuer and subject matching, and the identity object's own access scope.

Practical implication: govern the federation trust path as strictly as any privileged credential.

Why secretless access changes credential exposure risk

A secretless flow removes the most common harvestable artifacts: static access keys, long-lived tokens, environment-variable secrets, and credentials written to disk. That matters because attackers who gain runtime execution usually search file systems and process environments first. If there is nothing persistent to steal, compromise becomes harder to turn into later reuse. The model does not eliminate abuse during the active session, but it sharply narrows the time window in which stolen credentials retain value. This is why secretless patterns are most effective when paired with short expiry and tight authorization boundaries.

Practical implication: reduce blast radius by eliminating reusable credentials rather than relying on faster rotation alone.

How native authorization still enforces least privilege

Token exchange does not replace authorization. Azure still decides what the managed identity can do through its native RBAC and resource-scoped permissions. That separation matters because a valid token is only one half of access control. A workload can authenticate successfully and still receive a 403 when the managed identity lacks the right resource-group scope. In other words, secretless access changes how credentials are issued, not the need to design permissions carefully. The governance challenge is to keep trust establishment, identity binding, and permission scope aligned across environments.

Practical implication: review managed identity scope and RBAC together, because successful authentication does not guarantee access.

Threat narrative

Attacker objective: The attacker wants to turn transient runtime access into reusable cloud access and then extend that access beyond the original workload boundary.

1. Entry occurs when an attacker gains runtime execution inside a workload, CI/CD runner, or container that uses secretless access instead of stored cloud secrets.
2. Credential harvesting is blunted because there are no long-lived secrets on disk, in configuration files, or in environment variables for the attacker to extract and reuse.
3. Impact is limited to the short-lived token window and the managed identity's native authorization scope, which reduces long-term lateral reuse but does not stop abuse inside the active session.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Credential custody is no longer the primary control point for workloads that authenticate through federation. Once access is tokenised and short-lived, the real governance question becomes whether the federation trust path is correctly constrained. That changes the operating model for NHI programmes because the risk is no longer only stored-secret theft, but also trust configuration drift and scope creep. Practitioners should treat federation setup as part of privileged identity governance, not just application plumbing.

Secretless access exposes the limits of secret rotation as a defence strategy. Rotation helps only when there is a durable secret to rotate, but this model removes that object from the architecture. The result is a named shift from credential rotation to credential elimination, which is a stronger security posture for machine access. The implication for identity teams is that lifecycle controls must move upstream to issuance, binding, and authorization design.

Ephemeral credential trust debt: the security debt created when an organisation assumes that removing a stored secret automatically means access is fully governed. That assumption fails if the workload can still obtain broad native permissions through a poorly scoped managed identity. The implication is that governance must focus on the lifetime and scope of issued access, not just on secret removal.

Managed identity scope is the decisive control variable in secretless Azure access. A secretless design reduces exposure, but only the assigned RBAC scope determines the blast radius when the token is valid. This is why the article's 403 scenario is useful: it shows the model working as intended when authorization boundaries are narrow. Practitioners should use that boundary as a governance checkpoint rather than treating token exchange as a complete control plane.

Federated workload identity is becoming the baseline pattern for modern cloud NHI governance. The article reflects a broader market move away from static workload secrets toward externally asserted identity and native cloud authorization. For identity architects, that means workload identity, secrets management, and cloud IAM can no longer be designed as separate disciplines. The practical conclusion is to align federation policy, managed identity scope, and credential lifecycle in one governance model.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Secretless workload access should now be treated as an NHI governance pattern, not just a developer convenience. The architectural win is that there is no credential artifact to steal, but the governance burden shifts to federation trust, managed identity scope, and lifecycle ownership.

Ephemeral credential trust debt: teams can remove static secrets and still leave overly broad access in place. That is why secret elimination and permission scoping must be governed together, especially in CI/CD and workload automation.

For identity programmes, the practical signal is simple: if a workload can still do too much after the secret disappears, the programme has only solved custody, not control. That is the point where workload identity, secrets management, and cloud IAM need a single operating model.

For practitioners

• Map every workload secret to an issuance path Inventory which CI systems, containers, and automation jobs still depend on client secrets, API keys, or long-lived tokens. Replace each one with a federated issuance path only where the trust boundary, issuer, and subject claims are explicit and reviewable.
• Scope managed identities to the narrowest resource boundary Treat the managed identity as the authorization boundary and verify that RBAC assignments match the exact resource group, subscription, or service scope the workload actually needs. Broad assignments undermine the security gain from removing secrets.
• Validate token lifetime and refresh behaviour Confirm that access tokens are short-lived, refreshed automatically, and never written to disk or exported as static environment variables. If token material persists beyond memory, the secretless model is incomplete.
• Test authorization failure paths deliberately Use an out-of-scope resource or subscription to verify that the workload receives a clean denial rather than broader fallback access. This proves that native authorization, not just authentication, is enforcing the boundary.
• Reclassify workload identity as a governance subject Bring federated workload access into IAM, PAM, and NHI review cycles so that federation trust, issuer claims, and credential lifecycle are audited together. Secretless architecture still needs ownership, review, and exception handling.

Key takeaways

• Secretless Azure access eliminates a common credential theft path, but it does not eliminate the need for careful governance of trust and scope.
• The decisive control is no longer secret rotation alone, because the important boundary is where federation is trusted and what the managed identity can reach.
• Identity teams should treat workload federation, authorization scope, and lifecycle review as one programme rather than three separate controls.

Key terms

• Workload Identity Federation: A mechanism allowing workloads in one environment to authenticate to another using short-lived tokens rather than stored credentials, based on mutual trust between identity providers.
• Secretless Access: Secretless access is a pattern where workloads authenticate and receive access without relying on long-lived embedded credentials. It typically uses runtime identity verification, federation, and short-lived authorization decisions. The goal is to reduce exposure from hardcoded or reusable secrets while keeping machine-to-machine access functional.
• 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

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.