At some point in the last few years, someone in your organisation built an integration. A Power Automate flow, a custom app, a third-party connector. It used an app registration in Entra ID to authenticate. They created a client secret — valid for one or two years — and set a calendar reminder they probably never kept.
The secret expired. The integration broke. Nobody got an email. The failure surfaced as a support ticket about something else — a report that stopped generating, a sync that hadn't run in days, a workflow that silently stopped three weeks ago and nobody noticed until today.
This is one of the most common, most preventable, and most consistently overlooked problems in Microsoft 365 administration.
Microsoft does send notifications about expiring app credentials — but only to the email address of the user who owns the app registration, and only if that user is still in the organisation and still has a mailbox. In practice, app registrations are often created by developers or contractors who have since left. The notification goes to a departed employee's mailbox, which is either disabled or redirected to a generic IT inbox nobody monitors.
There is no built-in dashboard showing all app registrations sorted by credential expiry date. You can see this per-app in the Entra admin centre, but there is no tenant-wide view that tells you "these three secrets expire in the next 30 days."
What broken actually looks like: A finance team's automated report stops appearing in SharePoint every Monday morning. The Power Automate flow shows a generic authentication error. The app registration's client secret expired four days ago. The flow has been silently failing since — no alert, no email, no notification in Teams. The team only noticed when someone asked where last week's report was.
App registrations can authenticate using either a client secret (a password-like string) or a certificate (a public/private key pair). Both have expiry dates. Both expire silently. Client secrets can be set to expire after 6 months, 1 year, or 2 years. They cannot be retrieved after creation — if you lose the value, you must generate a new one.
Certificates are more secure and support longer lifetimes. Managed identity credentials (for Azure-hosted workloads) don't expire at all — but only workloads running in Azure can use them.
In Entra admin centre, go to App registrations → All applications. Click each app, then Certificates & secrets. The expiry dates are shown per-credential. There is no tenant-wide filter or export built in — you must click through each app individually. Alternatively, the Microsoft Graph API call GET /applications?$select=displayName,passwordCredentials,keyCredentials returns expiry dates programmatically.
M365Clarity scans all app registrations on every scan and checks every client secret and certificate expiry date. First-party Microsoft apps are excluded.
Create the new secret first. The old secret remains valid until its original expiry. Update every integration that uses the old value, confirm they're working, then delete the old secret. The most common mistake is deleting the old secret immediately after creating the new one — before updating all the places where the old value is stored.
For Azure-hosted workloads, managed identities eliminate the credential management problem entirely. For non-Azure workloads, certificate-based authentication with a longer validity period reduces rotation frequency. For secrets that remain necessary: document every app registration, who owns it, and when its credentials expire. M365Clarity's 30-day warning is your safety net when that documentation lapses.
M365Clarity scans every app registration in your tenant and flags expiring credentials automatically — no PowerShell required.
Run a free scan →Related articles