Certificate Authority Authorization, or CAA, is a DNS record that states which certificate authorities are allowed to issue TLS certificates for a domain. Certificate authorities check it before issuing a certificate, so domain owners can limit unauthorised issuance and reduce certificate mis-issue risk.
How CAA works in certificate issuance
CAA is a DNS-based policy signal that tells certificate authorities which issuers may issue TLS certificates for a domain. It does not issue certificates itself, but it changes the issuance decision before a certificate is created.
That makes CAA a control point in the public PKI workflow. When present, a CA is expected to check the record and respect the domain owner’s policy, so the record can narrow who is authorised to mint certificates for the domain.
Why CAA matters for domain trust
CAA exists to reduce the chance of unauthorised or accidental certificate issuance. If the wrong CA can issue a valid certificate for a domain, attackers may use that certificate to support phishing, traffic interception, or impersonation that looks legitimate to users and systems.
For domains that depend on TLS for customer trust, this is not a cosmetic setting. It is part of the domain’s trust boundary, because it influences who can create cryptographic proof that the domain is genuine.
Where CAA fits in PKI and DNS governance
CAA sits at the intersection of DNS administration and PKI governance. It is typically managed alongside certificate inventory, renewal processes, and CA selection rules, because the record only helps when it matches the organisation’s real issuance model.
It also complements other PKI controls such as certificate lifecycle management, issuance policy, and trust-store decisions. A domain owner still needs visibility into which certificates exist, which CAs are approved, and whether the record covers the domains and subdomains that matter.
For background on the surrounding PKI mechanics, see PKI Basics Guide and CA/Browser Forum, which define the baseline issuance ecosystem that CAA influences.
Operational mistakes that weaken CAA
CAA only helps when it is kept in sync with the organisation’s actual certificate strategy. A common failure is allowing drift between DNS policy and procurement reality, such as adding new certificate providers without updating the record.
Another failure is assuming CAA is a complete certificate-control strategy. It is a policy guardrail, not a substitute for private-key protection, certificate monitoring, or revocation readiness. For operational guidance on certificate lifecycle and renewal risk, see Machine Identity, PKI and Certificate Lifecycle Guide.
Risk and Threat Considerations
CAA reduces certificate mis-issue risk, but it does not eliminate it. If the record is missing, stale, or incomplete, a domain may be more exposed to unauthorised issuance, which can enable impersonation or abuse of trust in TLS-enabled services.
Failure mechanism: An attacker or mistaken issuance path succeeds because the authoritative DNS policy either does not restrict issuers tightly enough or does not cover the relevant domain scope.
Impact: A certificate may be issued by an unexpected CA, creating a path to phishing, service impersonation, or loss of confidence in the domain’s TLS identity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | 3 — Key Management Concepts and Principles | CAA governs who may obtain certificates tied to the domain's trust and key lifecycle. |
| Recommendation — Align certificate issuance policy with cryptoperiod and lifecycle controls for domain keys and certificates. | ||
| NIST SP 800-53 Rev 5 | SC-12 — Cryptographic Key Establishment and Management | CAA supports control over certificate issuance paths that depend on managed cryptographic trust. |
| IA-5 — Authenticator Management | CAA helps constrain issuance of TLS credentials that act as authenticators for domains and services. | |
| Recommendation — Use SC-12 to govern certificate issuance trust paths and related key management dependencies. Apply IA-5 to manage certificate issuance, renewal, and replacement for authenticating systems. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | CAA relates to controlling the issuance of authentication material used in TLS trust. |
| A.8.24 — Use of cryptography | CAA is part of governing certificate trust and issuance within cryptographic operations. | |
| Recommendation — Define issuance rules for certificates as controlled authentication information. Document certificate issuance constraints within cryptographic usage and trust controls. | ||
Practitioner Guidance
Why practitioners should care: Treat CAA as part of issuance governance, not as a one-time DNS hardening task. The record should reflect the live CA set used for production, staging, automation, and emergency reissue workflows.
What to watch for: Review whether subdomains inherit the policy you intend, because gaps often appear when teams add new services faster than DNS and certificate governance can keep up. A practical operating model pairs CAA with certificate inventory and renewal visibility, and with clear ownership for who may approve new issuers.
For a broader view of issuance control and certificate operations, Private CA Design and Operations Guide is a useful companion reference.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org