TL;DR: ACME protocol standardises how certificate requests, renewals, and validation are automated, reducing manual handling across DevOps and certificate operations according to GlobalSign. The governance issue is not automation itself but whether teams can prove identity, scope issuance tightly, and prevent unmanaged certificate sprawl.
Editorial analysis by NHI Mgmt Group, based on content published by GlobalSign: “Sarah Topping”.
Key questions
Q: How should security teams automate certificate management in DevOps environments?
A: Security teams should embed certificate issuance, renewal, and revocation into orchestration and deployment workflows so certificates follow workload creation and teardown.
Q: Why do automated signing certificates create governance risk?
A: Because software can invoke them repeatedly without human presence, so the certificate behaves like a non-human identity with delegated trust.
Q: What are the signs that certificate automation is creating sprawl?
A: Watch for multiple certificates serving the same workload, unclear ownership, renewal handled outside the normal lifecycle process, and certificates that remain valid after a service is retired.
Practitioner guidance
- Scope ACME clients to named workloads Restrict certificate request permissions to specific services, hosts, or deployment identities instead of shared automation accounts.
- Track certificate ownership and inventory Maintain an authoritative record of which workload, environment, and team owns each certificate so renewal and revocation are not guesswork.
- Align renewal with revocation controls Automate renewal where appropriate, but pair it with fast revocation and offboarding so abandoned certificates do not persist after service changes.
Bottom line: ACME changes the operational model for certificates, but the governance problem remains ownership, scope, and lifecycle control.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Certificate automation only improves security when issuance is treated as governed identity lifecycle, not convenience infrastructure. ACME removes manual bottlenecks, but it does not decide which workloads are entitled to certificates or when those certificates should expire. In identity terms, the danger is that automation shifts the failure point from request handling to policy design. Practitioners should treat certificate issuance as a governed entitlement with ownership, scope, and revocation rules.
A question worth separating out:
Q: How should organisations govern certificates alongside NHI controls?
A: They should treat certificates as part of the wider non-human identity estate and govern them with the same discipline used for service accounts and API credentials. That means assigning ownership, limiting scope, tracking lifecycle events, and proving revocation. Certificate governance should sit inside identity operations, not beside it.
👉 Read our full editorial: ACME protocol overview: what it changes for certificate automation