DNS-PERSIST-01 Is Great. Your Threat Model Needs Updating.

Five security assumptions that change when certificate validation becomes persistent — and what to do about each one.

DNS-PERSIST-01 is a genuinely great advancement. It solves real problems that practitioners deal with every day — DNS propagation delays, credential sprawl across your issuance pipeline, change management friction for every single renewal. The CA/Browser Forum approved it unanimously via Ballot SC-088v3. Let's Encrypt is rolling it out. This is a good thing.

But every time the PKI ecosystem gains a new automation capability, there's a pattern: teams adopt the operational benefits without updating their security assumptions to match. We saw it with ACME itself — teams automated certificate issuance but didn't think about what happens when the automation breaks, or what an attacker could do with access to the ACME client.

DNS-PERSIST-01 deserves a similar moment of "okay, what changes?" Not because it's dangerous — but because understanding the shift helps you adopt it well.

If you need the technical overview first, start with our DNS-PERSIST-01 Explained guide.

1. Your ACME Account Key Just Became a Persistent Authorization Token

The shift

With DNS-01, a compromised ACME account key gives an attacker the ability to request certificates — but they still need to complete a fresh DNS challenge for each one. The attack window is bounded by the validation cycle. With DNS-PERSIST-01, that same compromised key can issue certificates for every domain where a _validation-persist record exists, with no additional DNS interaction needed. The authorization is already standing.

The reality check

Most teams store ACME account keys with far less protection than they give certificate private keys. They live in certbot config directories, in CI/CD secrets, in container environment variables. That was already not great, but the blast radius was limited. Now it's not.

What to do

• Treat ACME account keys with the same key management discipline as your most sensitive certificate private keys
• Audit where your ACME account keys are stored today — if they're in plaintext config files, fix that before deploying DNS-PERSIST-01
• Consider using separate ACME accounts for different security zones rather than one account with persistent authorization across everything
• Know that account key rotation (RFC 8555 §7.3.5) preserves the accounturi, so rotating keys doesn't break your records — do it regularly

2. "Set and Forget" Creates Monitoring Blind Spots

The shift

The entire value proposition of DNS-PERSIST-01 is that you configure DNS once and never touch it again. That's operationally beautiful. It also means nobody is looking at those records on an ongoing basis.

The reality check

With DNS-01, the constant DNS churn meant someone (or something) was interacting with your DNS zone regularly. That interaction created natural touchpoints where anomalies could surface. With DNS-PERSIST-01, the DNS zone goes quiet — which is great until an unauthorized _validation-persist record appears and nobody notices because nobody's looking.

What to do

• Add _validation-persist TXT records to your DNS monitoring/alerting — any addition, modification, or deletion should trigger a notification
• Include _validation-persist records in regular DNS zone audits (you're already auditing CAA records, right?)
• Implement Certificate Transparency log monitoring for your domains — if a certificate you didn't request appears, investigate the authorization path
• Document which domains have persistent authorization and which CAs/accounts are authorized — maintain an inventory

3. The Revocation Playbook Has New Steps

The shift

When something goes wrong with DNS-01 (compromised DNS credentials, unauthorized validation), the response is straightforward: change your DNS credentials, clean up any rogue _acme-challenge records, and the attack surface is closed. The records were ephemeral anyway.

The reality check

With DNS-PERSIST-01, the response requires different steps with different timing:

• Removing the TXT record stops new validations, but any authorization the CA already completed remains valid for up to 10 days (per the Baseline Requirements' reuse period)
• Deactivating the ACME account (RFC 8555 §7.5.2) is the nuclear option — it's immediate and effective, but it's also permanent and irrevocable. That account is gone forever, along with all its authorizations across every domain.
• There's a gap between "remove the DNS record" and "all existing authorizations expire" where certificates can still be issued using cached validation data

What to do

• Document your incident response procedure specifically for ACME account compromise — before you need it
• Know the difference between removing TXT records (gradual) and deactivating the account (immediate but permanent)
• If you use separate ACME accounts per security zone, compromising one doesn't require nuking them all
• Have a plan for standing up a new ACME account and re-publishing _validation-persist records after a deactivation

4. policy=wildcard Is More Powerful Than It Looks

The shift

Without the policy parameter, DNS-PERSIST-01 authorization covers only the exact FQDN. Add policy=wildcard and it covers the FQDN, *.example.com, AND any specific subdomain at any depth — www.example.com, app.example.com, server.dept.example.com, all of it.

The reality check

Most teams will reflexively add policy=wildcard to their apex domain because "we might need subdomains." But this persistently authorizes certificate issuance for subdomains that don't exist yet — including ones that could be created by a subdomain takeover attack. If an attacker can claim abandoned-app.example.com (dangling CNAME, expired cloud resource, etc.), and your apex has policy=wildcard, they're one step closer to a valid certificate for that subdomain.

What to do

• Default to FQDN-only (no policy parameter) unless you specifically need wildcard or subdomain coverage
• If you use policy=wildcard, maintain active subdomain hygiene — audit for dangling CNAMEs, expired cloud resources, abandoned DNS records
• Consider placing _validation-persist records on specific subdomains rather than one wildcard authorization on the apex
• Remember that policy=wildcard on dept.example.com only covers subdomains of dept.example.com — scope it as narrowly as possible

5. The Automation Dependency Deepens — and That's Okay (With a Plan)

The shift

This isn't DNS-PERSIST-01 specific, but it's the backdrop. The PKI ecosystem is moving steadily toward full automation: shorter certificate lifetimes (47-day certs via SC-081), email/phone DCV methods being sunset (SC-090), and now persistent DNS authorization that removes the last manual touchpoint from the renewal path.

The reality check

When automated certificate management works, it's invisible. When it breaks — CA outage, ACME client bug, expired account, DNS provider issue — teams often don't have the knowledge or muscle memory to respond manually. DNS-PERSIST-01 makes the happy path even smoother, which is great, but it also means the gap between "everything works" and "something broke and we don't know what to do" gets wider.

What to do

• Ensure your team understands the certificate lifecycle, not just the automation tooling — if certbot disappeared tomorrow, could your team issue a certificate manually?
• Maintain documentation of your ACME setup: which accounts, which CAs, which domains, which validation methods, where the keys are stored
• Test your incident response: what happens when a renewal fails? Who gets paged? What's the manual fallback?
• Monitor certificate expiration independently of your ACME automation — don't rely on the same system to both renew and alert on failure to renew

Adopt It Thoughtfully

DNS-PERSIST-01 is a genuine improvement. It solves real problems that practitioners deal with every day. The CA/Browser Forum's unanimous approval and Let's Encrypt's adoption signal that this is the direction the ecosystem is heading.

The point isn't to be cautious about adopting it — the point is to adopt it thoughtfully. Update your threat model, tighten your ACME key management, add monitoring for your persistent records, and document your incident response. Do those things and you get all the operational benefits with your eyes wide open.

Ready to implement? Start with our full DNS-PERSIST-01 technical guide.