You Don’t Have a Certificate Management Strategy. You Have a Spreadsheet and a Prayer.
SSL/TLS certificate lifetimes just dropped to 200 days. They’re heading to 47.
And the way most enterprises manage certificates won’t survive what’s coming.
By Salil Kulkarni, Chief Strategy and Information Officer, Virima
The Comfortable Lie You Tell Yourself
You think you’re managing your SSL/TLS certificates.
You’re not.
You’re maintaining a spreadsheet that was accurate about six months ago. You’re relying on calendar reminders that one person on your team might see. You’re trusting that the developers who spun up certificates on test environments actually told somebody about it.
And until now, that was survivable. With 398-day certificate lifetimes, you had enough runway to catch mistakes before they became outages.
That runway just got cut in half.
As of March 15, 2026, the CA/Browser Forum’s SC-081 ballot caps new public TLS certificates at 200 days. That’s not a proposal. It’s not a draft. It’s ratified. And the roadmap doesn’t stop there: 100-day maximums arrive by March 2027. By March 2029, you’re looking at 47-day certificate lifetimes.
Forty-seven days.
If you can’t find every certificate in your IT environment today, how will you manage them when they expire eight times a year?
The Pain You’ve Accepted as Normal
Let’s name what you already know but haven’t said out loud.
You don’t have a complete certificate inventory. Not really. You have the certificates your team knows about including the ones on production web servers, the ones behind the load balancers, etc. that you actively manage. But the full picture? That’s a different story.
Shadow certificates are everywhere. Developers issued them for staging environments that became semi-permanent. A project team provisioned a wildcard cert on an appliance two years ago. Someone in DevOps grabbed a Let’s Encrypt cert for an internal tool and never documented it. They’re scattered across servers, load balancers, proxies, cloud endpoints, containers, and appliances you haven’t audited in months.
Your tooling is fragmented. You might have a certificate manager for your public-facing web properties, but what about the rest? What about the certs on your F5s, your Nginx proxies, your Kubernetes ingress controllers, your Azure App Gateways? Different tools. Plus, Different teams. Different renewal cycles. No single source of truth.
And here’s the part that keeps CISOs up at night: when a certificate expires unexpectedly, you don’t know the blast radius. You know a cert died. You don’t know which business services depend on it, which customers are affected, or how far upstream the damage travels.
This isn’t negligence. It’s the natural outcome of managing modern infrastructure with tools that were built for a simpler era. When a certificate lasted 398 days, the margin for error was wide enough to absorb these gaps. You had time to notice. Time to scramble. Time to fix things before customers felt the impact.
That margin is evaporating.
And the consequences of getting it wrong aren’t theoretical. Expired certificates don’t degrade gracefully. They fail hard. Browser warnings. Broken API integrations. Payment processing halted. Partner data feeds severed. The kind of failures that generate incident reports, customer escalations, and uncomfortable conversations with the board.
What 200 Days Actually Means for You
Let’s do the math that should make you uncomfortable.
At 398-day lifetimes, a certificate needed renewal roughly once a year. If you had 500 certificates, that was 500 renewal events annually, which is roughly 10 per week. Manageable, even manually.
At 200 days, that same inventory requires renewal every 6.5 months. You’re now running nearly 1,000 renewal events per year or 19 per week.
At 100 days? That’s 1,825 renewals. 35 per week.
Then, at 47 days? You’re renewing certificates 3,885 times a year. Seventy-five per week. More than ten per business day.
And that’s per 500 certificates. Many enterprises have thousands.
Now layer in the real complexity. Each renewal isn’t just a technical event. It requires knowing:
- Where the certificate is installed, including every instance, not just the primary
- The issuer, SANs, and the key algorithm tied to it
- Which services, applications, and infrastructure depend on it
- Who owns it, and whether that person still works here
- Whether the renewal requires a change request, and what the approval chain looks like
Spreadsheets don’t track this. Point tools track pieces of it. Nobody has the full picture unless certificates are managed as configuration items within a CMDB that is linked to the business services they support.
Without that linkage, every certificate renewal is a bet. You’re betting you know where it is. You’re betting you know what breaks if you miss it. You’re betting you’ll catch it in time.
At 47-day lifetimes, you’ll be placing that bet 75 times a week.
Want to see how Virima maps your certificates to business services?
Book a 30-minute demo →
Why Discovery Without Context Is Just a Better Spreadsheet
Some vendors will tell you the answer is automated certificate discovery. They’re half right.
Discovery solves the inventory problem. It may find certificates across your servers, load balancers, proxies, and cloud endpoints. It captures the technical metadata: issuer, SANs, key algorithms, validity dates, expiration windows, where each cert is installed.
That’s necessary. It’s not sufficient.
Knowing that certificate X expires in 30 days is useful. Knowing that certificate X is the TLS termination point for your payment processing gateway, which handles $2.3M in daily transactions, and that its expiration will cascade upstream into three customer-facing applications is actionable.
This is the gap most tools leave open. They find certificates. They don’t connect them to the business.
Virima closes that gap.
When Virima discovers your certificates, it doesn’t just log them into a database. It stores them as dedicated certificate records and then automatically maps them to the host CIs in the CMDN that they are installed in through a relationship table and so the assets they support are linked to the CIs and are kept current.
Virima’s ViVID visual service mapping renders this visually. You don’t just see a list of expiring certificates. In addition, you see the upstream and downstream dependencies. You see which business services are at risk. Plus, you see the blast radius before the outage happens.
This is the difference between reacting to certificate failures and preventing them. It’s the difference between a 2 AM scramble and a Tuesday afternoon workflow.
And when 47-day lifetimes arrive in 2029, this kind of business-level visibility won’t be a competitive advantage. It will be a survival requirement.
From Alerts to Action: What Operational Readiness Actually Looks Like
Finding certificates and understanding their impact is step one. Operating at the velocity that 200-day, and eventually 47-day, lifetimes demand requires operational infrastructure most enterprises don’t have yet.
Here’s what it looks like when it’s built right:
Configurable Alert Thresholds
Through the Business Rules Module, Virima provides you the ability to create a task that gets triggered to assign a task to an authorized user and a dashboard report that alerts as many times and whatever timeframe you want according to the thresholds you want to set. These are not generic notifications but are routed to the authorized Virima users, so they know that they are expiring.
Automated ITSM Ticket Creation
When a certificate crosses an alert threshold, auto-creation of an ITSM ticket is the next step. No manual entry. No waiting for someone to notice. The ticket includes the certificate details, its business service linkage, and the impact context because the person picking up that ticket needs to know what they’re protecting, not just what they’re renewing.
Standardized Lifecycle Management
Certificate request, approval, issuance, installation, and renewal are steps tied to a change request with an auditable trail. Tracking historical rotation data so you can see patterns: which certificates are chronically late, which teams consistently miss windows, where automation is working and where it’s not are the steps that are needed.
This isn’t about adding complexity. It’s about building the operational muscle that 47-day lifetimes will require, which starts now, while the timeline is still forgiving.
Two Kinds of Organizations in 2027
By March 2027, when 100-day lifetimes take effect, there will be two kinds of organizations.
The first kind will have spent 2026 building the foundation. They’ll have complete certificate inventories mapped to business services. They’ll have alert thresholds calibrated for shorter lifetimes. They’ll have ITSM workflows that route renewals to the right teams with the right context. They’ll have already practiced at 200-day velocity, so 100 days will be an adjustment—not a crisis.
The second kind will still be reacting. They’ll discover certificates only when they expire. They’ll scramble to figure out what broke and who’s responsible. They’ll burn engineering hours on fire drills instead of innovation. And they’ll dread 2029, because they’ll know they’re not ready for 47 days.
Which kind are you building?
The window to decide is open right now. It won’t stay open long.
The difference isn’t talent. It’s not budget. It’s whether you have a platform that connects certificate discovery to business context, or whether you’re still stitching it together with scripts, spreadsheets, and hope.
Your 90-Day Playbook: Start Before You’re Forced To
You don’t need to solve everything at once. But you need to start. Here’s the sequence that works:
- Baseline Discovery
Run a full automated scan across every environment—production, staging, dev, cloud, on-prem. Find your certificates. Capture issuer, SANs, key algorithms, validity windows, and installation points. Virima’s discovery does this across servers, load balancers, proxies, and cloud endpoints.
- Establish Ownership and Impact
Map every certificate to its CI owner and its upstream/downstream service dependencies using ViVID. This is the step most organizations skip. When you can see that a cert on a load balancer is the TLS termination point for three customer-facing applications, you’ve moved from inventory to intelligence – not just tracking certs.
- Configure 200-Day Alert Workflows
Set tiered alert thresholds at 90, 60, and 30 days before expiration. Configure a weekly report to return a list of expiring certs and mail that report to a service email address capable of auto-opening incidents and tasks. Test the workflow end-to-end. Don’t wait for the first 200-day cert to approach expiration. Simulate it now.
- Design for 100-Day and 47-Day Phases Now
If your workflows can’t handle 200-day renewals smoothly, they’ll collapse at 100 and 47. Use 2026 as your proving ground. Identify which certificates can be fully automated, which require human approval, and where your process bottlenecks are. Fix them while the stakes are lower.
Ready to build your certificate baseline? Start with a Virima discovery assessment →
What It Looks Like When You Get This Right
Imagine this: a certificate on a proxy server is 60 days from expiration. Your platform already knows it’s there. It knows the proxy terminates TLS for your partner API gateway. And, it knows three business services depend on that gateway. It knows who owns the proxy CI.
An ITSM ticket was auto created at 90 days and routed to the right team. The renewal is tied to a change request. When the new cert is installed, the CMDB is updated automatically. Historical rotation data logs the event.
No surprises. No spreadsheet audit and no 2 AM phone call.
Now multiply that across every certificate in your environment. Every server. Every load balancer. Plus, every shadow cert that was hiding in a dev environment.
That’s not a fantasy. That’s what Virima delivers today.
And it’s the difference between surviving the 47-day era and being overwhelmed by it.
Your next certificate outage is already on the calendar.
You just don’t know which cert it is.
