CAA policy shifts certificate issuance from CA choice to DNS control

At a glance

What this is: This is an analysis of mandatory CAA checking and how it changes certificate issuance governance by pushing authorization into DNS.

Why it matters: It matters because PKI, IAM, and infrastructure teams must now treat certificate issuance policy as an access-control problem, not just a cryptographic one.

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.

👉 Read DigiCert's analysis of mandatory CAA checking and certificate governance

Context

Certificate issuance is an identity control, not just a transport-security step. CAA records let a domain owner specify which certificate authorities may issue a certificate for that domain, which means issuance policy can be enforced at the DNS layer instead of being inferred from CA practice.

That matters for enterprise PKI because certificate authority approval, domain ownership, and operational authority are often split across different teams. When those responsibilities drift apart, certificate issuance becomes a governance problem: who can authorize certificates, who can override policy, and what happens when DNS policy and procurement history disagree.

Key questions

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. The allowed issuer list should match internal PKI policy, change control should cover every CAA update, and delegated domains should be reviewed for label-level exceptions. Without that discipline, DNS policy and certificate authority practice drift apart.

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. CAA adds that missing authorisation step by constraining which CAs can issue for the domain. That separation matters because validation and issuance approval solve different governance problems.

Q: What breaks when certificate policy is not aligned with DNS ownership?

A: Issuance can fail in both directions. An attacker may find a permissive CA path if policy is absent, while legitimate business teams may be blocked if DNS is changed without coordination. The result is either trust abuse or operational interruption, which is why certificate policy needs a named owner.

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.

Technical breakdown

How CAA records control certificate issuance

CAA, or Certification Authority Authorization, is a DNS policy record that tells certificate authorities which issuers are permitted for a domain. Before issuing a certificate, the CA checks the record and compares its own authorization string against the domain policy. If no CAA record exists, or if the listed issuer matches, issuance can proceed. This shifts control from informal CA relationships to explicit, machine-readable authorization. It also means domain policy can narrow which CA may issue wildcard certificates or define reporting behavior. The mechanism is simple, but the governance implication is deeper: issuance is now conditional on DNS truth, not just CA validation practice.

Practical implication: treat CAA as an authoritative issuance policy layer and align it with your internal certificate approval process.

Why FQDN label traversal creates policy complexity

CAA checking does not happen at only one name node. The CA walks labels in the fully qualified domain name until it finds the first CAA record, and that first record controls policy. For names built from multiple labels, such as service or IoT hostnames, the effective policy may be inherited from a higher or lower label depending on what exists in DNS. That makes the policy surface more granular, but also more fragile. If a label has no record, the CA keeps walking. If aliasing or CNAME behavior is involved, implementation ambiguity can appear. The result is that certificate policy can be precise, but only if DNS structure is managed deliberately.

Practical implication: map CAA ownership to DNS hierarchy before rollout, especially where delegated labels, aliases, or IoT naming patterns exist.

Why mandatory CAA does not remove trust assumptions

Mandatory CAA checking improves control, but it does not create perfect verification. The CA still performs a point-in-time check, and the domain operator still depends on the CA to execute that check correctly. The article also notes that a malicious or inattentive DNS operator can stall issuance by setting bad policy or a long TTL, which shows that issuance governance has moved, not disappeared. In practical terms, the control now depends on both DNS administration and CA enforcement discipline. That makes the policy better than optional checking, but not self-validating.

Practical implication: pair CAA policy with monitoring, change control, and certificate issuance testing so DNS errors do not become production outages.

Threat narrative

Attacker objective: The objective is to obtain a publicly trusted certificate that should not have been issued for the target domain.

1. Entry occurs when an attacker or unauthorized requester attempts certificate issuance against multiple certificate authorities for the same domain.
2. Escalation happens if at least one CA accepts the request because policy is absent, inconsistently applied, or not enforced.
3. Impact is unauthorized certificate issuance, which can support impersonation, traffic interception, or trust abuse against the domain.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Identity authority and encryption are not the same control. The post correctly separates proof that a domain can be validated from proof that a specific issuer is allowed to issue. That distinction matters across IAM and PKI because many governance failures happen when authentication or validation is mistaken for authorization. The lesson is that certificate trust depends on both identity verification and issuance authority, and those are separate controls.

DNS becomes the control plane for certificate authorization when CAA is mandatory. The article shows that whoever governs DNS can influence which certificate authorities can issue, including in enterprise acquisition scenarios. That is a classic access-control problem in infrastructure form, because policy expressed in DNS can override years of informal issuance practice. Practitioners should recognise DNS administrators as part of the certificate governance chain, not merely record operators.

CAA exposes an identity policy gap between operational ownership and business authority. Enterprises may think certificate issuance is already covered by procurement, prior arrangements, or CA validation staff, but CAA makes those assumptions visible and enforceable at runtime. The first practical implication is that certificate policy must be tied to current ownership, not legacy relationship memory. The second is that governance teams need a named owner for issuance policy across every domain and delegation path.

7ms per record is not the real question; policy drift is. The article argues that checking overhead is low, which pushes the real debate to policy correctness, label traversal, and operational ownership. That is the right lens for identity governance because most failures come from misalignment between control design and actual administrative structure. Practitioners should focus on whether the policy hierarchy matches how domains are really managed, not just whether the control is fast.

From our research:

• 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.
• That confidence gap makes lifecycle control, issuance authority, and ownership mapping a priority topic in Ultimate Guide to NHIs , Key Challenges and Risks.

What this signals

CAA adoption should be read as part of a broader shift toward treating issuance authority as a governance boundary. For teams operating mixed human, machine, and infrastructure identities, the lesson is that policy controls only work when ownership, change control, and enforcement are aligned across the same administrative chain.

Identity policy drift: when DNS records, certificate approvals, and operational ownership sit in different teams, the control exists on paper but fails in practice. That pattern is especially relevant for organisations with delegated subdomains, acquired business units, or fragmented PKI administration, where the certificate control plane is already split across functions.

Teams that are rationalising machine identity governance should pair certificate policy work with broader NHI lifecycle discipline. A domain can be technically valid and still operationally misgoverned, which is why control effectiveness depends on who can change policy, who can approve issuance, and who can detect drift before a certificate is issued outside bounds.

For practitioners

• 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.
• Monitor for unauthorized policy changes and long TTL abuse Watch for CAA edits that broaden issuer scope or introduce excessive TTLs that could delay correction after a mistaken or malicious update.

Key takeaways

• CAA changes certificate issuance from a permissive default to an explicit policy decision expressed in DNS.
• The operational risk is not the DNS record itself but the gap between who owns domain policy and who actually controls certificate issuance.
• Enterprises need coordinated DNS, PKI, and security governance if they want CAA to reduce trust abuse without creating avoidable outages.

Key terms

• CAA Record: A CAA record is a DNS policy record that tells certificate authorities which issuers may issue certificates for a domain. It does not create trust by itself. Instead, it narrows certificate issuance to the authorities the domain owner has explicitly allowed.
• Certificate Authority Authorization: Certificate Authority Authorization is the practice of using DNS policy to control which certificate authorities can issue certificates for a domain. It adds an authorisation step to certificate lifecycle governance and helps align issuance with current domain ownership and policy.
• FQDN Label Traversal: FQDN label traversal is the process of checking each label in a fully qualified domain name until a CAA record is found. The first record encountered controls policy, which makes DNS hierarchy a practical part of certificate governance.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: New CAA Requirement: What You Should Know. Read the original.