🚨 Azure Error: 'AADSTS7000222: The provided client secret keys are expired' — Cause, Fix, and Troubleshooting Guide

What this error means

Entra ID returns AADSTS7000222 during a client-credentials token request when the client secret presented by the application has passed its expiry date. The secret was valid and correctly formed — it has simply aged out. The literal error:

AADSTS7000222: The provided client secret keys for app '11112222-3333-4444-5555-666677778888'
are expired. Visit the Azure portal to create new keys for your app:
https://aka.ms/NewClientSecret, or consider using certificate credentials for added security.
Trace ID: ... Correlation ID: ... Timestamp: 2026-07-12 14:11:07Z

This is the explicit expired-secret variant of the broader invalid_client family — distinct from AADSTS7000215 (a wrong/invalid secret value).

Where it surfaces

• A service principal / daemon app suddenly fails all token requests with AADSTS7000222.
• The failure starts abruptly on the secret’s expiry date, not after a code change.
• CI/CD service connections, Terraform runs, or backend services using client-credentials break simultaneously.
• The app registration shows a client secret with a past expiry in the portal.

Identity and permission causes

• Secret reached its expiry — the client secret’s endDateTime is in the past (secrets are capped at 24 months and often set shorter).
• No rotation process — the secret was created once and never rotated, so expiry was inevitable.
• Rotated app but stale consumers — a new secret was created but the config/Key Vault entry the app reads still holds the expired one.
• Multiple secrets, wrong one in use — the app has several secrets and the code is sending an old, expired one.

Tracing the failed authorization

List the app’s secrets and their expiry dates to confirm which are expired:

az ad app credential list \
  --id 11112222-3333-4444-5555-666677778888 \
  --query "[].{keyId:keyId, hint:displayName, start:startDateTime, end:endDateTime}" -o table

Any row whose end is before now is expired. Confirm the app id you are diagnosing matches the one in the error:

az ad app show --id 11112222-3333-4444-5555-666677778888 \
  --query "{name:displayName, appId:appId}" -o json

If the secret is stored in Key Vault, check what version consumers actually read:

az keyvault secret show \
  --vault-name app-kv --name sp-client-secret \
  --query "{updated:attributes.updated, expires:attributes.expires}" -o json

Resolution

Rotate the client secret and capture the new value (it is shown only once):

az ad app credential reset \
  --id 11112222-3333-4444-5555-666677778888 \
  --display-name "rotated-2026-07" \
  --years 1 \
  --query "{appId:appId, password:password, tenant:tenant}" -o json

Update every consumer — push the new secret to Key Vault (and let apps read the new version) or update pipeline/service-connection settings:

az keyvault secret set \
  --vault-name app-kv --name sp-client-secret \
  --value "<new-secret>"

Prefer certificate or federated credentials to eliminate secret expiry as a class of outage. Federated identity credentials (workload identity federation) remove long-lived secrets entirely:

az ad app federated-credential create \
  --id 11112222-3333-4444-5555-666677778888 \
  --parameters '{"name":"gh-oidc","issuer":"https://token.actions.githubusercontent.com","subject":"repo:org/repo:ref:refs/heads/main","audiences":["api://AzureADTokenExchange"]}'

Remove the expired secret once nothing uses it, so it cannot be sent by mistake:

az ad app credential delete \
  --id 11112222-3333-4444-5555-666677778888 --key-id <expired-keyId>

Hardening access

• Overlap during rotation. Create the new secret and roll consumers before deleting the old one to avoid a gap — but here the old one is already expired, so rotate immediately.
• Secrets are shown once. The password from credential reset cannot be retrieved later; store it in Key Vault right away.
• Alert before expiry. Track endDateTime and alert weeks ahead; this outage is entirely predictable.
• Certificates and federation don’t expire silently the same way — for high-value automation, migrate off client secrets to workload identity federation.

Related identity errors

• AADSTS7000215 — an invalid (wrong-value) client secret, as opposed to an expired one.
• AADSTS700016 / AADSTS50076 — app-not-found and MFA-required errors.
• DefaultAzureCredential failed to retrieve a token — SDK credential-chain failures that surface expired secrets.