TL;DR: A new DNS-based domain control validation method lets certificate authorities verify ownership with a persistent TXT record instead of recurring DNS write access, reducing operational friction and attack surface, according to DigiCert and the CA/Browser Forum. The shift matters because certificate automation now depends less on standing DNS privileges and more on tightly scoped, auditable domain control.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on DigiCert's blog post: A persistent DNS TXT validation method can replace recurring DNS write access for certificate automation, reducing the operational burden of proving domain control.
Why it matters: IAM, PAM, and certificate lifecycle teams need to treat domain validation as a governance control, because automation shifts risk from repeated manual access to durable trust relationships in DNS.
Context
Certificate automation often fails when the control used to prove domain ownership depends on standing write access to DNS. The issue is not just convenience, but governance: recurring validation creates an ongoing privilege window that administrators must maintain, audit, and eventually remove.
Persistent DNS validation changes that pattern by allowing a domain control validation record to be created once for a specific domain and CA pairing. That matters for NHI governance because the lifecycle of the validation credential now becomes part of certificate lifecycle management, not a one-off DNS task.
The underlying question is whether domain trust can be established without granting broad, persistent DNS change rights. In this article's model, the answer is yes, but only if the record, its scope, and its expiry are managed as part of a controlled lifecycle rather than as an ad hoc workaround.
Key questions
Q: How should teams govern persistent DNS validation for certificate automation?
A: Teams should treat persistent DNS validation as a governed lifecycle object, not a one-time technical workaround. That means assigning ownership, tracking the domain and CA pairing, recording expiry where supported, and revoking the record when the relationship changes. The goal is to remove recurring DNS write access while preserving a clear audit trail for domain control.
Q: Why does DNS-PERSIST-01 reduce risk compared with recurring DNS-01 updates?
A: It reduces risk because the older model depends on standing DNS write privileges every time a record must be created or refreshed. A persistent record narrows that exposure by allowing domain control to be proven once for a specific pairing, which lowers the number of privileged changes and makes the validation path easier to audit.
Q: What breaks when DNS automation and certificate lifecycle share the same credential?
A: The credential becomes over-burdened and harder to govern. A task that only needs to place validation records should not also be able to administer zones or reroute traffic. Sharing one secret across those functions makes revocation harder, audit trails noisier, and containment weaker when something goes wrong.
Q: What should security teams review before adopting persistent DNS validation?
A: They should confirm who owns the validation record, how the CA and account identifier are scoped, whether expiry is enforced, and how offboarding will work when domains or providers change. Those questions determine whether the method reduces risk or simply moves privilege into a less visible place.
Technical breakdown
How persistent DNS validation works in certificate automation
The CA/Browser Forum's DNS-PERSIST-01 method uses a TXT record in authoritative DNS to prove domain control for a certificate request. The record name identifies the domain, while the value identifies the certificate authority, a unique customer account identifier, and optionally an expiration date. That structure matters because validation is no longer tied to repeated DNS edits for every renewal cycle. Instead, the persistent record becomes a durable proof artifact that can support automation while keeping the validation boundary narrow.
Practical implication: Treat the DNS TXT record as a governed control object, not a one-time setup task.
Why DNS write privileges become the real governance issue
The previous DNS-01 pattern required customers to create or update validation records repeatedly, which meant ongoing DNS write access was part of the operating model. Persistent validation reduces that standing privilege by separating proof of control from continuous record manipulation. In identity terms, this is a shift from repeated authority to bounded authority. The control problem moves from proving the domain once to proving that the ongoing validation path stays limited to the intended domain, CA, and account pairing.
Practical implication: Remove recurring DNS write access where the persistent method makes it unnecessary.
What certificate automation changes in the trust model
Certificate automation works best when issuance, renewal, and validation can proceed without manual intervention, but that also increases the need for precise scoping and expiry. The article's optional expiration field is important because it shows validation should not be assumed to last indefinitely. For practitioners, the mechanism is less about convenience and more about lifecycle discipline: the automation path, the CA relationship, and the domain proof must all remain attributable and revocable.
Practical implication: Bind validation records to ownership, expiry, and offboarding processes.
Breaches seen in the wild
- GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Persistent DNS validation is really a lifecycle control, not just a technical shortcut. The important change is that validation no longer depends on repeated DNS write access for every certificate renewal. That shifts the security question from operational convenience to governance over a durable trust artefact, which is exactly where certificate lifecycle discipline belongs. Practitioners should treat the validation record as a governed identity assertion, not a convenience setting.
DNS write privilege has been overused as a proxy for domain trust. The older DNS-01 model bundled proof of control with recurring administrative authority, which created a standing privilege window that many teams accepted as normal. DNS-PERSIST-01 breaks that assumption by separating proof from repeated change rights. The implication is that certificate automation programmes must re-evaluate which access is actually required versus merely inherited from legacy process.
Persistent validation record governance: this article shows why durable validation objects need the same lifecycle thinking as secrets and certificates. If the record proves domain control for a specific CA and account, then scope, expiry, and revocation logic must be explicit. That makes certificate automation a governance domain, not just an issuance workflow, and it raises the bar for offboarding and change control across DNS, PKI, and NHI practice.
Standards alignment is now part of the control design. The CA/Browser Forum baseline change, the related ACME proposal, and the Chrome Root Program policy review all point in the same direction: automated certificate management is becoming standards-governed rather than tool-governed. Teams that treat the validation path as an isolated implementation detail will miss the broader shift toward auditable, policy-aligned automation. Practitioners should align certificate controls with the standards path, not only the platform path.
What this signals
Persistent validation record governance: certificate automation becomes safer when proof of domain control is managed like any other lifecycle-bound identity artefact. The key shift is away from repeated DNS privileges and toward explicit ownership, expiry, and revocation.
Persistent DNS validation also shows why identity governance has to extend into PKI operations. If a TXT record can stand in for recurring administrative access, then teams need a control model that covers issuance, renewal, offboarding, and auditability together.
For practitioners
- Reclassify DNS validation as governed lifecycle state Track persistent validation records alongside certificates, owners, and renewal schedules so the proof of control is reviewable and revocable.
- Remove recurring DNS write access where possible Use the persistent DNS method for supported domain and CA pairings so operators do not retain standing DNS change rights for routine renewals.
- Bind validation records to explicit expiry Require an expiration value and an accountable owner for each persistent TXT record so validation does not outlive the relationship it represents.
- Update offboarding for certificate authorities and domains Revoke or replace persistent validation records when domain ownership, CA relationships, or account identifiers change.
Key takeaways
- Persistent DNS validation reduces the need for recurring DNS write access, which changes certificate automation from an access problem into a lifecycle governance problem.
- The practical benefit is narrower standing privilege for domain validation, but only if ownership, scope, and expiry are managed explicitly.
- Teams should align DNS validation records with certificate offboarding and audit processes so trust does not outlive the relationship it represents.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Persistent DNS validation replaces recurring access with durable trust material that must not outlive its scope. |
| NHI-01 — Improper Offboarding | The article's lifecycle question is how to retire validation records when domains or CA relationships change. | |
| Recommendation — Limit persistent validation records to defined domain and CA pairings and revoke them when the relationship ends. Build offboarding steps for persistent validation records into certificate lifecycle procedures. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Validation records function as authenticators in certificate issuance workflows and need lifecycle governance. |
| Recommendation — Apply IA-5 to govern issuance, rotation, and revocation of DNS-based validation artefacts. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The shift from recurring DNS writes to bounded validation changes who needs privileged access. |
| Recommendation — Review entitlements so DNS write access is removed wherever persistent validation replaces it. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Standing DNS write access expands the opportunity to abuse validation-related privileges. |
| Recommendation — Map validation-related privileges to TA0006 and reduce exposed DNS change paths. | ||
Key terms
- Persistent DNS Validation: A domain control validation method that uses a long-lived DNS TXT record to prove authority over a domain for certificate issuance. It reduces the need for repeated DNS changes, but it also turns the validation artefact into a lifecycle object that must be owned, scoped, and revoked.
- Domain Control Validation: Domain Control Validation is the process a certificate authority uses to confirm that a requester can control a domain before issuing a certificate. In practice, it is a governance checkpoint that ties certificate issuance to DNS authority, approval flow, and proof of control rather than to a person’s assertion.
- Certificate Automation: Certificate automation is the use of policy-driven tools to discover, issue, renew, revoke, and report on digital certificates without relying on manual administration. It reduces expiry risk and improves consistency, but it only strengthens security when ownership, key handling, and audit evidence are built into the process.
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org