Skip to main content
AppAlert

Entra SAML signing certificate expired

Reviewed

On this page
Credential type
SAML Certificate
Resource type
Enterprise application
Blast radius
Users signing in to the affected SAML application
Likely first responder
Service desk or application owner
Suggested owner
Identity administrator and application owner
Suggested planning buffer
30 calendar days

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, plus User.Read for 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

  1. Read the application's rollover instructions and check whether it accepts overlapping certificates.
  2. Create and save a replacement under Single sign-on, SAML Certificates.
  3. Coordinate certificate upload or metadata discovery with activation. Plan downtime if the application accepts only one certificate.
  4. After the application has the replacement, select "Make certificate active" on the new certificate row. Follow Microsoft's activation procedure.
  5. 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.

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.