Baseline Requirements are the certificate-issuance rules published by the CA/Browser Forum for publicly trusted TLS certificates. Certificate operators and consuming teams should follow them for validation, key protection, validity limits, revocation, and recordkeeping, because non-compliance can lead to distrust, browser rejection, and weaker assurance in public certificates.
What the Baseline Requirements govern
The Baseline Requirements define the minimum certificate-issuance rules for publicly trusted TLS certificates. They standardise how certificate authorities validate applicants, protect private keys, limit certificate validity, handle revocation, and keep records so that browsers and other relying parties can trust the certificate ecosystem.
Because these rules apply to public trust, they are not just policy language. They shape whether a certificate is accepted, how much assurance it provides, and whether a misissued or weakly managed certificate can undermine encrypted web traffic.
Why the rules matter for public trust
The CA/Browser Forum exists to prevent fragmentation in certificate issuance and to keep browser trust decisions consistent. CA/Browser Forum publishes the baseline rules that certificate operators and consuming teams use as the common floor for publicly trusted TLS.
That common floor matters because a public certificate is only useful if browsers, devices, and applications are willing to trust it. If issuance rules are weak or inconsistently applied, the result can be browser distrust, shortened trust lifetimes, or weaker confidence in the identity bound to the certificate.
What organisations need to verify
Organisations should confirm that every public certificate in scope has a clear owner, a valid validation trail, and a documented lifecycle. The most important checks are whether the issuing CA follows the required validation steps, whether keys are generated and stored with adequate protection, and whether revocation and recordkeeping are working as intended.
This is especially important for teams that consume third-party certificates through cloud platforms, proxies, or managed services, because responsibility for operational use does not remove the need to understand the certificate’s trust status and renewal path. Strong baselines also help teams distinguish a valid public certificate from one that is technically present but no longer trustworthy.
How Baseline Requirements affect remediation and assurance
When a certificate does not meet the baseline rules, the issue is usually not cosmetic. It can affect browser acceptance, renewal timing, revocation handling, and the evidence available to prove that the certificate was issued correctly. Organisations should treat gaps as certificate assurance failures, not only as administrative exceptions.
For teams comparing issuer practices or hardening their own certificate operations, controls around validation, logging, and lifecycle discipline matter more than any single technical setting. A useful reference point for broader application-security requirements is OWASP ASVS, which helps frame how trustworthy authentication and transport assumptions are verified in practice.
Risk and Threat Considerations
Baseline Requirements failures create a direct trust risk: a certificate may be issued for the wrong subject, protected too weakly, or allowed to remain valid beyond the point where browsers and relying parties are comfortable trusting it. In public PKI, that can turn a certificate into an attack enabler or a reliability problem at the same time.
Failure mechanism: Weak validation, poor key protection, or missed revocation can allow misissuance, impersonation, or continued use of a certificate that should no longer be trusted.
Impact: The result can be browser rejection, service disruption, loss of user trust, and increased exposure to interception or impersonation if a compromised or misissued certificate is still accepted.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | Public TLS trust underpins secure authentication flows and certificate-bound trust assumptions. |
| V12 — Secure Communication | Baseline Requirements govern the trustworthiness of publicly used TLS certificates. | |
| Recommendation — Verify authentication and trust assumptions that depend on valid TLS certificates. Validate certificate trust and transport protections for all public-facing services. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate handling depends on secure lifecycle control of authentication material. |
| SC-12 — Cryptographic Key Establishment and Management | Public certificate assurance depends on protected key generation, handling, and lifecycle. | |
| AU-2 — Event Logging | Baseline Requirements require recordkeeping and audit evidence around issuance and revocation. | |
| Recommendation — Manage certificate lifecycle, rotation, and revocation as controlled authenticators. Protect certificate keys through disciplined generation, storage, rotation, and destruction. Log issuance and revocation events so certificate decisions can be reviewed later. | ||
Practitioner Guidance
Why practitioners should care: Certificate teams should treat the Baseline Requirements as an operational control set, not a reference document to read once. The practical question is whether issuance, renewal, revocation, and evidence collection are actually aligned with the public trust model.
Governance implication: Ownership should be explicit across CA operations, application teams, and platform teams, because certificate failures often emerge at the boundary between issuance policy and day-to-day deployment.
Practitioner takeaway: If a public certificate cannot be tied back to compliant validation and lifecycle evidence, it should not be treated as trustworthy merely because it still appears to work.