Automation profile and policy governance
Trust Architecture Playbook: Automation pillar
Certificate profiles translate governance intent into operational reality. A profile is not a template in the administrative sense but rather it’s an enforcement boundary. It defines what certificates can be issued, to whom, under what authorization, for what purpose, from which issuing CA, with which cryptographic parameters, and for how long. When profiles are designed correctly and tied to business units, certificate owners, and environment boundaries, they transform PKI policy from a document that lives in a SharePoint folder into a control that’s enforced on every issuance event, across every enrollment, regardless of which team or which automation pattern initiated the request.
This matters across the entire certificate estate, not just for public-trust TLS, and not just for the services that are actively being onboarded to automation. A profile governance framework that only covers the certificates you are actively managing leaves the rest of the estate: legacy services, third-party integrations, shadow PKI remnants, and the certificates that teams issued through unofficial channels operating entirely outside policy. Those certificates will expire, be renewed manually, be renewed incorrectly, or be discovered during an audit or an incident. None of those outcomes is acceptable at enterprise scale.
Designing the profile catalog
The profile catalog should be deliberate and actively maintained. Define the minimum number of profiles that cover your approved use cases factoring in separated environments, trust type, enrollment method, and issuing CA and govern them with the same rigor you would apply to any critical enterprise control. Require explicit approval for new profiles. Review existing profiles on a defined cadence and retire those that are redundant, overly permissive, or no longer tied to an active business need. Profile sprawl is not a minor inconvenience it’s a governance failure that compounds.
Getting the profile and policy layer right from the start is vital. Everything else in the automation program: the patterns, the pipelines, the integrations, the delegated execution model, they all operate within the boundaries that profiles define. If well-designed, automation enforces policy at scale; if not, automation scales the problem. The following sections provide example baselines and reference controls for defining, enforcing, and auditing automation profiles and their associated policies across the enterprise.
Profile governance baseline
Define the least number of approved profiles required by environment, trust type, issuing CA, cryptographic parameters, validity, and enrollment method.
Establish a consistent naming convention for profiles that is meaningful and supports operational continuity during PKI admin turnover or responsibility transfers.
Separate production from non-production profiles. Require explicit approval for broader SAN or namespace scope.
Constrain profiles further with allowlists, naming rules, or approval workflows.
Tie profiles to business units, certificate owners, and custom attributes used for reporting and exception tracking.
Review usage periodically and retire redundant or higher-risk profiles to prevent profile sprawl.
For multi-CA environments, ensure profile constraints apply regardless of CA source.
Minimum profile elements
Profile element | Guidance |
|---|---|
Key algorithm and size | Define allowed algorithms and key sizes by tier. RSA-2048 minimum for Tier 2/3; RSA-3072 or ECDSA P-256/P-384 for Tier 0/1. Plan for post-quantum algorithm migration. |
EKUs and certificate type | Constrain to intended usage. Server authentication, client authentication, and mTLS profiles should be distinct. |
Subject / SAN constraints | Domain allow-lists or namespace rules. No wildcard SANs for Tier 0/1 without explicit approval and documented blast radius. |
Validity and renewal window | Align to operational renewal capability. Public trust: follow CA/Browser Forum maximums (currently 90 days; plan for 47). Private trust: define by use case and rotation capability. |
Key generation and protection | Tier 0/1: require KMS or HSM-backed key generation where the platform supports it. Define acceptable key storage for each tier. |
CA source | Specify approved CA source per profile. Document CA-specific chain requirements and OCSP/CRL configuration. |
Authorization and identity baseline
Use dedicated service users, automation credentials, ACME accounts, and connector identities rather than shared human accounts.
Grant least privilege: approved profiles, domains, environments, and actions only.
Keep break-glass access separate from day-to-day automation identities with distinct controls, approval paths, and audit requirements.
Store automation credentials in approved secret stores (vaults or PAM platforms).
Define procedures for disabling and rotating compromised or retired automation identities.
Require proof of domain or namespace control before enabling delegation.
Monitor for anomalous issuance patterns and unexpected profile usage.
Logging and audit baseline
Capture who or what requested issuance, which profile was used, what certificate was issued, where it was deployed, and how deployment was validated.
Correlate lifecycle events with inventory records, service ownership, and incident tickets.
Plan ingestion of Trust Lifecycle Manager audit data into SIEM or central logging for operational and compliance reporting.
Retain evidence on a defined schedule.
Revocation strategy
As certificate validity periods shorten, revocation strategy becomes more operationally relevant. Organizations should define their revocation posture as part of profile design, not an afterthought.
Multi-CA environments: Document CA-specific CRL and OCSP endpoint differences. These affect trust store configuration and may require different monitoring approaches per issuing CA.
Private-trust certificates: Define OCSP responder availability requirements as part of the internal CA architecture. An unavailable OCSP responder can degrade service for OCSP-checking clients.
Short-lived certificates (workload identity, service mesh) may eliminate the operational need for revocation, but this requires that the issuance and rotation pipeline is reliable enough that expired certificates do not linger in production.