Credentials Without Secrets: Federated Identity Credentials as an Unwatched Trust Path

Every mature identity programme has a rhythm for secrets. Client secrets get expiry dates, so forgotten ones eventually stop working. Scanners search code, logs and pipelines for strings that look like keys. Tenant policy can forbid new passwords altogether or cap how long certificates live. Workload identity federation was designed to make most of that machinery unnecessary, and for the problem it solves, leaked and long-lived secrets, it largely succeeds. But it does so by introducing a different kind of credential: a short rule saying that tokens from a particular issuer, about a particular subject, meant for a particular audience, should be accepted as proof of identity. That rule never expires on its own, contains nothing a scanner would recognise, and sits outside the policy controls that govern passwords and keys. It is, in the most literal sense, a credential without a secret. This article argues that federated identity credentials should be governed as standing trust paths rather than as configuration, and shows how to do it with controls that exist today.

Background: what a federated identity credential is

A federated identity credential is an object attached to an application registration or a user-assigned managed identity in Microsoft Entra ID. Microsoft documents five fields: a name, an issuer, a subject, an audiences value and an optional description. The issuer is the URL of the external identity provider; the subject identifies the workload within that provider, in whatever format the provider uses; the audience names the intended recipient, with api://AzureADTokenExchange as the recommended value. Issuer, subject and audience are each limited to 600 characters, a single audience value must be supplied, and the name, between 3 and 120 URL-friendly characters, is immutable once created.

At sign-in, the workload obtains a token from its own identity provider and presents it to the Microsoft identity platform as an assertion. This follows the pattern standardised in IETF RFC 7523, which profiles how a JSON Web Token, the signed claims format defined in RFC 7519, can be used as an authorization grant or for client authentication under the OAuth 2.0 framework of RFC 6749. The platform looks for a federated identity credential whose issuer, subject and audience match the presented token, validates the token's signature against keys published by the issuer, and, if both checks pass, issues a Microsoft Entra access token for the application or managed identity. Microsoft documents that the comparison is case-sensitive, that wildcard characters are not supported in any property value, and that leading or trailing whitespace in the issuer blocks the exchange.

Several further rules bound the mechanism. A maximum of 20 federated identity credentials can be added to one application or user-assigned managed identity. Federated credentials cannot be configured on system-assigned managed identities. Only issuers whose tokens are signed with the RS256 algorithm are supported. Tokens issued by Microsoft Entra ID itself may not be used as the external token, with one documented pattern in which a user-assigned managed identity serves as the federated credential of an application. The broader idea of exchanging one security token for another is generalised in RFC 8693, OAuth 2.0 Token Exchange; Microsoft's implementation is narrower and specific to its platform, but the conceptual lineage is the same.

RFC 8725, the JSON Web Token best current practices, is relevant for a different reason. It insists that recipients validate the issuer and the audience of every token they accept, because a valid signature alone proves only who signed, not whom the token was for. A federated identity credential is, in effect, the recipient-side configuration of exactly those checks, which is why its three matching fields carry so much weight.

Problem statement: governance built for secrets

Credential governance in most organisations rests on three properties of the credentials it governs, usually without saying so. The first is that a credential contains secret material, so its exposure can be detected by searching for that material. The second is that a credential has a lifetime, so neglect is self-correcting: an unused, forgotten secret eventually expires. The third is that a credential's creation and lifetime can be constrained by policy, so the organisation can forbid the riskiest forms outright.

A federated identity credential has none of these properties in the form governance expects. It holds no secret, so no scanner will ever find one. Its documented fields contain no expiry or lifetime, so a forgotten credential does not fade. And, as the next section shows, the tenant's app management policies define restrictions for passwords and keys but none for federated credentials.

We state the problem precisely. A federated identity credential is a standing trust path: from the moment it is created until someone deletes it, any principal able to obtain a token from the named issuer with the named subject and audience can sign in as the application or managed identity. The question this article addresses is how such paths should be governed when the three properties that made secrets governable are absent. The scope is governance of the trust object itself; the reach of an identity once signed in, and how quickly removed access takes effect, are separate problems.

Method: comparing the three credential types property by property

An application registration in Microsoft Entra ID can carry three kinds of credential: password credentials, usually called client secrets; key credentials, usually certificates; and federated identity credentials. We compare them on six properties that governance programmes depend on, using only documented behaviour. Where a property is absent, we say so only when the documentation lists the relevant fields or options exhaustively.

Secret material. Password credentials are secrets; key credentials depend on a private key held by the workload; federated identity credentials contain only public identifiers, the issuer URL, a subject string and an audience. There is nothing in the federated credential that would be dangerous if published.

Lifetime. Password and key credentials carry validity periods. The documented fields of a federated identity credential, name, issuer, subject, audiences and description, include no lifetime. It remains valid until deleted.

Policy restriction. Microsoft Graph's app management policy, available both as a tenant default and per application or service principal, lists its manageable restrictions explicitly: password addition, password lifetime, custom password addition, symmetric key addition and lifetime, asymmetric key lifetime, and two restrictions on redirect URI additions. None applies to federated identity credentials. The related app management configuration resource likewise models only password and key credential restrictions. The absence is documented, not inferred.

Who can add one. Microsoft documents that anyone with permissions to create an app registration and add a secret or certificate can add a federated identity credential to an app, and that for applications the Application Administrator, Application Developer, Cloud Application Administrator and Application Owner roles qualify. For user-assigned managed identities, the Contributor or Owner role assignment is required. The set of principals who can add a federated credential is therefore at least as large as the set who can add a secret.

Validation at creation. In the documented pattern where a managed identity is configured as an application's federated credential, Microsoft states that if incorrect information is added to the issuer, subject or audience, the credential is created successfully without error. Creation is not a test of correctness, and a misconfigured credential is indistinguishable from a correct one until something tries to use it.

Breadth. Standard federated credentials match one exact subject. Flexible federated identity credentials, a preview feature, add a restricted expression language with a matches operator supporting single-character and multi-character wildcards, an eq operator and an and operator, currently for GitHub, GitLab and Terraform Cloud issuers. For GitHub, a flexible credential must also match the immutable repository_id or repository_owner_id claims. Microsoft motivates the feature with the 20-credential limit, which scale can exhaust quickly.

The trust path: who can actually sign in

The comparison changes what a review must ask. For a secret, the review asks who holds it. For a federated identity credential, there is nothing to hold; the review must ask who can cause the named issuer to mint a token with the named subject and audience. That is a question about the external system, not about Microsoft Entra ID, and it is where the trust path actually runs.

We describe the path in three hops, as our own synthesis of the documented mechanism. The first hop is credential creation: any principal able to add a federated credential to the identity can open a new path. The second hop is issuer control: whoever governs the external identity provider decides which workloads receive tokens and what subjects those tokens carry. The third hop is subject reachability: within the external system, any principal able to run a workload that is issued the matching subject can sign in. The effective set of principals who can sign in through a given credential is everyone who can reach hop three, plus everyone who can perform hop one.

Exact matching narrows hop three to precisely one subject value, which is the safety property of standard federated credentials. How narrow that is depends entirely on the external system's subject format. A subject that names a single protected deployment environment in a source-control platform admits only workflows that platform allows to run in that environment; a subject that names any branch of a repository admits anyone who can push a branch. Microsoft notes that subjects have no fixed format because each provider uses its own, so the meaning of a given string must be read against the provider's rules.

Flexible credentials widen hop three by design. A matches expression with a wildcard admits every subject that fits the pattern, which can be exactly what a large organisation needs and exactly what a careless one does not intend. Microsoft's requirement that GitHub flexible credentials also match an immutable repository or owner identifier is a meaningful guard: it binds the pattern to a specific repository or organisation that cannot be recreated under the same name by someone else. A pattern evaluated only against mutable names would lack that anchor.

Failure modes from documented behaviour

The properties above produce characteristic failure modes. We list them by the documented behaviour that causes each, without speculating about frequency.

Silent misconfiguration. Because creation succeeds even when the issuer, subject or audience is wrong in the documented managed-identity pattern, teams can believe a trust exists when it does not, or, worse, create a second, broader credential to work around a failure they misdiagnose. Misdiagnosis is easy because the platform's error for a missing match, AADSTS70021, no matching federated identity record found for presented assertion, is the same whether the credential is wrong or merely not yet propagated.

Propagation and concurrency. Microsoft documents that a newly created credential takes time to propagate and that requests during that window can fail with AADSTS70021, and recommends retry logic. It also documents that creating several federated credentials on the same user-assigned managed identity concurrently triggers concurrency detection and fails with an HTTP 409 conflict. Automation that creates credentials in parallel, or treats the first failure as a configuration error, can produce partial or duplicated trust.

Orphaned paths. With no lifetime, a credential created for a migration, a proof of concept or a repository that has since been archived remains valid until someone deletes it. If the external subject can later be reproduced, by a new workflow, a renamed environment or a reused service account name, the old path reopens. Exact matching does not protect against this; it guarantees only that the same string is required, not that the same workload produces it.

Slot pressure. The 20-credential ceiling per identity creates pressure to consolidate, either by sharing one identity across many workloads or by moving to flexible credentials with wildcards. Both are legitimate; both widen the trust path, and both deserve a deliberate decision rather than a default.

Policy blind spot. Because app management policies have no federated-credential restriction, an organisation that has forbidden new client secrets tenant-wide may believe its applications can no longer acquire new standing credentials. They can, through federation. The policy also, by design, never blocks token issuance for existing applications; it constrains only creation and update operations that violate it, so it was never a runtime control in the first place.

A governance design: the trust-path register

If the three properties governance relied on are missing, the design question is how to supply each one by other means. We propose a trust-path register with three controls, each standing in for one missing property. This is our synthesis, built from controls the platform documents; it is a design, not a product feature.

Creation control replaces policy restriction. Because no app management policy restricts federated credentials, restriction has to come from who may create them. Limit the application roles that can update credentials, documented as requiring the microsoft.directory/applications/credentials/update permission, to a small group, and remove application ownership from people who do not need it. For user-assigned managed identities, treat Contributor and Owner on any identity holding privileged roles as credential-issuing rights and grant them accordingly. Route new credentials through a change process that records issuer, subject, audience, owner, business purpose and an intended review date in the register before creation.

Change detection replaces scanning. A scanner looks for exposed secrets; the equivalent for federation is detecting new or modified trust. Inventory federated credentials across every application and user-assigned identity on a schedule, compare the inventory with the register, and treat any credential not in the register as an incident until explained. Directory audit logging records changes to applications and identities; the specific event names vary and should be confirmed in the tenant rather than assumed.

Attestation replaces expiry. Since credentials do not expire, give each one a review date in the register and require its owner to re-attest that the subject still names the intended workload and that the external system still governs it the same way. A credential whose owner cannot be found, or whose repository, environment or cluster no longer exists, is deleted. Microsoft's guidance to build retry logic for propagation also belongs here: deletion and replacement should be tested, not assumed instantaneous.

Two design rules fall out of the trust-path analysis. Prefer standard, exact-subject credentials, and adopt flexible credentials only where the pattern is anchored to an immutable identifier and the wildcard's reach has been written down. And prefer subjects that the external system protects with its own controls, such as environments that require approval, over subjects any contributor can produce.

Why AI agents raise the stakes

AI agents, programs that use a large language model to plan and invoke tools, are commonly built, deployed and sometimes hosted by pipelines and clusters outside Microsoft's cloud, and federation is the natural way to give them access to Azure without a stored key. That is a genuine improvement: an agent with no secret in its configuration cannot be manipulated by prompt injection into disclosing one.

The trust-path view shows where the risk goes instead. Agent projects move quickly, spawn many repositories and environments, and are frequently prototyped before they are governed. Each prototype that needs Azure access is a candidate for a new federated credential, often with a broad subject chosen for convenience, and each one persists after the prototype is abandoned because nothing expires. The 20-credential ceiling then pushes teams towards shared identities or wildcard patterns just as the number of agents grows.

An agent's pipeline is also an attractive place to stand. Whoever can modify the workflow that deploys or runs an agent can, if the federated credential's subject matches that workflow, sign in as the agent's identity directly, without touching the agent at all. For agents, then, the register's rules matter more: one identity per agent, subjects bound to protected environments rather than branches, flexible patterns only with immutable anchors, and a review date short enough to match the pace at which agent projects appear and disappear.

Limitations and threats to validity

This analysis is based on public documentation as of 2026. Flexible federated identity credentials are a preview feature, and its supported issuers, operators and constraints may change. The property comparison reports a property as absent only where documentation enumerates the relevant fields or restriction types; future additions, such as a lifetime field or a policy restriction for federated credentials, would remove part of the problem this article describes, and the register design would then become partly redundant rather than wrong.

The silent-creation behaviour is documented explicitly for the pattern in which a managed identity serves as an application's federated credential. We do not claim the same documentation exists for every issuer, although the general mechanism, matching at sign-in rather than at creation, suggests the same property; teams should verify it for the issuers they use.

We report no measurements of how many federated credentials exist in real tenants, how many are orphaned, or how often subjects are broader than intended. Those questions require access to real environments and are a natural subject for a measurement study. Finally, the trust path's middle hop, control of the external issuer, depends on the security of systems outside Microsoft Entra ID, which this article does not assess.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

function diff(inventory, register, today):
    for cred in inventory.federated_credentials():
        key = (cred.parent_id, cred.issuer, cred.subject, cred.audience)
        entry = register.lookup(key)
        if entry is none:
            report('UNREGISTERED', cred)          # treat as incident until explained
        else if entry.review_date < today:
            report('ATTESTATION OVERDUE', cred, entry.owner)
        else if cred.issuer has leading or trailing whitespace:
            report('WILL NEVER MATCH', cred)
    for entry in register.entries():
        if not inventory.contains(entry.key):
            report('REGISTERED BUT MISSING', entry)

STANDARD federated-identity-credentials
  1. A federated credential MAY be created only through the change process, after a register entry exists.
  2. Each entry records: parent identity, issuer, subject, audience, owner, purpose, review date.
  3. Subjects MUST name a protected environment, a dedicated service account, or an equally narrow workload.
  4. Flexible credentials REQUIRE an immutable anchor and written approval of the pattern's reach.
  5. Each AI agent uses its own identity; agent credentials are reviewed at least as often as the agent is changed.
  6. Unregistered credentials found by inventory are incidents.
  7. Credentials past their review date without attestation are deleted.

Glossary

Federated identity credential

A trust object on an application or user-assigned managed identity that accepts external tokens matching a specific issuer, subject and audience.

Workload identity federation

Microsoft Entra ID's mechanism for exchanging a token from an external identity provider for a Microsoft Entra access token.

Issuer

The URL identifying the identity provider that signed a token.

Subject

The claim identifying the specific workload or principal a token was issued to, in the provider's own format.

Audience

The claim naming the intended recipient of a token.

App management policy

A Microsoft Entra ID policy, tenant-wide or per application, that restricts the creation and lifetime of password and key credentials.

Flexible federated identity credential

A preview form of federated credential that matches subjects with a restricted expression language including wildcards.

Trust-path register

This article's term for an owned inventory of federated credentials with purpose, owner and review date, used to drive creation control, change detection and attestation.

Assertion

A signed token presented to an authorization server as proof of identity, as profiled for JWTs in RFC 7523.

References

1. Microsoft Learn: Important considerations and restrictions for federated identity credentials
2. Microsoft Graph: applicationAuthenticationMethodPolicy resource type (app management policies)
3. Microsoft Learn: Flexible federated identity credentials (preview)
4. IETF RFC 6749: The OAuth 2.0 Authorization Framework
5. IETF RFC 7519: JSON Web Token (JWT)
6. IETF RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants
7. IETF RFC 8693: OAuth 2.0 Token Exchange
8. IETF RFC 8725: JSON Web Token Best Current Practices
9. NIST SP 800-207: Zero Trust Architecture