DigiCert’s 4 November 2026 update extends UltraDNS automatic domain validation to multiple organizations in one CertCentral account. Each organization still receives separate validation.
For certificate operators, this is a good time to review two parts of the runbook: which organizations a domain is assigned to, and what each automated request asks the service to do. Treat those as separate acceptance checks.
Keep validation evidence tied to its organization
The assignment guide requires a linked UltraDNS account, a CertCentral Administrator and permission to manage the relevant UltraDNS domains. Domains are assigned one organization at a time. The guide recommends testing with one domain first; assigned domains initially show pending validation, with the first automatic validation at the top of the hour.
A useful local record is a row per domain and organization, with an owner, expected result and the evidence that confirms it. Do not close a rollout ticket merely because one row succeeded. Decide who investigates a pending or failed row before expanding the batch.
Automatic validation has product boundaries
DigiCert’s UltraDNS overview describes adding the required DNS TXT record, removing it after validation, and repeating validation every seven days. Only imported, automated domains are covered. DV TLS orders still need fresh validation for each order; they cannot reuse this prevalidation. If the integration option is absent, DigiCert directs customers to their account manager or support for enablement.
Prepare for the separate 12 November API change
The same change log schedules enforcement of account DCV-method restrictions for Services API requests no earlier than 12 November 2026, 14:00 UTC. Explicitly disallowed dcv_method values will produce invalid_value for order/add-domain requests or dcv_method_not_allowed for method changes. Where the parameter is optional, omission still uses the configured default.
Our proposed pre-change review
- Inventory the request builders and their owners. Capture sanitized examples of what each actually sends; never put API keys or DNS credentials in a ticket.
- Document the intended account policy before editing anything. Resolve mismatches with the integration owner rather than enabling every method to make an error disappear.
- Give policy rejection its own alert and escalation route. An unchanged retry is not a substitute for understanding a rejected request.
- Use an approved low-risk test case, record the expected outcome, and define how to recover from a partial rollout. Check the resulting certificate workflow, not just the HTTP response.
These are proposed operational checks, not deployment-test results. We have not changed an account, DNS records or API settings, and have not tested the scheduled enforcement.