47-Day Certificates Will Make Every Website Look Like a Phishing Site

By 2029, every public TLS certificate on the internet will be dead within 47 days of being issued. The industry sold this as a fix for stolen certificates. It is — but it also just made the system that issues those certificates the single most valuable target on your network, and quietly deleted one of the oldest tricks defenders had for spotting a phishing site.

TL;DR

The CA/Browser Forum’s Ballot SC-081v3 is already cutting maximum TLS certificate validity from a 398-day baseline: 200 days has been in effect since March 2026, dropping to 100 days in March 2027 and 47 days by March 2029

Domain validation reuse shrinks in parallel — down to 10 days by 2029 — pushing any organization running public-facing TLS at scale toward automated certificate lifecycle management, usually ACME or a CA’s own vendor API

Academic research (ACM Web Conference 2025) shows stolen ACME account credentials can yield fraudulent certificates without ever controlling the domain, thanks to a 30-day validation cache

As 94%+ of certificates become automated, domain-validated, and short-lived, defenders lose the “freshly issued cert = suspicious” heuristic — because now everyone’s certificate looks freshly issued

A related change — the Chrome Root Program’s removal of the clientAuth EKU from public certificates, with CAs front-running its March 2027 deadline since late 2025 — breaks mutual TLS (mTLS) for device onboarding and B2B integrations

Why This Matters to You

If you run anything that terminates TLS — a web app, an API gateway, an IoT fleet, a telecom core network — this isn’t a compliance footnote. The 200-day cap has been live since March 2026. The next cut, to 100 days, lands in March 2027. Nokia’s own Threat Intelligence Report 2025 puts it bluntly to its telecom customers: manual certificate renewal across APIs, IoT, OSS/BSS, and embedded devices “becomes unworkable,” and without automation, “disruptions will hit as hard as cyberattacks.”

That’s the framing every CA vendor is using right now to sell automation tooling. What none of them are advertising is that the automation itself is the new thing worth attacking.

What’s Actually Changing

The relevant rule is CA/Browser Forum Ballot SC-081v3, originally proposed by Apple and passed 29-0 in April 2025. It sets a phased countdown:

Date	Max certificate validity	Domain validation (DCV) reuse
Baseline (pre-2026)	398 days	398 days
March 15, 2026 — in effect now	200 days	200 days
March 15, 2027	100 days	100 days
March 15, 2029	47 days	10 days

The DCV reuse column matters as much as the certificate lifetime itself. DCV (Domain Control Validation) is how a Certificate Authority (CA — an organization trusted to vouch that you actually control a domain before issuing you a certificate for it) proves you own a domain before handing you a certificate. Under the pre-2026 baseline, a CA could reuse a successful validation for up to 398 days before checking again. As of this writing that’s already down to 200 days, and by 2029 it drops to 10 — meaning domain ownership will get re-verified roughly 36 times a year instead of about once. Every one of those checks is a fresh opportunity, for both legitimate renewal and for an attacker who can momentarily fake control of your domain.

A second, related change compounds this: public CAs are removing the clientAuth Extended Key Usage (EKU) — the flag that lets a certificate be used to authenticate a client, not just a server — from public TLS certificates. The driving mandate comes from the Google Chrome Root Program, which requires CAs to stop including clientAuth in public TLS certificates entirely, with a hard cutover on March 15, 2027 (only serverAuth will be permitted from that date). CAs are front-running that deadline on their own staggered schedules: DigiCert stopped including it by default on October 1, 2025 (full removal by March 1, 2027), and Sectigo is phasing it out in three steps ending February 10, 2027. Nokia’s “by 2025” framing reflects that first wave of default-off changes, not the final hard deadline — worth keeping the distinction straight if you’re planning around it. Either way, if you use public-CA certificates for mutual TLS (mTLS — where both sides of a connection present a certificate to authenticate each other, common in IoT device onboarding and B2B API integrations), that stops working on this timeline unless you migrate to private PKI first.

The Offensive Angle: Automation Is the New Attack Surface

Shortening certificate lifespans was sold as a defensive win: a stolen certificate and private key are worthless faster. That part is true. But pushing organizations running public-facing TLS at scale toward automated certificate lifecycle management — usually ACME (Automatic Certificate Management Environment, the protocol that lets a server request and renew certificates from a CA without a human clicking buttons), sometimes a CA’s own vendor API — changes what an attacker actually needs to compromise.

Your ACME Account Is Now Worth More Than a Stolen Certificate

Stealing a single certificate and key used to be the prize. Now the prize is upstream of that: the ACME account and client that can mint certificates on demand, automatically, for as long as it stays compromised.

Research presented at the ACM Web Conference 2025 documented what its authors call the ACME Authz Cache Attack: because the ACME protocol allows CAs to cache a successful domain authorization for up to 30 days, an attacker who steals ACME account credentials can request a fraudulent certificate for a domain without ever actually controlling that domain at request time — riding on a stale, cached authorization. The researchers note even Let’s Encrypt, the largest CA in the world, is exposed to this pattern, and propose a hardened protocol (ACME++) that binds ACME accounts to a client IP and unique identifier to close the gap.

Palo Alto Networks’ Unit 42 has documented this outside the lab, too: real incidents where an adversary compromises a domain’s control plane — most often DNS — and then simply runs the legitimate ACME workflow on top of that hijacked control to obtain a valid certificate. No exploit needed. The automation does exactly what it was built to do; it just does it for the wrong owner.

The defensive takeaway is uncomfortable: as renewal cycles shrink from 398 days to 47, the ACME client credentials, private keys, and the CI/CD runners or NOC systems that hold them become a single point of failure for your entire certificate estate — not just one site.

BGP Hijacking and the Reason MPIC Exists

DCV has a second, longer-standing weakness: most validation checks historically came from a single network vantage point — the CA’s own infrastructure. An attacker capable of a BGP hijack (announcing false routes to redirect internet traffic, a well-documented and still-common class of attack against the internet’s core routing protocol) can intercept that one validation request in transit and answer it fraudulently, walking away with a certificate for a domain they don’t own.

This is exactly why the CA/Browser Forum forced through MPIC (Multi-Perspective Issuance Corroboration) via Ballot SC-067v3: CAs must now validate domain control from at least three network vantage points spanning two separate Regional Internet Registries, climbing to five perspectives by December 2026, specifically to make a localized BGP hijack insufficient to fool validation. A companion rule, SC-085v2, now requires CAs to validate DNSSEC responses during DCV, closing a related DNS-spoofing path.

Both changes are direct, public admissions that the validation step underpinning every certificate on the internet was attackable at internet-routing scale. Shrinking the reuse window to 10 days without MPIC and DNSSEC validation in place would have made things worse, not better — more frequent validation means more frequent opportunities to attack it, unless each individual check is hardened.

The Vanishing Heuristic: When Every Certificate Looks Fresh

Here’s the part nobody’s advertising. Security teams and savvy users have long used “this certificate was issued five minutes ago” as a quiet signal that a site might be a fast-thrown-up phishing page. That signal is about to disappear.

Free, automated, domain-validated (DV) certificates already dominate the web: Netcraft’s 2025 data puts DV certificates at 94.3% of all issued certificates. Phishing operators noticed this dynamic over a decade ago — Netcraft recorded that 61% of phishing sites with a valid TLS certificate in early 2017 used Let’s Encrypt, and APWG data shows the share of phishing sites using HTTPS climbed from roughly 60% in 2019 to 83% by 2021, precisely because free, instant, automated DV certificates removed every practical reason for an attacker not to use one.

Now apply the same logic industry-wide. When every legitimate certificate on the internet renews automatically every 47 days, “newly issued” stops correlating with “suspicious” at all — because it now describes every single certificate, good or bad, all the time. MITRE ATT&CK already tracks this as a resource-development technique (T1588.004 — Digital Certificates): adversaries acquiring TLS certificates, including free DV certificates, to encrypt C2 traffic or enable adversary-in-the-middle interception. Shortening lifespans doesn’t reduce that technique’s usefulness to an attacker. It just makes their infrastructure indistinguishable from yours.

The Cautionary Tale: When Cert Expiry Becomes an Outage

The risk here isn’t hypothetical. In December 2018, an expired software certificate inside Ericsson’s core network software triggered a fault in specific SGSN-MME nodes (the network elements that handle mobile data sessions), knocking O2’s UK network offline for almost 23 hours and taking down Giffgaff, Sky Mobile, Lyca, and Tesco Mobile along with it — roughly 25 million customers affected, plus SoftBank in Japan hit by the same root cause. It took Ericsson around 12 hours just to identify the fix.

That happened with 398-day certificates and annual renewal cycles, where a single missed expiry could still slip through change-control. Nokia’s own threat intelligence team flags exactly this pattern as the top operational risk of the 2026-2029 transition: “hidden legacy certificate dependencies,” “vendor gear with hard-coded trust settings,” and certificate inventories nobody fully owns. Compress the renewal cycle to 47 days and the margin for a missed renewal — or a quietly compromised ACME account nobody’s watching — gets correspondingly smaller.

How to Verify You’re Actually Covered

Shrinking lifespans force automation whether you’re ready or not. The question worth answering now isn’t “do we have ACME set up” — it’s “would we notice if it failed, or if someone else were using it.”

Inventory Before You Automate

You cannot protect what you don’t know exists. Pull a full list of every certificate your organization presents externally using Certificate Transparency logs — every publicly trusted certificate is logged there by design, which makes it a free audit tool for your own domains:

# Pull every certificate ever logged for a domain via crt.sh
curl -s "https://crt.sh/?q=%.yourdomain.com&output=json" \
  | jq -r '.[] | "\(.not_before) -> \(.not_after)  \(.name_value)"' \
  | sort -u

Cross-reference this against your asset inventory. Anything you didn’t issue, or any subdomain you don’t recognize, is worth investigating immediately — it’s exactly how Certificate Transparency monitoring catches both misissuance and forgotten shadow infrastructure.

Harden the Automation Itself

Your ACME client and account credentials now carry the blast radius that used to belong to a single certificate’s private key. Treat them accordingly:

Store ACME account keys and CA API tokens with the same access controls as production secrets — not as a config file on a shared NOC box
Run ACME clients with the least privilege needed (e.g., DNS-01 challenge credentials scoped to a single subdomain via your DNS provider’s API, not account-wide access)
Rotate ACME account keys on a schedule, and audit every issuance event against who requested it

Lock Down Domain Validation

Add a CAA (Certification Authority Authorization) DNS record to every domain you control. It tells every CA on the internet which CAs are actually allowed to issue for you — anyone else’s validation attempt should be rejected outright, regardless of how it was obtained:

; Only letsencrypt.org and your internal CA may issue for this domain
yourdomain.com. CAA 0 issue "letsencrypt.org"
yourdomain.com. CAA 0 issue "your-internal-ca.example"
yourdomain.com. CAA 0 iodef "mailto:security@yourdomain.com"

Pair that with DNSSEC on every zone you control — it’s now a CA requirement during DCV (SC-085v2), and it closes the DNS-spoofing half of the BGP-hijack problem described above.

Monitor Like It’s Already Broken

Don’t wait for a browser warning to find out a certificate expired. Treat certificate expiry as a first-class health-check metric, not an annual calendar reminder:

Run a blackbox_exporter-style probe (or equivalent) against every TLS endpoint, alerting well before — not at — expiry
Feed certificate issuance events into the same pipeline as your other identity and secrets monitoring (non-human identities like ACME service accounts deserve the same scrutiny as a privileged user account)
Build expiry alerts into NOC/SOC workflows directly, exactly as Nokia’s own remediation table recommends to its telecom customers

Don’t Forget mTLS

If any device onboarding, B2B integration, or internal service relies on a public-CA certificate with the clientAuth EKU, it will break on a CA-by-CA basis between now and the Chrome Root Program’s March 15, 2027 hard cutover — some CAs have already defaulted it off. Migrate client authentication to a private/internal PKI (your own CA, or an enterprise PKI service) well before your specific CA’s removal date — not after something fails.

What You Can Do Today

Inventory every public certificate via Certificate Transparency logs and reconcile against your asset list
Add CAA records (and DNSSEC) to every domain you control
Audit who and what holds your ACME account credentials, and rotate them now
Wire certificate expiry into existing monitoring — don’t rely on a human remembering a 47-day cycle
Identify any client-authentication use of public-CA certificates and start the migration to private PKI before your CA removes clientAuth support (check its specific date — the hard industry deadline is March 15, 2027)

Post-Quantum Cryptography: Prepare Before Your Encryption Breaks — the same crypto-agility pressure driving shorter certificate lifespans is also driving the migration off RSA and ECC
ADCS Abuse with Certipy: From Low-Priv User to Domain Admin via Certificate Services — when certificate infrastructure itself becomes the attack path, internal PKI included
Non-Human Identities: The Attack Surface Your Security Team Isn’t Managing — ACME accounts and automation credentials are exactly this category of unmanaged identity