Define automation scope and tiers
Trust Architecture Playbook: Automation pillar
Discovery inventory
The discovery inventory is where automation decisions should be traceable back to: an inventory record that includes confirmed owner, known install locations, environment classification, platform mapping, and business relevance.
Certificates without complete inventory records must not move into production automation.
Shadow PKI, or certificates that are issued outside governed processes must be discovered and remediated before the services hosting them can be onboarded into automation.
Note
In the DigiCert® Trust Architecture Playbook, the Baseline pillar addresses discovery and shadow PKI remediation in detail. This volume assumes that work is underway and that the inventory is sufficiently mature to determine the initial automation cohort.
Criticality model
Criticality reflects several things: business impact, blast radius, identity sensitivity, and operational complexity, among others. Define a small number of tiers with documented criteria and require tier assignment for all certificates before automation is enabled.
Tier | Typical scope | Minimum controls | Automation priority | Required sequencing |
|---|---|---|---|---|
0 | Customer-facing, regulated, revenue-impacting, or identity-core services. | Highest rigor: protected keys where required, deterministic rotation, strong validation and rollback, change approval. | Automate first; highest operational investment. | Design first; automate in production only when every readiness gate is fully met and rollback is rehearsed. |
1 | Enterprise-critical internal dependencies: SSO, gateways, shared platforms, core security tooling. | High observability, standardized deployment, fast recovery procedures. | Automate early; high rigor. | Automate once deterministic deployment and ownership are proven. |
2 | Standard internal services and well-understood platforms. | Template-driven issuance, basic validation, monitoring and alerting. | Automate after Tier 0/1 patterns are proven. | Primary scale-out cohort. |
3 | Legacy, unknown ownership, isolated, lab environments, or decommission candidates. | Basic controls still required; inventory cleanup must precede automation. | Automate last or remediate and reclassify first. | Use for shakeout or remediation validation only. |
Tier definition worksheet
Define business impact and acceptable downtime for this tier.
Blast radius boundaries: what services or customers are affected by a certificate failure?
Minimum key protection requirements (software, KMS, HSM).
Minimum testing and validation requirements pre- and post-deploy.
Monitoring and alerting requirements including renewal and deployment confirmation.
Escalation requirements and recovery time objectives.
CA source constraints for this tier.
Crypto agility requirements: can services in this tier rotate on demand?
CA governance across multiple sources
Trust Lifecycle Manager is CA-agnostic, meaning it can automate and manage certificates from DigiCert, Sectigo, GlobalSign, Let's Encrypt, AWS Private CA, and Microsoft ADCS, among others, under a unified governance and policy framework. This ability alters the considerations around the operating model in two important ways.
First, organizations with existing CA relationships can bring those certificate populations under Trust Lifecycle Manager governance without migrating issuance. The governance model, profile controls, and operational runbooks described in this volume apply regardless of which CA issued the certificate.
Second, CA agnosticism enables vendor redundancy and reduces lock-in risk. Organizations can define the CA source per profile type and use Trust Lifecycle Manager's automation functions to switch CA for deployed certificates at any time. Governance requires central approval of each CA source on a per use case basis. New CA sources aren’t introduced without PKI review.
Important
Key takeaways
Maintain a CA source registry: approved CA per certificate type, environment, and trust requirement.
Define profile constraints that apply regardless of CA source: key parameters, validity caps, SAN rules, EKU constraints.
Document CA-specific operational differences: OCSP responder endpoints, CRL distribution points, chain requirements, and any protocol constraints that affect automation.
Test automation paths against each approved CA source independently: do not assume equivalent behavior.