47-Day Countdown: Why Machine Identity Is Critical Now
The CA/Browser Forum voted in April 2025 to dramatically reduce TLS certificate validity periods. By March 2029, certificates will last just 47 days. The ballot SC-081v3 lays out a phased reduction that changes the operational reality of certificate management for every enterprise.
But this announcement isn’t just about certificates. It’s a forcing function that exposes a much larger challenge: machine identity management.
Certificates, SSH keys, and cryptographic assets are the credentials that machines use to authenticate, encrypt, and communicate. Together, they form the trust fabric of enterprise infrastructure. And for most organizations, that fabric is held together by manual processes, partial automation, and institutional knowledge.
The 47-day deadline makes that unsustainable. Here’s why.
TLS Certificates: The Math That Breaks Manual Processes
The CA/Browser Forum’s phased timeline introduces three milestones:
- March 2026: Maximum validity drops to 200 days
- March 2027: Maximum validity drops to 100 days
- March 2029: Maximum validity drops to 47 days
The operational impact is straightforward. A certificate that used to require renewal once a year will need renewal roughly 8 times a year by 2029.
For a team managing 1,000 certificates with each renewal taking 4 hours, the staffing requirement grows from 2 people today to 8 by 2027 and 16 by 2029. Most enterprises manage tens of thousands of certificates. The numbers scale accordingly.
But the staffing problem isn’t the only concern. The perception of outages is about to change. When certificates lasted a year, an expired certificate was embarrassing but understandable. After years of public notice and a graduated timeline, that understanding disappears. Customers and auditors will ask a harder question: why weren’t you ready?
Semi-automation won’t survive this transition. Many teams today operate with partial coverage. Some certificates are managed through ACME. Others are tracked in spreadsheets. Others exist in the environment without anyone knowing they’re there. A certificate that was borrowed from another team, a wildcard deployed across dozens of endpoints, a legacy certificate on a system nobody owns anymore. These are the certificates that cause outages, and no amount of scripting catches what you don’t know exists.
The shift from annual renewals to 47-day cycles means every unknown certificate becomes a production incident waiting to happen. Not once a year. Every 47 days.
The only sustainable path forward is end-to-end automation where humans set policy and oversee, and the system handles discovery, renewal, and deployment without manual intervention.
SSH Keys: The Quiet Risk
While TLS certificates are getting urgent attention, SSH keys present a different but equally critical challenge.
SSH keys grant privileged access to an organization’s most sensitive systems. Unlike certificates, they don’t expire. They get created by engineers as needed, shared across environments for convenience, and forgotten when people leave or change roles.
A complete and current SSH key inventory is rare, because the tooling to maintain one hasn’t existed. The result is key sprawl: an unknown number of credentials granting an unknown level of access across an unknown number of systems.
The security implications are significant. An orphaned SSH key for a former employee’s account is an active access credential that will remain valid indefinitely unless someone identifies it and revokes it manually. Multiply that across hundreds or thousands of endpoints, and the attack surface grows invisibly over time.
The challenge isn’t awareness. Security teams understand that unmanaged SSH keys are a risk. The challenge is visibility. Without automated discovery and inventory, remediation is a manual audit that’s outdated before it’s complete.
Cryptographic Discovery: You Cannot Secure What You Cannot See
TLS certificates and SSH keys are the most visible machine identities, but they’re part of a broader cryptographic landscape.
Producing a complete cryptographic inventory across an enterprise infrastructure is genuinely difficult. The assets are distributed across on-premise data centers, cloud environments, containers, and edge systems. The tooling is fragmented. And the inventory changes faster than any manual process can track.
This matters for two reasons.
First, compliance. Regulatory frameworks and industry standards increasingly require organizations to demonstrate visibility into their cryptographic posture. An audit that asks “what cryptographic assets do you have?” requires a defensible answer, not a best guess.
Second, post-quantum readiness. NIST finalized the first post-quantum cryptography standards in August 2024. Government migration timelines are already in motion. When the deadline arrives, the first question will be: what do you have, and is it ready for the transition? Without a current inventory, you can’t answer either question.
The industry has treated certificate management, SSH key management, and cryptographic discovery as separate problems solved by separate tools. But they’re all the same underlying challenge: do you have complete visibility into your machine identities, and can you act on what you find?
The Path Forward
The organizations that will navigate this transition successfully share a few characteristics.
They prioritize discovery over automation. Automation is essential, but it only works on what you know about. The first step is complete visibility into every machine identity across the infrastructure.
They think platform, not point solution. Certificates, SSH keys, and cryptographic assets are interconnected. Managing them with separate tools creates silos, duplicated effort, and gaps between the seams.
They look for solutions that work with what they have. The right approach integrates with any CA, including internal PKI, and works with existing CMDB, ITSM, and observability tools. It operates across on-premise, cloud and hybrid environments without requiring agents or new infrastructure.
They automate end to end. Not just renewal. Discovery, monitoring, procurement, and deployment. Humans set policy and oversee. The system handles execution.
The 47-day deadline is less than three years away. The 100-day milestone is less than one. The window to prepare is now.
At Thryam, this is the problem we’re solving with Asparz. If you’d like to learn more, visit Asparz.
Calculate the operational impact for your organization
Key Takeaways
The 47-day TLS deadline is real and approaching fast. The CA/Browser Forum’s ballot SC-081v3 sets a phased reduction starting in 2026.
Semi-automation will not survive this transition. Partial coverage and manual processes break at 47-day renewal cycles. End-to-end automation is the only sustainable path.
The problem extends beyond certificates. SSH key sprawl and cryptographic inventory gaps represent equally critical risks that are receiving far less attention.
Visibility is the foundation. You cannot automate what you haven’t discovered. You cannot secure what you can’t see. And you cannot prepare for post-quantum migration without knowing what needs to change.
The organizations that act now will be ready. The ones that wait will be explaining why they weren’t.
References
CA/Browser Forum Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/