Define PKI governance scope
Trust Architecture Playbook: Governance pillar
Certificate populations in scope
Governance scope should be defined by use case and risk, not only by issuing CA. The same issuing CA can support low-risk internal TLS, high-risk mTLS, user authentication, device identity, or privileged infrastructure certificates. Conversely, the same application can depend on certificates from multiple CAs. A governance model that starts and ends with CA ownership misses the real control boundary: what the certificate is trusted to do. The following certificate populations should be in scope for enterprise PKI governance regardless of issuing CA:
Public TLS certificates for internet-facing services and externally trusted domains.
Private TLS certificates for internal applications, APIs, gateways, load balancers, and infrastructure services.
mTLS and workload identity certificates for service-to-service authentication, service mesh, ingress, and API authentication.
User, device, mobile, VPN, Wi-Fi, and endpoint authentication certificates.
Cloud-managed certificates and certificates stored in cloud vaults or secrets managers.
Certificates discovered through CT logs, cloud scans, internal network scans, system scans, connector-based imports, API imports, and third-party scanning tools.
Certificates issued or renewed from any approved CA source, including public and private trust issuance across DigiCert and third-party CA vendors.
Avis
Certificate populations in scope is a governance-scope decision, not a CA design decision. Structuring CA hierarchies to limit the certificate types a single CA issues remains important for fail-fast authorization; see the Issuance pillar for CA hierarchy design guidance.
Use-case taxonomy
The following table maps different certificate populations to their governance focus areas and DigiCert® Trust Lifecycle Manager control points.
Use case | Typical scope | Governance focus | Trust Lifecycle Manager control points |
|---|---|---|---|
Public TLS | External websites, APIs, CDN edges, public ingress | Domain control, CA/B requirements, renewal cadence, public outage impact | Certificate profiles, connectors, CT logs monitoring, CA source registry, certificate owners, audit logs |
Private TLS | Internal web apps, gateways, load balancers, databases, middleware | Internal namespace authority, trust anchor distribution, revocation model, client compatibility | Private CA profiles, connectors, inventory metadata, audit logs |
mTLS / workload identity | Service mesh, Kubernetes, Istio, API-to-API, agents | Short lifetime, automation identity, workload attestation, namespace scoping | ACME/mTLS profiles, service users, metadata rules |
User / device | Wi-Fi, VPN, mobile, desktop, smartcard, endpoint posture | Identity proofing, enrollment authentication, recovery, suspension/revocation | Business units, user-focused enrollment methods (for example, DigiCert Trust Assistant, SCEP, autoenrollment), certificate owners |
CA operations | Private roots/intermediates, Microsoft CA, cloud private CAs | Root protection, issuing policy, audit evidence, CA lifecycle, hierarchy changes | CA source registry, root/intermediate inventory, connectors |
Special purpose | Code signing dependencies, S/MIME, TLS inspection, test PKI | Use-case-specific policy, key protection, legal/regulatory constraints, exception review | Dedicated profiles, restricted roles, exception review |
Trust-domain registry
The trust-domain registry is the governance inventory of approved trust environments. It should not duplicate every certificate in the inventory; it should define the allowed categories of trust and the authority responsible for each category.
Field | Description |
|---|---|
Trust domain name | A descriptive name identifying the trust environment, typically combining trust type and scope. |
Trust type | The trust relationship category for this domain: public, private, internal enterprise, partner, or regulated. |
Maturity state | The governance maturity of this domain, for example standard, lab, or transitional. For details, see Governance transition states. |
Issuing authority | The approved CA source, root/intermediate, connector, and profile family authorized to issue certificates in this domain. |
Relying-party population | Who or what is expected to trust certificates issued in this domain. |
Allowed certificate types | The certificate EKUs and use cases permitted in this domain, such as server authentication, client authentication, or S/MIME. |
Policy owner | The named policy authority or governance body responsible for this domain. |
Operational owner | The team responsible for operating issuance, connectors, profiles, and support for this domain. |
Evidence requirements | The categories of evidence required to govern this domain, including approvals, audit records, inventory metadata, validation output, access reviews, and exception records. |
Review cadence | The frequency at which this domain's governance posture should be reviewed, based on risk level and maturity state. |
Example trust-domain registry entry
The following example shows the level of specificity expected for a governed trust domain. The actual registry should use enterprise-specific names, owners, and CA identifiers.
Field | Example entry |
|---|---|
Trust domain name | Private TLS - enterprise server |
Trust type | Private, internal enterprise |
Maturity state | Standard |
Issuing authority | DigiCert Private CA - Enterprise Server Issuing CA; Trust Lifecycle Manager private TLS profile family |
Relying-party population | Corporate-managed servers, load balancers, internal applications, and managed endpoints that trust the enterprise root |
Allowed certificate types | Server authentication only; no client authentication or code signing EKUs |
Policy owner | PKI governance board |
Operational owner | Central PKI/security with delegated platform operations for approved business units |
Evidence requirements | Profile approval, CA-source approval, requester identity, certificate owner, deployment target, validation result, and exception status |
Review cadence | Quarterly until the trust domain reaches target governed state; semiannual after control stability is proven |
Source-of-truth hierarchy
Source-of-truth hierarchy prevents governance reviews from devolving into debates about which system is right. Different systems are authoritative for different fact types — the following entries identify the authoritative source for each:
Issuing CA records: authoritative for certificate issuance and CA-side lifecycle state.
Trust Lifecycle Manager inventory: governed record for ownership, metadata, profile assignment, and lifecycle status.
Platform connectors: authoritative for platform context, deployment location, and binding where supported.
Live endpoint validation: authoritative for what a service is actually presenting to clients.
CT logs: authoritative external signal for public certificates that have been logged, but not sufficient for ownership or deployment state.