Entra SAML Signing Certificate Expired: What It Means
When an Entra SAML signing certificate is expired, federated sign-in for that application breaks tenant-wide — not because of an attack, but because of a routine administrative task nobody scheduled. Every enterprise application configured for federated single sign-on (SSO) through SAML in Microsoft Entra ID relies on a signing certificate: Entra ID uses its private key to cryptographically sign the SAML assertions it issues, and the service provider validates those assertions against the matching public key. This is the trust anchor for the entire federation relationship — if the certificate is invalid, the assertion is worthless to the service provider no matter how correct the rest of the authentication flow is.
"Certificate health" covers three distinct but related risk states tracked in the EtcSec vulnerability catalogue for Azure Applications:
- Expired — the certificate's validity period has already passed. This is a functional outage, not just a security weakness.
- Expiring soon — the certificate will expire within 30 days and no renewal has been staged.
- Long lifetime — the certificate was issued with an excessively long validity window (Entra ID defaults to three years), which widens the blast radius if the private key material is ever mishandled and increases the chance that whoever owned the rotation process has since left, been reorganized, or simply forgotten.
By default, when you configure SAML-based SSO for a gallery or non-gallery application, Entra ID auto-generates a self-signed certificate valid for three years (Microsoft Learn). Unlike an application secret with a short default lifespan that forces frequent attention, a three-year SAML certificate is easy to configure once and never think about again — until it silently expires.
How the Certificate Underpins Federated Sign-In
When Entra ID acts as the identity provider (IdP) for a SAML application, the sign-in flow depends on certificate state at two points:
- Entra ID signs the SAML assertion (or the response) with the private key of the active signing certificate on the enterprise application's service principal.
- The service provider validates that signature against the public certificate it has on file (either uploaded manually or fetched dynamically from the application's federation metadata URL).
If the certificate Entra ID used to sign has expired, Entra ID does not stop signing with it — it keeps using whatever certificate is marked active. It is the service provider that rejects the assertion once it sees the certificate is no longer within its validity window, and that rejection is what users experience as a failed login (Microsoft Learn). In other words: Entra ID does not "notice" the expiry and block sign-in proactively — the failure surfaces downstream, at the application, and only after users start hitting it.
Metadata polling and email notifications
Two mitigations exist depending on the application's capabilities:
- Federation metadata polling. For applications that support it, Entra ID checks the application's federation metadata roughly 35 days before signing certificate expiry; if a new certificate is discoverable there, no manual intervention or notification is needed (Microsoft Learn).
- Email notifications. For everything else, Entra ID emails the configured notification addresses on the enterprise application 60, 30, and 7 days before expiry, from
[email protected]— up to five addresses, defaulting to just the admin who originally configured SSO (Microsoft Learn).
Both mitigations depend on someone having configured them correctly in the first place, and both are commonly skipped: metadata polling only works if the application actually supports and consumes it, and the notification list is trivially left at a single departed admin's mailbox.
⚠️ Warning: If certificate expiration validation is disabled on the application side and a new certificate is created before the scheduled maintenance window for the rollover, Entra ID can automatically switch to that valid-but-not-yet-uploaded certificate ahead of schedule — and because the service provider hasn't received it yet, this causes an application outage rather than a quiet fix. Microsoft's own guidance is to wait for the maintenance window before creating the new certificate, and to keep expiry validation enabled on the service provider in the first place (Microsoft Learn).
What Breaks When the Certificate Expires or Sits Too Long
The impact of an expired SAML signing certificate is availability, not confidentiality: federated sign-in for that application fails for every user until the certificate is renewed and reactivated on both sides. For a line-of-business SaaS app used tenant-wide, that is a full outage triggered purely by an administrative oversight, not by any attacker action.
Long-lived certificates carry a different, quieter risk. A three-year (or longer) validity window means:
- Rotation happens rarely enough that the manual process — generate, download, upload to the SP, activate, verify, clean up the old cert — is unfamiliar every time it's needed, increasing the odds of a mistake during the actual rotation.
- Ownership drift: the admin who set it up may no longer be with the organization by the time renewal is due.
- A longer window for private key material to be exposed if the certificate or its export is ever mishandled, without a forced refresh.
Microsoft's own guidance to ISVs building SAML integrations acknowledges this directly, noting that manual rollover becomes "untenable" at scale as certificate lifetimes trend shorter industry-wide, and recommends applications support automated metadata-based rollover with primary/secondary signing certificates specifically to remove the operational fragility of long, manually-managed lifetimes (Microsoft Learn).
This is also why the gap matters from a coverage standpoint: SAML certificate lifecycle is a distinct risk from application permission hygiene. A related but different Applications-category risk — over-privileged app registrations with excessive delegated permissions — is covered in Azure App Registrations: Over-Privileged Tenant Apps; certificate health is an orthogonal, availability-first concern within the same category.
Detection: Finding Expiring and Long-Lived SAML Certificates
Don't wait for a help desk ticket storm to discover a certificate has expired. Entra ID exposes certificate state through several channels:
| Signal | Where | What to look for |
|---|---|---|
| Certificate expiration status | Entra admin center → Enterprise apps → [App] → Single sign-on → SAML Certificates | Status, expiration date, and thumbprint of each certificate (active and inactive) |
keyCredentials, passwordCredentials | Microsoft Graph servicePrincipal object | endDateTime in the past or within 30 days; multiple credentials with unclear active state |
preferredTokenSigningKeyThumbprint | Microsoft Graph servicePrincipal object | Confirms which certificate Entra ID is actually signing with — cross-check it matches what's uploaded to the service provider |
| Renew expiring service principal credentials recommendation | Entra admin center → Overview → Recommendations, or Graph /beta/directory/recommendations (servicePrincipalKeyExpiry) | Flags any service principal credential expiring within 30 days, tenant-wide, without checking app by app (Microsoft Learn) |
| Audit logs | Microsoft Entra audit logs — Service: Core Directory, Category: ApplicationManagement, Activity: Update Application – Certificates and secrets management / Update Service principal | Credential added outside a known change window, or no credential update logged as expiry approaches (Microsoft Learn) |
| Sign-in logs | Microsoft Entra sign-in logs, filtered to the affected application | A spike of failed sign-ins concentrated on one app is the operational symptom; third-party SAML troubleshooting references (e.g. SSOJet's Entra SAML error guide) commonly associate this failure mode with AADSTS50008 (InvalidSamlToken) at the relying party — treat the code as a signal to check certificate status, not a certainty, since the same code can have other causes |
💡 Tip: Query keyCredentials and passwordCredentials across every servicePrincipal in the tenant rather than checking applications one at a time — this is exactly the audit Microsoft's own security operations guidance recommends for catching long credential expiration windows before they become an outage (Microsoft Learn).
For a broader walkthrough of how to structure a full Entra security review beyond just certificates, see How to Audit Microsoft Entra ID Security. For tenant-wide default hardening that reduces exposure alongside certificate hygiene, see Azure Tenant Hardening: Fix Insecure Default Settings.
Remediation: Renewing Without Downtime
Microsoft's documented renewal sequence exists specifically to avoid an outage during rotation — skipping steps or doing them out of order is the most common way teams turn a planned renewal into an unplanned one.
Step 1 — Create the new certificate early
Create the new certificate with an expiration date that overlaps the current certificate's remaining validity, via Enterprise apps → [App] → Single sign-on → SAML Certificates → New Certificate. It is saved as Inactive — this step alone causes no disruption (Microsoft Learn).
Step 2 — Upload it to the service provider first
Download and upload the new certificate to the service provider, in the encoding format the application's SSO configuration guide specifies, before activating it in Entra ID.
Step 3 — Activate, verify, and clean up
Activate the new certificate in Entra ID (select the new certificate's … menu → Make certificate active) — this automatically marks the previous certificate inactive. Verify sign-in works end-to-end for the application before considering the rotation complete, then remove the old certificate once verified so it can't be mistakenly reactivated later.
# Microsoft Graph PowerShell — inspect current SAML signing certificate state for a service principal
Connect-MgGraph -Scopes "Application.Read.All"
Get-MgServicePrincipal -ServicePrincipalId "<service-principal-object-id>" `
-Property "keyCredentials,preferredTokenSigningKeyThumbprint" |
Select-Object -ExpandProperty KeyCredentials |
Select-Object DisplayName, Usage, StartDateTime, EndDateTime
To add a new token signing certificate programmatically, use the Graph servicePrincipal addTokenSigningCertificate action, then set preferredTokenSigningKeyThumbprint to the new certificate's thumbprint to make it the one Entra ID signs with (Microsoft Learn — Configure SAML SSO using Microsoft Graph).
✅ Note: Close the long-lifetime gap at the same time as any renewal. Set the new certificate's expiration to a shorter, deliberate window instead of accepting the three-year default, and put the next renewal on a calendar with enough lead time to avoid a repeat scramble.
Preventing recurrence
Beyond the certificate itself, two low-effort controls prevent recurrence:
- Populate the notification email addresses field on every federated application with a distribution list, not an individual's mailbox — up to five addresses are supported, and Entra ID sends the 60/30/7-day warnings there (Microsoft Learn).
- Act on the Renew expiring service principal credentials recommendation in the Entra admin center Overview page as a standing, tenant-wide check rather than relying on per-application memory.
For app-permission risks that often live alongside certificate misconfiguration on the same enterprise applications, see OAuth Consent Phishing: How Malicious Apps Bypass Password Theft. For the broader Conditional Access controls that govern how federated apps can be reached in the first place, see Entra ID Conditional Access Gaps.
How EtcSec Detects This
EtcSec's Azure audit checks every enterprise application's SAML signing certificate state during each tenant scan. SAML_CERTIFICATE_EXPIRED flags any application whose active signing certificate has already lapsed — a critical, availability-impacting finding, since federated sign-in for that app is actively broken. SAML_CERTIFICATE_EXPIRING_SOON flags certificates approaching expiry so renewal can be scheduled instead of rushed, and SAML_CERTIFICATE_LONG_LIFETIME flags certificates issued with an excessive validity window, so you can shorten it at the next rotation rather than resetting the same multi-year clock.
ℹ️ Note: EtcSec automatically checks for this vulnerability during every Azure audit. Run a free audit to verify your environment's SAML certificate posture across every federated application.
Explore the identity security pages that support this topic