DEV Community: Sarwar

Every Compliance Framework Requires Key Rotation. No Platform Tells You When.

Sarwar — Tue, 07 Apr 2026 11:31:00 +0000

Disclosure: I built ExpiryPulse, a credential expiry tracking tool. The information here applies regardless of what tool you use.

The gap nobody talks about

If your organization handles sensitive data, you're subject to at least one compliance framework that requires credential rotation. NIST SP 800-57 defines cryptoperiods. PCI DSS mandates key replacement. CIS Benchmarks flag unrotated access keys. SOC 2 auditors ask for evidence of credential lifecycle management.

These aren't suggestions. They're requirements.

And yet, the platforms where your credentials live will not tell you when they're about to expire. Not AWS. Not Microsoft. Not Google. You're expected to comply with rotation policies on platforms that give you zero visibility into what's expiring and when.

That's the gap. The frameworks mandate it. The platforms ignore it.

What the frameworks actually say

NIST SP 800-57 (Key Management)

The gold standard for federal and enterprise key management. NIST defines the concept of a "cryptoperiod," the maximum time a cryptographic key should remain active. The recommended period depends on the algorithm, the volume of data processed, and the sensitivity of the information.

NIST doesn't prescribe a single rotation interval. Instead, it requires organizations to define their own cryptoperiods based on risk. The problem is that most teams set the policy and then have no mechanism to enforce it.

NIST SP 800-53 Rev 5, SC-12

The security control that governs cryptographic key establishment and management. SC-12 requires organizations to establish and manage keys "in accordance with organization-defined requirements." It maps directly to CEK-12 (Key Rotation) in the Cloud Security Alliance's Cloud Controls Matrix.

If you're pursuing FISMA, FedRAMP, or CMMC, this control applies to you.

PCI DSS (Requirement 3.6.4)

If you handle payment card data, PCI DSS requires that encryption keys be replaced when they reach the end of their defined cryptoperiod. The standard doesn't specify 90 days or 1 year. It says you define the period and then you enforce it.

Auditors will ask: what is your rotation policy, and how do you know it's being followed?

CIS Benchmarks

The CIS AWS Foundations Benchmark (controls 3.6 and 3.8) recommends enabling KMS key rotation and rotating IAM access keys every 90 days. These are scored controls. If your keys are older than 90 days, you fail the check.

SOC 2 (CC6.1)

SOC 2's Common Criteria 6.1 covers logical access controls, including credential management. Auditors expect to see evidence that credentials are tracked, rotated on schedule, and revoked when no longer needed.

The pattern is the same across every framework: define a policy, enforce it, and prove it.

What the platforms actually do

AWS

IAM access keys have no expiry date. Once created, a key stays valid until you manually deactivate or delete it. AWS recommends rotating every 90 days, but provides no built-in reminder, no notification, and no enforcement mechanism.

To get alerts, you have to build your own pipeline: a Lambda function that queries the IAM Credential Report, calculates key age, and publishes to SNS or SES. Some teams use AWS Config rules to flag non-compliant keys, but that only tells you after the fact that a key is overdue, not before it happens.

The AWS documentation acknowledges this gap and points to custom automation as the solution. For a platform that charges for everything, the absence of a simple "your key is 80 days old" email is striking.

Microsoft Entra ID

App registration client secrets and certificates expire on a date you set when you create them. When that date arrives, Entra ID does not send an email, a Teams notification, or a portal alert. The integration breaks, and you find out because something stops working.

There is a "Recommendations" panel in the Entra admin center that lists expiring credentials, but you have to go look at it. There's also a weekly digest email for Security Administrators, but it's buried among other recommendations and easy to miss.

For a tenant with dozens or hundreds of app registrations, the only reliable approach is a PowerShell script that queries Microsoft Graph and dumps all credential expiry dates to a report. Microsoft does not provide this script. You build it yourself or find one in the community.

Google Cloud Platform

GCP service account keys, by default, never expire. Google recently introduced an optional organization policy (constraints/iam.serviceAccountKeyExpiryHours) that lets you set expiry times on newly created keys. But there is no built-in notification when a key is approaching expiry.

Google's own documentation recommends monitoring keys "using Cloud Asset Inventory" and sending your own alerts. In other words, build a custom pipeline, same as AWS.

The irony is that Google explicitly warns against using service account keys in production and recommends Workload Identity Federation instead. But for teams that need keys for third-party integrations or legacy systems, the reality is that keys exist, they expire (or should), and nobody is watching.

Stripe, Twilio, Slack, and others

Most SaaS API keys don't expire at all. Stripe, Twilio, and Slack all issue long-lived keys that stay valid until manually revoked. There's no rotation reminder, no age warning, and no built-in lifecycle management.

This is by design. These platforms prioritize developer convenience over credential hygiene. But if your compliance framework requires rotation, you need to track these keys yourself, define a rotation schedule, and follow through.

Why this keeps happening

The platforms that issue credentials are not in the business of managing credential lifecycles. AWS wants you to use its services. Microsoft wants you to build integrations. Google wants you to deploy workloads. The credential is a means to an end for them, not a product they actively manage on your behalf.

Enterprise tools like CyberArk, Venafi, and HashiCorp Vault solve parts of this problem, but they come with six-figure price tags, lengthy implementations, and operational overhead that most teams can't justify.

That leaves a gap: you have compliance requirements that demand rotation, platforms that don't help you track it, and enterprise tools that are overkill for your team size.

What actually works

The teams that handle this well do three things.

They maintain a single inventory. Every credential, from every platform, in one place. Not a spreadsheet per team, not a wiki page that nobody updates, not a shared bookmark folder of portal links. One list, with expiry dates, owners, and status.

They automate alerts. Not "check the dashboard weekly" but actual notifications at defined intervals before expiry. Delivered to email, Slack, or Teams, where people already work.

They assign owners. Every credential has a primary and backup owner. When an alert fires, someone specific is responsible for acting on it. No "the team will handle it."

This is not complicated. It's just not built into any of the platforms you use.

Closing the gap

I built ExpiryPulse specifically to fill this gap. One dashboard for credentials across all platforms. Automated alerts at 30, 14, 7, and 1 day before expiry. Primary and backup assignees. Audit trail. CSV import so you can migrate off spreadsheets in minutes.

It doesn't store your actual credentials. Only names and expiry dates.

If you're managing Entra ID app registrations, I've published an open-source PowerShell script that exports all your secret and certificate expiry dates to a CSV you can import directly. More platform scripts are on the way.

Free tier available, no credit card required. expirypulse.dev

Or use a spreadsheet. Use calendar reminders. Use whatever works. The important thing is that you're tracking it somewhere, because the platforms won't do it for you.

The Credential Nobody Owned

Sarwar — Tue, 24 Mar 2026 10:30:00 +0000

Full disclosure: We built ExpiryPulse. But this article is just a collection of real incidents, real data, and real takeaways. We think the problem is worth talking about honestly.

It always starts the same way

Someone gets paged at 2 AM. A site is down, an API is throwing 500s, or a payment flow just stopped working. The team scrambles. Thirty minutes of checking logs, restarting services, and ruling out deployment issues. Then someone finally asks: when does the cert expire?

The answer: yesterday.

It's a story that repeats across the industry — not because teams are careless, but because credentials are uniquely easy to lose track of. They're set up once, they work silently for months, and the only reminder they exist is the moment they stop working.

This isn't a small-team problem

What makes certificate and credential expiry so interesting as a failure mode is that it doesn't discriminate by company size, budget, or engineering talent. Some of the most well-resourced technology organizations in the world have been caught by it.

Google Bazel: December 2025. On Boxing Day, an expired SSL certificate took down bcr.bazel.build and releases.bazel.build, breaking builds for Bazel users globally. The outage lasted roughly 13 hours. The root cause? A DNS record for an unused subdomain was removed a month earlier, which silently prevented the certificate's auto-renewal from completing. No alerts were fired. Nobody noticed until users started filing GitHub issues.

IPinfo: September 2025. An expired TLS certificate caused a complete API outage for 2 hours and 36 minutes — at a service handling over 100 billion requests per month. Their cert-manager had been logging renewal errors, but no monitoring or alerting was configured for those specific logs. The team later described it as one of the most severe outages in their 12-year history.

Epic Games: 2021. An expired wildcard certificate brought down Fortnite, Rocket League, the Epic Games Store, and a host of backend services. The cert was deployed across hundreds of services. It took 12 minutes to identify the cause but nearly 5.5 hours to fully recover, because the initial outage triggered a cascade of secondary failures across their infrastructure.

Microsoft Teams: 2020. A Monday morning. Millions of users worldwide couldn't access Teams. The cause: Microsoft forgot to renew an authentication certificate. Three hours of downtime for one of the world's most widely used collaboration platforms.

The list goes on. Spotify, LinkedIn (twice), Ericsson (affecting millions of mobile users across Europe and Japan), and even the U.S. government — which at one point had 80 expired certificates rendering federal websites inaccessible or insecure.

These aren't obscure startups cutting corners. These are organizations with dedicated security teams, infrastructure budgets in the hundreds of millions, and established processes. And they still got bitten.

Why does this keep happening?

The pattern across nearly every incident is remarkably consistent. It's usually not a technology failure — it's a visibility failure.

Ownership is unclear. The person who set up the certificate moved to another team, left the company, or simply forgot. Nobody else knows the cert exists until it expires.

Alerts depend on systems that can fail. Google's Bazel team relied on automated renewal — but the automation failed silently when a precondition changed. IPinfo's cert-manager was logging errors that nobody was watching. Fortmatic's team never received AWS's expiry notification because their email group was misconfigured.

Credentials don't announce themselves. Unlike a failing server or a crashed process, a valid certificate generates zero signal. It works invisibly until it doesn't. There's no degradation curve, no warning in your APM dashboard, no slow build of errors. One second it's fine, the next it's expired.

Tracking methods drift. A spreadsheet works great when someone maintains it. A calendar reminder works great until someone dismisses it. Automation works great until the underlying assumption changes. Every tracking method requires ongoing attention, and that attention competes with a hundred other priorities.

I've been on both sides of this

I'm not writing about this problem from a distance. I work in federal IT, and I've been caught by the exact failure modes described above — twice.

The first was a Microsoft Graph API key powering an internal application. The app had worked fine for months. Then one day it just stopped — no gradual degradation, no warning, just a hard stop. When we dug in, the key had expired. The dev team assumed the Entra ID team was tracking the renewal. The Entra team assumed the dev team owned it. Neither side was wrong for thinking that — the ownership had simply never been made explicit. The key expired in a gap between two teams who each thought the other was watching. It's the most common version of this story: not negligence, just an honest assumption that went unchecked.

The second was a customer-facing website I managed that used Let's Encrypt for SSL. Auto-renewal was configured. It had worked before. So I didn't think about it — which is exactly what automation is supposed to let you do. Then one day my phone rang. The customer was calling to tell me their site was showing a browser security warning. The cert had expired. The auto-renewal had broken silently at some point, and because I had no monitoring on top of the automation, I didn't catch it. The customer finding out before I did — that's the part that stung.

These weren't catastrophic, company-ending events. They were the quiet, everyday version of the same problem — the kind that happens in IT departments everywhere and never makes a headline, but still erodes trust, wastes hours, and keeps you up at night wondering what else you might be missing.

Both incidents came down to the same root cause: there wasn't a single place where I could see what was expiring and when. The information existed somewhere, scattered across admin consoles and config files, but it wasn't visible in a way that could warn me before things broke.

These experiences and more from colleagues is why ExpiryPulse exists. Not because I think people can't manage credentials, but because I kept running into the same gap between "it's set up" and "someone's actually watching it."

What actually helps

We've thought about this problem a lot (it's why we built ExpiryPulse), but the principles apply regardless of the tool.

Centralize visibility. The single biggest improvement any team can make is knowing what they have. If your certificates, API keys, and credentials live across cloud consoles, password managers, Slack threads, and one person's mental model — you have a visibility problem. Whether you consolidate into a spreadsheet, a wiki page, or a purpose-built tool, having one place to look makes everything else easier.

Assign ownership explicitly. Every credential needs an owner and a backup. "The team knows" is how things get lost. When someone leaves or switches roles, credential ownership should be part of the handoff — right alongside access and documentation.

Set up layered alerts. A single reminder isn't enough. Things get snoozed, dismissed, or lost in inbox noise. Multiple alerts at different intervals (30 days, 14 days, 7 days, 1 day) with escalation to a second person dramatically reduces the chance of something slipping through.

Expect automation to fail. Auto-renewal is wonderful — until it isn't. Every team that got burned by a silent auto-renewal failure had assumed the automation was working. Monitor the monitors. If your cert-manager hasn't successfully renewed in a while, you should know about it.

Prepare for the 47-day world. SSL/TLS certificate lifespans are about to drop to just 47 days by 2029 — meaning roughly 8 renewals per year per cert instead of 1. Manual tracking that barely works now won't survive that cadence. We wrote a full breakdown of what's coming and how to prepare: 47-Day SSL Certificates Are Coming. Is Your Team Ready?

Where ExpiryPulse fits

We'd be disingenuous if we didn't mention our own tool, so here's the honest version.

ExpiryPulse is designed for small-to-mid IT teams — the ones managing 10 to a few hundred credentials who don't need (or can't justify) a $50K enterprise certificate lifecycle management platform, but who've outgrown the spreadsheet.

You add your credential information, never the actual credential. It can be SSL certs, API keys, tokens, licenses, professional certifications — anything with an expiry date, and ExpiryPulse handles the rest: a single dashboard for visibility, automated email alerts at multiple intervals, escalation when things get critical, and team features for shared accountability.

It's free to start with up to 5 credentials and it's straightforward to set up. If it fits your needs, great. If you'd rather use something else or keep your spreadsheet tight, that's fine too — the important thing is that you're tracking.

The takeaway

Expired credentials aren't a competence issue, nor are they an infrequent one. They're a systems issue. The smartest engineers at the largest companies in the world still get caught by them, because the failure mode is silence — and silence is the hardest thing to monitor.

The question isn't whether you're good enough to track your credentials manually. The question is whether you want to bet your uptime on never forgetting, never getting distracted, and never having an assumption break silently in the background.

If the last few years have taught us anything, it's that the answer — from Google to Spotify to the sysadmin managing 50 certs — is the same: build a system with backups, don't rely solely on memory or assumptions.

ExpiryPulse is a credential expiry tracking tool for individuals and IT teams. Free tier available at expirypulse.dev.

Related: 47-Day SSL Certificates Are Coming. Is Your Team Ready? — What the CA/Browser Forum's decision means for your team.

Entra App Secrets: One script to find them all!

Sarwar — Thu, 19 Mar 2026 10:30:00 +0000

Disclosure: This article was written by the team behind ExpiryPulse, a credential expiry tracking tool. The PowerShell script referenced in this article is free to use and MIT licensed.

The problem

App registration client secrets and certificates in Microsoft Entra ID expire quietly. No banner in the portal, no email from Microsoft, no Teams notification. Just a broken integration at 2am and a frantic team.

Entra ID app registrations are easy to create and easy to forget. A developer spins one up for an integration, sets the secret to expire in a year or two, and moves on. Months later that developer might not even be at the company anymore. The secret expires. Something breaks.

The portal doesn't make this easy to audit either. You can view credentials on a per-app basis, but there's no native view that shows you all secrets and certificates across all app registrations sorted by expiry date. You'd have to click into every single app manually.

In a tenant with dozens or hundreds of app registrations, that's not a workflow — it's a prayer.

The script

I wrote a PowerShell script that connects to Microsoft Graph, pulls every app registration in your tenant, extracts all client secrets and certificates with their expiry dates, and exports them to a CSV.

.\Export-EntraAppCredentials.ps1

The script solves the Entra ID piece — but in today's environments, secrets and API keys are sprawled across dozens of platforms. Azure Key Vault, AWS Secrets Manager, GitHub, Stripe, your CI/CD pipeline. Some with its own expiry logic, each with its own portal, and none with a single view across all of them.

More platform scripts are on the way. For now — here's how to run this one.

Authentication: It uses interactive login — a browser window opens, you sign in with your Microsoft account, MFA is handled natively. No service principal setup, no app registration of your own required.

Required permissions: The script only needs Application.Read.All — a read-only delegated permission. It never reads secret values, key material, or anything sensitive. It only reads metadata — names and expiry dates.

If you're running this in a tenant where you don't have that permission, your admin can grant it or run the script themselves.

Install the Microsoft.Graph module if you don't already have it:

Install-Module Microsoft.Graph -Scope CurrentUser

Then run the script:

.\Export-EntraAppCredentials.ps1

To export to a specific path:

.\Export-EntraAppCredentials.ps1 -OutputPath "C:\exports\creds.csv"

To also export an audit file listing app registrations with no trackable credentials — useful for identifying orphaned or misconfigured apps:

.\Export-EntraAppCredentials.ps1 -IncludeAudit

The output looks like this:

name	service	expiry	notes
MyApp - ClientSecret1	Entra ID	2026-06-15	App ID: xxxx \
MyApp - APICert	Entra ID	2026-09-01	App ID: xxxx \

You can grab the script here: GitHub — expirypulse-tools

What to do with the output

Once you have the CSV, you have two options.

Option 1 — Open it in Excel. Sort by expiry date, identify what's expiring in the next 30, 60, 90 days, and add calendar reminders manually. Gets the job done once. But doesn't scale and it's easy to forget to run it.

Option 2 — Import into ExpiryPulse. Upload the CSV to ExpiryPulse and get automated expiry notifications without maintaining a spreadsheet. Free tier available — no credit card required. You'll get notified before anything expires. The import is direct — the script output maps exactly to ExpiryPulse's CSV format, so there's no reformatting needed.

The bigger picture

Expired app registration secrets are one of those problems that feel minor until they aren't. A broken integration at the wrong moment — during a customer demo, at end of quarter, in the middle of an incident — is entirely preventable.

The organizations that handle this well are the ones that treat credential expiry as an ongoing operational concern, not a one-time audit. That means visibility across platforms, not just Entra ID. And it means alerts before expiration, not silence until something breaks.

Run the script. Know what you have. Set up notifications so you're never surprised.

Next up: Azure Key Vault secrets and certificates — same idea, different platform.

This script is part of expirypulse-tools, an open source and MIT licensed collection of export scripts. Use it standalone, drop the output into a spreadsheet, or import it into ExpiryPulse if you want automated alerts without the maintenance.

I've seen both sides of credential management — neither works

Sarwar — Tue, 17 Mar 2026 10:00:00 +0000

I've spent years in both federal IT and the private sector. Different budgets, different compliance regimes, different acronyms. Same problem.

Nobody has a good answer for "what's expiring and when?"

The enterprise side

On the federal side, there's no shortage of tooling. CyberArk for privileged accounts. Venafi or AppViewX for certificate lifecycle. SailPoint for identity governance. ServiceNow for tickets. Splunk for logs. Each one solves a slice of the problem, and each one costs six figures.

You've got SSL certs managed in one platform, API keys tracked in another, vendor-issued licenses in a spreadsheet someone started three years ago, and service account passwords that live in someone's head, across different teams. The enterprise tools handle their slice — sometimes beautifully — but the seams between them are where things fall through.

None of them give you a single pane of glass across all of it.

I've watched teams with seven-figure security budgets miss certificate renewals. Not because they lacked tools — but because the cert that expired wasn't in the system that sends alerts. It was in the other system. Or it was in no system at all — just a sticky note on a wiki page that nobody updated after the last rotation. Google, Spotify, and Microsoft have all had outages from expired certificates. The problem scales with you.

I once saw a Splunk license lapse at a federal organization. Splunk — the tool that's supposed to be watching everything else. Nobody tracked the license renewal because it wasn't in any of the security platforms. It was a procurement thing, an admin thing, someone else's thing. The outage was short, but the embarrassment lasted longer. When your monitoring platform goes down because nobody monitored its own expiry date, the irony writes itself.

The tooling exists. The visibility doesn't.

The commercial side

On the private sector side, I lived the problem firsthand. Smaller teams, smaller budgets, and the tracking situation was exactly what you'd expect: a spreadsheet.

Sometimes it was a good spreadsheet. Columns for credential name, service, expiry date, owner, notes. Color coding for urgency. Someone might even set up conditional formatting. All of it worked until it didn't — which was usually when the person who maintained it went on vacation, or changed roles, or left the company.

The failure mode is always the same: silence. A credential expires at 3am on a Saturday and nobody knows until customers start calling. Not because anyone was negligent, but because the system for tracking it was a file that required a human to remember to check it.

Calendar reminders help, but they don't scale. Set a reminder for 5 credentials and you're fine. Set reminders for 50 and you start ignoring them. Set them for 200 across a team and you've just created noise.

The gap

Here's what struck me after seeing both sides: the problem isn't technical sophistication. Federal agencies have incredibly capable security teams. Commercial shops have sharp (and overworked) engineers who know exactly what needs to rotate and when.

The problem is that there's no simple, central answer to a simple question: what credentials do we have, when do they expire, and who's responsible?

Enterprise platforms answer parts of that question for the credential types they manage. But they don't cover everything, and they're overkill if you're a 10-person IT team managing a mix of SSL certs, API keys, vendor licenses, and service account tokens.

Spreadsheets answer the question too — until they go stale. And they always go stale.

So I built something

I started building ExpiryPulse to fill that gap. Not an enterprise platform. Not a secrets manager. Just a dashboard that tracks what you have, when it expires, and who owns it — with email (and Teams) alerts so you don't have to remember to check.

One design decision I made early and never reconsidered: ExpiryPulse doesn't store your actual secrets. No passwords, no API key values, no private keys, no certificate files. It stores metadata — the name of the credential, the service it belongs to, the expiry date, and who's responsible for it. That's it. Coming from a cybersecurity background — I've spent years working with DLP, incident response, and data protection — I know exactly what happens when sensitive data gets concentrated in one place. It becomes a target. I didn't want to be in the business of storing your secrets. That's what vaults and secret managers are for. ExpiryPulse answers a different question: what do you have, when does it expire, and who's on the hook?

The core is simple on purpose. Add a credential — any type, SSL cert, API key, license, token, whatever — set the expiry date, assign an owner (or two), and forget about it. You'll get alerts at 30, 14, 7, and 1 day before expiry. If it expires, you get follow-up reminders so nothing goes quietly into the night.

A few features came directly from the pain I'd experienced:

CSV import. Because if I'm replacing a spreadsheet with 40 credentials in it, I'm not manually entering them one by one. That's a dealbreaker. Drag and drop a CSV file, map the columns, and you're running in five minutes.

SSL certificate scanning. Paste a domain, ExpiryPulse connects via TLS, reads the certificate chain, and auto-populates the credential details. The scan runs nightly to keep expiry dates current automatically.

Teams/Slack webhooks. Email is fine, but half the teams I've worked with live in, Teams or Slack. If a credential is about to expire, the alert should show up where people actually look.

Audit logging. Every change is timestamped with who did what. Not because I love logging, but because when an auditor asks "can you show me evidence of credential rotation?" you need more than "yeah, we do that."

What I learned building it

Sysadmins are skeptical of new tools, and rightfully so. The first reaction I got was "I can do this with a spreadsheet." And honestly? They're right — you can. But a spreadsheet works until the person maintaining it gets pulled into a P1 incident, goes on PTO, or moves to a different team. The spreadsheet doesn't know that nobody's looked at it in three weeks. It doesn't chase you down when something's about to expire. It doesn't escalate to a backup when the primary owner is unreachable. It just sits there, quietly going stale, until something breaks. The difference is that ExpiryPulse doesn't depend on someone remembering to check it — it comes to you. And if you don't respond, it goes to your backup.

SSL chain scanning. I didn't think about certificate chains expiring until I built the scanner. When I dug into how SSL actually works end-to-end, I realized every intermediate cert in the chain has its own expiry date, and they can expire before the leaf! I looked at the tools in this space and most of them don't scan the full chain. They just check the domain cert. That gap has caused real outages — not from the cert you're watching, but from the one you didn't know to watch.

Where it stands

ExpiryPulse is live at expirypulse.dev. The free tier gives you 5 credentials — enough to get your most critical items tracked and see if the workflow fits.

For solo admins who need more room, the Power plan covers up to 30 credentials with all notification thresholds and priority support. For teams that need shared visibility, the Team plan adds multi-seat access, backup assignments, break-glass delegation, and more — so coverage doesn't disappear when someone's on vacation or leaves the company.

I'm using it to track my own keys — Stripe, Resend, Supabase, Azure, etc. If the tool that tracks credentials can't track its own credentials, well, you know the rest.

I'm not pretending this replaces CyberArk or Venafi for organizations that need those platforms. It fills the gap for teams that don't — and for the credentials that fall between the cracks even in organizations that do.

One thing no tool can fix: you have to put the data in. ExpiryPulse, a spreadsheet, CyberArk — none of it matters if nobody takes the time to inventory what exists and enter it into the system. The best tooling in the world is useless if nobody feeds it. That's the unsexy truth about credential management. The hard part isn't the alerts or the dashboards or the chain analysis. The hard part is the discipline of saying "we just provisioned a new API key — let me log it." Everything else builds on that habit.

If you're tracking credentials in a spreadsheet and/or a calendar right now, I built this for you. If you've got a system that works, genuinely, keep using it. The important thing is that something exists between "I'll remember" and nothing.

If you want to try it: expirypulse.dev. Free tier, no credit card. Happy to answer questions in the comments.

47-Day SSL Certificates Are Coming. Are You Ready?

Sarwar — Tue, 10 Mar 2026 11:45:00 +0000

The short version

In April 2025, the CA/Browser Forum — the industry body that sets SSL/TLS certificate standards — voted unanimously to reduce maximum certificate lifespans from 398 days to just 47 days by 2029. The change rolls out in phases, and the first one takes effect this month.

If you manage SSL certificates for your organization, this affects you. Here's what's changing, why it matters, and how to prepare.

The timeline

The reduction is phased to give organizations time to adapt:

March 15, 2026 — 200 days. Maximum certificate lifespan drops from 398 to 200 days. Domain Control Validation (DCV) reuse also drops to 200 days. This is the first real operational change. If you were renewing once a year, you're now renewing twice.

March 15, 2027 — 100 days. Certificates max out at 100 days. DCV reuse drops to 100 days. You're now renewing roughly every three months. Quarterly renewal is manageable manually, but it's tight.

March 15, 2029 — 47 days. The final target. Certificates last a maximum of 47 days. DCV reuse drops to just 10 days. You're renewing every month, and validating your domain ownership almost continuously.

The vote passed 25-0 among certificate authorities, with all four major browser vendors — Apple, Google, Mozilla, and Microsoft — voting in favor. This isn't a proposal. It's happening.

Why 47 days?

The number sounds arbitrary, but the logic is straightforward.

Shorter exposure windows. When a certificate is compromised — through a leaked private key, a misconfigured server, or a CA mistake — the damage window is limited to the certificate's remaining validity. A 398-day cert gives an attacker up to 13 months. A 47-day cert gives them weeks at most.

Revocation doesn't work well. The existing systems for revoking compromised certificates — Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) — are unreliable in practice. Many browsers have stopped checking them altogether. Shorter lifespans are a pragmatic workaround: if you can't reliably revoke a certificate, make it expire quickly instead.

Forcing automation. The CA/Browser Forum has been signaling for years that manual certificate management is unsustainable. Shorter lifespans make that explicit. The intent is to push the entire ecosystem toward automated renewal using protocols like ACME (the same protocol behind Let's Encrypt).

Crypto agility. As quantum computing advances, the ability to rotate certificates quickly becomes a security requirement, not just an operational convenience. Short-lived certificates make it easier to transition to new cryptographic algorithms when the time comes.

The math gets uncomfortable fast

Here's where it gets real for most IT teams.

At 398-day lifespans, managing 50 certificates means roughly 50 renewal events per year. That's just under one per week — manageable with a calendar and some discipline.

At 47-day lifespans, those same 50 certificates require approximately 400 renewal events per year. That's more than one per day, every day, including weekends and holidays. And that's before you factor in the 10-day DCV reuse window, which means you're also re-validating domain ownership almost constantly.

For a single certificate on a single site with Let's Encrypt and a working ACME client, this is a non-issue — the automation handles it. But most organizations aren't in that situation. They have certificates spread across web servers, load balancers, CDNs, firewalls, mail servers, VPN appliances, API gateways, and legacy systems that don't support ACME. Some of those systems require manual certificate installation. Some require change board approval. Some run in air-gapped environments.

The teams that will feel this the most aren't the ones with fully automated cloud-native infrastructure. It's the ones in the middle — managing a mix of modern and legacy, cloud and on-prem, automated and manual. Which, frankly, describes most organizations.

What this means for different teams

If you're already fully automated with ACME: You're in good shape. Make sure your renewal processes are monitored (silent failures in auto-renewal are a leading cause of outages — I wrote about that here). Test that your pipeline handles the shorter renewal cycles without hitting rate limits.

If you're partially automated: Identify which certificates are covered by automation and which aren't. The ones that aren't are your risk. Prioritize getting those into an automated pipeline, or at minimum into a tracking system with alerts.

If you're managing certificates manually: You have until March 2026 to start changing that — which is now. Manual renewal at 200-day intervals is feasible but tight. At 100 days (March 2027), it becomes a part-time job. At 47 days, it's untenable for anything more than a handful of certificates.

If you're in a regulated or change-controlled environment: This is where it gets complex. Many organizations require change requests and CAB approval for certificate installations. That process needs to be streamlined or exempted for routine renewals, because the current cadence won't survive monthly certificate rotations.

This only applies to public certificates

One important clarification: the 47-day mandate only applies to public SSL/TLS certificates issued by publicly trusted Certificate Authorities. Internal PKI certificates — the ones you issue yourself for internal applications, dev environments, and non-public systems — aren't subject to these rules.

That said, the principles behind the change — shorter lifespans, automated renewal, better monitoring — are worth adopting internally too. If your internal certificates expire and take down an internal service, the CA/Browser Forum's rules don't matter much. The outage is the same.

What you should do now

Regardless of your current setup, here are concrete steps to take before the first reduction hits:

Inventory everything. You can't manage what you can't see. Build a complete list of every public certificate your organization uses — not just the ones on your main website, but wildcard certs, SAN certs, certs on mail servers, API endpoints, and third-party integrations. If you don't have this list today, that's the first problem to solve.

Identify what can't auto-renew. Some systems support ACME or API-driven renewal. Others don't. Know which is which. The ones that can't auto-renew are the ones that will cause you the most pain as lifespans shorten.

Set up monitoring on your automation. If you're using auto-renewal (Let's Encrypt, cloud provider managed certs, etc.), verify that it's actually working — not just that it was working last time you checked. Silent auto-renewal failures are one of the most common causes of certificate outages. Set up alerts for renewal failures, not just for upcoming expirations.

Talk to your change management team. If certificate installations currently require change board approval, start the conversation now about how to handle monthly renewals. Automation-friendly policies (like pre-approved change templates for routine renewals) will save everyone significant pain.

Pick a tracking system. Whether it's a spreadsheet, a monitoring tool, or something purpose-built like CertWatcher — make sure you have a single source of truth for what's expiring and when. The 47-day cycle doesn't leave room for "I thought someone else was tracking that."

The bigger picture

The shift to 47-day certificates is part of a broader trend: the things that secure our infrastructure are getting faster, shorter-lived, and more automated. That's a good thing for security. But it raises the operational bar for every team that manages certificates.

The organizations that will handle this transition smoothly are the ones that treat certificate management as an ongoing operational concern — not a set-it-and-forget-it task. The ones that will struggle are the ones that don't realize they need to change until the first renewal deadline slips by. The good news is that for teams that start now, this is a solvable problem.

March 2026 is the starting line. The time to prepare is now.

ExpiryPulse helps individuals and IT teams track credential expiry dates with automated alerts at 30, 14, 7, and 1 day before expiration. Free tier available at expirypulse.dev.