Tailspin: 38 Client Secrets, a GitHub Pipeline, and Sign-Ins from 12 Countries

Classify each credential holder by where its code runs.

• Azure Function → managed identity. It runs on an Azure resource, so give it a system-assigned managed identity, grant that identity Key Vault Secrets User via Azure RBAC, and delete the credential from application settings. There is now no secret to expire or leak.
• GitHub Actions → workload identity federation. The runner is not an Azure resource, so there is no managed identity to assign. Instead add a federated credential to the app registration with issuer = GitHub's OIDC endpoint, audience api://AzureADTokenExchange, and a subject restricted to a specific repo and environment (repo:org/repo:environment:prod). The workflow then requests a short-lived token per run. Delete the GitHub secret afterwards - leaving it in place defeats the change.

Why not the same mechanism: a managed identity exists only inside Azure's trust boundary; a federated credential trusts an external OIDC issuer. Choosing the wrong one produces either 'identity not found' or an over-broad subject claim.

The 38 secrets: the multi-tenant SaaS app still needs a credential to authenticate to customer tenants and to your own APIs. There, federation does not apply - rotate to certificates stored in Key Vault or Managed HSM, configure credential preference so certificate wins when both exist, and set a hard rule: no secret with a lifetime over six months. Aim to drive the secret count to zero rather than to manage it better.

Treat notification email as a backup, not a control. Expiry mail only reaches the addresses the platform has, often a distribution list nobody owns, and it does not create an accountable owner per application.

Build a scheduled expiry report:

1. A job (Azure Automation runbook or Function) with a system-assigned managed identity holding Application.Read.All queries Graph for /applications?$select=appId,displayName,passwordCredentials,keyCredentials and for the corresponding service principals.
2. Compute days-to-expiry per credential and emit a table: application, credential type, end date, owner, environment.
3. Alert at 60 / 30 / 7 days into the owning team's channel, not into a mailbox, and open a work item at 30 days. Escalate to the platform team at 7 days.
4. Require an owner on every app registration and on the associated service principal; an application without an owner is itself a finding.

The strategic fix matters more than the alert: three outages from the same cause means the rotation process is manual and unowned. Prioritise converting the production-critical apps to federation or managed identity so those credentials stop existing, and reserve certificate rotation for the small residual set.

You cannot cover all 140, so make a defensible prioritisation.

1. Attribute the sign-ins before you react. Filter service principal sign-in logs by credential type and IP, and separate Microsoft first-party traffic from your own identities. Twelve countries may be three real identities plus CDN and Microsoft noise.
2. Rank by blast radius, not by volume. The 22 apps with tenant-wide mail and file permissions are the top risk regardless of where they sign in from. Remediate those first: replace tenant-wide Graph application permissions with narrower scopes where the workload permits, and apply application-level scoping (for example an application access policy restricting which mailboxes an app may touch) instead of tenant-wide mailbox access. Re-consent under an approval process - a single admin consent granting tenant-wide mail is a process failure, not just a configuration error.
3. Spend the 50 licenses on the highest-blast-radius identities. Confirm what the license actually covers in your agreement before scoping - you are buying coverage for a subset of 140, not for all of them. Apply Conditional Access for workload identities where the supported conditions match your risk (location and risk conditions; the grant surface is narrower than for users - validate the supported controls rather than assuming user-policy parity).
4. Managed identities are not covered by workload identity Conditional Access. Protect those with network controls: Key Vault firewall and private endpoints, and constrained egress.
5. For everything unlicensed, the fallback is credential hygiene: short-lived certificates, federated credentials where possible, and Sentinel detections on anomalous service principal sign-in location.