About this pillar
Trust Architecture Playbook: Governance pillar
Executive summary
Enterprise PKI governance is the operating system for digital trust. It defines who, what, where, when, why, and how of the certificate estate. At the same time, it allows the organization to validate and prove that those controls were followed. Without that layer, discovery is a list, automation becomes a convenience feature, and certificate policy remains a document no one can reliably enforce (if even defined).
Who: Who can issue a certificate, and how do I prove they are who they claim to be?
What: What kinds of certificates?
Where: What CA sources, which certificates, to which destinations (internal TLS, cloud workload, etc.)?
When: How long is the lifetime of the certificate, what are renewal policies?
Why: For what purpose is the certificate being issued (which KU/EKU, OID, etc.)?
How: What mechanisms are used to issue, renew, revoke, etc.?
DigiCert ONE is a unified digital trust platform that combines CA-agnostic certificate lifecycle management with PKI services, including discovery, management, notification, automation, integration, intermediate CA creation, and private certificate issuance. DigiCert® Trust Lifecycle Manager provides the control plane that translates governance decisions into repeatable operating controls with practical enforcement mechanisms including certificate profiles, business units, admin roles, certificate owners, assignment rules, and audit logs.
Public-trust requirements are important, with maximum certificate validity periods reducing under the CA/Browser Forum schedule, but this pillar is deliberately broader than that. Private trust, mTLS, workload identity, device identity, user certificates, code signing dependencies, internal TLS, cloud certificates, and certificates issued by disparate CAs all require governance. These different trust domains create different obligations, but they don’t eliminate the need for a common operating model.
Read this pillar as the anchor for the governance operating model, not as a requirement that every organization implement every artifact, cadence, and control described here. The right governance model should be proportionate to the complexity and risk of the certificate estate. An organization with a small, centrally managed public TLS footprint may only need a lightweight version of the model: named authority, approved CA sources, basic profile control, ownership metadata, exception tracking, and periodic reporting. An enterprise operating across multiple CAs, private trust domains, workload identity platforms, delegated business units, regulated environments, and high-volume automation requires a more formal governance framework because the number of decision points, trust boundaries, and failure modes is much higher.
Baseline, Issuance, and Automation are not separate projects; they are control surfaces of one governed digital trust program. Baseline establishes the facts. Issuance builds approved paths for issuing new certificates. Governance defines the ongoing controls and guardrails for how those paths are used: who can request, approve, and rely on issuance, and how that use is monitored and proven. Automation then executes that governed model at scale. The practical goal is to adopt enough governance to make all control surfaces coherent, enforceable, and measurable without creating unnecessary process for lower-risk environments. As the certificate estate becomes more distributed, more automated, more business-critical, or more dependent on delegated execution, the governance model should mature accordingly.
Intended audience
PKI, security architecture, identity, and cryptography teams
Trust Lifecycle Manager platform owners and administrators
Cloud, infrastructure, platform engineering, and DevSecOps teams
Application, service, workload, device, and product owners
Governance, risk, compliance, audit, legal, and privacy stakeholders
Enterprise architecture and technology risk leadership
Core assumptions
Trust Lifecycle Manager is the intended governance and certificate lifecycle management control plane for the program.
The Baseline pillar discovery work is either complete or underway so that certificates can be mapped to owners, deployment locations, business context, and criticality.
The Automation pillar operating model is the intended downstream execution model for governed lifecycle actions, readiness gates, exceptions, and control loops.
The organization manages both public-trust and private-trust certificate populations, which may include certificates issued by non-DigiCert CA sources.
Target outcomes
Governance succeeds when the organization can consistently answer a small set of hard questions for every certificate and every issuing path: who authorized it, what policy allowed it, what identity requested it, what CA issued it, where it is deployed, how it is monitored, and what evidence proves the lifecycle event was legitimate. The Governance pillar targets the following outcomes:
A clear PKI policy authority exists and owns standards, exceptions, CA source approvals, and risk acceptance.
Certificate profiles are treated as governed enforcement boundaries, not administrative conveniences.
Public-trust and private-trust certificate populations are governed under a common operating model while preserving trust-domain-specific obligations.
Delegated teams can execute lifecycle work without escaping central guardrails.
Every lifecycle action produces evidence that can support audit, incident response, and executive reporting.
Exception volume, profile sprawl, unknown ownership, and unmanaged CA sources trend down over time.
Crypto agility becomes a measurable capability rather than an emergency project.
Belangrijk
Key takeaway
PKI governance is not the policy binder. It is the control system that makes policy executable, observable, and enforceable across the certificate estate.
Quick start checklist (first 30 days)
The first 30 days are not about perfecting every policy document. They are about establishing enough authority, segmentation, evidence, and decision discipline to stop uncontrolled growth while the broader governance program matures.
Name the PKI governance board and approve its charter, quorum, escalation path, and decision rights.
Approve the initial trust-domain taxonomy: public TLS, private TLS, mTLS/workload identity, user/device, code signing, S/MIME, and special-purpose PKI.
Create the initial CA source registry: approved CA, trust type, issuing scope, owner, supported certificate types, and retirement or migration disposition.
Freeze new uncontrolled certificate profiles and require review for every new profile, template, issuing CA, ACME account, or automation identity.
Confirm business unit segmentation and minimum metadata standards: owner, environment, criticality, exposure, platform, trust domain, and CA source.
Define the minimum role model for administrators, service users, profile managers, certificate owners, and delegated requesters.
Publish a one-page exception intake form and exception register with mandatory expiry date, compensating controls, and retirement plan.
Stand up governance reporting for unowned certificates, unmanaged CA sources, dormant/high-risk profiles, public certificate transparency (CT) log anomalies, expiring high-criticality certificates, and open exceptions.
Schedule the first access review, first CA source review, first profile catalog review, and first crypto-agility tabletop exercise.
What this pillar doesn't cover
The following topics are out of scope and/or covered elsewhere in the DigiCert documentation or Trust Architecture Playbook:
Detailed cryptographic engineering decisions for every application protocol, device class, or platform.
Complete legal terms for subscriber agreements, relying party agreements, or external CA contracts.
A full Certificate Policy (CP) or Certification Practice Statement (CPS). This pillar defines how to govern and operationalize those documents; RFC 3647 remains the framework for CP/CPS structure.
Step-by-step Trust Lifecycle Manager configuration procedures.