Best Practices for Approval Workflows¶
Start Narrow, Expand Gradually¶
When first introducing approval workflows, resist the temptation to configure a catch-all (*) workflow that blocks every certificate operation. A broad workflow will generate high approval volume, fatigue approvers, and increase the risk of rubber-stamp approvals that undermine the control entirely.
Start with specific, high-value domains:
- Wildcard certificates (
*.example.com) - Production or customer-facing domains
- Domains associated with regulated systems
Once the approval process is running smoothly and approvers are familiar with the tooling, extend coverage to additional domains as needed.
Enable Bypass on Renewal for Automated Environments¶
Automated renewal processes — renewal threshold jobs, Bridge-driven certificate rotation, and ACME clients — are designed to run without human interaction. If these processes trigger an approval workflow, they will stall silently until the request expires or an approver manually acts on it.
For any workflow that covers domains managed by automated renewal, enable Bypass on Renewal. This allows the automation to continue while still requiring approval for new issuance requests.
If you need approval on renewals as well (for example, for compliance reasons), disable the bypass and ensure that your approval SLA is shorter than your renewal lead time so that certificates do not expire while waiting for a decision.
Set an Approval Timeout¶
Leaving approval requests open indefinitely creates operational risk. A certificate request that is silently stalled may not be noticed until a deployment fails or a service is unable to obtain a certificate it needs.
Configure an approval timeout on every workflow. The appropriate value depends on your internal SLA for certificate issuance:
| Scenario | Suggested timeout |
|---|---|
| Standard certificate request | 48–72 hours |
| Urgent or incident-driven request | 4–8 hours |
| Low-urgency or batch requests | 5–7 days |
For workflows where you cannot guarantee timely approval, consider whether the workflow should exist at all — a workflow with a very long or no timeout offers weaker guarantees than one with a defined SLA.
Keep Approver Lists Small and Current¶
Designate approvers who are genuinely responsible for the domain or system in question. Large approver lists create diffusion of responsibility — if ten people can approve, no one may feel obligated to act.
Review approver assignments when team members change roles or leave the organisation. A workflow with stale approver IDs will send notifications to former employees and delay legitimate requests.
For most workflows, one to three designated approvers strikes the right balance between coverage and accountability.
Use Required Approvals > 1 for Sensitive Domains¶
The Required Approvals setting enforces multi-person integrity. For certificate operations on sensitive systems — payment infrastructure, core authentication services, or systems in scope for regulatory compliance — requiring two approvals provides a meaningful control: one person cannot unilaterally authorise issuance.
Set required_approvals: 2 (or higher) for these cases. Ensure the approver pool is large enough that two approvers can act within your SLA even if one is unavailable.
Pair Approval Workflows with Certificate Policies¶
Approval Workflows and Certificate Policies serve complementary roles:
- Certificate Policies enforce field-level constraints at request time — key size, validity period, algorithm, wildcard restrictions. They evaluate the content of a certificate request.
- Approval Workflows pause the entire operation pending a human decision. They enforce who authorises a certificate operation, not what the certificate contains.
For sensitive domains, use both. A policy can enforce minimum security standards on the certificate attributes, while a workflow ensures an appropriate person reviews the request before it is dispatched.
Scope Revocation Workflows Carefully¶
Workflows with the revoke or both trigger block revocation as well as issuance. For most environments, requiring approval on revocation creates a risk: if a private key is compromised, the time to revocation now depends on an approver acting promptly.
Before adding revocation triggers to a workflow, consider:
- Is there a legitimate reason an unauthorised user could submit revocation requests that need to be reviewed?
- Does your incident response process account for the approval delay?
If revocation approval is required, set a short timeout (4–8 hours) and ensure approvers are reachable out-of-hours for incident scenarios.
Audit Approvals Regularly¶
Review the approval requests list periodically to:
- Identify patterns of repeated rejection for a particular domain or requester, which may indicate a process or configuration problem.
- Confirm that approved requests resulted in the expected certificate issuance.
- Verify that expired requests were followed up — an expired request means a certificate was never issued for a reason that was not recorded.
- Check for outliers: unusually rapid approvals may indicate rubber-stamping rather than genuine review.
The audit log retains the full decision history, including decision notes, the deciding user, and timestamps for all approval events.
Summary¶
| Guidance | Key point |
|---|---|
| Start narrow | Use specific domain patterns before catch-all |
| Enable bypass on renewal | Prevent blocking automated renewal jobs |
| Set timeouts | Define SLAs; do not leave requests open indefinitely |
| Keep approver lists small | Avoid diffusion of responsibility |
| Use required approvals > 1 for sensitive systems | Enforce two-person integrity where needed |
| Combine with policies | Policies enforce content; workflows enforce authorisation |
| Scope revocation workflows carefully | Short timeouts; plan for incident response |
| Audit regularly | Review decisions and expired requests periodically |