MSPs: Certificate Automation Across Client Estates Before March 2027

A managed service provider with fifty client domains currently performs somewhere around fifty certificate renewals a year. Annoying, tractable, and frequently still done through a mixture of tickets, calendar reminders and one person who remembers.

From March 2027 that becomes roughly two hundred renewals a year. From March 2029, around four hundred.

The work does not scale linearly with the ceiling reduction. It scales worse, because each renewal carries a coordination cost with a client whose DNS you may not fully control.

The schedule

From	Maximum lifetime	Renewals per domain per year
2026-03-15	200 days	~2
2027-03-15	100 days	~4
2029-03-15	47 days	~8

Running in parallel, Domain Control Validation reuse drops toward 10 days by 2029. Today a domain validation can be reused for over a year. Eventually you will re-prove control roughly three times a month, per domain.

That second change is the one that kills manual workflows outright. Renewal can be batched by a determined human. Revalidation on a 10-day cycle across an estate cannot.

Why MSPs feel this harder than a single vendor

A SaaS company automating its own certificates controls its own DNS, its own load balancer and its own deploy pipeline. An MSP faces three complications.

DNS authority is fragmented. Some clients delegate DNS to you. Others keep it at a registrar their office manager has the password for. ACME DNS-01 challenges need a programmatic path to create TXT records, and “email the client and wait” is not one.

Termination points vary. One client is behind a CDN, another on an appliance, a third on a legacy IIS server where certificate installation is a manual import.

Failure is client-visible and attributed to you. An expired certificate on a client’s domain produces a browser interstitial on their website. They will not describe it as a certificate lifetime policy change.

The migration, in the order that works

1. Inventory first, including what you do not manage. Certificate transparency logs will show you subdomains that exist on client domains that nobody told you about. Marketing microsites and campaign landing pages are the usual discoveries, and they are also the ones that expire unnoticed.

2. Sort clients by DNS control, not by size. Clients whose DNS you hold are a same-week migration. Clients whose DNS sits elsewhere need a delegation conversation, and that conversation has a lead time measured in weeks.

3. Use CNAME delegation for the stubborn cases. Rather than demanding full DNS control, have the client create one permanent CNAME from _acme-challenge.theirdomain.com to a zone you do control. They make one change, once. You then answer every future challenge without touching their DNS again. This single technique resolves most of the fragmented-authority problem and is the highest-leverage step on this list.

4. Standardise the client. lego as a single binary for odd environments, cert-manager for anything on Kubernetes, certbot where it already works. The variety is less important than eliminating hosts where installation is a manual copy.

5. Trigger on fraction remaining, not on days. Renew at one third of lifetime remaining. When the ceiling drops again, nothing in your configuration needs revisiting. Every estate that hardcodes “30 days before expiry” will have to be revisited twice more.

6. Monitor externally, per client. Internal automation that stops silently is the failure mode that hurts, because it removes the human who used to notice. External expiry checking per client domain is the backstop, and it is also a deliverable you can show the client.

The commercial angle

This is a rare compliance-adjacent change that is straightforwardly saleable, because the client-visible failure is concrete and the deadline is external.

For MSPs already positioning around NIS2 obligations for smaller clients, certificate lifecycle sits naturally inside the same conversation. It maps to NIS2 Article 21(2)(h) on cryptography, and the automation evidence answers the crypto-agility question that increasingly follows.

It also pairs with the two other 2026 transport changes, which are equally cheap to deliver across an estate and equally invisible until someone asks:

• MTA-STS and TLS-RPT for client mail domains, where adoption is below one percent and the deployment is two DNS records.
• Hybrid post-quantum key agreement, one configuration line per termination point.

Delivered together, these are a defensible “2026 transport security baseline” package with a deadline attached to it, which is considerably easier to sell than an open-ended hardening engagement.

What to check per client, monthly

# Issued lifetime, not just expiry
echo | openssl s_client -connect client.example.com:443 2>/dev/null \
  | openssl x509 -noout -dates

# Mail transport policy and its mode
dig +short TXT _mta-sts.client.example.com
curl -s https://mta-sts.client.example.com/.well-known/mta-sts.txt | grep -i mode

Any certificate issued for more than 100 days is a domain whose renewal cadence has to change before March 2027. Sorting your estate by that number is the migration backlog, already prioritised.

The short version

The deadline that matters is 2027-03-15, not 2029, because 100 days is where a human process stops working.

Start with the inventory, sort by DNS authority, use CNAME delegation for clients who will not hand over their zone, and trigger renewal on fraction remaining so the next reduction costs you nothing.