Topic starter
10/06/2026 11:36 pm
TL;DR: Tokenless access is shown in a flow that exchanges external OIDC identity tokens for short-lived Azure credentials through federated identity and User-Assigned Managed Identity, eliminating stored secrets, disk persistence, and manual rotation in the example flow, according to Riptides. Secretless access reduces blast radius, but it also shifts the control problem to trust establishment, native authorization, and credential lifetime management.
Editorial analysis by NHI Mgmt Group, based on content published by Riptides: “Secretless Azure access with tokenex: Federated Identity via User-Assigned Managed Identity”.
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
Bottom line: Secretless Azure access eliminates a common credential theft path, but it does not eliminate the need for careful governance of trust and scope.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
12/06/2026 5:51 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Secretless Azure workload identity and token exchange with tokenex
This post was modified 2 days ago by NHI Mgmt Group