Understanding the CP and CPS in PKI

Public Key Infrastructure (PKI) relies on a framework of policies and practices to establish trust. Two key documents in any PKI are the Certificate Policy (CP) and the Certification Practice Statement (CPS). These documents define the security assurances a certificate provides and how a Certificate Authority delivers them. This article covers CP and CPS in detail, differentiates between the two, and references relevant standards including RFC 3647, RFC 6484, RFC 7382, WebTrust, and the CA/Browser Forum.

Quick Answer: What Are CP and CPS in PKI?

A Certificate Policy (CP) is a high-level document defining what a certificate is for and the assurance level it provides. A Certification Practice Statement (CPS) is the operational document describing how a Certificate Authority implements those policy requirements. The CP is the strategy; the CPS is the tactics. Both are required by auditors, regulators, and the CA/Browser Forum for any PKI claiming public or enterprise trust.

Key Takeaways

The CP defines what a certificate is for and the assurance level it provides. The CPS describes how the CA meets those requirements operationally. The CPS must not contradict the CP and can only be more specific or more restrictive.
Both documents must be structured according to RFC 3647 for publicly trusted CAs under the CA/Browser Forum Baseline Requirements. Section 2.2 of the Baseline Requirements explicitly mandates this format.
The CA/Browser Forum requires publicly trusted CAs to review and update their CP/CPS at least annually, even if no changes are made. Version numbers and dates must be incremented to confirm the review occurred.
The CA/Browser Forum Ballot SC-081v3 (April 2025) reduces maximum public TLS certificate validity to 200 days (March 2026), 100 days (March 2027), and 47 days (March 2029). Each validity reduction may require CP/CPS updates to reflect new permitted validity periods and automation requirements.
Without a documented CP and CPS, organizations cannot pass WebTrust for CAs audits, CA/Browser Forum compliance checks, or demonstrate PKI governance to auditors under HIPAA, PCI DSS, DORA, or ISO 27001.

Introduction: What CP and CPS Define

A Certificate Policy (CP) is a high-level specification of security requirements and certificate usage rules. It outlines what a certificate is intended for and the level of trust or assurance it provides, describing the boundaries and acceptable uses of certificates from a given PKI. For example, a CP might specify that a certain class of certificates is suitable for securing TLS web servers and define the identity verification requirements for issuance.

A Certification Practice Statement (CPS) is a detailed description of how the Certificate Authority meets the requirements of the CP. It is defined as a statement of the practices that a certification authority employs in issuing, managing, revoking, and renewing certificates. The CPS documents the operational procedures and security controls: how the CA performs identity verification, protects its private keys, generates certificates, and handles revocations.

The CPS must be consistent with the CP. The CPS describes in more detail how a CA implements a given Certificate Policy and cannot contradict what is stated in the CP. For example, if the CP permits issuing only email encryption certificates, the CPS cannot describe procedures for issuing TLS server certificates outside that scope.

Together, the CP and CPS represent the CA’s business practice disclosures and serve as the governance framework for CA operations. The CP must be publicly available to all relying parties; most CAs also publish their CPS publicly. Some organizations combine these into a single CP/CPS document for simplicity; others maintain them separately.

Who Should Care About CP and CPS

CP and CPS governance is not owned by a single team. Every role below has a direct stake in ensuring these documents are complete, current, and aligned with both operational practice and regulatory requirements.

Role	Why It Matters	Action Item
PKI Admins	Own the operational procedures documented in the CPS: key generation ceremonies, certificate issuance workflows, revocation processes, and HSM management	Ensure CPS accurately reflects current CA operations; flag any operational changes that require CPS revision; document all key ceremonies with dual-control evidence
Security Architects	Own the policy decisions documented in the CP: assurance levels, approved certificate types, algorithm standards, and trust model	Define CP assurance levels aligned to regulatory obligations; enforce NIST SP 800-131A algorithm floors; include crypto-agility and PQC readiness planning in CP design
Platform / DevOps Teams	Must operate within the certificate types, validity periods, and issuance rules defined in the CP; self-signed certificates or unapproved CAs violate CP controls	Review CP to understand approved certificate types and validity periods; integrate ACME-based automated issuance into pipelines using only approved CAs
Compliance Teams	Must map CP and CPS controls to regulatory requirements (HIPAA, PCI DSS, DORA, ISO 27001) and confirm documents are updated when standards change	Conduct annual CP/CPS review against current CA/Browser Forum Baseline Requirements and applicable regulatory frameworks; maintain version control and approval records
CISOs	Own overall PKI governance; CP changes may require CISO or PMA approval; CP/CPS gaps create direct regulatory exposure	Approve CP changes; fund annual CP/CPS review and development for new PKI deployments; include CP/CPS compliance in board-level risk reporting

Key Aspects of a Certificate Policy

A Certificate Policy covers the types of certificates and their uses (authentication, digital signature, encryption) and the level of identity verification or security required for certificate issuance, often called assurance levels. Many CPs define multiple assurance levels or certificate classes.

Example: The Government of Canada’s PKI certificate policy defines four assurance levels (Rudimentary, Basic, Medium, High) for each of two broad applications (digital signature and confidentiality), resulting in eight distinct policy OIDs within a single CP document.

Each level has increasingly stringent requirements and corresponds to a unique policy Object Identifier (OID) included in certificates. Including the policy OID in a certificate’s Certificate Policies extension ties the certificate to the CP’s rules, allowing software or auditors to identify which policy the certificate claims to adhere to.

A CP is also used to facilitate trust decisions and comparisons. Different organizations or CAs can map their certificates to standardized CP OIDs to indicate they meet certain common criteria. The CA/Browser Forum’s Baseline Requirements document serves as a de facto Certificate Policy for publicly trusted TLS server certificates, defining the minimum requirements that all such certificates and CAs must adhere to. Each publicly trusted CA must publicly disclose a CP/CPS that incorporates the Baseline Requirements as its policy for TLS issuance.

CP and CPS Glossary: Key Terms, When They Matter, and Implementation Considerations

Use this reference table to understand the key CP and CPS concepts, identify when each applies to your environment, and determine the right implementation approach.

Concept	Definition	When It Matters	Implementation Consideration
Certificate Policy (CP)	High-level document defining what a certificate is for, the assurance level it provides, and the requirements that must be met before issuance	Every PKI deployment; required by WebTrust, CA/Browser Forum, HIPAA, PCI DSS, DORA, and ISO 27001	Structure per RFC 3647; define policy OIDs for each certificate type and assurance level; make publicly available
Certification Practice Statement (CPS)	Operational document describing how a CA implements the CP requirements: identity proofing, key ceremonies, certificate issuance, revocation, and audit controls	Every CA deployment; auditors request this first; required by CA/Browser Forum Baseline Requirements Section 2.2	Structure per RFC 3647; must not contradict the CP; can be more restrictive; update annually at minimum
Policy OID	Object Identifier embedded in issued certificates that ties the certificate to a specific CP assurance level, enabling automated trust decisions	When issuing certificates claiming a specific assurance level (e.g., EV, IV, DV); required for EV certificates under CABF EV Guidelines	Define OIDs in the CP; ensure CLM platform embeds correct OID in issued certificates; document OID-to-policy mapping
Assurance Level	A classification within the CP defining the rigor of identity verification required before a certificate is issued (e.g., Rudimentary, Basic, Medium, High)	When issuing certificates for different use cases requiring different levels of identity trust (device vs. human vs. organization)	Map assurance levels to identity proofing procedures in the CPS; align levels to regulatory requirements (CMMC, FedRAMP, eIDAS)
RFC 3647 Framework	IETF standard (2003) providing a nine-section standardized outline for CP and CPS documents, enabling consistent structure across different CAs	All CP and CPS authorship; mandated by CA/Browser Forum Baseline Requirements Section 2.2; recommended by WebTrust	Use RFC 3647 section numbering; write No Stipulation for non-applicable sections rather than leaving blank
No Stipulation	The phrase used in a CP or CPS to explicitly mark a section as not applicable, confirming the omission is intentional per CA/Browser Forum guidance	When a CA does not perform a specific function (e.g., does not allow certificate suspension)	Never leave RFC 3647 sections blank; use No Stipulation to confirm intentional inapplicability
Policy Management Authority (PMA)	The governance body responsible for approving changes to the CP; may be internal (CISO plus PKI admin) or external (CA/Browser Forum for Baseline Requirements)	Any change to the CP; cross-certification requests requiring policy equivalence determination	Define the PMA in the CP; document the approval process and quorum requirements for CP changes
Registration Authority (RA)	An entity authorized by a CA to perform identity verification on behalf of the CA, but which does not itself issue certificates	When delegating identity proofing to a third party; common in enterprise PKI (e.g., HR as RA for employee certificates)	Document RA responsibilities and limitations in the CPS; RA must comply with relevant CP/CPS provisions per WebTrust requirements

Certification Practice Statement (CPS): Implementing the Policy

If the CP is the what and why, the CPS is the how. The CPS is a detailed, technical document describing the practices and procedures a CA uses to implement the requirements of one or more CPs. This includes how the CA performs identification and authentication of applicants, how it generates and protects keys, how it issues and delivers certificates, how it publishes revocation information, and other operational details.

A CPS is typically written from the perspective of the Certification Authority’s operations and used by auditors, internal security teams, and policy authorities to verify that the CA’s actual practices are consistent with the policy. Unlike CPs (often set by a policy authority or industry group), a CPS is usually authored by the CA itself. Most public trust CAs make their CPS public for transparency; in some private or internal PKIs, a CPS might be kept internal and shared only with relying parties, auditors, or partners.

Typical Content of a CPS

Organizational responsibilities: roles including CA, Registration Authority, and Subscriber
Procedures for identity verification: how the CA or RA verifies the identity of certificate applicants
Certificate lifecycle management: issuance, renewal, re-key, modification, suspension, and revocation procedures
Facility and personnel controls: physical security, personnel security, background checks, separation of duties
Technical security controls: cryptographic module standards for HSMs, key generation ceremonies, key protection, backup and recovery
Certificate and CRL/OCSP profiles: technical certificate format details and revocation infrastructure
Compliance and audit requirements: how the CA demonstrates conformance to the CP

The Key Rule: CPS Must Not Contradict the CP

The CPS can be more specific or restrictive than the CP, but it cannot loosen a requirement stated in the CP. If the CP requires identity verification in-person with a government ID, the CPS cannot allow verification via email alone. A CPS might add extra practices beyond the CP as long as they do not undermine the CP’s requirements. This consistency is what makes the CP the authoritative source of truth for the PKI’s trust claims.

CP vs. CPS: Differences and Relationship

The CP is the strategy; the CPS is the tactics. The CP focuses on what objectives or assurances must be met (and for whom), while the CPS focuses on how to achieve them in practice.

Aspect	Certificate Policy (CP)	Certification Practice Statement (CPS)
Purpose	Defines what the certificate is intended for, and what security assurances or requirements apply. High-level rules or criteria for certificate usage.	Describes how the CA meets the policy requirements. Detailed statement of practices for issuing and managing certificates.
Focus and Audience	Focuses on the needs of relying parties and the trust community. Often set by a Policy Authority or industry group.	Focuses on the CA’s internal operations and controls. Used by auditors and internal PMAs. Authored by the CA itself.
Content	High-level requirements, scope, and applicability: certificate uses, assurance level definitions, broad requirements. Each policy identified by an OID in issued certificates.	Detailed procedures and technical controls: identity proofing steps, cryptographic practices (HSM details, key lengths), physical security, personnel security, incident response.
Multiplicity	One CP can govern multiple CAs or a whole PKI; one document can contain multiple related policies (multiple assurance levels or certificate types).	Typically one CPS per CA or CA family. A single CPS can cover multiple CPs. Organizations sometimes merge CP and CPS into a single document.
Governance and Changes	Changes to CP may require approval by a Policy Management Authority (PMA) or external body. Often versioned and controlled at a higher level.	Changes to CPS are usually made by the CA with PMA oversight. Public CAs must review and update CP/CPS at least annually. Significant changes may be reported to auditors or root programs.

Standards and Frameworks for CP and CPS

RFC 3647: The Framework for CP and CPS

To bring consistency to how CPs and CPSs are written, the IETF published RFC 3647: “Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework” in 2003. RFC 3647 provides a standardized outline of topics that a CP or CPS document should cover, making it easier for policy writers, readers, auditors, and cross-certifying entities to find and compare information across different CP/CPS documents.

RFC 3647’s framework is organized into nine major sections:

Introduction (scope, document identification)
Publication and Repository Responsibilities
Identification and Authentication (how identities are vetted)
Certificate Life-Cycle Operational Requirements (application, issuance, acceptance, revocation, renewal)
Facility, Management, and Operational Controls (physical security, personnel security, audit logging)
Technical Security Controls (key management, cryptographic controls, lifecycle security controls)
Certificate, CRL, and OCSP Profiles (technical certificate format details)
Compliance Audits and Other Assessments
Other Business and Legal Matters (disclaimers, financial responsibility, privacy, confidentiality)

By following this common structure, a CP and a CPS for the same CA will cover the same categories of information, making it straightforward to see how the CA’s practices (CPS) satisfy each policy requirement. The CA/Browser Forum updated its Baseline Requirements in 2015 to require that CAs structure their CP/CPS according to RFC 3647. Section 2.2 of the Baseline Requirements explicitly states: the Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 and MUST include all material required by RFC 3647.

If a particular section is not applicable, the documents should explicitly state “No Stipulation” rather than leaving it blank. This confirms to readers that the omission is intentional. For instance, if a CA does not allow certificate suspension, the CPS section on Suspension would state: “Not applicable; the CA does not suspend certificates.”

RFC 6484: Certificate Policy for the RPKI

RFC 6484 is a specific Certificate Policy: “Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI).” The RPKI is a specialized PKI used to secure Internet routing by issuing certificates for IP address blocks and Autonomous System (AS) numbers. RFC 6484 serves as the common, agreed-upon CP for all RPKI participants, including the Regional Internet Registries (RIRs). It was structured using the RFC 3647 template and covers identification requirements for IP address certificates, operational requirements, and revocation timelines specific to the RPKI context.

RFC 7382: CPS Template for the RPKI

To complement the RPKI’s CP in RFC 6484, the IETF published RFC 7382: “Template for a Certification Practice Statement (CPS) for the RPKI” in 2015. This is a boilerplate CPS tailored to the RPKI environment using the RFC 3647 structure, filling in guidance specific to RPKI operations such as key rollovers, repository data availability, and the operational requirements of an RPKI CA like an RIR.

WebTrust Principles and CA/Browser Forum Guidelines

WebTrust for Certification Authorities strongly encourages and effectively requires for public CAs that a CA has a CP/CPS conforming to the standard framework. WebTrust auditors verify that the CA discloses its key and certificate lifecycle practices via a CP/CPS document and that the CA actually follows those disclosed practices. External Registration Authorities used by a CA must comply with the relevant provisions of the CA’s CP/CPS, making the CP/CPS the authoritative source for what an RA is allowed to do.

CA/Browser Forum (CABF) Baseline Requirements serve as an overarching CP that all publicly trusted CAs must incorporate. Key requirements include: CP/CPS must be publicly available 24/7 in a text-based format and in English; the CP/CPS must clearly identify which certificates (roots, sub-CAs) they apply to; the CP/CPS must follow RFC 3647 format with every subsection filled (even if just with “No Stipulation”); EV certificate issuers must include a specific policy OID in EV certificates and assert EV Guidelines compliance in their CP/CPS; and CAs must review and update their CP/CPS at least annually, incrementing the version number and date even when no operational changes are made.

The combination of RFC 3647 and these industry requirements has made CP/CPS structure and maintenance fairly uniform across the industry. A relying party or auditor can navigate any CP/CPS and find where it addresses identity proofing (Section 3 of RFC 3647) or key management (Section 6) and compare it to another CA’s documents or to expected standards.

CP/CPS and Certificate Lifecycle Management

The CP defines the rules that a certificate lifecycle management (CLM) platform must enforce. Approved CAs, permitted certificate validity periods, required algorithms, and identity verification requirements documented in the CP must all be reflected in CLM platform policy. The CPS documents how the CA implements those rules operationally.

As the CA/Browser Forum Ballot SC-081v3 (April 2025) reduces maximum public TLS certificate validity to 47 days by March 2029, CP/CPS documents must be updated to reflect these new permitted validity periods, and CLM automation must be deployed to manage the resulting renewal cadence. Manual certificate management cannot support a 47-day renewal cycle at any meaningful certificate volume.

For organizations building or modernizing their PKI, PKI-as-a-Service providers typically include a CPS covering the managed CA infrastructure, which organizations can reference in their own CP/CPS documentation. For organizations that need to inventory their cryptographic estate before authoring a CP, CBOM Secure automates cryptographic discovery across hybrid and multi-cloud environments and generates a Cryptographic Bill of Materials that serves as the baseline for CP scope definition. For post-quantum readiness planning, the PQC Center of Excellence provides NIST FIPS 203, 204, and 205 aligned guidance that should inform CP algorithm policy decisions.

How Encryption Consulting Can Help

Encryption Consulting LLC offers specialized expertise in developing Certificate Policy (CP) and Certification Practice Statement (CPS) documents to ensure a client’s PKI is compliant, secure, and aligned with industry standards. Consultants leverage RFC 3647 as the template for CP/CPS documentation, ensuring all required sections and controls are addressed per CA/Browser Forum Baseline Requirements and WebTrust criteria, tailored to the organization’s unique environment and specific compliance obligations.

Gap Analysis and PKI Compliance Assessments

Encryption Consulting assists clients through comprehensive PKI assessments and gap analyses to achieve compliance readiness. PKI Assessment services include a detailed gap analysis examining cryptographic practices, operational procedures, and existing policies against industry best practices and required standards, uncovering vulnerabilities or non-compliant areas that could jeopardize the PKI.

As part of these assessments, Encryption Consulting performs a focused policy assessment reviewing existing CP and CPS documents for alignment with NIST guidance, ISO 27001, and other regulatory frameworks. Misalignments are flagged for remediation. By pinpointing weaknesses in governance, certificate practices, or technical controls, Encryption Consulting prepares organizations to pass audits (whether internal, external, or WebTrust for public CAs) with confidence. Reports and guidance serve as a roadmap for continuous compliance rather than a one-time audit pass.

Conclusion

CPs and CPSs embody the principle of trust, but verify. They are the documents that let us verify why we should trust a digital certificate and how that trust is being managed. The CP sets the rules; the CPS proves the CA follows them. Together they create the governance framework that regulators, auditors, and relying parties use to evaluate PKI trustworthiness.

In a world increasingly dependent on PKI, from HTTPS and code signing to smart grid and IoT device identity, these policies and practice statements continue to play a critical role in cybersecurity. As certificate lifetimes shorten, post-quantum algorithms arrive, and regulatory expectations rise, keeping CP and CPS documents current is not just a compliance checkbox but an operational necessity.

Frequently Asked Questions

What is the main takeaway from Understanding the CP and CPS in PKI?

The Certificate Policy (CP) and Certification Practice Statement (CPS) are the governance foundation of any PKI. The CP defines what a certificate is for and the assurance level it provides. The CPS describes how the CA delivers those assurances operationally. Together they are the documents auditors, regulators, and relying parties use to evaluate whether a PKI can be trusted.

Why do CP and CPS matter for enterprise PKI teams?

Enterprise PKI teams must have documented CP and CPS to pass audits under HIPAA, PCI DSS, DORA, ISO 27001, WebTrust, and CA/Browser Forum Baseline Requirements. Without these documents, there is no governance framework to demonstrate that certificate issuance, revocation, and key management practices meet regulatory expectations. The CA/Browser Forum requires publicly trusted CAs to review and update their CP/CPS at least annually.

What risks increase without a documented CP and CPS?

Without documented CP and CPS, organizations face immediate audit findings under HIPAA, PCI DSS, DORA, and ISO 27001; inability to demonstrate the assurance level of certificates issued; inconsistent CA operations creating gaps between policy intent and actual practice; mis-issuance risk because staff lack documented issuance rules; and inability to cross-certify with other PKIs requiring documented policy equivalence.

Which teams should own the CP and CPS?

PKI admins own the operational procedures documented in the CPS. Security architects own the policy decisions documented in the CP. Compliance teams ensure the CP and CPS map to regulatory requirements and are updated when standards change. CISOs own overall governance and approve any material changes to the CP.

How do the CP and CPS connect to certificate lifecycle management?

The CP defines the rules that a CLM platform must enforce: which CAs are approved, what certificate validity periods are permitted, which algorithms are required, and what identity verification is needed before issuance. A CLM platform like CertSecure Manager automates the enforcement of CP rules across every certificate, preventing policy violations from creating audit findings or service disruptions.

How should organizations measure success in CP and CPS governance?

Key metrics include: CP and CPS documents reviewed and version-controlled at least annually; all certificate issuance workflows documented in the CPS and consistent with the CP; no audit findings related to undocumented PKI practices; zero CP/CPS-to-practice gaps identified during internal audits; and complete mapping between CP policy requirements and CLM platform enforcement rules.

What should be audited or monitored regularly in a CP/CPS program?

Audit annually: CP and CPS documents for alignment with current CA/Browser Forum Baseline Requirements, NIST guidance, and applicable regulatory frameworks; version control and approval records; and policy-to-practice consistency confirming CA operations match CPS descriptions. Review quarterly: new regulatory or CABF policy changes that may require CP/CPS updates, and any operational changes that require CPS revision.

How do CP and CPS affect cloud, hybrid, or multi-CA PKI environments?

In hybrid and multi-CA environments, each CA in the hierarchy should have its own CPS describing its specific operational practices, all governed by a common CP. Without this structure, different CAs may operate under conflicting rules, creating governance gaps. PKI-as-a-Service providers typically provide a CPS covering their managed CA infrastructure, which organizations can reference in their own CP/CPS documentation.

What common mistakes should teams avoid when writing a CP or CPS?

The most common mistakes are: not structuring the CP and CPS according to RFC 3647; leaving sections blank instead of writing “No Stipulation” for non-applicable areas; allowing the CPS to contradict the CP; not updating the CP/CPS annually even when no operational changes occur; and not mapping CP policy OIDs to actual certificate issuance so that policy claims cannot be verified in issued certificates.

What should be refreshed quarterly or annually in a CP/CPS governance program?

Review quarterly: CA/Browser Forum policy updates (Baseline Requirements, EV Guidelines, S/MIME BR) for changes requiring CP/CPS updates; NIST algorithm guidance (SP 800-131A, SP 800-57) for cryptographic standard changes; and any operational changes to the CA environment. Review annually: full CP and CPS documents for accuracy against current practices; mapping between CP assurance levels and CLM policy enforcement; and cross-certification agreements that reference the CP. Use the PQC Center of Excellence for guidance on NIST FIPS 203, 204, and 205 algorithm policy updates.