I see this far too often. Things run fine for months, and then one morning users of an important SaaS platform can't sign in. Nearly every time, the cause is an expired SAML token signing certificate in an Entra enterprise app. Renewing a SAML certificate ought to be routine. In practice the technical steps are the easy part, and the real risk sits in communication gaps and in the odd behaviour of individual service providers.
A SAML certificate renewal in Entra needs no outage if you keep the old one active
SAML token signing certificates for Entra enterprise applications expire after three years by default. You start the renewal in the Entra admin center under Enterprise applications → [your app] → Single sign-on → SAML Certificates → Edit. There you can add a new certificate and leave the old one active. This is the part that matters: don't remove or deactivate the old certificate until every service provider instance trusts the new one. Some applications pull the SAML metadata from a URL and refresh on their own, but many need a manual upload. As long as both certificates stay active in the metadata, there's no downtime risk and no reason to hurry.
Practical tip: Use group mailboxes or ticketing addresses for SAML certificate notifications, not personal mailboxes. You set them under "Notification email addresses" in the Entra SAML configuration. It spares you a frantic search for the right person during an incident.
The metadata URL lets the app pick up the new certificate by itself
Renewal is cleanest when the service provider can fetch the SAML metadata URL. Then it takes a few clicks: create and publish the new certificate, and the app imports it automatically. The outage risk drops to zero. In many real deployments, though, I still run into apps that only read the metadata at startup or accept it by manual upload. With those, you have to time the switch and keep both certificates available for the transition. Microsoft covers these scenarios and a few more in its official documentation.
The process looks like this:
flowchart TD
Old_cert["old certificate active"] --> Add_new["add new certificate"]
Add_new --> Both_active["both certificates valid"]
Both_active --> SP_update["service provider updates metadata"]
SP_update --> Remove_old["remove old certificate"]
Figure: SAML certificate renewal with zero downtime. The app sees both certificates until it's ready to switch.
Graph PowerShell finds SAML certificates that expire soon
Once you look after more than a handful of SAML apps, keeping track of expiry dates by hand gets messy. The Microsoft Graph PowerShell module helps a lot here. The script below (PowerShell 7, Microsoft.Graph.Applications module, Application Administrator or higher) lists every SAML certificate that expires within the next 60 days:
Connect-MgGraph -Scopes "Application.Read.All"
$apps = Get-MgServicePrincipal -Filter "servicePrincipalType eq 'Saml'"
$today = Get-Date
$expiring = $apps | Where-Object {
$_.KeyCredentials | Where-Object { $_.EndDateTime -lt ($today.AddDays(60)) }
}
$expiring | Select-Object Id, DisplayName, @{N='Expires';E={$_.KeyCredentials.EndDateTime}}
You get the app ID, display name and expiry date. From what I've seen, anyone responsible for SAML SSO should run a check like this once a month. If you want automated monitoring for all app certificates and secrets, have a look at my post App credential expiry: Reporting and alerts in Entra ID.
Outdated notification addresses cause most of the trouble
The biggest pitfall is organizational rather than technical. Notification addresses are often out of date or belong to someone who has left the company. Entra then sends its expiry warnings, nobody reacts, and SAML SSO fails without warning. So check the notification addresses in the SAML configuration every time you renew. If external vendors are involved, write down how each app handles metadata, whether it fetches it automatically or needs a manual upload.
SAML certificate renewal works best as a boring routine
There's nothing dramatic about renewing a SAML certificate if you prepare for it. Where you can, use the metadata URL so the switch happens on its own. For everything else, rely on a clear process and regular reporting. What really counts is keeping both certificates available until the app is ready and making sure the notification contacts are current. With those habits in place, renewal is just another admin task, which is exactly what it should be.
The official guidance has the full details, including edge cases and troubleshooting.


