What breaks
SAML sign-in can fail if the application rejects an expired signing certificate. Applications that do not check expiry may still accept it. See Microsoft's SAML certificate guide.
Don't rely on the built-in SAML expiry mails alone
AppAlert emails your admins before SAML signing certificates expire. Read-only, free during Early Access. Connect read-only
- Read-only permissions
- Microsoft Graph application permissions
Application.Read.All,Directory.Read.All,AgentIdentity.Read.All,AgentIdentityBlueprint.Read.All,AgentIdentityBlueprintPrincipal.Read.All, plusUser.Readfor sign-in. No write permissions: AppAlert cannot create, rotate, or delete credentials. - Never received
- Secret values, certificate private keys, Microsoft account passwords, and mailbox contents. AppAlert stores credential metadata such as type, expiry date, and owner email addresses.
- Where data lives
- App functions and database in Frankfurt, Germany (Vercel fra1, Neon on AWS eu-central-1). Alert emails are sent through Resend, which stores them in the United States. Data location
- Revoke any time
- A Microsoft Entra administrator can revoke AppAlert's enterprise application consent. That stops future directory reads; deleting stored data is a separate request. Retention and revocation
How you notice
Microsoft Entra sends an expiry email 60, 30 and 7 days before a SAML signing certificate expires. The emails come from azure-noreply@microsoft.com and go to up to five notification addresses, including the administrator who added the app. Use a distribution list to reach more people. Microsoft's federation certificate tutorial lists these details.
If you set the notification addresses with Microsoft Graph or PowerShell, open the app in the Entra admin center under Enterprise applications, then Single sign-on, SAML, and check the notification email address in the SAML Certificates section. Microsoft notes that expiry emails might not be sent if the SAML settings are not verified there. See the notification guidance.
If sign-in fails, compare the application's errors with the certificate configured on both sides. A SAML error alone does not prove expiry.
How do I find SAML certificates that expire soon?
Inspect service principal keyCredentials with usage Verify or Sign and an endDateTime. The service principal reference describes the collection, and the key credential reference defines these fields.
Run this snippet in an authenticated Microsoft Graph PowerShell session:
$WarningDays = 30
$Cutoff = [DateTimeOffset]::UtcNow.AddDays($WarningDays)
$Properties = @('id', 'displayName', 'preferredSingleSignOnMode', 'keyCredentials')
Get-MgServicePrincipal -All -Property $Properties -ErrorAction Stop |
ForEach-Object {
$App = $_
foreach ($Credential in $App.KeyCredentials) {
if ($Credential.Usage -notin @('Verify', 'Sign')) { continue }
if ($null -eq $Credential.EndDateTime) { continue }
$End = [DateTimeOffset][DateTime]::SpecifyKind($Credential.EndDateTime, 'Utc')
if ($End -le $Cutoff) {
[pscustomobject]@{
App = $App.DisplayName
ServicePrincipalId = $App.Id
SignOnMode = $App.PreferredSingleSignOnMode
KeyId = $Credential.KeyId
Usage = $Credential.Usage
EndDateTime = $End.UtcDateTime.ToString('o')
}
}
}
}
Treat these rows as candidates and confirm which belong to SAML apps. preferredSingleSignOnMode may be null for older SAML apps, so do not filter only for saml. This example includes expired certificates and skips missing expiry dates. Review those separately. Set $WarningDays to your renewal lead time.
Why it happens
Rollover needs agreement between Entra and the receiving application. Automatic discovery depends on the application's support for federation metadata. See Microsoft's rollover guidance.
Renewal path
The commands follow Microsoft's documentation and were not run against a real environment.
In the Entra admin center
- Read the application's rollover instructions and check whether it accepts overlapping certificates.
- Create and save a replacement under Single sign-on, SAML Certificates.
- Coordinate certificate upload or metadata discovery with activation. Plan downtime if the application accepts only one certificate.
- After the application has the replacement, select "Make certificate active" on the new certificate row. Follow Microsoft's activation procedure.
- Test a new sign-in before retiring the previous certificate.
If an expired certificate exists, Entra uses a newly created certificate for signing even before you activate it. Coordinate the application's update before creating the replacement. Follow the Microsoft rollover procedure.
With Microsoft Graph
addTokenSigningCertificate creates a self-signed certificate. It adds private Sign and public Verify key credentials plus a password credential. The display name must start with CN=. Choose an expiry up to three years after creation. The default is three years.
The least privileged permissions are Application.ReadWrite.All for delegated access and Application.ReadWrite.OwnedBy for application access, as listed in the API reference. Replace <expiry-utc> with your chosen ISO 8601 date:
POST https://graph.microsoft.com/v1.0/servicePrincipals/<sp-object-id>/addTokenSigningCertificate
Content-Type: application/json
{
"displayName": "CN=<name>",
"endDateTime": "<expiry-utc>"
}
Or use Add-MgServicePrincipalTokenSigningCertificate in Microsoft Graph PowerShell:
Connect-MgGraph -Scopes 'Application.ReadWrite.All'
$NewCertificate = Add-MgServicePrincipalTokenSigningCertificate `
-ServicePrincipalId '<sp-object-id>' `
-BodyParameter @{
displayName = 'CN=<name>'
endDateTime = '<expiry-utc>'
} -ErrorAction Stop
# The response is the public part of the new certificate.
# Give its key and thumbprint to the application's owner for the update.
Update the receiving application with the public certificate or metadata before switching the signing certificate. For SAML apps, preferredTokenSigningKeyThumbprint selects the signing certificate. Use the replacement thumbprint only after the application accepts it. Set it with an update service principal request:
PATCH https://graph.microsoft.com/v1.0/servicePrincipals/<sp-object-id>
Content-Type: application/json
{
"preferredTokenSigningKeyThumbprint": "<new-certificate-thumbprint>"
}
Test a fresh sign-in before retiring the old certificate. Apply the expired-certificate caveat above when planning recovery.
Who should own it
Assign a joint change to the identity administrator and the person who controls the application's SAML settings.
Lead time and business-day math
Suggested planning buffer: 30 calendar days. Book the application owner's working-day availability and any vendor support window before selecting a rollover date.
Related failure modes
A client authentication certificate authenticates a workload rather than signing user SAML assertions.
Monitored by AppAlert
Monitored
AppAlert monitors SAML signing certificate expiry and sends email alerts to configured admin recipients before a certificate expires, with optional routing to application owners.
Expiration tracking does not verify the application's rollover configuration.
Use the Operations queue to review the expiry and application context. Configure who receives alerts in Alert settings and recipients; for a missing alert, follow Missing notifications.