Does the 100-day cap apply to internal / private PKI certificates?

Not directly. The cap applies to publicly trusted TLS certificates issued by public CAs. Private CAs (ADCS, HashiCorp Vault PKI, TigerTrust PKI-as-a-Service, EJBCA) can issue certificates at any validity your policy permits. However, if your internal CA cross-signs through a public root for publicly-trusted TLS, the public leaf inherits the 100-day cap.

When does Let's Encrypt move to 64-day certificates?

Let's Encrypt's default certificate lifetime drops to 64 days on 10 February 2027 — 33 days ahead of the CA/B Forum's 100-day cap. Teams on Let's Encrypt will feel the operational shift a month before the industry-wide deadline. Treat the February-to-March window as a rehearsal for the 100-day transition.

What domain validation methods are retiring?

Phone-based DCV (where a CA validates domain control by calling a phone number on the registrant's listed contact) retires in March 2027. Email-based DCV (where the CA emails a fixed inbox like admin@yourdomain.com and waits for a click) retires in 2028. After 2028, DCV must be a protocol flow — HTTP-01, DNS-01, or tls-alpn-01 under the ACME framework.

How many hosts are exposed to the 15 March 2027 transition?

InternetData's October 2026 scan found 346,620 browser-trusted IPv4 hosts presenting pre-cap certificates (longer than 100 days) that remain valid on 15 March 2027. These hosts won't fail on the deadline itself — their existing certificates still chain — but their first renewal after 15 March will fail unless their issuance pipeline is already producing 100-day-or-shorter certs.

What percentage of hosts are already compliant?

The same InternetData scan found 35.5% of browser-trusted IPv4 hosts already present certificates with lifetimes of 100 days or fewer. Teams on Let's Encrypt, ZeroSSL, and any CA with automated short-lived issuance are largely compliant already. The exposure is concentrated in traditional OV / EV deployments and legacy long-validity contracts.

What is ACME Renewal Information (ARI)?

ARI is an extension to the ACME protocol (RFC 9773) that lets the CA signal when a client should renew. Instead of renewing at a fixed interval like T-30 days, the client polls the CA's ARI endpoint and renews when the CA indicates. ARI lets CAs force early renewals for compliance events (CT misissuance scans, revocation campaigns) without manual coordination with every relying party.

Do I need to update my CAA records?

If you run OV, EV, or multi-CA TLS, yes — CAA records explicitly authorise which CAs can issue for your domains. Without CAA, any public CA can issue for any of your domains, which is a specific risk the post-eMudhra WebPKI environment has sharpened. At minimum, add CAA records listing every CA you actually use plus an iodef contact for incident reports.

What should an enterprise do before 15 March 2027?

The 10-step checklist: (1) run certificate discovery across every cloud, cluster, appliance, and host; (2) deploy ACME wherever possible; (3) enable ARI in every ACME client that supports it; (4) add CAA records to every zone; (5) move DCV off email and phone; (6) prepare for MPIC (multi-perspective issuance corroboration) by opening firewall paths for validation fetches from multiple CA network vantage points; (7) audit non-browser trust stores; (8) start ADCS migration if you issue through a public cross-sign; (9) enable OCSP stapling and Must-Staple; (10) build runbooks and monitoring for the shorter cadence.

How does TigerTrust help with the 100-day transition?

TigerTrust automates every step: discovery (agent + network + cloud + CT log), multi-CA orchestration (ACME, ARI, EST, SCEP, CMPv2, REST), CAA audit, non-browser trust-store enumeration, scheduled and automated rotation, and signed audit evidence. For TigerTrust customers, the 100-day cap is a configuration toggle, not a project.

100-Day TLS Certificates: Your 15 March 2027 Readiness Checklist

The Deadline That Isn't Negotiable

On 15 March 2027, the second of the CA/Browser Forum's SC-081v3 milestones lands. Every publicly trusted CA on the WebPKI will cap new TLS certificate lifetimes at 100 days and domain-control validation (DCV) reuse at the same window. The browser root programs enforce this unilaterally — a CA that issues a 101-day cert after 15 March gets distrusted by a Mozilla, Chrome, or Apple root program.

The industry has had two years to prepare. Public-facing scans suggest many teams haven't.

The Numbers Nobody Wants to Look At

InternetData's October 2026 scan of the browser-trusted TLS surface found:

35.5% of browser-trusted IPv4 hosts already present certificates valid for 100 days or fewer. These hosts are already compliant with the 15 March 2027 cap by default.
346,620 hosts present pre-cap certificates (longer than 100 days) that are still valid on 15 March 2027. These hosts work today, continue to work on the deadline, but will discover on their first renewal that the issuance pattern they relied on is gone.

The 346,620-host number is the quiet one. It's not an outage count — those certs still validate after the deadline. It's a renewal-pipeline time bomb: the first renewal cycle after 15 March fails because the CA refuses to re-issue at the old validity, and whatever automation (or manual process) was built around the old validity breaks.

What Changes on 15 March 2027

Certificate validity cap

Field	Before 15 Mar 2027	After 15 Mar 2027
Max TLS validity	200 days	100 days
Max DCV reuse	200 days	100 days
Max OV SAN reuse	200 days	100 days

The validation-method retirement that goes with it

Separately but in the same window:

Phone-based validation retires in March 2027. "Call this phone number on the registrant's listed contact" stops being a permitted DCV method. The remaining methods are the HTTP-01-style file challenge, DNS-01 TXT record, email-based validation (for now), and the newer methods under the baseline requirements.
Email-based validation retires in 2028. The one that reads "we send a verification email to [email protected]" or one of the five fixed inbox names. After 2028, DCV has to be a protocol flow — HTTP-01 or DNS-01 — not a human click on a validation link.

If your DCV automation today relies on either, 15 March 2027 (or 2028, respectively) is a hard migration deadline.

Let's Encrypt moves first

Let's Encrypt is cutting its default cert lifetime from 90 days to 64 days on 10 February 2027 — 33 days ahead of the CA/B Forum deadline. They've consistently been the forcing function on the industry: the 90-day default drove mainstream ACME adoption, and the 64-day default will drive the automation discipline required for the 100-day world.

If your fleet uses Let's Encrypt, you get the operational pressure a month before the industry-wide cap kicks in. Treat that month as your rehearsal.

Who Is Exposed

Six categories, in rough order of blast radius:

1. Teams with no ACME deployment

If your current TLS renewal process involves a human clicking a button in your CA's web console, filing a ticket, or running a scheduled PowerShell job that calls a proprietary API — the 100-day cadence breaks it. Even at 200 days, the manual process was borderline. At 100 days, it collapses: double the renewal volume, same ticket queue. Automation isn't optional after 15 March.

2. ADCS fleets issuing to public-trust chains

If your internal CA (Active Directory Certificate Services or similar) cross-signs through a public CA for publicly-trusted TLS, the 100-day cap applies to the leaf. Your internal issuance pattern has to shorten to match — because the chain inherits the leaf's validity constraints. ADCS auto-enrollment via GPO was built for annual renewals; at 100 days it needs tuning (polling interval, renewal threshold, backup paths) or outright replacement.

3. Device fleets and IoT endpoints

Devices that enroll via SCEP or EST against a public CA and have no over-the-air certificate rotation path will hit the first-renewal cliff. If the device firmware's renewal routine doesn't actually run at expiry, shortening validity just moves the outage earlier.

4. Load balancers and network appliances with frozen configurations

A production FortiGate, F5, or NGINX load balancer configured once in 2023 with a 398-day commercial cert has one renewal cycle per year in its operator's head. After 15 March 2027, that becomes 3-4 renewals per year. The configuration-management discipline required to track this is often absent in network-ops teams that aren't on an ACME flow.

5. Non-browser clients validating certs against OS trust stores

Not directly affected by the cap itself, but — if your OS trust bundle update cadence is "when we remember to patch" — shortening lifetimes means more rotations, more chain changes, more intermediates added and retired. A fleet that got away with a stale trust bundle at 398-day cadence may not get away with it at 100-day cadence.

6. OV and EV certificate operators with CAA policy drift

CAA records that don't allow the specific CAs you use will start showing up as issuance failures more frequently (more issuances = more opportunities to notice). OV/EV teams on manual renewal often don't maintain CAA carefully.

The 10-Step Checklist

1. Discovery — know what you have

You cannot renew what you cannot enumerate. Run full certificate discovery across:

Every public DNS zone (via Certificate Transparency log queries)
Every cloud account (ACM, Key Vault, Certificate Manager)
Every Kubernetes cluster (secrets, cert-manager resources, service mesh)
Every network appliance (FortiGate, PaloAlto, F5, Cisco, Juniper, Check Point)
Every host inventory (agent-based discovery on prod + staging)

Target: one unified list with owner, expiry, chain, and deployed location per cert. For TigerTrust customers, the agent discovery plus network scan plus cloud API scan plus CT-log monitoring collapses this into a single query.

2. ACME everywhere you can

ACME (RFC 8555) is the common denominator. Every public CA worth using in 2026 supports it: Let's Encrypt, ZeroSSL, Sectigo, DigiCert, Google Trust Services. Your private CA should too — TigerTrust's PKI-as-a-Service exposes ACME v2 natively for internal issuance.

Deployment checklist:

cert-manager for Kubernetes
Traefik, Caddy, HAProxy with native ACME
acme.sh / certbot for traditional Linux hosts
Agent-based ACME for Windows hosts and hosts without an in-process TLS terminator

3. ACME Renewal Information (ARI)

ACME Renewal Information (RFC 9773) lets the CA signal when a client should renew — ahead of expiry, often as a response to upstream events like a CT-log misissuance scan or a scheduled cert rotation. ARI support in Let's Encrypt is live; client support is rolling into cert-manager 1.15+, Caddy 2.9+, and lego 4.17+.

ARI is the difference between "renew 30 days before expiry" and "renew when the CA tells you to renew." Enable it in every client that supports it.

4. CAA records on every active zone

RFC 8659 Certificate Authority Authorization records tell CAs which issuers you've authorised for a given domain. Without them, any public CA can issue for any of your domains (and the post-eMudhra world should have put this concern front-and-centre for every security team).

Minimum CAA record set:

text
1example.com. CAA 0 issue "letsencrypt.org"
2example.com. CAA 0 issue "digicert.com"
3example.com. CAA 0 iodef "mailto:[email protected]"

Audit every zone. Add CAA where it's missing. Set a quarterly recurring review.

5. DCV automation that doesn't rely on email

Phone-based DCV retires in March 2027. Email-based DCV retires in 2028. Your renewal flows need to use:

HTTP-01: file-based challenge served from /.well-known/acme-challenge/
DNS-01: TXT record challenge — requires DNS API access
tls-alpn-01: TLS-handshake-based challenge for environments where HTTP-01 isn't practical

For wildcard certs, only DNS-01 works. Automate your DNS provider's API access now if you haven't. Route 53, Cloudflare, Google Cloud DNS, Azure DNS all have terraform providers for IaC-driven zone management.

6. Multi-Perspective Issuance Corroboration (MPIC)

MPIC is the CA/B Forum's response to BGP-hijack attacks on domain validation — CAs now validate domain control from multiple network perspectives (3+ as of the current baseline requirements) before issuance. This is already in effect at Let's Encrypt, Sectigo, and the big public CAs.

For operators, this mostly means: the first few seconds of a DCV flow may include requests from multiple network perspectives. Firewall rules that block "unexpected" source IPs during the /.well-known/acme-challenge/ fetch will cause issuance failures. Open the path.

7. Non-browser trust stores

Your production estate isn't just browsers. Every container base image, every Go binary compiled against x509.SystemCertPool(), every Fortinet / Cisco / F5 appliance has its own trust store. Audit:

Container base image rebuild cadence (should be weekly minimum)
Linux distro trust bundle update cadence (quarterly minimum, monthly preferred)
Agent-based trust-store sync on fleet hosts (via TigerTrust or similar)
Pinned trust anchors in device firmware (document which anchors, for what fleet, with what expected replacement path)

8. ADCS: shadow or migrate

If you're running ADCS for internal issuance:

If the chain stays internal (no cross-sign through a public root), the 100-day cap doesn't apply to you directly — but it applies to your renewal cadence discipline, which should shorten anyway.
If the chain crosses into public trust, you need to migrate off ADCS or restructure the cross-sign pattern before 15 March.

The shadow-issuance migration pattern (see Migrating off Microsoft ADCS) runs the new CA in parallel for 4-8 weeks, proves parity against the old one, then cuts over on a scheduled window. Start the parallel run now if you haven't.

9. OCSP stapling + Must-Staple

At 100-day validity, revocation is a smaller problem than it was at 398-day — compromised certs age out faster. But it's not a solved problem. Configure:

OCSP stapling on every terminating TLS server
Must-Staple on new certificate profiles where client support allows it
Monitor stapled response freshness — a staple older than its nextUpdate means the server isn't refreshing, and the staple is doing nothing

See CRL vs OCSP for the full revocation discipline.

10. Runbook + monitoring

Every certificate in your inventory needs:

An owner (human, team, or on-call rotation)
An expected renewal mechanism (ACME client name, manual process, deployment pipeline)
A monitoring signal (alert at T-14 days from expiry if not renewed)
A rollback plan (what happens if the renewed cert deploys and breaks TLS)

Build this before 15 March, because after 15 March the alerts will fire 2x more often per cert.

How TigerTrust Automates This

TigerTrust handles every step in the checklist as a managed workflow:

Discovery — agent + network + cloud API + CT log monitoring in one inventory
ACME + ARI + EST + SCEP + CMPv2 + REST — every issuance protocol worth speaking, including ARI for ahead-of-expiry renewals triggered by CA-side events
CAA audit — periodic sweep of every zone with a certificate in inventory
Multi-CA orchestration — Let's Encrypt, DigiCert, Sectigo, Google Trust Services, private CAs, all under one policy plane
Non-browser trust-store enumeration — the agent reports every anchor present on every host, cross-referenced against expected lists
Scheduled + automated rotation — policy-driven renewal with retry, backup CA fallback, and zero-downtime deployment
Signed audit stream — every issuance, every renewal, every revocation emits a signed audit line to your SIEM

The 100-day transition is a configuration toggle for TigerTrust customers. For everyone else, it's a project.

Ready to Transform Your Certificate Management?

See how TigerTrust can help you automate certificate lifecycle management at scale.