Microsoft warns that a federated credential can keep trusting a mutable name after the original workload is renamed, transferred or deleted. A recycled subject can then match the old trust relationship. Microsoft Learn This is a concrete cloud identity assessment question, not merely a recommendation to remove stored secrets.
Quick answer. An Entra workload identity federation test should inventory federated credentials, map each issuer, subject and audience to a live workload, and check the target app or managed identity privileges. Use controlled token-exchange cases and avoid acquiring someone else's workload identifier. Stingrai can scope a human-led cloud and Entra assessment around those trust relationships.
Federation replaces a stored credential with trust in an external token, but the trust is only as narrow as its matching conditions and its lifecycle. Microsoft documents issuer and subject matching during token exchange and separately warns about stale name-based subjects. Microsoft considerations and mutable-subject guidance together define the test boundary.
The buyer's test matrix
This matrix is a starting point for a scoped engagement, not a claim about any particular customer's configuration. Replace every generic object with a named test account, record, workspace, role or application that your team owns. The expected behavior should be approved by the business owner before the tester observes it.
Boundary | Expected decision | Safe test | Evidence to keep | Control owner |
|---|---|---|---|---|
Inventory | Every credential maps to a live owner and workload | Reconcile app credentials with approved workload register | Credential ID, owner and status | Identity administrator |
Issuer | Only approved issuer tokens are accepted | Compare controlled valid and invalid issuer cases | Trust entry and exchange result | Cloud security |
Subject | Trust names a stable intended workload | Review mutable and immutable claim options | Subject design and lifecycle evidence | Platform engineering |
Audience | Token is minted for intended exchange | Use a controlled wrong-audience token | Audience condition and denial | Identity engineering |
Privilege | Successful exchange grants only needed actions | Test an allowed and a denied low-impact resource action | Target role and effective result | Resource owner |
Retirement | Deleted workload leaves no dangling trust | Inspect stale credentials and remove in change window | Before/after inventory and denied retest | Application owner |
Figure 1: A practical evidence path for this assessment. The stages are an editorial test-planning model based on the cited provider documentation.
Inventory the trust object and the workload it represents
The useful unit of review is a pair: the federated identity credential in Entra and the external workload that is supposed to produce its token. A spreadsheet of app registrations without repository, namespace or job ownership cannot establish whether the subject is still valid. Microsoft calls a credential dangling when it remains after the workload it trusted no longer exists. Microsoft Learn The buyer should ask for an owner, issuer, subject, audience, target app or managed identity and retirement date for every entry.
An application registration and a user-assigned managed identity need different inventory paths. Microsoft Graph exposes a list of federated identity credentials on an application. Azure Resource Manager exposes the credentials under a user-assigned managed identity. An export of only app registrations can therefore miss a material part of the trust estate. The inventory should identify the object ID of the target, its owner and business purpose, each credential's issuer, subject or matching expression, audience, and the external workload that emits the token. Separately record the resources the resulting Entra identity can access. Treat the credential and its privileges as related records, not one blended risk score.
Ask the platform owner to produce this inventory under an approved read-only role before the test begins. For applications, distinguish the app object's ID from its application or client ID: Microsoft's Graph listing documentation accepts either form through different request paths. That small distinction matters in a large tenant because a request against the wrong identifier can produce a false gap in coverage. For managed identities, capture subscription, resource group and identity name so the security team can reproduce the Azure Resource Manager view. Include inactive applications in the review if they retain credentials or permissions; inactivity does not retire a trust relationship.
The external workload side needs independent evidence. A repository name, namespace or workspace in an old spreadsheet is not proof that the current holder is the original trusted workload. Match the source owner's current record to the claim value that the issuer would emit, then ask when ownership last changed. If the source was transferred, renamed or retired, document whether Entra's credential changed with it. A missing owner is a governance finding; a confirmed ability of a different controlled workload to exchange a token is a different, stronger finding. Keeping those categories separate avoids turning a plausible stale-name risk into an unearned exploit claim.
Do not prove a takeover by registering someone else's released name. That would cross an ownership boundary. A safe assessment can identify the mutable subject design, show that the original workload is gone, and demonstrate token exchange using a separately controlled test resource with the same pattern. The report should distinguish a demonstrated acceptance from a potential exposure inferred from configuration.
Separate standard credentials from flexible credentials
The ordinary federated credential uses exact issuer, subject and audience values. Microsoft specifies a required audience and says the usual commercial-cloud value is api://AzureADTokenExchange; it also says ordinary property values do not accept wildcard characters. Microsoft, credential considerations A buyer should not accept a proposal that assumes one ordinary credential can automatically cover a branch pattern. First establish the subject actually emitted by the issuer, then compare it with the configured string. Record whether the intended scope is one job, one repository, one environment or an approved group of workloads. The answer determines whether exact matching is suitable.
Microsoft currently limits an application or user-assigned managed identity to 20 federated identity credentials. Its flexible federated credential feature is in preview and adds restricted expressions for supported issuers. It can consolidate a documented group of branches or workflows, but broad matching changes the authorization boundary. The assessment should inspect both the expression and the issuer's immutable claims, not merely count the number of entries. A convenient wildcard is acceptable only if the remaining predicates still identify the intended workload and every matching branch is approved for the target privilege.
This preview currently supports tokens from GitHub, GitLab and Terraform Cloud. For GitHub, Microsoft requires a flexible credential to match sub and at least one of repository_id or repository_owner_id. For GitLab, Microsoft's mutable-subject guidance describes matching a stable project identifier rather than relying solely on a reusable project path. These are issuer-specific conditions, not a universal recipe. Require the tester to state whether the target is an application or managed identity, whether it uses a standard or flexible credential, the issuer capabilities observed, and any preview limitation that affects remediation. If the issuer does not expose the needed immutable claim, the report should state the residual risk and an ownership or retirement control rather than promise a control the platform cannot enforce.
Model issuer changes as a lifecycle test
A useful assessment samples the events that change identity meaning. For GitHub Actions, GitHub's OIDC reference documents an immutable default subject format for repositories created after July 15, 2026, while older repositories keep the earlier name-based format unless they opt in. GitHub Enterprise Server is outside that rollout. A tenant with both generations may have different Entra credentials for apparently similar workflows. For each GitHub trust, capture the current subject format and repository identity, then compare the Entra credential to the token the approved workflow emits. This is particularly important after a transfer or rename, when a previously valid credential may either fail safely or remain as a stale name-based trust.
Microsoft has a migration guide for GitHub immutable subjects. Its continuity pattern is to establish the new credential alongside the old one, validate that the approved workflow authenticates with the new subject, and remove the old name-based credential. For a buyer, the acceptance evidence is more than a successful deployment: retain a before-and-after credential inventory, a successful exchange tied to the intended identity, and proof that the old credential was removed. If a customer-owned legacy-format workload can still emit the old subject, include a denied retest. Do this within the owner's change process. A failed pipeline immediately after a subject-format change may be a compatibility problem; a leftover old trust after the new path works is a lifecycle problem.
GitLab and Terraform Cloud require a different ownership question. Microsoft's flexible-credential documentation lists both as supported issuers and describes the issuer-specific claims and operators. A GitLab name-based project path should be compared with the immutable project identity where available; a Terraform Cloud trust should be tied to the intended organization, workspace and run phase. The test should not assume a GitHub-shaped sub for either. Ask the source-system owner to verify current workload identity, ownership and retirement behavior, then reconcile the Entra record to that evidence. This is a configuration and lifecycle review that complements, rather than substitutes for, controlled token-exchange testing.
Check matching conditions and resource privilege separately
Microsoft says Entra checks the issuer and subject of the federated credential against claims in the external token. Microsoft, Workload identity federation considerations The test plan should also record the configured audience and whether the issuer supports stable internal identifiers. The positive case is the intended workload obtaining a token. Negative cases change one controlled claim at a time so the reason for denial is visible. Avoid publishing usable token contents in the report.
A successful exchange is only half the risk. The target identity may hold directory roles, cloud roles or application permissions broader than the job requires. Choose one low-impact permitted action and one forbidden action on a synthetic resource. The report should identify the target privilege that enabled the result. A narrow subject with an overpowered target role still produces an overpowered workload.
For a standard credential, the acceptance packet can be organized by claim rather than by screenshot. The intended case records the token issuer, subject and audience as redacted claim values, the Entra credential it matched, the target identity and whether the approved resource action succeeded. An issuer-negative case uses a separate issuer controlled by the assessment team; a subject-negative case uses a different controlled workload; an audience-negative case uses a token deliberately minted for the wrong test audience. Each comparison should change one condition while holding the others constant. A denial without a corresponding valid baseline is inconclusive because the test configuration itself may be broken. A success should be tied to the target identity that actually received the exchanged token, not merely to a green pipeline indicator.
For a flexible credential, the test design must also show why each allowed expression branch is intended. If the expression uses a wildcard across refs, select an approved ref, an adjacent unapproved ref and, where the issuer supports it, a controlled repository with a similar name but a different immutable ID. The unapproved case should fail while the approved one succeeds. The tester should quote the expression as configured and identify which predicate caused the expected denial. Do not paste a live bearer token into the report. A sanitized claim map, policy excerpt, timestamps and selected request or audit references are enough for an authorized reviewer to repeat the decision without turning the report into reusable credentials.
Do not confuse a token-exchange failure with evidence that the trust is sufficiently narrow. Microsoft notes that new federated credential changes can take time to propagate and that requests shortly after configuration can fail while regional caches update. Microsoft, credential considerations Schedule the negative tests after the positive baseline is stable, preserve the time and exact error category, and retry only within the agreed test window. If the authorized workload cannot exchange a token, the result is an availability or setup problem until the team diagnoses it. Only a controlled, repeatable allowed or denied decision supports a conclusion about the trust boundary.
The privilege check belongs in a separate result row. Ask the resource owner to name the smallest operation the workload must perform and a neighboring operation it must not perform. A cloud role, directory permission and downstream API role may each be managed by a different team. Map the effective permission on the target identity to the resource action observed, then assign remediation to the owner of the grant that produced it. Removing a stale federated credential does not fix an overprivileged identity that still has other credential paths. Conversely, reducing resource privilege does not clean up an unnecessary trust entry. The report should recommend and retest the specific control that failed.
Treat lifecycle as part of the pentest
Microsoft recommends preferring immutable subjects where supported, deleting dangling credentials and reviewing federated credentials regularly. Microsoft Learn Ask the team how credentials are created, reviewed after repository transfers, and removed when a job is retired. Review audit evidence for creation and deletion. Where a feature is in preview or not supported for an issuer, record that dependency rather than promise an unavailable control.
The SOW should include app object IDs, managed identities, issuer owners, approved test workloads, allowed token-exchange paths, resource scope and stop conditions. A vendor should deliver an inventory reconciliation, matched and denied test cases, effective permissions, remediation owners and a retest. That package lets an identity team fix a specific trust edge rather than act on a vague "federation risk" finding.
The owner should also specify what happens on retirement. A repository archival, workspace deletion or service replacement must trigger a review of both its federated credential and its assigned permissions. A monthly review may find stale entries, but a change-driven deprovisioning step is what closes the window immediately after ownership changes. Microsoft's hygiene guidance calls for deleting dangling credentials and regular audits. Require a documented owner to approve removal, evidence that the old trust no longer matches a controlled test token, and a rollback decision if a still-active workload unexpectedly depends on that credential. That turns an identity inventory into a maintainable control rather than a one-off spreadsheet.
Specify acceptance evidence for each Entra trust edge
The statement of work should define a trust edge as the external workload, issuer, subject, audience, Entra target identity and resource permission that together produce access. Name the application object ID or user-assigned managed identity resource, the external system owner, the approved test workload, and the target resource. A purchase order that says only “review workload identity federation” leaves the tester free to sample easy credentials while overlooking a highly privileged identity with a stale subject. Prioritize the edges whose target identity can reach the most sensitive resources, whose source ownership recently changed, or whose credential uses a mutable subject. That prioritization is the buyer's risk decision and should be recorded before testing.
For each selected edge, require a positive and a negative result. The positive case establishes that the intended workload can exchange its token and perform one harmless approved resource action. The negative case changes one claim or source ownership condition under the customer's control and shows the expected denial. For a flexible expression, name a ref or workspace outside the intended match set. Then test a separate forbidden resource action using the legitimately assumed identity. The report must say whether a denial happened at the source issuer, Entra exchange or resource authorization. These outcomes have different owners and remediation paths.
An evidence row should contain the credential identifier, target identity, source workload identifier, redacted iss, sub and aud claims or expression predicates, expected result, observed result, time, relevant audit or request reference, and the role that determined the resource decision. The actual bearer token should never appear in the delivered report or issue tracker. Ask for a separate “not tested” column: a workload for which the customer did not authorize token issuance must not silently be marked secure. A static inventory can establish a dangling or overbroad configuration concern, but only an observed authorized exchange proves the runtime outcome. The distinction should appear in the executive summary as well as the technical appendix.
Retest acceptance is specific to the fix. If an owner removes a dangling credential, confirm it is absent from the application or managed-identity inventory and that an approved current workflow still works. If an owner switches to an immutable subject, validate the new credential, remove the old one, and check the migration evidence. If an owner reduces target permissions, repeat the forbidden action and confirm the needed action still works. A screenshot of a changed portal field is useful change evidence, but it does not replace the matching result or the resource decision the original finding concerned.
Questions to put in an Entra federation RFP
Ask the provider which inventory method it will use for app registrations and which for user-assigned managed identities. Microsoft's Graph and Azure Resource Manager documentation show why those paths differ. Will the provider reconcile each credential to a source workload owner, or only export Entra settings? Will it identify standard credentials separately from preview flexible expressions and test the issuer-specific immutable claims? What is the plan when the external issuer cannot supply an immutable subject?
Ask how testers will obtain a controlled token without copying production secrets or claiming a released identifier. Which source-system and Entra owners must approve each case? Which exact cloud or application resource will prove the privilege boundary, and what low-impact action is permitted there? Who watches the Entra and source-system logs during the test? The answers should be in the rules of engagement along with a test window, rate limits, monitoring contact, stop condition and an explicit exclusion for provider-owned or third-party surfaces. Possession of one tenant or integration does not authorize tests against every connected platform.
Finally, ask the provider to show the format of its credential-to-workload inventory and one anonymized evidence row. Require it to distinguish configuration risk, demonstrated exchange, overprivileged target identity and coverage gap. Name the person who will review ambiguous results before they are escalated, the time frame for a confirmed finding to reach its owner, and the retest method for each remediation type. The buyer should be able to trace every conclusion back to one trust record and one observed decision without needing access to sensitive token material.
What Stingrai can scope
Stingrai is a CREST-accredited penetration testing company whose cloud testing service includes Azure and Entra ID identity paths. A human-led Entra federation assessment can be scoped around named customer-owned app registrations, user-assigned managed identities, external workloads and resource permissions. The SOW should specify which credentials will receive a lifecycle review, which controlled exchanges testers may run, and which resource actions establish the privilege boundary. The testers can report confirmed outcomes with proof and remediation guidance, then retest the changed trust or permission. This is a more useful deliverable than a blanket statement that the tenant “uses federation securely.”
For a migration or procurement gate, a one-time assessment may be enough. For an estate where repositories, workspaces and identities change frequently, the buyer can also scope a continuous program. Stingrai's services describe both testing and the portal-based retest workflow. In either model, the buyer remains the owner of the Entra configuration and approval decisions; the testing produces evidence and remediation direction for its security and audit program.
Frequently Asked Questions
What does an Entra workload identity federation pentest test?
It tests the mapping from external issuer, subject and audience to the intended workload, then checks the privileges of the Entra app or managed identity that receives the exchanged token.
What is a dangling federated identity credential?
Microsoft uses this term for a credential left configured after the workload it trusted no longer exists. If a name-based subject is later reused, the old trust may accept a different workload.
Should testers claim a deleted repository name to prove the issue?
No. Identify the stale or mutable trust and use controlled test resources for a safe proof. Do not acquire an identifier owned or formerly owned by another party without authorization.
What should the final report include?
It should include the credential-to-workload inventory, exact trust conditions, controlled positive and negative results, target privileges, telemetry, remediation owner and retest result.
Related reading
Workday Integration Security Assessment: A Buyer Scope for 2026
Enterprise Identity Test Matrix 2026: SSO and SCIM Controls Buyers Can Verify
Talk to Stingrai
Share the assets, identities and expected access decisions you want tested. Get a Quote or book a free discovery call to define the authorization boundaries and deliverables.
