Microsoft Entra ID, formerly Azure AD, rejects fresh token requests that use an expired credential. The app registration remains in place, but integrations using that credential can’t authenticate until a replacement is configured. Creating a new secret alone doesn’t restore service: the application, script or connector must receive its new value.
Entra client secret expiration can interrupt website sign-in, automated reporting or Exchange Online mail sending. Existing access tokens may continue working temporarily, which can delay the visible failure. Start by identifying the failing credential and every service that uses it.
Key Takeaways
- An expired Entra client secret blocks fresh token requests that use it, but previously issued access tokens may keep working until they expire.
- Creating a replacement secret doesn’t update the applications that use it. Copy its value when it appears, store it securely and update every dependent service.
- Use the Application (client) ID to identify the app in authentication requests, and the registration’s Object ID for the Microsoft Graph PowerShell command.
- Keep the old secret during deployment when it’s still valid, then test fresh authentication and the actual business operation before removing it.
- Assign an owner to each credential and monitor expiry dates with reminders that reach the responsible people.
What Entra client secret expiration actually breaks
The application cannot prove its identity
A confidential application presents its credential to Microsoft Entra ID when requesting tokens. The credential authenticates the application rather than the person using it.
Once that secret expires, Entra ID rejects authentication attempts using it. The error commonly includes AADSTS7000222, which identifies expired client secret keys. The registration, API permissions and consent normally remain unchanged.
For OpenID Connect sign-in, the application may fail when exchanging an authorisation code for tokens. An unattended mail-sending process may fail when requesting an application token. Neither problem is resolved by resetting a user’s password.
Cached tokens can delay the symptoms
Secret expiry does not automatically invalidate every access token already issued. A running service may continue until its token expires, whilst a restarted instance fails immediately.
This explains why an integration can appear healthy after the expiry time, then fail without another configuration change. Test a fresh token request rather than relying on an existing session or a previously successful scheduled job.
Identify the credential and every dependent service
Separate the application identifiers
Use the failed request’s client ID to locate the correct registration. Similar display names aren’t reliable identifiers, particularly where development and production applications coexist.
These identifiers have different purposes.
| Identifier | Purpose |
|---|---|
| Application (client) ID | Identifies the application in authentication requests |
| Registration object identifier | Identifies the registration object used for Graph management commands |
| Secret ID | Identifies a credential entry, but isn’t its authentication value |
Take the registration’s Object ID from its Overview page. An enterprise application’s service principal has a separate Object ID, so don’t substitute it.
Find consumers before changing credentials
Review deployment settings, Azure App Service configuration, Function Apps, automation accounts, scheduled tasks, CI/CD variables and connector settings. Search configuration references using the client ID, rather than exposing the secret in searches or support tickets.
Sign-in logs help identify workloads, but don’t provide a complete inventory of every configuration holding a secret. Infrequent jobs may have no recent activity.
Record the application owner, technical owner, deployment location and recovery procedure. Ownership also needs transferring when administrators leave; our Microsoft 365 leaver checklist covers connected applications and other access that ordinary account closure can miss.
Replace the secret in the Entra admin centre
There is no in-place option to renew client secret credentials. Instead, create a new client secret on the same app registration, then deploy its value to each dependent service. This preserves the application’s identity and permissions. A separate registration would have a different client ID and could require new consent.
Follow These Steps:
- Open the Azure portal and select the Microsoft Entra admin center for the correct tenant.
- Go to Identity > Applications > App registrations, then select the application.
- Open Certificates & secrets > Client secrets > New client secret.
- Enter a description that identifies the consuming service, choose an expiration date and select Add.
- Copy the new client secret value immediately into an approved secret store, then update the dependent application.
The portal offers 6 months (Recommended), 12 months, 24 months or Custom. Its maximum is 24 months, and a custom date cannot exceed 2 years. Microsoft recommends a lifetime of less than 12 months in its client secret lifetime guidance.
The secret value is displayed only immediately after creation. You can’t retrieve it after leaving the page. If you didn’t capture it, create another secret and remove the unused credential.
Copy the Value, not the Secret ID. Store it in Azure Key Vault or another approved credential store, rather than email, a ticket or an unrestricted document.
A shorter lifetime reduces exposure, but it also requires a reliable rotation process. Choosing 24 months only postpones that requirement.
Create a replacement with Microsoft Graph PowerShell
The Microsoft Graph PowerShell module creates a new password credential using the registration’s unique identifier. The ApplicationId parameter name is easy to misread: for this command, supply the registration’s Object ID, not its Application (client) ID.
Run the following in an authorised administrative session:
Install-Module Microsoft.Graph -Force
Connect-MgGraph -Scopes "Application.ReadWrite.All"
$appObjectId = Read-Host "Enter the app registration identifier"
$passwordCredential = @{
displayName = "Scheduled credential rotation"
endDateTime = (Get-Date).ToUniversalTime().AddMonths(6)
}
$newSecret = Add-MgApplicationPassword `
-ApplicationId $appObjectId `
-PasswordCredential $passwordCredential
Microsoft’s Add-MgApplicationPassword documentation includes the 6-month credential pattern.
The returned $newSecret.SecretText contains the replacement value. Transfer it directly into the approved secret store through a controlled process. Avoid writing the complete response into transcripts, pipeline logs or shared terminal output.
The requested scope requires appropriate consent and administrative authorisation. Use a controlled account with the necessary role, then disconnect the session after completing the change.
This command doesn’t update the consuming application’s configuration. It also doesn’t remove the old secret. Both actions remain part of the rotation procedure.
Switch consumers before removing the old secret
Use an overlap period where possible
If the existing secret is still valid, retain it whilst deploying the replacement. Multiple credentials can coexist on an app registration, which allows consumers to move without a simultaneous cutover.
Update each application’s secret reference, deployment variable or connector setting. Restart or redeploy services that only read configuration at startup. A Key Vault update does not guarantee every application has refreshed its cached value.
If the old secret has already expired, there is no working overlap. Restore the consumers first, then complete validation and cleanup.
Prove the replacement works
Force a fresh authentication request and run the actual business operation. For mail sending, test delivery rather than accepting a successful token request as proof that Exchange permissions are correct.
Check sign-in logs for the expected application and investigate remaining failures. Validate scheduled and secondary instances before deleting the previous credential.
An expired secret no longer authenticates, but removing it keeps the credential inventory clear. Record the replacement’s expiry, owner and affected services.
Build expiry alerts that reach an owner
Microsoft Entra provides a recommendation for application credentials expiring within 30 days. That visibility should not be confused with a dependable email reminder reaching the person responsible for rotation. Set up a secret expiration reminder that checks credential metadata daily and sends an expiry reminder to named owners. Azure doesn’t automatically notify every application owner.
Collect expiry metadata daily
A Logic App can run daily and query Microsoft Graph for application credential metadata. It can maintain an Azure Storage table backed by a storage account. Store the application identifiers, credential key ID, expiry, owner and notification status. Never store secret values in that table.
The workflow can then read the table and select expired credentials or those approaching expiry. Keep the table refreshed automatically; a manually maintained list will miss newly created credentials.
A Graph-based reader needs an appropriate permission such as the application permission Application.Read.All, with administrator consent. Prefer the Logic App’s managed identity where supported.
If a separate app registration authenticates the workflow, store its client ID, tenant ID and secret in Key Vault. Grant the Logic App’s managed identity access before testing. For a vault using access policies, add that identity to a policy allowing secret retrieval; RBAC-enabled vaults require the corresponding role assignment instead.
Deliver reminders and monitor the workflow
Email reminders for credentials expiring within 30 days, with a prominent warning for those within 5 days. Include expired credentials and suppress repeated notifications according to a documented schedule.
Power Automate can provide a similar scheduled reporting workflow, subject to connector permissions and licensing.
Monitor the alerting workflow itself. If it uses a client secret, that credential also needs rotation. Key Vault expiry events concern Key Vault objects; they don’t automatically track an app registration’s separate credential expiry.
Reduce the number of secrets requiring rotation
Managed identities remove the need to distribute a client secret for supported Azure workloads. Workload identity federation can do the same for supported external workloads, including suitably configured deployment pipelines. Both still require appropriate permissions and ownership.
Where those options are unsuitable, certificate authentication can replace a shared secret. Certificates still expire, and private keys still need protection. Microsoft advises using stronger credential approaches for production workloads rather than treating long-lived client secrets as a permanent solution.
User authentication is a separate decision. Our guidance on Microsoft Entra passkeys concerns people signing in; deploying passkeys does not replace an application’s credential.
Maintain an expiry register alongside automated monitoring, with a named owner and replacement procedure for every remaining secret. A personal reminder can help, but shared responsibility must survive absence, staff changes and supplier handovers.
Frequently Asked Questions
What happens when an Entra client secret expires?
Entra ID rejects fresh authentication attempts that use the expired secret, often with error AADSTS7000222. Previously issued access tokens may continue working until they expire, so a service can appear healthy for a time.
Does creating a new client secret restore the application?
Creating a new secret adds a credential to the app registration, but doesn’t change the configuration used by the application, script or connector. Update each consumer with the new secret value and test a fresh authentication request.
Which value should I use to update the application?
Use the secret Value, not the Secret ID. The portal displays the value only immediately after creation, so copy it into an approved secret store before leaving the page.
When can I remove the old secret?
If the old secret is still valid, keep it while you update consumers and check that they use the replacement. Test fresh authentication and the actual operation, then remove the old credential; if it has expired, restore service with the new secret before completing those checks.
Keep credential ownership with the service
A replacement secret restores authentication only after every dependent service receives and uses it. Reliable rotation combines an owner, an overlap period where possible and a fresh authentication test before cleanup.
Treat expiry monitoring as part of service ownership, rather than an administrator’s calendar task.
Speak to our team about Microsoft Azure, Microsoft 365 and IT consultancy support to review application credentials, document dependencies and establish a repeatable rotation process.
