Operating model and RACI for automation
Trust Architecture Playbook: Automation pillar
Most enterprises need both centralized control and delegated execution. Over-centralizing creates bottlenecks that push teams toward shadow PKI and unmanaged workarounds. Over-delegation without guardrails produces issuance sprawl and elevates identity and outage risks. A sustainable operating model must balance tasks like central ownership assignment for policy as well as delegated ownership for reliable execution.
Central vs. delegated responsibilities
Operating area | Central team responsibilities | Delegated team responsibilities |
|---|---|---|
Policy and profile governance | Define approved certificate profiles, naming standards/constraints, key parameters, validity, and separation of production and non-production. | Use only approved profiles and route exception requests through governance review. |
Identity and access | Create service users, roles, business units, and least-privilege authorization boundaries. | Protect credentials locally, rotate them, and use only approved identities for automation and deployment. |
Pattern selection | Approve which Trust Lifecycle Manager automation patterns are allowed for which platforms and risk tiers. | Implement the chosen pattern, document the deployment path, and maintain target-specific validation. |
CA relationship management | Govern which certificate authorities are approved for which use cases. Trust Lifecycle Manager is CA-agnostic and can manage certificates from DigiCert, Let's Encrypt, Sectigo, Amazon, Microsoft ADCS, and others under a unified policy framework. | Use only approved CA-profile combinations. Don’t introduce new CA sources without central approval. |
Operations and incidents | Define dashboards, routing, evidence retention, and break-glass policy. | Operate validation, monitor outcomes, remediate failures, and keep inventory mappings accurate. |
Guardrails: Non-negotiable controls
As a baseline, the following controls should be considered non-optional and are not subject to exception without PKI governance review:
Require the use of defined certificate profiles/templates for all automation.
Limit automation identities to minimum required privileges, scoped only to approved profiles, namespaces, or domains.
Log all certificate lifecycle actions from issuance to deployment to validation and correlate to intended deployment targets. Issuance by itself doesn’t confirm deployment.
Keep break-glass procedures clearly defined, regularly test them, and ensure fully auditability, who is authorized, under what conditions, and via which workflow.
Responsible, Accountable, Consulted, Informed (RACI)
Activity | Central PKI / Security | Platform / Infra | App / Service owner | Compliance / GRC |
|---|---|---|---|---|
Define profiles and constraints | R/A | C | C | C |
Approve delegation scope | R/A | C | C | C |
Approve CA source for use case | R/A | C | I | C |
Implement deployment mechanisms | C | R/A | C | I |
Renewal and failure response | C | R/A | R | I |
Maintain inventory accuracy | C | R | R/A | I |
Audit evidence and reporting | C | I | I | R/A |
Break-glass execution and review | R/A | C | C | C |