Certificate Issuance Workflows
Certificate issuance is where most enterprises first encounter the operational reality that certificate management is not a single workflow. Different services need different issuance patterns. Forcing a single workflow across the estate produces either bottlenecks (where automation could have served) or compliance gaps (where automation should not have).
Part of: Enterprise PKI Operating Model — the pillar page for the operations library.
There are two primary issuance patterns. The mature operating model runs both, with explicit rules for when each applies. The pattern choice is part of the operating model, not an artefact of the tooling.
PKI Health Radar
Drag the sliders to assess your current posture — scores update instantly.
The two patterns
Combined workflow — developer-driven, automated end-to-end. The service requests its own certificate at the moment it needs one, the request is fulfilled automatically against pre-defined policy, the certificate is delivered to the service's filesystem or secret store without human intervention. This is the ACME pattern, the cert-manager pattern, the EJBCA REST pattern, the Vault PKI pattern. The service handles its own renewal because it never stopped owning the certificate.
Admin-mediated workflow — request, approve, fulfil. The service team raises a request through a ticketing system or service catalogue, an authorised approver reviews and approves, the operations team or an automated fulfilment process issues the certificate, and it is delivered to the requestor through a documented channel. This is the legacy pattern that pre-dates ACME, and it remains the right pattern for several specific use cases described below.
The two are not competitors. They are operational tools for different problems. An organisation that runs only combined workflow has compliance gaps for high-assurance certificate types. An organisation that runs only admin-mediated workflow has issuance bottlenecks for high-velocity services. Mature operations run both, with the routing decision encoded in the issuance policy.
When combined workflow is correct
Combined workflow is the right pattern when four conditions are met:
Policy can be encoded. The issuance policy — algorithm, key size, validity period, allowed Subject Alternative Names, allowed CA, profile selection — can be expressed as automated rules. If a human needs to make a judgement call on each issuance, automation cannot perform that judgement. Combined workflow assumes the policy decisions have been made in advance.
The service can prove its identity to the issuance system. Combined workflow requires automated authentication: the requesting service must be able to prove it is who it claims to be. ACME does this through the HTTP-01, DNS-01, or TLS-ALPN-01 challenges. Service mesh patterns do this through mTLS or workload identity. Cloud-native patterns do this through cloud IAM. Without a strong identity proof, combined workflow becomes an issuance API anyone can call.
The service handles its own renewal. Once the certificate is issued, the service must be able to renew it without human intervention. This requires either an in-process automation (cert-manager, ACME client, sidecar) or an external automation that monitors the certificate and triggers renewal. Combined issuance with manual renewal is the worst of both worlds.
The blast radius of mis-issuance is acceptable. If a misconfigured service can issue a certificate that breaks something important, combined workflow needs additional controls — typically rate limits, allowlists, or staged validation. For most TLS certificates serving normal services, the blast radius is bounded; the certificate works or it doesn't. For code-signing certificates, EV certificates, or certificates for critical infrastructure, the blast radius is structural and overrides the other criteria — these stay admin-mediated regardless of how cloud-native the rest of the estate is.
When all four conditions are met, combined workflow is dramatically more efficient than admin-mediated workflow. The service issues its own certificates as needed, renews them automatically, and the operations team is involved only in policy maintenance and exception handling.
When admin-mediated workflow is correct
Admin-mediated workflow is the right pattern when one or more of these conditions apply:
The certificate is high-assurance. Code-signing certificates, EV TLS certificates, certificates for critical infrastructure, certificates that bind a corporate identity to a service. These require explicit human approval as a control. Automating issuance of these certificate types creates a control gap that auditors will identify.
The service cannot prove its identity automatically. Legacy services, third-party-managed services, services running in environments without integrated identity. The service team raises a request, the operations team verifies the request manually, the certificate is issued. This is operationally heavier but it is the right pattern when automated identity proof is unavailable.
Issuance volume is genuinely low. A small number of services with infrequent renewal cycles do not justify the engineering cost of combined-workflow integration. The break-even point is roughly: if a service team would spend more time integrating with the automation than they would spend over five years on manual requests, manual is correct. The break-even point is lower than most people assume because integration cost is high and tickets are cheap until volume scales.
The certificate has organisational policy implications. A new service requesting a certificate that introduces a new domain, a new CA relationship, a new compliance scope, or a new third-party trust relationship. These should not be automated; they should trigger explicit governance review.
The mature operating model classifies certificate types in advance and routes each type to the appropriate workflow. Most enterprises have between three and seven distinct issuance categories.
The combined workflow operational pattern
For the certificate types routed to combined workflow, the operational structure has five components:
Policy definition. Certificate templates or profiles encode the allowed parameters: which Subject Alternative Name patterns are permitted, which validity periods, which key types and sizes, which extensions, which CA. The policy is the authority for what can be issued.
Identity verification. The mechanism by which the requesting service proves identity. ACME challenges for public certificates. Cloud IAM (IRSA in AWS, Workload Identity in GCP) for cloud-native services. mTLS or service-mesh identity for inter-service communication. The identity verification has to be at least as strong as the certificate itself, or the certificate adds nothing to security.
Issuance API. The interface the service uses to request certificates. ACME is the dominant standard for external CAs. EJBCA's REST API, Vault's PKI secrets engine, and AWS Private CA's API are common for internal CAs. The mature pattern is a single issuance interface that abstracts across underlying CAs, so that services request certificates without needing to know which CA will fulfil the request.
Delivery mechanism. How the issued certificate reaches the service. Direct API response (the service receives the certificate inline). Filesystem delivery (the certificate is written to a defined path). Secret store delivery (Vault, Kubernetes Secrets, AWS Secrets Manager). Each mechanism has operational implications for renewal and rotation.
Renewal automation. The mechanism that ensures the certificate is renewed before expiry. Self-monitoring services (cert-manager watches its own certificates and renews them). External monitoring (a renewal service watches certificates across the estate and triggers renewal). The renewal automation is part of the issuance design, not an afterthought.
The admin-mediated workflow operational pattern
For certificate types routed to admin-mediated workflow, the operational structure is different:
Service catalogue entry. The request channel — typically a ServiceNow form, a Jira workflow, or a dedicated service portal. The form captures all the information required for issuance and approval: requestor, service identity, certificate purpose, technical parameters, business justification.
Approval routing. Different certificate types route to different approvers. Standard internal certificates may approve at the team-lead level. EV certificates may require approval from the CISO and a finance role (because of the EV vetting cost). Code-signing certificates may require approval from compliance and the executive owner of the signing identity. The routing is encoded in the workflow.
Validation and fulfilment. The operations team (or an automated fulfilment service) validates the approved request, generates the certificate, and delivers it through the documented channel. For high-assurance certificates, this includes additional vetting: domain ownership verification, organisation verification, identity verification.
Delivery and acknowledgement. The certificate is delivered to the requestor. The requestor acknowledges receipt and confirms successful deployment. The acknowledgement closes the request and triggers the renewal-tracking record.
Renewal tracking. Because the requestor is responsible for renewal, the operations team tracks the upcoming expiry and notifies the requestor in advance. The notification cadence is part of the operating model — typical patterns are 90, 30, and 7 days before expiry, but the right cadence depends on the typical lead time for the requestor to respond.
The routing decision
The routing logic — which certificate types go to which workflow — is encoded in policy and enforced at the issuance layer. The decision parameters:
Certificate purpose. TLS for internal services, TLS for external services, mTLS for service-to-service, code signing, document signing, client authentication, device authentication, S/MIME. Each has its own assurance requirements and its own workflow fit.
Certificate authority. Public CAs (Let's Encrypt, Sectigo, DigiCert) and private CAs (internal AD CS, EJBCA, Vault, AWS Private CA) have different cost profiles, different policy controls, and different workflow integrations. The CA choice influences the workflow choice.
Validity period. Short-lived certificates (24 hours, 7 days, 90 days) make automation mandatory; the renewal frequency is too high for any manual process. Long-lived certificates (1 year, 397 days, 825 days for some private CAs) tolerate manual workflows.
Service identity capability. Whether the requesting service can prove identity automatically. Cloud-native services typically can; legacy on-premise services often cannot. Service identity capability is the gating factor for combined workflow.
Blast radius. The scope of damage from mis-issuance. Low blast radius (a single internal service) tolerates aggressive automation. Medium blast radius (a customer-facing service) tolerates automation with monitoring. High blast radius (a code-signing certificate that signs every release; an EV TLS certificate for the corporate identity; a CA-signing certificate) does not tolerate automation regardless of how the rest of the estate is configured. Blast radius is the override parameter — it overrides the other four when it is high.
Medium-blast-radius certificate with adequate organisational tolerance. Combined workflow is appropriate provided additional controls are in place: rate limits, anomaly monitoring, and audit logging of every issuance.
Note: Document the controls as part of the issuance design. Without explicit controls, "combined with monitoring" becomes "combined" in practice.
EV TLS certificates bind a corporate identity to a service. The vetting that EV requires is itself a manual control and cannot be automated.
Note: Treat as a high-assurance certificate type with named approver, documented vetting, and explicit logging of every issuance.
Low-blast-radius certificate with adequate service identity. Combined workflow is the right fit — fast issuance, automated renewal, and the operations team focused on policy maintenance rather than per-request approval.
Low-blast-radius certificate with adequate service identity. Combined workflow is the right fit — fast issuance, automated renewal, and the operations team focused on policy maintenance rather than per-request approval.
Code-signing certificates require explicit human approval as a structural control. Automated issuance creates a control gap that auditors will identify.
Note: Treat as a high-assurance certificate type with named approver, documented vetting, and explicit logging of every issuance.
Service identity verification is weak. Combined workflow with weak identity creates a false sense of security — the certificate is only as strong as the identity proof that authorised it. Admin-mediated provides the human verification step that compensates.
Note: Long-term, invest in stronger service identity (mTLS, cloud IAM, service mesh identity) so this certificate type can migrate to combined workflow.
Where issuance workflows break
One-size-fits-all routing. Forcing all certificate types through combined workflow creates compliance gaps for high-assurance types. Forcing all through admin-mediated creates bottlenecks for high-velocity services. Both failure modes are predictable and both are common. The fix is parameterised routing — classify each request by assurance requirement and velocity sensitivity, then route to the workflow that matches.
Workflow drift. The issuance workflow was defined two years ago when the estate was different. New service patterns have emerged (Kubernetes, service mesh, edge functions, ephemeral workloads) that don't fit the original workflow design. The operations team has been adding ad-hoc exceptions; the workflow is now a series of special cases rather than a coherent design. The fix is periodic workflow review — recognise that issuance patterns evolve with the estate and redesign the workflow rather than accreting exceptions.
Approval-as-rubber-stamp. Admin-mediated workflows that require approval but where the approval is mechanical — every request gets approved, no requests are challenged. The approval step adds latency without adding control. The fix is to either remove the approval step or strengthen it with explicit criteria the approver must verify; the rubber stamp is operational theatre.
Identity verification weaker than the certificate. Combined workflow with weak service identity (e.g., shared API keys, IP-based authentication) creates a false sense of security. The certificate is only as strong as the identity proof that authorised its issuance. The fix is to align identity-verification strength with certificate assurance — high-assurance certificates require strong service identity (workload identity, attestation), not shared secrets.
Underestimated rework cost. Admin-mediated workflows accumulate hidden cost in rework — tickets that need fixing before fulfilment — and reopens — tickets closed but reopened because the certificate didn't work. Reopen rates of 15–25% are typical and rarely tracked. The fix is to instrument rework and reopen rates explicitly and surface them in the cost model, so the true cost of admin-mediated workflow is visible when comparing to combined-workflow alternatives.
Time per ticket
Total effective time per ticket: 14.3 hours. Hidden time (rework + reopens) is 19% of base time.
Annual cost
Migration projection
If approximately 70% of admin-mediated volume migrates to combined workflow:
Estimated migration cost: £1.70M. The model assumes 70% of admin-mediated volume can move to combined workflow given typical estate composition; high-blast-radius certificate types should remain admin-mediated.
Maturity progression for issuance workflows
The five-level PKI operational maturity model introduced in the pillar maps onto the issuance domain as follows.
Level 1 — Ad-hoc. A single workflow handles all certificate requests, usually a generic IT ticket queue. No classification of certificate types. Every request goes through manual handling regardless of urgency or assurance level. Combined workflow does not exist as a concept; all issuance is admin-mediated by default.
Level 2 — Tooled. A CLM platform has been deployed. Some certificate types use combined workflow, typically public TLS via ACME. Most still go through tickets. Routing happens by team preference rather than by policy — teams that figured out how to use cert-manager use it; others still raise tickets.
Level 3 — Operationalised. Both workflows are defined and routed. Certificate types are classified into routing categories. The operations team knows which types use which workflow. Routing decisions are made by humans against documented criteria, but the criteria themselves are explicit and the routing matrix is part of the operating model documentation.
Level 4 — Integrated. Routing is policy-driven with automated classification. The issuance system itself classifies the incoming request based on certificate purpose, requestor identity, blast radius, and other parameters, and routes it to the appropriate workflow without human intervention. Exceptions surface to the steering function rather than being handled silently. New service patterns are onboarded by adding to the policy, not by adding new workflows.
Level 5 — Intelligent. Routing is data-driven. The system tracks which patterns succeed and which fail, and the routing policy is updated on a feedback loop. High-velocity issuance happens with appropriate controls. Policy violations are detected and flagged before issuance reaches the CA. The routing decision is increasingly invisible because the policy is increasingly correct.
Most organisations are between levels 1 and 2 on issuance workflows, with a CLM tool deployed but ad-hoc routing in practice. The progression to level 3 is achievable within three to six months once the routing policy is explicitly documented and the operations team is briefed on it.