Home › Guides › Identity & Security
Find Expiring App Secrets and SAML Certificates in Microsoft 365 (Free Script)
Your scanner stops emailing scans. The accounting software can't sync. Single sign-on to a vendor portal fails on a Monday morning. Behind a surprising number of these outages is the same thing: a client secret or certificate in Microsoft Entra ID quietly reached its expiry date, and nobody knew it existed. This guide shows where those credentials live, what Microsoft warns you about (and what it doesn't), and a free script that finds every one before it expires.
The short version
- Apps connected to Microsoft 365 often sign in with a client secret (a long password) or a certificate. Both expire.
- For SAML single sign-on certificates, Microsoft emails a warning 60, 30 and 7 days before expiry, but by default only to the admin who first added the app.
- For app registration secrets, there's no per-secret expiry email like that. A preview Entra recommendation can email your Application Administrators, but don't rely on it alone.
- The free script below lists every secret and certificate expiring in the next 30 days (or whatever window you pick), in one report.
Where these credentials live
There are two places in the Microsoft Entra admin center to look:
| Where | What you'll find | Typical example |
|---|---|---|
| Entra ID > App registrations > (app) > Certificates & secrets | Client secrets and certificates that an app or script uses to sign in as itself | A backup tool, a scan-to-email app, a reporting integration, or a script a consultant left behind |
| Entra ID > Enterprise apps > (app) > Single sign-on > SAML Certificates | The token-signing certificate that proves sign-ins to a SAML app really came from your tenant | SSO to an HR, payroll, CRM or vendor portal |
Checking these one app at a time works for two or three apps. Past that, it's easy to miss one, which is the point of the script.
What Microsoft warns you about, and what it doesn't
SAML certificates: emails, but to one person
When you set up SAML single sign-on, Microsoft creates a signing certificate that lasts three years by default. Microsoft sends expiry emails 60, 30 and 7 days before it expires, from [email protected]. The catch: by default they go only to the admin who added the app. If that was a consultant or someone who has left, nobody sees them (Manage certificates for federated single sign-on).
Fix it now: open each SAML app's Single sign-on page, edit SAML Certificates, and add a shared mailbox or distribution list under Notification email addresses (up to five addresses). Add [email protected] to your safe senders so the warnings don't land in junk.
App registration secrets: no per-secret warning
Unlike SAML certificates, an app registration's client secret doesn't come with its own expiry emails. Microsoft Entra has a preview recommendation, Renew expiring application credentials, that flags credentials expiring within the next 30 days (Renew expiring application credentials). Recommendations can also send preview email notifications, and for this one they go to users with the Application Administrator role (Recommendations overview).
Three reasons not to rely on that alone: it's a preview feature; Microsoft notes some recommendations need extra licensing; and if nobody holds the Application Administrator role (common in small offices, where one Global Administrator does everything), or your admins use Privileged Identity Management and aren't elevated at the time, Microsoft says no email is sent.
The free script: one report of everything expiring
I wrote Get-EntraAppCredentialExpiry.ps1 to do this check across the whole tenant. It only reads from your tenant: it never changes or deletes anything there. (The optional Teams and email alerts below do send a message, and nothing else.)
- Checks every app registration's client secrets and certificates.
- With
-IncludeServicePrincipals, also checks enterprise apps, which is where SAML signing certificates live. Microsoft's own built-in apps are skipped. - Shows each SAML certificate once and marks which one is active. Old certificates left over from a rollover show as Inactive instead of raising a false alarm.
- Writes a CSV and an HTML report, sorted by days remaining.
- Can post an alert to a Teams channel or email the report, and only does so when something needs attention.
- Runs on Windows, Mac or Linux, and can run on a schedule.
Download the script (free) Windows PowerShell 5.1 or PowerShell 7 · about 16 KB · no sign-up
Run it the first time
- On Windows, the built-in Windows PowerShell (5.1) works, and so does PowerShell 7. On a Mac or Linux, install PowerShell 7.
- Install the one Microsoft module it needs:
Install-Module Microsoft.Graph.Authentication -Scope CurrentUser - On Windows, unblock the downloaded file:
Unblock-File .\Get-EntraAppCredentialExpiry.ps1 - Run it, including already-expired credentials and SAML certificates:
.\Get-EntraAppCredentialExpiry.ps1 -IncludeExpired -IncludeServicePrincipals - Sign in when the browser window opens. The first time anyone in your tenant runs it, a Global Administrator needs to approve the
Application.Read.Allpermission for Microsoft Graph Command Line Tools. On the consent screen, tick Consent on behalf of your organization before accepting; otherwise each admin who runs it later gets asked again. After that, an account with the read-only Global Reader role is enough. - Open the HTML report it saves in the current folder.
To look further ahead, add -DaysAhead 90. For a full inventory of every credential, add -AllCredentials. If you set up the Teams or email alerts, add -WhatIf to see what it would send without sending it. Get-Help .\Get-EntraAppCredentialExpiry.ps1 -Full shows every option.
Get a weekly alert in Teams
- In the Teams channel you want alerts in, add the Workflows app and choose the template Post to a channel when a webhook request is received. Copy the URL it gives you.
- Run the script with that URL:
.\Get-EntraAppCredentialExpiry.ps1 -IncludeExpired -IncludeServicePrincipals -TeamsWebhookUrl "<your workflow URL>"
To email the report instead, add -MailFrom [email protected] -MailTo [email protected]. When you run it yourself, -MailFrom has to be your own mailbox.
To run it automatically every week, it needs to sign in without you. The script's built-in help covers both options: an app registration with a certificate (for a Windows scheduled task) or a managed identity (for Azure Automation). If an unattended run sends email, its Mail.Send permission lets it send as any mailbox in your tenant, so limit it to your alerts mailbox with RBAC for Applications in Exchange Online.
When the report finds something
Don't let a credential simply expire, and don't delete the old one first. The safe order is:
- Find out what uses it. The secret's description and the app's name are your clues. If it's a vendor's app, ask the vendor or check their setup guide.
- Create the new one first. For a client secret, add a new secret under Certificates & secrets and copy the value immediately, because Entra only shows it once. Store it in your password manager. For a SAML app, create a new certificate on the SAML Signing Certificate page.
- Update the app or vendor. Paste the new secret into the app's settings, or upload the new SAML certificate to the vendor. For SAML, make the new certificate active in Entra at the same time; if Entra and the app don't match, sign-ins fail.
- Test. Make sure scans send, sync runs, or SSO sign-in works.
- Remove the old credential. Only after the new one is confirmed working.
Give each new secret a description that says who uses it and why, so the next person doesn't have to guess. For example: Scanner - Scan to Email - PROD - 2026-10-24 - AB.
Mistakes I'd avoid
- Leaving SAML warnings going to one person. Add a shared mailbox to every SAML app's notification list today. It takes a minute per app.
- Deleting secrets you don't recognize. An unknown secret might be the one keeping your backup running. Find the owner first.
- Sharing one secret between several apps. When it expires, they all break at once. One secret per app or vendor.
- Picking the longest expiry to "avoid the hassle". A secret that lasts two years is one everyone forgets. A shorter expiry with a weekly report is safer.
Sources
- Manage certificates for federated single sign-on (Microsoft Learn)
- Application management certificates FAQ (Microsoft Learn)
- Microsoft Entra recommendation: Renew expiring application credentials (Microsoft Learn)
- What are Microsoft Entra recommendations? Email notifications (Microsoft Learn)
- Role Based Access Control for Applications in Exchange Online (Microsoft Learn)
- Add and manage application credentials (Microsoft Learn)
- Client secret expiration now limited to a maximum of two years (Microsoft 365 Developer Blog, 2022; cited only for the removal of "Never")
Useful links for this guide: install PowerShell 7 (Mac and Linux) · install the Microsoft Graph PowerShell SDK. These are ordinary links, not affiliate links.