Entra app registration secrets expire: how to prevent the outage

An expired client secret is one of the most common reasons an integration in Microsoft 365 suddenly stops: the backup goes quiet, the ticketing connector stops syncing, a PowerShell job dies with an authentication error. Nothing was changed, nothing was hacked. A date simply passed.

Why secrets and certificates expire at all

Every app registration in Microsoft Entra ID authenticates with a client secret or a certificate. Both carry a fixed expiry date:

• Client secrets get their lifetime when they are created. The Entra portal suggests 180 days and allows at most 24 months.
• Certificates expire when the certificate itself expires, typically after one to three years.

That is by design. A credential that never expires is a credential that stays valid forever after a leak. The problem is not the expiry date. The problem is that nobody hears about it in time.

Microsoft does not warn you

Microsoft Entra has no built-in notification for expiring app credentials. No email, no message in the admin center, no entry in service health. The app registrations list does show "Expiring soon" in its "Certificates & secrets" column, but somebody has to open it. For every tenant. Regularly.

With one tenant and five apps that is manageable. An MSP with 40 customer tenants and a few hundred app registrations has no such overview without tooling.

What happens when it expires

Once the secret has expired, Entra rejects the token request. The log then shows something like:

AADSTS7000222: The provided client secret keys for app '…' are expired.

Everything that uses this app stops: Graph API scripts, backup and archiving solutions, monitoring tools, Power Automate connections, single sign-on in third-party apps. IT often learns about it from a department wondering why no data has arrived since yesterday.

Four ways to keep track

1. The portal column

In the Entra admin center under App registrations, the "Certificates & secrets" column shows per app whether a credential is current, expiring soon or expired. Free, works, does not scale. Somebody has to remember, and with several tenants that means signing in several times.

2. PowerShell with Microsoft Graph

A script that reads every app registration with its credentials and sorts those expiring within 30 days by date:

Connect-MgGraph -Scopes "Application.Read.All"
$limit = (Get-Date).AddDays(30)

Get-MgApplication -All -Property DisplayName, AppId, PasswordCredentials, KeyCredentials |
  ForEach-Object {
    $app = $_
    @($app.PasswordCredentials) + @($app.KeyCredentials) |
      Where-Object { $_.EndDateTime -lt $limit } |
      ForEach-Object {
        [pscustomobject]@{
          App        = $app.DisplayName
          Credential = $_.DisplayName
          Expires    = $_.EndDateTime
        }
      }
  } | Sort-Object Expires

This works well as long as somebody runs it regularly, reads the output and maintains a connection for every tenant. In practice the script ends up in a folder nobody opens after three months.

3. Azure Automation or Logic App

The script from step 2 as a scheduled runbook or Logic App, plus an email step. More reliable than manual, but now you operate a small application yourself: permissions, a credential for the automation (which also expires), error handling, one deployment per tenant.

4. A service that does exactly this

SecretExpiry reads metadata only, via admin consent with the Application.Read.All permission: app names, IDs and expiry dates. The service never sees the secret values themselves. After that:

• a daily sync across all connected tenants in one dashboard,
• email alerts at thresholds of your choice (default 90, 30, 14, 7 and 1 day), immediately or as a weekly digest,
• the same alerts in a Teams or Slack channel,
• every expiry date as a calendar subscription in Outlook,
• a dedicated recipient address per customer tenant.

The effort per tenant: grant admin consent once.

Rotation without downtime: five rules

Knowing when something expires is half the job. The other half is swapping the credential so that nothing stops:

1. Rotate with overlap. Create the new secret, switch the application, verify, and only then delete the old one. An app registration may have several valid secrets at the same time.
2. Certificates over secrets wherever the application supports them. They are harder to leak and typically live longer.
3. Managed identities and workload identity federation for everything running in Azure, GitHub Actions or Kubernetes. There is no secret left to expire.
4. Maintain description and owner. A secret called "Test" with no owner cannot be traced when it matters. Write the purpose into the description and assign an owner on the app.
5. Standardise lifetimes. Twelve months for secrets, warnings at 30, 14 and 7 days. Rotation becomes a rhythm instead of an emergency.

Conclusion

Expired secrets are not a security incident, they are a calendar problem. Whoever sees the expiry dates of every app registration in one place and gets reminded in time rotates calmly instead of reviving integrations at night. Whether with a script, an automation or a service: the point is that it happens automatically.