Full automation is powerful — but in the age of 47-day certificates, it can also be dangerous without the right controls underneath it. The teams discovering this the hard way are the ones who treated automation as the end state, rather than the foundation for a governance layer.
Tools like cert-manager, Certbot, and ACME-based renewal scripts have made certificate issuance frictionless. That's mostly good. An expired certificate causes a production outage; automation prevents that. For renewal of existing certificates, automation should be the default.
The problem shows up at the edges: new certificate requests, expanded scope (a wildcard where there was a single-name cert before), unusual CAs, or requests that cross organizational boundaries. These are the requests where a human seeing the certificate before issuance can prevent a problem that automation would happily create.
A Kubernetes developer with cluster RBAC can submit a Certificate manifest for *.prod.example.com. cert-manager will issue it without question — because cert-manager has no concept of whether that request should have happened. The security team never saw it. It doesn't appear in any audit trail. If the private key is later leaked, the blast radius is your entire production domain.
Certificate misissuance gets discussed mostly in the context of public CAs accidentally issuing certificates for domains they shouldn't have. But internal misissuance — certificates issued by your own PKI infrastructure for things they shouldn't cover — is far more common and far less visible.
Real examples from production environments:
None of these required a malicious actor. All of them are governance failures that a human in the loop would likely have caught.
With 47-day certificate lifetimes arriving in phases, the volume of certificate operations is increasing dramatically. Each renewal is another opportunity for drift — a scope change slipping through, a configuration error propagating, a key that was supposed to be rotated but wasn't.
At annual renewal, security teams could (in principle) manually review each certificate before issuance. At 8× annual renewal, that's not realistic. But that doesn't mean automation should run without any oversight — it means the oversight needs to be smarter and more targeted.
The goal isn't to slow everything down. It's to add the right amount of control exactly where it matters — and get out of the way everywhere else.
The pattern that security-mature organizations have converged on is tiered approval — different levels of scrutiny based on risk, not blanket automation or blanket manual review.
| Request type | Risk level | Approval path |
|---|---|---|
| Renewal of existing cert, unchanged scope | Low | Auto-approve |
| New cert for dev / staging domain | Low | Auto-approve |
| New cert for production domain | Medium | Security team approval |
| Wildcard certificate | Medium–High | Security lead + justification required |
| External-facing cert from internal CA | High | Multi-level review |
| Certificate for sensitive internal service | High | Multi-level review + CISO notification |
The key insight is that the majority of certificate operations — especially renewals — can be fully automated with no human involvement. The governance layer only activates for the minority that carry real risk.
An approval workflow that doesn't produce a durable record is just a speed bump. For the audit trail to have value — for compliance reports, for incident investigation, for demonstrating control to auditors — each approval needs to capture:
This record needs to be immutable. An audit trail someone can edit after the fact is not an audit trail.
SOC 2 CC6 requires evidence that logical access to systems is authorized and reviewed. PCI-DSS requirement 4 requires that cryptographic keys and certificates used for transmission security are managed under a documented process. ISO 27001 A.10.1 requires that cryptographic controls are managed with appropriate procedures and approval.
In practice, auditors asking about certificate management want to see: a policy stating who can approve certificate issuance, evidence that the policy is enforced, and a record of actual approvals tied to actual certificates. A spreadsheet doesn't cut it at any meaningful audit maturity. An automated governance layer that captures the full approval chain does.
The failure mode of manual approval workflows is bypass. When the approval process is slow or unclear, teams route around it — requesting certs directly from the CA, using a development certificate in production, or deploying with a self-signed cert "temporarily" that never gets replaced.
A governance layer that sends approvers a clear notification, shows them exactly what's being requested and why, and lets them approve in one click from a mobile browser will get used. One that requires logging into a separate portal, navigating to the right queue, and filling out a form will get bypassed.
The goal is approvals that take under two minutes for a low-context approver — because the request contains everything they need to make the decision.
CertForge approval workflows
Trust Profiles define auto-approve conditions. Everything outside those conditions goes to a named approver — with Slack, Teams, or email notification, a full view of the request, and one-click approve/reject. The full audit trail is signed and exportable. Works with cert-manager, direct API requests, and MCP-based agent requests.
Start free — no credit card