Notifications
Clear all
Topic starter
25/06/2026 10:36 pm
TL;DR: Mandatory CAA checking moves certificate issuance policy from ad hoc CA practice into DNS-controlled authorization, reducing the number of CAs that can issue for a domain and tightening control over wildcard and enterprise issuance, according to DigiCert. The governance issue is not encryption strength but who is allowed to request a certificate, and that assumption now sits in DNS policy.
NHIMG editorial — based on content published by DigiCert: New CAA Requirement: What You Should Know
By the numbers:
- The push for CAA record checking was driven by the increasing number of entities embedding roots in the browser, with over 60 entities currently operating embedded roots.
Questions worth separating out
Q: How should security teams govern certificate issuance with CAA records?
A: Security teams should treat CAA as part of their issuance approval model, not a standalone DNS setting.
Q: Why do CAA records matter when organisations already validate domain ownership?
A: Domain validation proves control of the name, but it does not prove that a particular certificate authority is authorised to issue.
Q: What breaks when certificate policy is not aligned with DNS ownership?
A: Issuance can fail in both directions.
Practitioner guidance
- Inventory all certificate-issuing domains and label owners Document which teams own each domain, delegated subdomain, and CAA policy record so certificate authority authorization can be mapped to real administrative responsibility.
- Align CAA records with internal approval workflows Ensure the CAA issuer list matches the CAs already approved by procurement, security, and PKI operations, including wildcard issuance rules and reporting contacts.
- Test issuance paths across nested DNS labels Validate how CAA behaves at each FQDN label, including delegated subdomains and CNAME-linked names, before you depend on it for enforcement.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- The CA/B Forum background on why mandatory CAA checking was debated and eventually adopted
- The DNS label-by-label lookup process that determines which CAA record controls issuance
- The implementation concerns around CNAME aliasing, retry behaviour, and CA software support
- The enterprise examples showing how CAA can affect acquisitions, internal PKI policy, and certificate procurement
👉 Read DigiCert's analysis of mandatory CAA checking and certificate governance →
CAA records and certificate issuance: what changes for PKI teams?
Explore further
25/06/2026 11:12 pm
CAA turns certificate issuance into a governance control, not a provider preference. The article’s core point is that a domain owner can express explicit authorization for certificate issuance in DNS, which means the trust decision moves from informal CA relationships into enforceable policy. That matters because PKI teams often manage certificates as a technical necessity while leaving issuance authority diffuse. Practitioners should treat CAA as a policy boundary for identity issuance, not as a cosmetic DNS record.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: Who should be accountable for CAA failures in enterprise PKI?
A: Accountability should be shared between the PKI team that defines issuance policy and the DNS administrators who implement it, but the security organisation should own the control objective. If a certificate is issued outside policy, both the DNS record and the CA enforcement path need review under the same governance process.
👉 Read our full editorial: CAA policy shifts certificate issuance from CA choice to DNS control
