The CA/Browser Forum Baseline Requirements are the minimum rules public certificate authorities follow when issuing TLS certificates for public websites and services. They cover identity validation, certificate contents, revocation, and operational controls, so browsers can rely on a common issuance standard.
What the Baseline Requirements govern
The CA/Browser Forum baseline requirements set the minimum public-policy rules for how publicly trusted TLS certificates are validated, issued, renewed, and revoked. They are the shared operating floor that lets browsers treat certificates from different public CAs as comparable.
Because the rules are common across the ecosystem, they matter most where organisations depend on public trust anchors rather than private PKI. The requirements influence certificate content, validation evidence, revocation timing, and the operational discipline a CA must sustain to keep its issuing practice trustworthy.
Why issuance rules matter for browser trust
Public TLS trust is fragile if certificate issuance becomes inconsistent, lax, or easy to game. The Baseline Requirements reduce that risk by standardising identity checks, domain control validation, certificate lifetime expectations, and revocation handling so browsers can make a predictable trust decision.
That predictability is especially important because a weakly issued certificate can be used to impersonate a website, intercept traffic, or legitimise a fraudulent service. For a practical overview of the issuance and lifecycle themes behind this standard, see the CA/Browser Forum Baseline Requirements Guide.
Publicly trusted certificates also sit inside a broader PKI lifecycle, where expiry, renewal, automation, and key protection all affect whether the issued certificate remains dependable over time. The Machine Identity, PKI and Certificate Lifecycle Guide is useful when you need to connect issuance rules to operational certificate management.
How the standard shapes certificate operations
In practice, the Baseline Requirements drive several control points at once. CAs must validate control over names, bound certificate fields to acceptable purposes, and operate revocation processes that browsers and relying parties can use when a certificate is no longer trustworthy.
They also create a common expectation for incident handling and mass replacement when trust is lost. If a CA is distrusted, or if an issuing key or intermediate is compromised, the response is not just technical cleanup but coordinated reissuance, trust store management, and communication with affected operators. The CA Compromise and Mass Certificate Replacement Playbook addresses that operational consequence directly.
Revocation is part of the same control story, because a certificate that can no longer be relied on must be withdrawn quickly enough to limit exposure. When you need the revocation mechanisms themselves, the browser-side handling, and the short-lived-certificate trade-off, the Certificate Revocation Guide provides the broader context.
What organisations should verify in practice
Organisations relying on public TLS certificates should check whether their certificate inventory, validation records, renewal processes, and revocation paths line up with the Baseline Requirements. The practical question is not only whether a certificate exists, but whether its issuance evidence still supports browser trust today.
That review should extend to root and intermediate relationships, because the trust impact of a mistake often appears first in the issuing chain rather than at the endpoint. Where root ceremonies, witness controls, or HSM usage are part of that chain, the Cryptographic Key Ceremony Template is a useful companion resource for the control environment around CA keys.
When organisations issue code-signing certificates or other specialised certificate types, the same trust discipline applies even if the operational details differ. For adjacent issuance governance, the Code Signing Buyer's Guide helps compare key custody and policy expectations across certificate use cases.
Risk and Threat Considerations
Weak adherence to the Baseline Requirements can create real exposure because a certificate is a trust token, not just a technical artifact. If validation is sloppy or revocation is slow, attackers can benefit from fraudulent issuance, certificate misuse, or delayed trust removal after compromise.
Failure mechanism: A CA or dependent organisation accepts insufficient validation evidence, issues an overbroad or wrongly bound certificate, or fails to revoke a compromised certificate quickly enough for browsers and relying parties to stop trusting it.
Impact: Attackers can impersonate services, intercept encrypted sessions, preserve trust after compromise, or force a costly emergency reissuance and trust-store recovery process.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle control of credentials and certificate-like authenticators used in public trust. |
| IA-9 — Service Identification and Authentication | TLS certificates authenticate services that browsers connect to, which is central to public certificate issuance. | |
| SC-23 — Session Authenticity | Public TLS certificates support authenticity of browser sessions and protect against impersonation. | |
| Recommendation — Manage certificate and key lifecycles so issued trust material is rotated, revoked, and retired on schedule. Verify service authentication material and ensure issued certificates are bound to the intended service identity. Use authenticated transport controls to preserve session authenticity for public web services. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Certificate issuance and revocation depend on controlled administrative access to PKI systems and records. |
| A.8.24 — Use of cryptography | TLS certificates are a core cryptographic trust mechanism for public websites and services. | |
| Recommendation — Restrict administrative access to CA systems and certificate issuance records. Apply cryptography controls to protect certificate issuance, validation, and trust operations. | ||
| CIS Controls v8 | CIS-5 — Account Management | PKI operations depend on disciplined account and privilege management for issuance and revocation systems. |
| CIS-3 — Data Protection | Certificate material, validation evidence, and CA records require protection as sensitive trust inputs. | |
| Recommendation — Control privileged accounts that can issue, revoke, or alter certificate trust data. Protect certificate records and trust data from alteration, leakage, and misuse. | ||
Practitioner Guidance
Why practitioners should care: The Baseline Requirements are not just a CA concern, they affect every organisation that depends on publicly trusted TLS. If your inventory, issuance evidence, and renewal cadence do not match the standard’s assumptions, you inherit avoidable trust and outage risk.
What to watch for: Pay special attention to long-lived certificates, inconsistent validation records, weak revocation handling, and gaps between certificate ownership and operational ownership. Those are the places where browser trust breaks down first.
Practitioner takeaway: Treat public certificate issuance as a governed lifecycle, not a one-time purchase, and keep validation, revocation, and replacement procedures aligned with the baseline the browser ecosystem expects.
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