Define risk tiers and control baselines
Trust Architecture Playbook: Governance pillar
Criticality tiers
Governance should apply the same criticality discipline used across the DigiCert® Trust Architecture Playbook (for example, see the Automation pillar), but extend it to policy, delegation, CA source approval, access, evidence, and exceptions. A Tier 0 certificate is not only harder to automate; it should be harder to create, harder to delegate, harder to change, and harder to exempt from policy.
Tier | Typical certificate population | Governance baseline | Decision posture |
|---|---|---|---|
0 | Customer-facing, regulated, revenue-impacting, identity-core, privileged access, root/intermediate CA, critical mTLS/workload identity. | Board-approved trust domain and profile. Strong key protection where supported. Named owner. Validated deployment. High-fidelity evidence. Tight exception approval. | Central approval and high scrutiny. No uncontrolled delegation. Break-glass pre-staged and tested. |
1 | Enterprise-critical internal services, SSO, API gateways, shared platforms, security tooling, high-impact private TLS. | Approved profile, owner mapping, access review, deployment validation, revocation/recovery process, audit evidence. | Delegated execution allowed within explicit guardrails and review cadence. |
2 | Standard internal services, standard web/API workloads, routine device/user issuance, well-understood platforms. | Template-driven profiles, owner metadata, standard monitoring, standard evidence, standard access review. | Standard governance path; primary target for delegated operations at scale. |
3 | Legacy, lab, unknown ownership, isolated systems, decommission candidates, temporary test issuance. | Inventory cleanup, restricted profile use, short validity, explicit owner or remediation path. | Do not normalize weak controls. Remediate, retire, or time-box exceptions. |
Control baseline by tier
The following table defines the minimum control requirements for each tier across key governance areas. Use it to assess whether a certificate population's current controls meet the standard for its assigned tier.
Control area | Tier 0/1 baseline | Tier 2 baseline | Tier 3 disposition |
|---|---|---|---|
Profile approval | Central approval; material changes reviewed. | Approved standard profile. | Restricted or temporary profile only. |
Ownership | Business and technical owner; tested escalation path. | Technical owner and service/team owner. | Owner remediation required before production use. |
Key protection | KMS/HSM/platform-protected where supported; documented exception if not. | Approved platform key storage. | No high-risk key material without remediation. |
Delegation | Narrow, named, reviewed quarterly. | Scoped to business unit/platform. | Avoid delegation unless remediation use case. |
Audit evidence | Complete evidence pack; incident linkage; reviewable chain of approval. | Standard lifecycle evidence. | Evidence sufficient for cleanup/retirement. |
Exception approval | Governance board and risk owner. | PKI/security approval with review date. | Route to remediation or decommission plan. |
Review cadence | Monthly or quarterly depending on risk. | Quarterly or semiannual. | Until retired, reclassified, or remediated. |
Governance gate questions
Use the following questions to evaluate governance readiness:
Is this certificate population in an approved trust domain?
Is the CA source approved for the use case, environment, and certificate type?
Is there an approved profile with sufficiently narrow constraints?
Is the requester, service, workload, device, or delegated authority entitled to the namespace?
Are the owner, business unit, criticality, environment, platform, and exposure metadata complete?
Does the key generation and protection model satisfy the tier requirement?
Is the lifecycle action routine, material, emergency, or exception-driven?
Is the audit evidence sufficient to prove approval, issuance, deployment, and validation?
Is there an exit path if this CA, profile, or exception must be retired?