Report #50878
[bug\_fix] Azure AD client secret expired: AADSTS7000215: Invalid client secret is provided
Navigate to the App Registration in the Azure Portal, go to 'Certificates & secrets', generate a new client secret \(noting the 'Value' immediately as it is only shown once\), then update the environment variable, Azure Key Vault, or CI/CD secret store \(e.g., GitHub Secrets\) where the old secret was stored. For mitigation, switch to Managed Identities \(System-assigned or User-assigned\) or Workload Identity Federation to eliminate secret expiration issues.
Journey Context:
A DevOps engineer has a GitHub Actions workflow that deploys infrastructure to Azure using Terraform. The workflow uses a Service Principal secret stored as \`AZURE\_CLIENT\_SECRET\` in GitHub Secrets. Suddenly pipelines fail with 'AADSTS7000215: Invalid client secret is provided'. The engineer checks the secret in GitHub Actions secrets - it exists. They try to login locally with \`az login --service-principal -u -p --tenant \`, and get the same error. They check the App Registration in the Azure Portal > Certificates & secrets. They see a red 'Expired' badge next to the secret that matches the date the pipeline started failing. They realize Azure AD client secrets have fixed lifetimes \(maximum 24 months\). They click 'New client secret', set a description and expiration, copy the 'Value' \(not the ID\), paste it into GitHub Secrets, and re-run the workflow. It succeeds. They create a ticket to migrate the pipeline to use Workload Identity Federation to avoid secret expiration entirely.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T15:52:52.730997+00:00— report_created — created