Your guide to getting started with ZoomMate
Everything you need to start using ZoomMate: notes, search, workflows, and AI tools — all inside Zoom Workplace.
Select a language
TLS certificate lifespans are dropping to just 47 days by 2029. For IT teams managing SSO, that means more renewals, more overhead, and more room for things to go wrong. But there's a better path. Self-signed certificates give you direct control over your trust relationships, remove CA dependencies, and sidestep the compression timeline entirely. Here's what's changing, why it matters, and how to make the switch.
8 min read
Published on September 3, 2026
Unless you track the CA/Browser Forum's voting records, you probably missed one of the biggest shifts in certificate management in years. In May 2025, the industry officially voted to compress TLS certificate lifespans from 200 days down to just 47 days by 2029. The goal: force automation and shrink the window for compromised certificates to do damage.
For IT teams managing SSO, this shift opens up a powerful opportunity. Instead of wrestling with ever-shorter renewal cycles and CA dependencies, there's a smarter, more efficient path forward: self-signed certificates. By eliminating the need for third-party validation, you gain direct control, reduce operational overhead, and strengthen your security posture—all while simplifying your certificate management strategy. Let's explore why self-signed certificates deserve a closer look for your SSO deployments, and why now is the right time to evaluate your options.
Publicly trusted Certificate Authorities (CAs) are progressively reducing the maximum lifespan of TLS certificates on a fixed schedule. Currently, certificates max out at 200 days. Based on the CA/Browser Forum's current published schedule, by 2027, that drops to 100 days and by 2029, the expiration will be set to 47 days.
The reasoning is straightforward. Shorter lifespans reduce the window during which a compromised certificate can be exploited. If an attacker gains access to a certificate that expires in six weeks, the window for compromise is limited compared to one valid for two years.
Modern computing power has made brute-force attacks on cryptographic keys more feasible than they were a decade ago. Cloud infrastructure and distributed processing changed the math. Several high-profile incidents involving poorly managed certificates accelerated the industry's response. The CA/Browser Forum, which sets the rules that Certificate Authorities follow, voted in May 2025 to formalize the compressed timeline.
DigiCert, one of the world's largest CAs, confirmed the decision: "The CA/Browser Forum has officially voted to amend the TLS Baseline Requirements to set a schedule for shortening both the lifetime of TLS certificates and the reusability of CA-validated information in certificates." The message from the industry is clear: annual TLS certificate management is no longer viable at scale.
When it comes to public websites, the industry has settled on automation to handle the constant cycle of certificate renewals that shorter lifespans demand. SSO configurations are different.
In an SSO setup, your organization's Identity Provider (IdP) communicates with a Service Provider (like Zoom) using certificates to establish trust. These certificates don't face the public internet the way a web server's TLS certificate does. They operate within a controlled trust relationship between two systems your organization manages or configures.
The security model for SSO certificates doesn't depend on a third-party CA vouching for your identity to the world. It depends on both sides of the authentication process recognizing and trusting the same certificate. That distinction opens the door to a better approach.
Self-signed certificates represent a powerful shift in how organizations manage SSO security. Unlike CA-issued certificates, self-signed certificates are created and signed by your own organization—giving you direct control over your security infrastructure. While this approach wouldn't work for public-facing web servers (where browsers need third-party validation), it's the ideal solution for SSO configurations. Here's why self-signed certificates are transforming SSO security:
When it comes to SSO configurations, a CA adds complexity without adding security value. Self-signed certificates are not appropriate for every use case; but when it comes to SSO configurations, self-signed certificates are the preferred approach.
When you configure SSO with Zoom using a self-signed certificate, your organization creates a cryptographic key pair and signs the certificate itself. You activate the certificate in your Zoom account configuration, and upload it to your Identity Provider. When someone in your organization authenticates, the trust is validated directly between your systems. No external authority involved.
Your people authenticate to Zoom through your organization's Identity Provider securely, without the complexity of managing short-lived CA certificates or depending on external validation chains.
For step-by-step instructions on creating and configuring a self-signed certificate for your SSO deployment with Zoom, see our support article: Using self-signed certificates for single sign-on (SSO).
Zoom isn't the only one making this recommendation. Already today, many providers use self-signed certificates by default. The move to self-signed certificates for SSO also aligns with guidance from OASIS (the organization that maintains the SAML specification) and leading identity providers including Auth0, OneLogin, Ping Identity, and Microsoft.
When the CAs, the standards bodies, and the major identity provider vendors all point in the same direction, it's worth paying attention.
If your organization uses SSO with Zoom and currently relies on a CA-issued certificate, now is a good time to evaluate the switch. Reduced certificate lifetimes are already in effect, and the operational overhead of frequent renewals will only increase.
Self-signed certificates for SSO give you more direct control over your trust relationships, reduce third-party dependencies, and align with where the industry is heading.
Ready to make the switch? Start with our support guide: Using self-signed certificates for single sign-on (SSO).
As of 2026, the maximum lifespan for a CA-issued TLS certificate is 200 days. Based on the CA/Browser Forum's current published schedule, the CA/Browser Forum has voted to reduce this to 100 days by 2027 and 47 days by 2029.
For SSO configurations, self-signed certificates can be equally appropriate when both sides of the trust relationship are controlled by the same organization. The CA's role (vouching for identity to unknown parties) isn't needed in this context.
If you're using a CA-issued certificate for SSO, you'll need to renew it more frequently as lifespans compress. Switching to a self-signed certificate removes this dependency entirely.
No. Standard tools like OpenSSL can generate self-signed certificates. Zoom's support documentation walks through the process step by step.
Yes. Self-signed certificates give each customer account a unique certificate, eliminate shared-certificate risks, and remove the operational burden of tracking CA-issued certificate expirations.
NIST SP 800-57 recommends a maximum period of 1-3 years for a private signing key and up to 2 years for encryption. Zoom supports these values. Consult your identity provider for their criteria.
