The 90-Day Secret Rotation Ticket Is Now Optional Across Tenants

The 90-Day Secret Rotation Ticket Is Now Optional Across Tenants

Every identity admin has the same recurring calendar entry: rotate the app secret before it expires and takes prod down at 2 a.m. You’ve written the runbook, automated half of it, and still been paged for the other half. As of today, Microsoft says you can delete it—at least for cross-tenant workloads.

The Microsoft Identity DevBlog declared General Availability on September 9, 2026 for using a managed identity as a federated identity credential on an Entra app registration. Translation: a managed identity living in Tenant A can now sign in as an app in Tenant B, and the thing it presents is a short-lived token from Azure, not a string you stored in Key Vault and prayed over.

This is not new physics. It’s workload identity federation—the same trust-a-token-instead-of-a-secret pattern that shipped for GitHub Actions and Kubernetes years ago—pointed at a new issuer. Which is exactly why it’s worth paying attention: the mechanism is proven, and the failure modes are already documented. You’re not the beta tester this time.

90 days of secret rotation, gone

The number that made this feature exist is 90. That’s the default lifetime, in days, that most shops put on an app’s client secret because the security team read a hardening guide once. Every 90 days something has to mint a new secret, push it into Key Vault or a pipeline variable, restart or re-read it in the consuming workload, and confirm nothing broke.

A federated identity credential has no expiry to rotate. The trust is a static configuration; the credential is a token that Azure issues on demand and that lives for minutes, not months. You configure the relationship once. Azure’s token endpoint handles freshness. The 2 a.m. page is now Microsoft’s problem, not yours.

If you’ve done workload identity federation before, stop reading the marketing and note the one genuinely new bit: the trusted issuer can now be a managed identity in another Entra tenant. Previously the interesting external issuers were CI/CD systems and Kubernetes clusters. Now it’s Azure’s own workload identity fabric reaching across a tenant boundary.

Two tenants, one trust relationship, zero shared secrets

Here’s the topology, because the words “Tenant A” and “Tenant B” stop meaning anything after the third paragraph.

  • Tenant A owns the workload—a Function App, a VM, a container—with a managed identity attached. That identity is the thing that wants access.
  • Tenant B owns the app registration and the resources you’re protecting (Graph, an Azure API, whatever). It’s the party deciding who to trust.

The flow at runtime: the workload in Tenant A gets a token for its managed identity from the local Azure token service, then presents that token to Tenant B’s app registration as proof of identity via a federated credential. Tenant B’s app has been told, in advance, “a token from this specific managed identity issuer with this specific subject is you.” No secret ever crosses the boundary. Nothing long-lived sits in either tenant waiting to leak.

The part people miss: this is a trust configuration on the app registration in Tenant B. You are not granting the managed identity anything by creating the credential. You still assign roles, app permissions, and consent exactly as before. Federation replaces the authentication factor. It does not touch authorization. Skip the RBAC step and your beautifully secretless workload will authenticate flawlessly and then get a 403.

The endpoint is the same one you already know

You configure this against the app registration in Tenant B, through the federatedIdentityCredentials relationship on the application object:

request.httpHTTP
POST https://graph.microsoft.com/v1.0/applications/{application-object-id}/federatedIdentityCredentials
GET  https://graph.microsoft.com/v1.0/applications/{application-object-id}/federatedIdentityCredentials

Same collection that GitHub Actions federation writes to. The properties that have defined a federated credential since it went GA—name, issuer, subject, audiences, description—are still the properties. What differs for the managed-identity scenario is what you put in issuer and subject: the issuer identifies the source tenant’s managed identity authority, and the subject identifies the specific managed identity. Read the GA post for the exact issuer and subject values before you paste anything. Getting the subject wrong is the difference between “it works” and an hour staring at AADSTS700213.

First, audit what already exists. Never create against a live tenant blind:

audit.ps1PowerShell
# Read-only. Lists existing federated credentials on an app so you know
# what you're changing before you change it.
Connect-MgGraph -Scopes 'Application.Read.All' -ErrorAction Stop
​
$appObjectId = '<application-object-id-in-tenant-B>'
​
try {
    $creds = Get-MgApplicationFederatedIdentityCredential `
        -ApplicationId $appObjectId `
        -All `
        -ErrorAction Stop   # -All handles paging for you
​
    if (-not $creds) {
        Write-Host "No federated identity credentials on $appObjectId yet."
    }
    else {
        $creds | Select-Object Name, Issuer, Subject, @{
            n = 'Audiences'; e = { $_.Audiences -join ',' }
        } | Format-Table -AutoSize
    }
}
catch {
    Write-Error "Failed to read federated credentials: $($_.Exception.Message)"
}

Then create from a reviewed object—never straight from a query result, and default to a dry run:

audit.ps1PowerShell
# Requires Application.ReadWrite.All. State-changing: defaults to dry run.
param(
    [switch]$Execute   # omit for dry run; pass -Execute to actually write
)
​
Connect-MgGraph -Scopes 'Application.ReadWrite.All' -ErrorAction Stop
​
$appObjectId = '<application-object-id-in-tenant-B>'
​
# Reviewed input. Fill issuer/subject from the GA doc, not from guesswork.
$fic = @{
    Name        = 'mi-tenantA-workload'
    Issuer      = '<issuer-from-GA-doc>'
    Subject     = '<managed-identity-subject-from-GA-doc>'
    Audiences   = @('api://AzureADTokenExchange')
    Description = 'Managed identity in Tenant A -> app in Tenant B'
}
​
if (-not $Execute) {
    Write-Host '[DRY RUN] Would create federated credential:'
    $fic | Format-Table -AutoSize
    Write-Host 'Re-run with -Execute to apply.'
    return
}
​
try {
    New-MgApplicationFederatedIdentityCredential `
        -ApplicationId $appObjectId `
        -BodyParameter $fic `
        -ErrorAction Stop
    Write-Host "Created '$($fic.Name)' on $appObjectId."
}
catch {
    Write-Error "Create failed: $($_.Exception.Message)"
}

api://AzureADTokenExchange is the standard audience for Entra workload identity federation and is not invented—but confirm it against the GA guidance for the managed-identity path all the same.

20 credentials per app is still the ceiling to watch

Workload identity federation has carried a documented cap of federated identity credentials per application object—historically 20. I have no reason to believe managed-identity federation raises it, and the GA post is where you confirm the current number. Verify it, because 20 sounds infinite until you’ve got one credential per environment per region and someone asks why the twenty-first won’t save.

Which forces a design decision the vendor blog won’t make for you: one FIC per workload, or one shared FIC behind many workloads? The moment you’re tempted to share, you’ve reintroduced the blast radius you were trying to kill. Prefer specificity. Hit the ceiling, split the app, don’t reuse subjects.

Both managed identity types—but confirm before you commit

The obvious question is whether this covers user-assigned managed identities, system-assigned, or both. User-assigned is the type you’d expect to lead with, because it has a stable lifecycle independent of any single resource—exactly what you want on the issuer side of a trust that outlives a VM reboot. System-assigned is tied to its resource and dies with it, which makes it fussier as a federation subject. The GA announcement is the authority on which types are supported at GA versus which stayed in preview. Don’t assume parity; check the matrix.

$0 in new licensing, almost certainly

Workload identity federation has never carried a per-credential charge and isn’t gated behind Entra ID P1 or P2—the app registration and its federated credentials sit in the Free tier plumbing. Expect the same here: no new SKU, no add-on. That said, “workload identity” is an overloaded phrase at Microsoft, and Entra Workload ID Premium is a real, separately-licensed product for things like Conditional Access on workloads and identity risk. Federating a managed identity as a credential is not that. If a licensing page tries to upsell you, read carefully which capability it’s actually charging for.

The migration is three steps, and step three is the one people skip

Moving an existing secret-based cross-tenant integration over looks like this:

  1. Add the federated credential alongside the existing secret. An app can hold both. Nothing breaks; you’ve just given it a second way to authenticate.
  2. Repoint the workload to acquire tokens via its managed identity instead of the stored secret. Run both paths in parallel long enough to trust the new one—a full business cycle, not an afternoon.
  3. Delete the secret. This is the step everyone forgets, and it’s the only step that actually improves your security posture. A federated credential you added while leaving the old secret live in the vault has bought you nothing but a longer credential inventory. Pull the secret, confirm sign-in logs show token-exchange auth, close the ticket.

None of this deprecates client secrets—Microsoft hasn’t said that and I’m not going to say it for them. Secrets still exist, still work, still expire at 2 a.m. But for machine-to-machine access across tenants, the excuse for using one just expired.

Related Post