All posts

7 min readMicrosoft Entra · App Registrations · Troubleshooting

AADSTS7000222 and other error codes for expired Entra credentials: causes and fixes

AADSTS7000222, AADSTS7000215 and other error codes applications see when Entra client secrets or certificates are expired or invalid: message, cause, where it shows up, fix. Plus how to read the token response, check remaining credentials in the portal and PowerShell, and recover fast.

Read this post in German

A backup job dies, a connector goes quiet, the log shows a line with AADSTS and a long number. This guide covers the error codes applications get when their Entra credentials are expired, wrong or missing: message, cause, where, fix. Messages are quoted from the Entra error code reference and the troubleshooting articles on Microsoft Learn.

How to read the token endpoint response

On failure the token endpoint answers with HTTP 400 or 401 and a JSON body. Libraries such as MSAL pass the text through as an exception, so it lands unchanged in the application log. The response for an expired secret:

{
  "error": "invalid_client",
  "error_description": "AADSTS7000222: The provided client secret keys for app '11111111-2222-3333-4444-555555555555' 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: https://aka.ms/certCreds. Trace ID: 9215ac31-5c4d-468e-9dc8-1fa64ee60c00 Correlation ID: 367afda0-ca2d-48eb-8f49-a13c765618f7 Timestamp: 2026-09-27 06:12:41Z",
  "error_codes": [7000222],
  "timestamp": "2026-09-27 06:12:41Z",
  "trace_id": "9215ac31-5c4d-468e-9dc8-1fa64ee60c00",
  "correlation_id": "367afda0-ca2d-48eb-8f49-a13c765618f7",
  "error_uri": "https://login.microsoftonline.com/error?code=7000222"
}
  • error: the OAuth category, invalid_client for credential problems. The only field code should react to.
  • error_description: AADSTS code, usually the app ID, often the tenant ID, plus trace ID, correlation ID and timestamp. Microsoft says this text can change.
  • error_codes: the number without the prefix, as the sign-in logs show it under "Sign-in error code". correlation_id and trace_id lead to the matching log entry, error_uri to the lookup at login.microsoftonline.com/error.

The error codes one by one

AADSTS7000222: Client secret expired

Message: InvalidClientSecretExpiredKeysProvided - The provided client secret keys are expired. Create new keys for your app, or consider using certificate credentials for added security. At runtime with the app ID: The provided client secret keys for app '…' are expired.

Cause: The secret that was sent belongs to an entry whose end date has passed.

Where: Application log, token response, sign-in logs on the "Service principal sign-ins" tab, error code 7000222.

Fix: Create a new secret under "Certificates & secrets", put it into the application, restart.

AADSTS7000215: Client secret invalid

Message: Invalid client secret is provided. At runtime extended with: Ensure the secret being sent in the request is the client secret value, not the client secret ID, for a secret added to app '…'.

Cause: The value is wrong: secret ID copied instead of the value, a secret from another app, a truncated value from configuration or Key Vault, or a secret since deleted.

Where: Same as 7000222, error code 7000215.

Fix: Create a new secret and copy the value immediately, the portal shows it only once. Check that client ID and secret belong to the same app.

AADSTS7000218: No credential in the request

Message: The request body must contain the following parameter: 'client_assertion' or 'client_secret'.

Cause: A confidential client sends no credential, usually because the configuration is empty: environment variable not set, wrong path, Key Vault reference not resolving.

Where: Token response, application log, error code 7000218.

Fix: Check that the secret is loaded at startup. "Allow public client flows" is only for genuine public clients (device code, ROPC), not for services.

AADSTS700027: Client assertion signature invalid

Message: Client assertion failed signature validation. At runtime for example Client assertion contains an invalid signature. The key was expired. or The certificate with identifier used to sign the client assertion is not registered on application. [Reason - The key was not found]. Thumbprint of key used by client: '…'.

Cause: The application signs with a certificate that is missing on the app registration or has expired there. Less often: a wrongly encoded thumbprint in the JWT header.

Where: As above, error code 700027. The message names the thumbprint used.

Fix: Compare the thumbprint with the "Certificates" tab. If it is missing or expired, upload a new certificate and switch the application.

AADSTS700024: Client assertion outside its time range

Message: Client assertion is not within its valid time range.

Cause: The signing certificate has expired or the client's system clock is significantly off.

Where: As above, error code 700024.

Fix: Check the certificate's NotAfter, check NTP. With certificates from Key Vault make sure the application loads the current version.

AADSTS700016: Application not found in tenant

Message: UnauthorizedClient_DoesNotMatchRequest - The application wasn't found in the directory/tenant. At runtime: Application with identifier '…' was not found in the directory '…'.

Cause: The client ID does not match the tenant in the authority URL: a typo, a multi-tenant app without consent in the target tenant, or a deleted app registration.

Where: Token response and application log. The message contains both IDs.

Fix: Compare both IDs with the app registration. Deleted app registrations can be restored for 30 days on the "Deleted applications" tab.

AADSTS650057: Resource not in the app's permissions

Message: Invalid resource. The client has requested access to a resource which isn't listed in the requested permissions in the client's application registration. Client app ID: {appId}({appName}). Resource value from request: {resource}. Resource app ID: {resourceAppId}. List of valid resources from app registration: {regList}.

Cause: The scope points to an API for which the app has no permission configured. Not a credential problem, but a typical follow-up error after a hurried re-registration.

Where: Token response. The message lists the app's valid resources.

Fix: Add the permission under "API permissions" and grant admin consent. Check the scope, for Graph https://graph.microsoft.com/.default.

AADSTS500011: Resource principal not in tenant

Message: InvalidResourceServicePrincipalNotFound - The resource principal named {name} wasn't found in the tenant named {tenant}.

Cause: The target API has no service principal in this tenant, the request went to the wrong tenant, or the resource URL is wrong. Common with MSPs: your own tenant ID instead of the customer's.

Where: Token response, error here is invalid_resource.

Fix: Check tenant ID and resource URL from the message. If the service principal is missing, provision the resource app or grant consent.

AADSTS53003: Blocked by Conditional Access

Message: BlockedByConditionalAccess - Access has been blocked by Conditional Access policies. The access policy does not allow token issuance.

Cause: A Conditional Access policy for workload identities blocks the service principal, for example by location or risk. The credential itself is fine.

Where: Sign-in logs, "Service principal sign-ins" tab. The "Conditional Access" tab in the entry shows the policy.

Fix: Adjust the policy or exclude the service principal. Rotating the secret changes nothing.

Finding the affected app

The error_description almost always contains the app ID, often the tenant ID. Search for it under "App registrations", tab "All applications".

Without the application log, use the sign-in logs, tab "Service principal sign-ins". Filter on status "Failure" and the time range. Each entry shows service principal, application ID, the error code as a number and the failure reason. The correlation ID gets you to the exact request.

Checking remaining credentials

In the portal, "Certificates & secrets" shows both tabs with description, expiry date and secret ID or thumbprint. With the Microsoft Graph PowerShell SDK, read permission is enough:

Connect-MgGraph -Scopes "Application.Read.All"

$app = Get-MgApplication -Filter "appId eq '11111111-2222-3333-4444-555555555555'" `
  -Property DisplayName, AppId, PasswordCredentials, KeyCredentials

$app.PasswordCredentials | Select-Object DisplayName, KeyId, EndDateTime
$app.KeyCredentials      | Select-Object DisplayName, KeyId, EndDateTime

PasswordCredentials are the client secrets, KeyCredentials the certificates. Anything with an EndDateTime in the past is dead. A script for every app in a tenant is in the post Entra app registration secrets expire.

Recover quickly

  1. Create a new secret or upload a new certificate, with a description such as "Backup connector, rotated 2026-09".
  2. Enter the value everywhere the application reads it: configuration, environment variables, Key Vault, pipeline variables, service connections. A forgotten location is the usual reason the error persists.
  3. Restart or deploy the application and confirm in the sign-in logs that the status changes to "Success".
  4. Delete the old credential only once every consumer has been switched. An app registration may hold several valid secrets and certificates at once.

Preventing the next incident

  • Inventory: which application uses which credential and who owns it, recorded on the app registration.
  • Rotate with overlap: create the new credential 30 days before expiry, switch, delete the old one afterwards.
  • Standardise lifetimes, for example twelve months for secrets, with reminders at 30, 14 and 7 days.
  • Use certificates, managed identities or workload identity federation wherever possible. No secret left to expire.
  • Monitor expiry dates, by script, automation or a service. Microsoft Entra itself sends no warning.

How SecretExpiry helps

SecretExpiry reads only app registration metadata with the Application.Read.All permission and monitors client secrets and certificates across many tenants. Expiring credentials are reported by e-mail, per event or as a weekly digest, via Microsoft Teams or Slack webhook, and as a calendar subscription (ICS). Each tenant can have its own notification address, and individual alerts can be snoozed. The dashboard lists the urgent cases. The service starts at 10 € per tenant per month, with a 14-day free trial. Details in the documentation.