Domain Control Validation at Scale: Persistent DCV and ACME

Certificate lifecycle management is becoming more automated, while domain validation is becoming more stringent. As organizations prepare for shorter certificate lifetimes and more frequent renewals, Domain Control Validation is emerging as one of the most important operational challenges in public key infrastructure (PKI).

The CA/Browser Forum has begun reducing how long domain and IP validation data can be reused. As of March 15, 2026, the maximum reuse period dropped from 398 days to 200 days, and it falls again to 100 days in 2027 and 10 days in 2029. In parallel, the industry continues moving toward shorter certificate validity periods, which increases the frequency of issuance and renewal. Together, these changes mean organizations can no longer rely on occasional, manual validation.

Persistent DCV, DNS automation, and ACME-based certificate management provide a scalable path forward. Implemented well, they reduce operational overhead, improve renewal reliability, and help organizations stay compliant as PKI requirements evolve. This guide explains how domain validation is changing, what Persistent DCV actually does, and how to build a validation model that holds up at enterprise scale.

Quick Answer: What Is Domain Control Validation and Why Is Automation Now Essential?

Domain Control Validation (DCV) is the mechanism Certificate Authorities use to verify that a certificate applicant controls the domain before issuing a TLS certificate. CA/Browser Forum Ballot SC-081v3 (April 2025) reduces DCV reuse from 398 days to 10 days by March 2029, running in parallel with certificate validity reductions to 47 days. At that combined cadence, manual DCV is operationally unviable and automated DNS-based validation with ACME is the only sustainable path.

Key Takeaways

• CA/Browser Forum Ballot SC-081v3 (April 2025) reduces domain validation reuse from 398 days to 10 days by March 2029 in three phases, running in parallel with TLS certificate validity reductions to 47 days by the same date. Both changes must be addressed together: a certificate renewal automation strategy without DCV automation will fail at the CA challenge step when the validation authorization expires.
• According to DigiCert’s Trust Pulse Survey (July 2, 2025), nearly half of all enterprises experienced certificate-related downtime in the past year. A stale DNS validation record can silently block every certificate renewal that depends on it, converting a DCV gap into a certificate expiry outage without any explicit failure signal until the service goes offline.
• Ballot SC-088v3 (adopted November 2025) added Persistent DCV as a new method: “DNS TXT Record with Persistent Value” (Baseline Requirements section 3.2.2.4.22). It allows a domain owner to place an account-scoped DNS TXT record once and reuse it across multiple certificate issuances, eliminating the need to create a fresh validation token for every renewal. CA adoption varies; the underlying IETF specification remains a draft.
• ACME (RFC 8555), DNS-01 challenge automation, and Persistent DCV together form the scalable DCV operating model for the 47-day/10-day world: the persistent record is placed once, DNS automation maintains it via provider APIs, and ACME drives validation and renewal on a schedule without human intervention.
• NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. Organizations building automated DCV and certificate issuance pipelines today should design for algorithm agility so that ACME workflows can adopt quantum-safe certificates without pipeline redesign when CA adoption of PQC algorithms advances.

Who Should Care About DCV Automation at Enterprise Scale

Domain validation automation is a cross-functional operational challenge. Every role below has a direct stake in whether the organization’s DCV infrastructure can scale to the March 2027 and March 2029 enforcement deadlines.

Role	Why It Matters	Action Item
PKI Admins	Own the DCV method selection, ACME client configuration, CA account setup, and validation record lifecycle; responsible for ensuring DCV authorizations do not expire and block certificate renewals	Audit all domains for current DCV method and authorization expiry status using CertSecure Manager; configure ACME DNS-01 automation for all domains before the March 2027 100-day reuse deadline; evaluate SC-088v3 Persistent DCV availability with each CA in scope
DNS Admins	Own the API integration between the certificate management platform and the DNS provider; responsible for zone delegation for automated validation records and DNS API credential management	Configure DNS provider API access for all zones where validation records will be placed; test ACME DNS-01 challenge completion end-to-end before production deployment; confirm DNSSEC is configured per SC-085v2 requirements where applicable
Platform / DevOps Teams	Own the ACME client configuration on TLS-serving systems and the certificate enrollment pipeline; most likely to encounter outages when failed DCV authorizations block automated certificate renewal	Audit all TLS endpoints for ACME DNS-01 client configuration; integrate ACME renewal with CI/CD pipelines for containerized and cloud-native workloads; test renewal end-to-end including DCV challenge completion before relying on automation for production certificates
Compliance Teams	Must demonstrate that DCV frequency meets CA/Browser Forum Baseline Requirements on the current reuse schedule; the transition to 10-day reuse by March 2029 creates a compliance evidence requirement for near-continuous DCV refresh	Include DCV authorization expiry dates in quarterly audit scope alongside certificate expiry dates; document the DCV automation implementation as a formal control; confirm CA/Browser Forum policy compliance for each DCV method in use
CISOs	Own the risk posture for DCV automation gaps that convert to certificate expiry outages at scale; as renewal frequency increases, the blast radius of a failed DCV automation scales proportionally	Require DCV automation to be included in PKI health assessments; fund CLM tooling for unified certificate and DCV authorization monitoring; include DCV automation readiness in enterprise PKI resilience reporting

Understanding Domain Control Validation

Domain Control Validation is the mechanism that prevents an unauthorized party from obtaining a certificate for a domain it does not own or manage. A Certificate Authority requires proof of control before it issues a certificate, and that proof is the foundation of trust in public PKI.

Several validation methods exist, the most common being DNS-based validation and HTTP-based validation. Email-based and phone-based methods also exist, but the CA/Browser Forum is phasing them out. Among the remaining options, DNS-based validation has become the preferred method for automation because it integrates cleanly with modern certificate workflows and supports large environments with minimal human involvement.

Historically, domain validation happened infrequently because certificate lifetimes were long. As renewal cycles shorten, validation shifts from an occasional event to a recurring operational function that must scale across hundreds or thousands of domains.

Why Domain Validation Reuse Is Tightening

The CA/Browser Forum’s Baseline Requirements are reducing how long domain and IP validation data can be reused. Under Ballot SC-081v3, approved in April 2025, the reuse period steps down on a fixed schedule.

Effective Date	Maximum DCV Reuse Period	Concurrent Max Certificate Validity	Renewals Per Year (Per Domain)
Until March 14, 2026	398 days	398 days	~1
From March 15, 2026	200 days	200 days	~2
From March 15, 2027	100 days	100 days	~4
From March 15, 2029	10 days	47 days	~8 (cert) / ~37 (DCV)

Source: CA/Browser Forum Ballot SC-081v3 (April 2025). The 2029 row reveals the most important operational implication: by March 2029, domain validation must be refreshed approximately every 10 days, meaning up to 37 DCV refresh cycles per domain per year even if certificate renewal only occurs every 47 days. At that cadence, DCV automation is not optional.

The rationale is straightforward. Validation data that was accurate six months ago may no longer reflect current domain ownership. Shorter reuse periods mean that Certificate Authorities must verify control more recently before each issuance, which directly reduces the risk of certificates being issued to parties that no longer legitimately control a domain.

Because certificate validity is shrinking at the same time, organizations face a compounding effect. Not only must each individual certificate be renewed more often, but the validation behind each renewal must also be refreshed on a shorter cycle. For large enterprises managing thousands of certificates, this creates substantial operational pressure. Organizations exploring how 47-day certificate lifetimes affect automation can see why Domain Control Validation strategy has become a critical priority alongside renewal automation.

Why Shorter Certificate Lifetimes Change Everything

For years, certificate operations centered on expiration monitoring. Teams tracked upcoming renewal dates and acted before certificates expired. Domain Control Validation was a one-time event tied to issuance, and the validation record remained usable for long enough that it rarely needed to be refreshed before a renewal.

As certificate lifetimes fall, organizations must revalidate domains much more frequently. A certificate renewed every 47 days requires a corresponding validation refresh on a similar cadence. That volume cannot be absorbed by manual processes. Each validation step requires a DNS record placement, a CA challenge, and a lifecycle event. Doing this by hand across hundreds of domains is not sustainable.

This is why Domain Control Validation has become central to certificate management complexity. The operational discipline required to keep validation current is now inseparable from the discipline required to keep certificates renewed. Organizations that address only one side of this equation tend to encounter outages on the other.

What Persistent DCV Is

Persistent Domain Control Validation is a DNS-based approach that reduces repeated validation work while preserving strong assurance of domain ownership. Because it is DNS-based rather than HTTP-based, it also supports the use cases that depend on the DNS-01 challenge, such as wildcard certificates, which cannot be validated over HTTP.

The CA/Browser Forum’s Ballot SC-088v3 added a new method, “DNS TXT Record with Persistent Value,” as section 3.2.2.4.22 of the Baseline Requirements for TLS Server Certificates. It lets a domain owner establish an account-scoped DNS TXT record that can be reused across multiple certificate issuances, removing the need to create a fresh validation record for every renewal while maintaining security equivalent to existing DNS-based methods. Certificate Authorities have been able to use the method since November 11, 2025, and implementation is at each CA’s discretion. Adoption is still early: the underlying IETF specification remains a draft and most Certificate Authorities are still moving the method toward production, so availability varies by provider.

Persistent DCV should not be mistaken for a permanent exemption from periodic revalidation. The Baseline Requirements still cap how long any completed validation can be reused, and that cap is shrinking on the schedule above. What Persistent DCV changes is the operational pattern. The validation record stays in place under the domain owner’s control, so the Certificate Authority can re-confirm control against the same record on each cycle without anyone manually creating a new token. That is what makes frequent revalidation sustainable.

Area	Traditional DCV	Persistent DCV (SC-088v3)
Validation record	A new record is created for each issuance cycle	An account-scoped record is placed once and reused across issuances
Operational effort	Frequent DNS updates and validation actions required for each renewal	Reduced ongoing validation workload once the persistent record is placed
Scalability	Hard to manage across large domain inventories at high renewal frequency	Better suited to enterprise-scale estates; designed for the 47-day/10-day world
Automation support	Often requires recurring manual intervention or complex per-renewal automation	Designed for automated renewal workflows; pairs naturally with ACME DNS-01
Wildcard certificate support	DNS-based only; HTTP-based cannot validate wildcards	DNS-based only; supports wildcard certificates natively
CA availability	All CAs supporting DNS-01 method	Varies by CA; most still moving to production as of 2026; IETF spec in draft
Risk of human error	Higher, due to repeated manual DNS actions per renewal cycle	Lower once correctly implemented; single DNS action per CA account

DNS Automation: The Missing Piece

Persistent validation becomes far more valuable when paired with DNS automation. Modern workflows rely on DNS-based challenges, such as creating TXT records in specific validation zones, and without automation those changes require coordination among PKI teams, DNS administrators, infrastructure teams, and change management.

DNS automation removes those dependencies by letting certificate management platforms and ACME clients interact directly with DNS providers through APIs. In practice, this removes manual DNS changes, reduces human error, prevents renewal delays, clears change-management bottlenecks, and cuts cross-team coordination overhead. For organizations spanning multiple DNS providers, cloud environments, and business units, these gains compound. The combination of non-human identity management and DNS automation is increasingly central to scalable certificate operations. CertSecure Manager provides the unified platform that connects certificate renewal workflows with DNS provider APIs, ACME-based validation, and lifecycle monitoring across cloud, on-premises, and hybrid environments from a single management plane.

ACME: The Foundation of Certificate Automation

Automatic Certificate Management Environment (ACME), defined in RFC 8555, is the standard protocol for automated certificate issuance and renewal. ACME lets a client communicate directly with a Certificate Authority, complete validation challenges, request certificates, and renew them without manual steps. Learn more in the ACME protocol overview.

As validity periods shrink, ACME is evolving from a convenience into a foundational PKI requirement. Organizations that still depend on manual requests, approvals, and installation will struggle to sustain frequent renewal cycles, because the work simply recurs too often. ACME addresses this by automating the entire flow, from validation through issuance, renewal, and deployment. The broader trajectory of the certificate lifecycle evolution shows how ACME has shifted from optional to essential.

Combined with Persistent DCV and DNS automation, ACME creates a highly scalable model. The persistent record is placed once, DNS automation maintains it through provider APIs, and ACME drives validation and renewal on a schedule, so the estate keeps pace with short lifetimes without manual intervention. For organizations deploying PKI as a Service, ACME is the enrollment protocol that connects the managed CA infrastructure to ACME clients on TLS-serving systems.

As cryptographic standards evolve, post-quantum algorithms defined in FIPS 203, FIPS 204, and FIPS 205 will eventually affect certificate issuance workflows. Organizations building scalable DCV infrastructure today should account for algorithm agility so that automated pipelines can adopt quantum-safe algorithms without redesign when CA adoption advances. Begin PQC readiness planning via the PQC Readiness assessment and the PQC Center of Excellence.

DCV Failure Modes, Monitoring Signals, and Responsible Owners

Use this table to map DCV operational requirements to their validation method, common failure mode, monitoring signal, governing source, and owner. Each row represents a distinct failure pattern that organizations must monitor to prevent certificate expiry outages caused by DCV gaps.

Requirement	Validation Method	Common Failure Mode	Monitoring Signal	Source / Policy	Owner
DCV authorization within reuse window	DNS-01 or HTTP-01; Persistent DCV (SC-088v3) where CA supports it	Authorization expires before renewal is triggered; CA rejects renewal with authorization-expired error; certificate fails to renew silently until expiry	CLM platform alert when DCV authorization expiry is within 30% of the applicable reuse window; ACME challenge failure event logged	CA/Browser Forum Ballot SC-081v3; Baseline Requirements Section 3.2.2.4	PKI Admin
DNS TXT record present and correct	DNS-01 ACME challenge; Persistent DCV (SC-088v3)	DNS record deleted, TTL expired and not refreshed, or incorrect token value placed in wrong zone or subdomain; CA challenge fails with DNS lookup error	DNS API health check confirming TXT record presence and correct content before each renewal trigger; ACME challenge failure alert	RFC 8555 (ACME); CA/Browser Forum Ballot SC-088v3	DNS Admin / PKI Admin
ACME client reachable and configured	ACME DNS-01 or HTTP-01	ACME client misconfigured, CA endpoint unreachable, or rate limit exceeded; renewal fails silently with no alert if CLM monitoring is not in place	ACME renewal success/failure rate monitoring per domain; CA reachability check from ACME client network; rate limit tracking per CA account	RFC 8555 (ACME); CA-specific rate limit policies	Platform / DevOps Team
Wildcard certificate DCV	DNS-01 only; HTTP-01 cannot validate wildcards	Organization attempts HTTP-01 for a wildcard certificate; CA rejects challenge; wildcard certificate cannot be renewed	Certificate type audit in CLM identifying all wildcard certificates; confirm DNS-01 is configured as the challenge method for each	CA/Browser Forum Baseline Requirements; RFC 8555	PKI Admin
DNSSEC validation for CAA/DCV lookups	DNS-01; CAA record lookup	DNS-based attack against DCV lookup because DNSSEC is present but not enforced by the CA; SC-085v2 non-compliance	DNSSEC validation status check for all zones where validation records are placed; CA compliance confirmation that SC-085v2 is enforced	CA/Browser Forum Ballot SC-085v2 (requires DNSSEC validation for CAA and DCV lookups when DNSSEC is present)	DNS Admin / Compliance Team
Domain ownership change without DCV update	All DCV methods	Domain transferred or delegated to another party; existing DCV authorization remains in CA’s record; new owner’s certificate may be blocked or orphaned authorization creates false trust	Domain ownership change events tracked in CLM; DCV authorization audit confirming current DNS zone owner matches certificate subscriber	CA/Browser Forum Baseline Requirements; RFC 5280	PKI Admin / Compliance Team

Why Certificate Operations Break at Scale

Most certificate incidents are not caused by cryptographic failures. They result from operational complexity. At small scale, manual validation can feel manageable. At enterprise scale, multiple teams, DNS zones, cloud providers, applications, and certificate authorities form a web of dependencies that is difficult to coordinate by hand. For example, a single stale DNS validation record can silently block every renewal that relies on it, so a certificate quietly fails to renew and the service it protects goes offline until someone traces the outage back to that one record.

The recurring failure modes are familiar: expired validation authorizations, missing or incorrect DNS records, failed renewals, unclear certificate ownership, disconnected automation workflows, and inconsistent validation policies across teams. As certificate lifetimes shorten, these problems occur more often and cause more disruption. Organizations that treat validation as a standalone task usually discover that the deeper challenge is governance over domain and certificate ownership, visibility into validation status and expiration across the estate, and lifecycle coordination across teams and systems. For complete cryptographic visibility across all domains and CA sources, CBOM Secure builds a Cryptographic Bill of Materials that surfaces certificate lineage, DCV method coverage, and CA source data across cloud, on-premises, and hybrid environments.

Security Considerations for DCV at Enterprise Scale

A common operational mistake is assuming validation records remain usable indefinitely. Reuse periods are governed by CA policy and are shrinking, so they must be monitored. Another is inserting a manual DNS step into an otherwise automated workflow, where a single missed update can block issuance and cause an outage. A third is separating certificate lifecycle management from validation management, which creates blind spots where teams can see expiration dates but cannot track validation status, ownership, or automation health.

To reduce operational risk, the most resilient programs standardize DNS-based validation wherever possible, since it automates more cleanly than other methods. They automate validation workflows using DNS provider APIs and ACME so that revalidation does not depend on manual action. They maintain centralized visibility into certificate inventories and validation status, not just expiration dates, and define clear ownership for domains, DNS zones, and certificate operations.

Private keys should be protected using secure key management and Hardware Security Modules (HSMs) where appropriate, ideally validated to FIPS 140-3 Level 3. Validation workflows should also be reviewed regularly as CA and browser requirements continue to evolve.

The most successful programs treat Domain Control Validation as an ongoing operational process rather than a one-time issuance step. Ballot SC-085v2 further strengthens the security posture by requiring DNSSEC validation for CAA and DCV lookups when DNSSEC is present, reducing the risk of DNS-based attacks against the validation process itself. The risks of mismanaged certificates show how quickly these gaps translate into real outages and compliance failures.

How Encryption Consulting Can Help

Managing domain validation at scale takes more than automation alone. Organizations need governance, visibility, and lifecycle control across the entire certificate ecosystem. Encryption Consulting helps design and implement scalable certificate management strategies that align with evolving CA/Browser Forum requirements and modern PKI practice.

Through Enterprise PKI Services, organizations can build validation architectures, establish governance frameworks, and design scalable lifecycle processes across business units, cloud environments, and DNS providers. For organizations evaluating PKI as a Service alongside DCV automation, EC’s managed PKI infrastructure provides native ACME support with DNS-01 challenge automation built in, removing the integration engineering effort required to connect a self-managed CA to DNS provider APIs.

For centralized visibility and automation, CertSecure Manager provides a unified platform for certificate discovery, inventory management, lifecycle monitoring, validation tracking, and renewal orchestration. By connecting certificate workflows with DNS automation and ACME-based processes, it reduces operational complexity while improving compliance and reliability. CBOM Secure complements this by building a Cryptographic Bill of Materials that provides domain-level and CA-source visibility across the full certificate estate, ensuring no domain’s DCV authorization goes untracked as reuse windows shrink.

EC’s Encryption Advisory Services help teams evaluate Persistent DCV strategies, optimize validation workflows, implement DNS automation, and plan post-quantum migration through cryptographic discovery, CBOM assessments, and quantum-safe readiness planning via the PQC Readiness assessment and the PQC Center of Excellence, without disrupting operations.

Conclusion

Domain Control Validation is becoming one of the most critical operational components of modern PKI. As reuse periods shrink and certificate lifetimes shorten, organizations must rethink how they validate domains at scale.

Persistent DCV provides a more sustainable validation model, DNS automation reduces operational friction, and ACME delivers the automation needed to support frequent renewals. Together, they let organizations move beyond reactive certificate management toward a scalable, resilient lifecycle program.

The practical starting point is visibility and ownership: know every domain and certificate you manage, confirm how each one is validated, and identify where manual DNS steps still sit inside otherwise automated workflows. From there, persistent records, DNS APIs, and ACME can close the gaps. To assess your Domain Control Validation architecture and plan the work, contact Encryption Consulting.

Frequently Asked Questions

What is the main takeaway from Domain Control Validation at Scale: Persistent DCV and ACME?

CA/Browser Forum Ballot SC-081v3 (April 2025) reduces domain validation reuse from 398 days to 10 days by March 2029, running in parallel with certificate validity reductions to 47 days. Both changes must be addressed together: a certificate renewal automation strategy without DCV automation will fail at the CA challenge step when the validation authorization expires. Persistent DCV (SC-088v3), DNS API automation, and ACME-based certificate management provide the scalable, automated path forward.

Why does domain validation automation matter for enterprise PKI teams?

Enterprise PKI teams are responsible for both certificate renewal and the domain validation that must accompany each renewal. As certificate validity shrinks to 47 days and domain validation reuse shrinks to 10 days, both must be refreshed roughly eight or more times per year per domain. According to DigiCert’s Trust Pulse Survey (July 2, 2025), nearly half of enterprises experienced certificate-related downtime in the past year. A stale DNS validation record can silently block every certificate renewal that depends on it, converting a DCV gap into a certificate expiry outage without any explicit failure signal until the service goes offline.

What risks increase if domain control validation is handled manually?

Manual DCV management increases the risk of: expired validation authorizations blocking certificate renewal without explicit warning; missed manual DNS TXT record creation causing failed ACME challenges and unrenewed certificates; human error in DNS record content causing CA challenge failures; and cross-team coordination failures between PKI, DNS, and infrastructure teams creating renewal delays when change windows are not aligned with the certificate renewal deadline.

Which teams should own domain control validation automation?

PKI admins own the DCV method selection, ACME client configuration, CA account setup, and validation record lifecycle. DNS admins own the API integration between the CLM platform and the DNS provider. Platform and DevOps teams own the ACME client configuration on TLS-serving systems. Compliance teams own the audit evidence confirming DCV frequency meets CA/Browser Forum Baseline Requirements. CISOs own the risk posture for DCV automation gaps that convert to certificate expiry outages at scale.

How does domain control validation connect to certificate lifecycle management?

Domain validation is the prerequisite for certificate issuance. CLM platforms that track expiry dates without also tracking DCV authorization expiry create a blind spot: a certificate may be scheduled for renewal but the underlying domain validation may already be expired, causing the renewal to fail at the CA challenge step. CertSecure Manager connects certificate renewal workflows with DNS automation and ACME-based validation, so that validation status, authorization expiry, and certificate expiry are tracked and triggered together in a single automated lifecycle.

How should organizations measure success for domain validation automation?

Key metrics: percentage of certificate renewals completed without manual DNS intervention (target: 100% via ACME DNS-01 automation); number of certificate expiry outages caused by failed or expired DCV (target: zero); mean time from ACME renewal trigger to deployed renewed certificate (target: under 1 hour, fully automated); percentage of domains using Persistent DCV (SC-088v3) where the CA supports it (target: 100% of supported domains); and percentage of DCV authorization records confirmed current within the applicable reuse window (target: 100% at all times via CertSecure Manager monitoring).

What should be audited or monitored regularly for domain control validation?

Monitor continuously: DCV authorization expiry dates alongside certificate expiry dates; ACME challenge success and failure rates per domain; DNS TXT record presence and correct content for all active validation records; and ACME renewal pipeline health including CA reachability and DNS API connectivity. Audit quarterly: confirmation that all DCV authorizations are within the applicable reuse window; SC-088v3 Persistent DCV adoption status where CAs support it; and CA/Browser Forum policy updates for any new DCV method deprecations or reuse period changes.

How does domain validation automation affect cloud, hybrid, or multi-CA PKI environments?

In cloud and hybrid environments, DCV must work across multiple DNS providers (Route 53, Cloudflare, Azure DNS, GCP Cloud DNS), multiple CA accounts, and multiple certificate management platforms. ACME DNS-01 automation requires API integration with each DNS provider in scope; organizations with multiple DNS providers need a CLM platform supporting all of them from a single management plane. In multi-CA environments, each CA may have different DCV method support and Persistent DCV availability, requiring per-CA configuration. CBOM Secure provides the cross-environment cryptographic inventory visibility needed to track DCV coverage across all CA sources.

What common mistakes should teams avoid with domain control validation?

The most common mistakes: inserting a manual DNS step into an otherwise automated renewal workflow (a single missed update can block every renewal for that domain); separating certificate lifecycle monitoring from DCV authorization monitoring; confusing Persistent DCV with a permanent exemption from periodic revalidation (the Baseline Requirements still cap reuse periods, and those caps are shrinking); and not testing ACME DNS-01 challenge completion end-to-end before relying on it for production certificate renewal.

What prerequisites are required before implementing Persistent DCV and ACME automation?

Prerequisites include: a complete certificate and domain inventory using CBOM Secure or CertSecure Manager to identify all domains requiring DCV and all certificates needing automated renewal; DNS provider API credentials for all zones where validation records will be placed; confirmation that the chosen CA supports SC-088v3 Persistent DCV; ACME client software configured on all TLS-serving systems; and a CA account with ACME access and DNS-01 challenge support tested before production deployment.

What should be refreshed quarterly for domain validation governance?

Refresh quarterly: DCV authorization expiry audit confirming all authorizations are within the current applicable reuse window; CA/Browser Forum policy review for new DCV method deprecations or reuse period changes; ACME pipeline health review confirming DNS API connectivity, CA reachability, and challenge completion success rates; PQC readiness review via the PQC Center of Excellence for NIST FIPS 203, 204, and 205 migration planning; and CertSecure Manager inventory review confirming certificate and domain ownership records are current.