There is a quiet countdown running across the internet. By March 2029, domain control validation (DCV), the proof that you control a domain, will only be valid for 10 days, and a public Transport Layer Security (TLS) certificate will be valid for just 47 days. Until recently, that proof could be reused for over a year, and certificates could last just as long; since 15 March 2026, both are capped at 200 days. This is one of the biggest changes to how the web proves trust, and most teams have not felt it yet.
You have probably heard about the 47-day certificate. That is one half of the story. The other half is the 10-day domain validation window. Both matter, and together they reshape how you issue and renew certificates. Let us walk through what is changing, why it is happening, and how to get ready without the last-minute panic.
What is Domain Control Validation?
Domain Control Validation, or DCV, is the check a Certificate Authority (CA) runs before it issues a TLS certificate. It confirms one simple thing. Do you actually control the domain you want to secure?
You prove control by doing something only the real owner could do. You might add a special DNS record or place a file on your web server. The CA looks for that proof. If it finds it, the certificate gets issued.
After you pass the check, the CA does not forget it right away. It can reuse that proof for a set period. During that window, you can get new certificates for the same domain without proving control again. Since 15 March 2026 that window is up to 200 days, down from 398 days before. That is why renewing has felt easy. The hard part was already cached.
What is Changing and When?
In April 2025, the CA/Browser Forum approved a measure called Ballot SC-081v3. The Forum is the group of CAs and browser makers that set the rules for public certificates. The browsers behind Chrome, Safari, Firefox, and Edge all voted yes.
The ballot does two things at once. It shrinks how long a certificate can live, and it shrinks how long domain validation can be reused. Both happen in steps.
| Effective date | Max certificate lifetime | Max domain validation reuse |
|---|---|---|
| Until 15 March 2026 | 398 days | 398 days |
| 15 March 2026 | 200 days | 200 days |
| 15 March 2027 | 100 days | 100 days |
| 15 March 2029 | 47 days | 10 days |
Notice that by 2029, the reuse window is shorter than the certificate itself. The practical effect is simple. Domain validation will need to happen for almost every renewal, not just once in a while.
There is one more change for higher-assurance certificates. If you use Organization Validated (OV) or Extended Validation (EV) certificates, the validated identity data that supports the certificate’s Subject field is called Subject Identity Information. From 15 March 2026, that information can only be reused for 398 days, down from 825. So your company identity check moves from a roughly two-year cycle to a yearly one.
Two quick notes. Some CAs already issue certificates a day or two under the official maximum, because validity is measured down to the second, so renew early and keep a buffer. And these rules only apply to publicly trusted certificates. A private internal CA that browsers do not trust, and is a part of your own Public Key Infrastructure (PKI), is not covered, though shortening its lifetimes is still good hygiene.
How Domain Validation Works
To get ready for far more frequent validation, it helps to understand the most common ways a Certificate Authority (CA) verifies domain control.
Email validation sends a message to an address such as [email protected] and asks you to confirm ownership by following a link. It is simple but typically requires manual action, making it impractical when validation must be repeated every 10 days. Email-based validation is also being gradually phased out by the CA/B Forum under Ballot SC-090.
HTTP-based validation (commonly the ACME HTTP-01 challenge) asks you to place a small token file at a specific path on your web server. It works well for individual servers but becomes harder to manage across load balancers, CDNs, and large distributed environments.
DNS-based validation (commonly the ACME DNS-01 challenge) requires publishing a TXT record in your domain’s DNS. It is the standard method for wildcard certificates and can be fully automated through DNS provider APIs, making it the preferred choice for frequent certificate renewals and DCV revalidation.
The technology that ties all of this together is the Automated Certificate Management Environment (ACME) protocol, defined in RFC 8555. ACME automates the whole loop. Your client asks for a certificate, the CA returns a challenge, your client publishes the proof, and the CA checks it and issues the certificate. No human clicks required. It is the same protocol that made automated certificate issuance standard across the modern web.
For this new era, DNS-01 with ACME is the strongest path. A useful trick is CNAME delegation. You point the validation record to a small dedicated zone, so your automation only touches that narrow space and not your main DNS. One more thing to expect. CAs now confirm domain control from several network locations at once, a safeguard called multi-perspective validation that makes attacks like BGP hijacking much harder.
In practice, it means your validation must look correct from every vantage point, so an unstable DNS setup or a half-finished change can cause failures. A related rule (Ballot SC-085v2, effective 15 March 2026) also requires CAs to check DNSSEC when present, so a broken DNSSEC setup can cause failures as well.
Why the Industry is Doing This
Shorter lifetimes are not about making your life harder. They fix a real weak spot.
When a certificate or its private key is stolen, the damage lasts as long as the certificate stays valid. Browsers are not great at revoking certificates quickly, since revocation checks are often skipped or time out. A long-lived certificate is a long-lived risk. A short one limits the damage window on its own, much like a key that stops working after a few weeks, even if no one noticed it was copied.
There is a forward-looking reason too. The industry is preparing for post-quantum cryptography. NIST finalized its first three post-quantum standards on 13 August 2024, known as FIPS 203 (ML-KEM), 204 (ML-DSA), and 205 (SLH-DSA). Swapping algorithms across thousands of certificates is painful if everything is long-lived and manual. Short lifetimes plus automation make that switch far easier. None of this is new advice. NIST SP 1800-16, a practice guide on TLS server certificate management, recommended certificate inventories, monitoring, and automation years ago. The new rules simply make that guidance non-optional.
What the Shorter Window Means for You
Let us make the workload concrete. A 47-day certificate needs renewing roughly eight times a year. Most teams renew about once a year today. With the 10-day reuse window, domain validation has to happen for almost every one of those renewals.
Now multiply that across a real environment. Web servers, APIs, load balancers, mail gateways, and short-lived workloads in Kubernetes all carry certificates. A manual process that copes fine with one renewal a year becomes a constant source of outages once that climbs to eight. And a single expired certificate can take down a payment flow, an API, or a login page in seconds.
Industry analysts make the same point. Gartner notes that organizations routinely suffer outages from unmanaged certificates, and that the 47-day requirement brings new urgency to certificate lifecycle management. Compliance adds pressure too, since standards like PCI DSS expect strong, current cryptography on data in transit. For teams on government timelines, the NSA’s CNSA 2.0 suite sets concrete post-quantum migration milestones. FIPS 140-3 validation also governs the modules protecting HSM-backed keys.
How to Stay Ahead of the Clock
You do not need to solve all of this at once. The phased timeline is your runway. Start here.
- Find every certificate. You cannot renew what you cannot see. Build a full inventory across cloud, on-prem, and internal systems, and give each certificate a clear owner.
- Automate issuance and renewal. Adopt ACME and a certificate lifecycle management approach so renewals happen without a human in the loop.
- Prefer DNS-01 with delegation. Move validation to DNS records driven by an API, and use CNAME delegation to keep changes contained.
- Retire manual and email validation from production. Anything that needs a person to click a link will break at this speed.
- Monitor and renew early. Track expiry dates, alert before they hit, and renew with a buffer instead of squeezing the last day.
- Build crypto-agility now. Treat fast, automated rotation as a core capability. It protects you today and prepares you for post-quantum migration.
A few traps to avoid. Do not assume your private PKI is affected, because it is not. Do not forget the yearly OV or EV identity check, since that step stays manual. Do not rely on a single network path for validation. And do not leave any certificate without a named owner, because orphaned certificates are the ones that expire unnoticed.
How Encryption Consulting Can Help
CertSecure Manager is Encryption Consulting’s certificate lifecycle management platform, purpose-built to handle exactly the challenges described above.
It integrates with existing ACME clients and acts as the enterprise system of record and policy engine across public and private CAs. The ACME clients keep doing what they do, while CertSecure Manager tracks every certificate they issue, enforces your cryptographic policies, and gives you a unified view of the entire lifecycle across your Linux and Windows infrastructure.
CertSecure Manager integrates with public CAs like Let’s Encrypt and with its own custom ACME endpoint, so issuance and renewal stay fully automated. It also reduces certificate-related outages by providing configurable 30-day or longer advance alerts.
On the deployment side, Ansible playbooks consistently manage ACME client configuration, certificate deployment, and service reloads across Apache, Nginx, Tomcat, and IIS in both on-premises and hybrid cloud environments, all without manual intervention.
As your environment grows, CertSecure Manager scales with it. It provides a unified certificate inventory, enforces cryptographic standards across all teams, and delivers visibility into lifecycle events. Its operational integrations for alerts, ticketing, and audit logging turn certificate management from a reactive fire-fighting exercise into a controlled, auditable process.
Conclusion
The countdown is already running. Certificate lifetimes drop to 200 days in 2026, 100 days in 2027, and 47 days in 2029, while domain validation reuse falls all the way to 10 days. Shorter certificates and constant, automated validation are now two sides of the same job.
The teams that start now will barely notice the deadlines, because they will have an inventory, automation, and clear ownership in place. The teams that wait will feel every renewal. If you are not sure where your certificates live or how they renew, that is the first thing to fix. Map it, automate it, and the rest gets a lot easier.
