Certificate Authority Authorization is a control that says which public certificate authorities are allowed to issue certificates for a domain. In practice, DNS records publish this policy so domain owners can reduce unauthorized certificate issuance and improve trust management across web, email, and other encrypted services.
What Certificate Authority Authorization Actually Controls
Certificate Authority Authorization is a domain-level policy for deciding which public certificate authorities may issue certificates for a name. That makes it a control over trust delegation, not just a DNS record, because it limits who can create publicly trusted TLS certificates for the domain.
The practical value is that domain owners can narrow the issuance path before a certificate is minted. When this policy is set correctly, it reduces the chance that an unexpected or unauthorised CA can issue a certificate that browsers, mail systems, or other relying parties would otherwise accept.
How It Works In The Public PKI
CAA is published in DNS and evaluated by certificate authorities during issuance checks. If a CA sees a restrictive policy, it is expected to stop and verify whether it is permitted to issue for that domain before completing the request.
Because it is enforced at issuance time, CAA is best understood as a preventive control in the public PKI lifecycle. It does not replace DNS security, domain ownership checks, or certificate monitoring, but it does add a policy signal that helps constrain certificate issuance to approved providers.
This matters most where multiple services depend on the same domain, especially HTTPS and email. A clear issuance policy helps keep certificate trust aligned with the owner’s approved CA relationships rather than with whatever CA a third party may try to use.
Why Certificate Authority Authorization Matters For Trust Management
CAA helps reduce certificate sprawl and unplanned trust relationships. In organisations with many properties, subdomains, or service teams, the issue is often not whether a certificate exists, but whether its issuer is expected, approved, and visible to the people who own the domain.
That control becomes more important as certificate automation increases. Automated issuance can be safe, but only when the policy layer still reflects the organisation’s real trust boundaries and approved certificate authority set. Machine Identity, PKI and Certificate Lifecycle Guide is useful background for the lifecycle side of that problem.
CAA is also a governance signal. It tells operators, auditors, and security teams which issuers are intended to represent the domain publicly, which is useful when certificate usage spans web services, API endpoints, mail infrastructure, and other externally trusted systems.
Operational Checks And Validation Points
To use CAA well, organisations need an accurate view of the domains they control and the certificate authorities they have actually approved. The first check is simple: know which DNS zones are authoritative, which subdomains inherit policy, and whether the CA list matches current procurement and platform reality.
The second check is visibility into real issuance paths. A policy is only useful if domain owners can compare it with certificate transparency logs, vendor issuance records, and internal service inventories to confirm that issuance is happening through the expected channels.
The third check is change control. If a team adds a new CA for automation, migration, or regional hosting, the policy should be updated in step with that decision so the DNS policy and the operational reality do not diverge.
When CAA Is Not Enough By Itself
CAA reduces unauthorized issuance risk, but it does not eliminate it. A misconfigured policy, a stale record, an overlooked delegated subdomain, or a weak monitoring process can all leave gaps even when the DNS record looks correct.
It also does not solve the broader compromise problem. If an attacker already controls DNS, a registrar account, or a certificate request workflow, CAA may be bypassed in practice through operational weakness rather than through the policy itself. For that reason, CAA should be paired with strong account protection, issuance monitoring, and certificate lifecycle controls.
For a wider view of the trust and key-management side of certificate handling, NIST SP 800-57 Key Management is a useful companion reference, and CA/Browser Forum defines the baseline requirements that shape public certificate issuance and revocation.
Risk and Threat Considerations
The main risk is unwanted trust delegation. If a domain’s CAA policy is absent, stale, or incomplete, a certificate may be issued by a CA the owner did not intend to use, which can widen the attack surface for impersonation, phishing, and trust abuse.
Failure mechanism: Attackers, misconfigured automation, or accidental approvals exploit gaps between the intended CA list and the actual DNS policy, then obtain or misuse a publicly trusted certificate that appears legitimate to clients.
Impact: The result can be domain impersonation, harder-to-detect man-in-the-middle opportunities, and trust confusion across web and email services, especially when monitoring does not promptly flag unexpected issuance.
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, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | 4.1 — Key Lifecycle Management | CAA supports control of certificate issuance within the broader key and certificate lifecycle. |
| Recommendation — Align certificate issuance policy with key lifecycle controls and review approved issuers as part of renewal governance. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | CAA governs who may issue certificates that function as authenticators for services and domains. |
| Recommendation — Control certificate issuance paths and rotate or revoke certificate-related authenticators when trust changes. | ||
| CIS Controls v8 | 5 — Account Management | CAA depends on managing approved issuance relationships and reducing unauthorized trust paths. |
| Recommendation — Maintain an approved issuer list and review certificate-related trust relationships during account and asset changes. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | CAA constrains issuance of certificate-based authentication material used by systems and services. |
| Recommendation — Protect certificate issuance policy as authentication information and keep issuer approvals current. | ||
Practitioner Guidance
Why practitioners should care: CAA is most effective when it is treated as part of certificate governance, not as a one-time DNS task. The policy should be owned alongside certificate inventory, renewal workflows, and domain management so approved issuers stay aligned with the real operating model.
What to watch for: Unexpected new issuers, missing subdomain coverage, or certificate issuance that does not match the approved automation path usually indicate a policy or process gap. Those signals deserve review before the next renewal event creates the same exposure again.
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 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org