SAML SSO Certificate Expirations: How Expired IdP Metadata Locks Out Enterprise Clients

It is 8:30 AM on a Monday. Your agency's support inbox fills with urgent tickets. Every employee at your highest-paying enterprise client, from the warehouse floor to the C-suite, hits the same error after clicking "Sign in with SSO." Something like "SAML Response Verification Failed" or "Invalid Signature." Nobody can log in. The project portal, the internal CRM and the custom SaaS tool your team built are all unreachable.

The cause is rarely an attack, a hardware failure or a bad deploy. More often it is an administrative blind spot: the identity provider's SAML signing certificate reached the end of its life (or was rotated), and the portal your agency maintains was still trusting the old one.

SAML signing certificates live for years, so they sit out of sight. Microsoft Entra ID generates them with a three-year lifetime by default, and Okta auto-generates them with a ten-year default. Because they are touched so rarely, the person who set up the integration has often left, or moved on to other work, by the time the date arrives.

This guide covers how SAML certificate trust works, why expiry warnings often never reach the agency, what to do during an outage, how to build rollover-safe integrations, and how to keep the dates in front of your team using a renewal register such as InstaRenewal.

---

1. How SAML Certificates Work

In a federated SSO setup there are two parties:

• Identity Provider (IdP): the enterprise's login system, for example Okta, Microsoft Entra ID, Ping Identity or OneLogin. It holds a private signing key.
• Service Provider (SP): the application being logged into, such as the client portal or web app your agency built. It holds the IdP's public certificate, usually taken from the IdP's metadata.

+-------------------+      1. User attempts login       +----------------------+
|                   | <-------------------------------- |                      |
|   Identity        | 2. Redirect with AuthN Request    |   Service Provider   |
|   Provider (IdP)  | <-------------------------------- |        (SP)          |
| (Okta / Entra ID) |                                   |  (Agency App/Portal) |
|                   | 3. Signed SAML Assertion (XML)    |                      |
|                   | --------------------------------> |                      |
+-------------------+   (SP verifies with public cert)  +----------------------+

The flow works like this:

1. A user tries to open the SP. The SP redirects them to their company's IdP.
2. The user authenticates at the IdP (password, MFA, biometrics).
3. The IdP builds a SAML assertion containing the user's identity claims (email, roles, group memberships) and signs it with its private key.
4. The browser posts the signed response to the SP's Assertion Consumer Service (ACS) URL.
5. The SP checks the signature against the IdP certificate it has on file. If the signature does not verify, the login is rejected.

The point of failure

Every X.509 certificate carries a validity window with two timestamps, notBefore and notAfter. These are defined in RFC 5280 and baked into the certificate when it is issued:

Validity
    Not Before: Oct  1 00:00:00 2023 GMT
    Not After : Sep 30 23:59:59 2026 GMT

A common mix-up: SAML assertions themselves also carry NotBefore and NotOnOrAfter attributes inside a <saml:Conditions> element. Those control how long a single login assertion is valid (minutes, not years), and are unrelated to the certificate's lifetime.

Why the error rarely says "expired"

You might expect the SP to log "certificate expired." Usually it does not. Most IdP signing certificates are self-signed, so there is no certificate authority or chain to validate. Trust comes from the metadata exchange: the customer's admin handed you the metadata, and you pinned the certificate inside it. Many SP libraries never check the notAfter date at all.

What actually breaks is the key change. When the IdP starts signing with a new certificate, the SP receives assertions signed by a key it has never seen, and the log shows something closer to "signature verification failed" or "no matching key." The result is the same as an expiry: everyone in that tenant fails at once, from the same minute.

Some IdPs and SPs behave differently at the moment of expiry. For example, WorkOS's Entra ID troubleshooting guide notes that Entra keeps signing assertions with an expired certificate, and it is the application that rejects them. Either way, the practical lesson is the same: the date on the certificate is the deadline for coordinating the change with the client.

---

2. Two Expiry Dates, Not One

Teams often track the wrong date, because a SAML metadata file contains two independent expiries:

The SAML 2.0 metadata specification requires the root metadata element to carry either a validUntil or a cacheDuration attribute. A metadata file can be fresh and still contain a certificate that expired last night, or the reverse. Monitoring one tells you nothing about the other. What a given SP does when validUntil passes depends entirely on the library: some reject stale metadata outright, some log a warning and carry on, and some never re-fetch at all.

---

3. How Long Do SAML Certificates Last?

There is no universal standard. The IdP chooses the lifetime.

Does the 47-day certificate rule apply?

You may have seen the CA/Browser Forum ballot (SC-081v3) that phases public TLS certificate validity down to 47 days by March 2029. That mandate covers publicly trusted TLS/SSL certificates. It does not apply to private SAML signing certificates issued by Entra or Okta, which keep their own multi-year defaults. Do not assume your SAML dates will suddenly shrink, but do keep your public SSL tracking separate from your identity-layer tracking.

---

4. Why Automated IdP Warnings Fail Agencies

It is tempting to assume the client's IT team has this covered. Several structural gaps say otherwise.

Gap 1: The alerts go to the enterprise, not the agency

Microsoft Entra ID sends an email notification 60, 30 and 7 days before a SAML certificate expires. By default these go to the admins on the tenant, and you can add up to five notification addresses per application. Unless the agency's shared mailbox is on that list, the people who maintain the SP never see the warning. Microsoft also notes that if notification addresses are configured programmatically (via Microsoft Graph or PowerShell), an admin should open the application's single sign-on page in the Entra admin center once, or the expiry emails may not be sent.

WorkOS makes the same practical point in its own guidance: if nobody watches those emails, the first sign of trouble is users being locked out. Its recommendation is to add multiple addresses, including an on-call alias, rather than only the admin who created the integration.

Gap 2: Static metadata uploads vs. metadata URLs

In a well-built integration, the SP periodically re-reads the IdP's metadata URL and picks up new keys on its own. Persona's help center describes this model for Okta: because it re-reads the metadata URL, a newly activated certificate is picked up automatically, whereas a static XML upload has to be re-uploaded every time the certificate rotates.

Many custom portals never got that far. They were onboarded with a one-time XML file. Even when the client's admin does everything right in Okta or Entra, the SP keeps trusting the old key until somebody re-uploads metadata.

Other vendors document the same manual step. Spendesk's help center, for example, says that once a new Okta certificate is activated, users cannot log in until the new certificate is uploaded on the Spendesk side. Citrix likewise notes that Entra ID does not automatically pull in its certificate and must be updated manually.

Gap 3: No overlap window

If a client admin activates a new certificate in the IdP before the SP has been updated, every login breaks instantly. Okta's own documentation warns that after a signing key credential is updated, users cannot access the SAML app until the new certificate is uploaded to the service provider.

The safe order, as documented by Teleport and AWS IAM Identity Center among others, is:

1. Generate the new certificate in the IdP (leave it inactive).
2. Import or trust the new certificate in the SP.
3. Activate it in the IdP.
4. Confirm logins work, then delete the old certificate.

Skipping step 2, or doing step 3 before it, is what turns a routine rotation into an outage.

---

5. Emergency Recovery SOP: When a SAML Certificate Has Already Broken Logins

Step 1: Confirm the shape of the problem

The signature of a certificate problem is that every user in one tenant fails from the same moment. If only some users are affected, look elsewhere: clock skew on an app node, a group or attribute change, or a second IdP connection that was not rotated.

Check the SP logs, or decode the base64 SAMLResponse with a SAML tracer browser extension, and look for signature validation errors such as "signature verification failed" or "no matching key." Do not expect the word "expired."

Step 2: Get the current IdP metadata or certificate

Ask the client's IdP administrator for the latest metadata (or fetch it from their metadata URL if one exists).

• Okta: Applications, select the SP app, Sign On tab, SAML Signing Certificates section. Download the certificate or use Actions > View IdP metadata. The metadata URL is shown under the SAML 2.0 sign-on method section.
• Microsoft Entra ID: Enterprise applications, select the app, Single sign-on, SAML Certificates. Download the certificate (Base64) or the Federation Metadata XML.

Step 3: Compare fingerprints

Compare the fingerprint of the certificate in the new metadata against what your SP holds. A mismatch confirms the diagnosis in seconds.

Step 4: Add the new certificate; do not just replace the old one

Load the new certificate into the SP's SAML configuration. If your platform allows it, keep the old certificate alongside the new one until you are sure the IdP has fully switched. Replacing outright can trade one outage for another if some assertions are still signed by the outgoing key.

If your SP still stores a single certificate in a database column, updating it looks like this:

UPDATE tenant_sso_configs
SET idp_x509_cert = '<new base64 certificate>'
WHERE tenant_id = 'enterprise_client_123';

Treat that as a stopgap. A single-value column cannot hold two certificates, which is why it cannot support overlapping rotation (see Rule 1 below).

Step 5: Clear caches and test

Clear any cached metadata (Redis, Memcached, in-process memory) so the SP uses the new key immediately. Then test an end-to-end login in a private browser window.

Step 6: Fix the class of problem, not just the instance

Afterwards, ask what allowed this to reach production: a single-certificate schema, a metadata refresh job that failed silently, or nobody tracking the date. The specific certificate is now good for another few years, which is exactly how long you have to forget about it again.

---

6. Proactive Agency SOP: Managing Enterprise SAML Lifecycles

Rule 1: Store a set of trusted certificates, not one

The SAML metadata specification allows an IdP to publish more than one signing KeyDescriptor, so the outgoing and incoming certificates can be listed at the same time. Your SP has to accept an assertion signed by any certificate in that set. If your schema keeps a single certificate per tenant, an overlapping rollover cannot help you, because the second key is discarded when metadata is ingested. Test this before you need it: load a metadata file with two signing keys and confirm both survive.

Rule 2: Prefer a metadata URL to a static XML file

Where the client publishes a reachable metadata URL, have the SP fetch it on a schedule (honoring cacheDuration as a polling hint) rather than relying on a one-time upload. Some caveats:

• Not every client can expose a metadata URL. Some IdPs are internal or IP-restricted.
• Auto-refresh is a trust decision. Fetch over HTTPS with certificate validation, and prefer signed metadata where available.
• Your polling interval must be shorter than the overlap window the IdP provides, otherwise auto-refresh is decorative.
• Alert if the refresh job stops succeeding. A job that has quietly failed for a month means your key set is a month stale.

Rule 3: Get on the IdP's notification list

For Entra ID, ask the client to add an agency-monitored mailbox (not a single person) to the application's certificate notification addresses. Up to five addresses are allowed. Confirm in writing who owns rotation on the client side.

Rule 4: Track days-remaining for every connection

Treat certificate notAfter, metadata validUntil, last successful metadata fetch and per-tenant login success rate as monitored signals. A tenant's login rate dropping to zero within one minute is a strong sign of a key or certificate problem, and it fires even when the root cause is something you did not anticipate.

For teams on Microsoft 365 / Entra, community write-ups show PowerShell and Microsoft Graph scripts that list enterprise applications, read each certificate's end date and send email alerts before expiry, which can be a useful supplement if you have delegated access to the tenant.

Rule 5: Give the human process a longer lead time

The slowest step in an outage is usually not technical. It is reaching the client's IdP admin and getting them to export metadata. Set reminders early enough that a real ticket can be raised with the client weeks ahead, not the night before.

---

7. Keeping SAML Dates Visible with InstaRenewal

Once an agency has a dozen enterprise clients across different IdPs, keeping the expiry dates in people's heads or in scattered spreadsheets stops working. This is the kind of gap a renewal register is built for.

InstaRenewal is a renewal-operations tool for agencies and freelancers. It tracks domains, SSL certificates, hosting, plugin licenses, ownership, payment responsibility and access status, and supports custom asset types and renewal reminders. It is intentionally narrow, and it is important to be precise about what that means for SAML.

What it can do for SAML certificates

You can log each client's IdP signing certificate as a custom asset and record the fields that matter when the date approaches:

(The rows above are an illustrative layout for your own records, not live data.)

With records like these, the platform's renewal reminders put the date in front of the team ahead of time, and the ownership, notice-contact and access fields answer the questions that slow down an incident: who owns the IdP, who gets its warnings, and can we even make the change ourselves?

What it does not do

Being accurate here protects your credibility with technical readers:

• InstaRenewal's automatic expiry detection applies to SSL certificates on supported public domains. It does not fetch or parse private IdP metadata, extract SAML certificate fingerprints, or detect a certificate rotation. For SAML certificates, the expiry date is something you enter and maintain.
• It is not an identity system, a login monitor or a security-audit tool, and it does not replace the technical controls in Section 6 (multi-certificate storage, metadata refresh, login-rate alerting).
• It is designed to track renewal operations, not to hold secrets. Its privacy policy asks users not to enter passwords, API secrets or private keys into asset fields or notes. Log the date and ownership details, never the key material.

Used this way, the register is the layer that makes sure a human is reminded weeks before the date, while the SP-side engineering makes sure the date does not cause an outage in the first place.

---

8. Quick Checklist for Every Enterprise SSO Integration

• [ ] Recorded the IdP (Okta, Entra ID, Ping, other) and the certificate expiry date
• [ ] Recorded whether the SP uses a metadata URL or a static XML upload
• [ ] SP can hold more than one trusted signing certificate per tenant
• [ ] Agency-monitored mailbox added to the IdP's certificate expiry notifications (Entra: up to five addresses)
• [ ] Named contact at the client who owns IdP certificate rotation
• [ ] Reminder set well ahead of the expiry date, with enough lead time to reach the client
• [ ] Metadata refresh job (if any) is monitored for failures
• [ ] Rotation runbook documented: generate, trust in SP, activate, verify, then delete the old certificate
• [ ] Post-rotation, expiry date updated in your renewal register

---

Frequently Asked Questions

How long are SAML signing certificates valid? There is no standard; the IdP decides. Entra ID defaults to three years and Okta auto-generates certificates with a ten-year default. On-premises IdPs such as AD FS are often rotated annually.

Will my SP fail if it does not check certificate expiry? Not necessarily on the date itself, since many SPs pin the certificate and skip the check. But the outage happens when the IdP rolls to a new key, and that happens on the IdP's schedule regardless of what your SP validates.

What is the difference between `validUntil` and the certificate's expiry? validUntil expires the metadata document; the certificate's notAfter expires the key. They are independent, and either can cause trouble first.

Do the new 47-day TLS certificate rules apply to SAML? No. That schedule applies to publicly trusted TLS certificates. SAML signing certificates issued by an IdP such as Entra or Okta are private and keep their own lifetimes.

Only some of our client's users are locked out. Is it the certificate? Probably not. A certificate or key problem normally affects everyone in the tenant from the same moment. Partial failures point to clock skew, attribute or group changes, or multiple IdP connections where only one was updated.

Should we auto-refresh IdP metadata? Where the client publishes a reachable metadata URL, yes, with HTTPS, ideally signed metadata, and a polling interval shorter than the expected overlap window. Where there is only a static file, rely on early reminders and a documented manual runbook.

---

Conclusion

An expired or rotated SAML certificate is one of the most predictable ways to lock an entire enterprise client out of a portal, and one of the easiest to prevent. The dates are known years in advance. What goes wrong is ownership: the warnings go to someone else, the SP can only hold one certificate, and nobody on your side has the date written down.

Store more than one trusted certificate, prefer metadata URLs where you can, get your own mailbox onto the IdP's notification list, monitor login failures per tenant, and keep every client's certificate date in a register your whole team can see, with reminders that leave time to reach the client.

---

Sources

• Microsoft Learn, Tutorial: Manage certificates for federated single sign-on (Entra ID certificate lifetime, notification schedule, notification addresses): https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/tutorial-manage-certificates-for-federated-single-sign-on
• Okta Help Center, Manage signing certificates: https://help.okta.com/en-us/Content/Topics/Apps/manage-signing-certificates.htm
• Okta Developer, Sign the Okta certificate with your own CA (behavior after updating a key credential): https://developer.okta.com/docs/guides/byo-saml/sign-the-csr/
• Teleport Docs, Rotating SAML Signing Certificates (default lifetimes, rotation order, Okta and Entra steps): https://goteleport.com/docs/zero-trust-access/sso/saml-cert-rotation/
• AWS Docs, Rotate a SAML 2.0 certificate, IAM Identity Center: https://docs.aws.amazon.com/singlesignon/latest/userguide/rotatesamlcert.html
• SSOJet, IdP Signing Certificate Expiry: Preventing a Total SSO Outage (validUntil vs. notAfter, multi-key metadata, instrumentation), September 17, 2026: https://ssojet.com/blog/idp-signing-certificate-expiry-saml-sso-outage
• SSOJet, The SAML Certificate Expiry Playbook (typical lifetimes by IdP): https://ssojet.com/white-papers/saml-certificate-expiry-rotation-playbook/
• WorkOS, Common Entra ID SAML errors and how to fix them: https://workos.com/blog/entra-id-saml-errors
• Persona Help Center, SAML SSO with Okta (metadata URL vs. static XML): https://help.withpersona.com/articles/3A0ZoW5ozu1k17n7bOrVuE/
• Spendesk Help Center, SAML SSO: update an expired security certificate: https://helpcenter.spendesk.com/en/articles/9937661-saml-sso-update-an-expired-security-certificate
• Clerk, Microsoft Entra ID SAML integration for SaaS apps (47-day TLS mandate does not apply to SAML signing certificates): https://clerk.com/articles/microsoft-entra-id-saml-integration-for-saas-apps
• OASIS, Metadata for SAML V2.0 and IETF RFC 5280: https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf, https://www.rfc-editor.org/rfc/rfc5280.html
• InstaRenewal (product scope and privacy policy): https://www.instarenewal.com/ and https://instarenewal.com/privacy