Certificate lifecycle governance
Trust Architecture Playbook: Governance pillar
Request and approval
Certificate request governance starts before enrollment. The requester must be entitled to the namespace, application, device, workload, or user population represented in the certificate. Approval should be based on policy, not on the requester knowing which button to click or which API to call.
Require requesters to identify service/application, owner, environment, criticality, platform, CA source, profile, domain/namespace, and deployment target.
Require owner approval for production, Tier 0/1, wildcard, broad SAN, user/device, privileged mTLS, and special-purpose certificates.
Use profile-level constraints to prevent requesters from self-selecting risky parameters.
Route requests that do not fit approved profiles to profile intake or exception review, not to ad hoc issuance.
Issuance
Issuance is the point where policy becomes a credential. Governance should verify that the issued certificate matches the approved profile catalog, allowed namespace, owner, and evidence requirements. Profile-specific rules are not repeated here; use Certificate profile and template governance as the source of truth. For manual or web-based issuance, approval evidence matters. For automated issuance, profile and identity constraints matter even more because the decision will repeat without human review.
Correlate issuance events to requester identity, service owner, profile, CA source, business unit, and certificate serial.
Alert on issuance outside approved profiles, unexpected CA sources, unsupported algorithms, unexpected SANs, or unusual volume.
Review public-trust issuance against CT logs monitoring and expected domain validation channels.
Ensure private-trust issuance is mapped to the correct root/intermediate and relying-party population.
Renewal, rekey, and reissue
Renewal governance should distinguish between renewing the same policy-approved credential and reissuing a certificate with materially different identity, key, CA, or profile characteristics. A certificate that changes SANs, key algorithm, issuing CA, profile, or deployment location may require a different approval path than a routine renewal.
Define what changes qualify as routine renewal versus material change.
Require rekey for key compromise, weak key material, key custody change, algorithm migration, or platform migration where appropriate.
Require approval for SAN expansion, wildcard addition, CA source change, EKU change, or movement to higher-risk environment.
Link renewal evidence to deployment validation and owner notification, not only CA issuance.
Use shorter renewal windows only when deployment validation and recovery paths are proven.
Revocation and suspension
Revocation governance defines when the organization must invalidate a certificate before expiration, who can make that decision, how the action is executed, how relying systems learn about it, and how replacement is coordinated. Public-trust revocation obligations are governed by external requirements. Private-trust revocation is governed internally, but must still be operationally credible.
Define revocation triggers: key compromise, unauthorized issuance, owner departure, service decommission, profile violation, CA distrust, domain loss, or policy breach.
Define who can approve and execute revocation by tier and trust domain.
Document replacement and rollback steps before revoking high-criticality certificates.
Monitor CRL/OCSP/status service availability where relying clients check status.
Record revocation reason, approver, time, replacement action, relying-party notification, and validation evidence.
Use suspension only where the trust model, CA capabilities, and relying applications have a documented and tested interpretation of suspended state.
Retirement and decommissioning
Certificate lifecycle governance does not end at expiration. Certificates and CA sources should be retired deliberately so that stale trust does not remain in inventory, trust stores, keystores, load balancers, automation profiles, CI/CD variables, or documentation.
Remove certificates from active endpoints and inventories when services are decommissioned.
Disable or retire profiles that no longer map to active use cases.
Remove trust anchors from trust stores when the relying population no longer needs them.
Retire connector credentials and service users for decommissioned CA sources or platforms.
Preserve evidence according to retention requirements after operational objects are removed.