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.
At a glance
What this is: ACME is a protocol for automating certificate issuance and renewal, and the key issue is whether that automation is governed tightly enough to avoid certificate sprawl.
Why it matters: It matters because certificate automation affects workload identity, service trust, and operational control, so IAM and security teams need clear governance around issuance scope and lifecycle.
Context
ACME is an automation protocol for certificate requests, renewals, and validation. The security problem it addresses is manual certificate handling, which is slow, inconsistent, and hard to scale across modern delivery pipelines and services.
For identity and access teams, the governance question is whether automated certificate issuance remains tied to a known workload, service, or environment, or becomes a source of unmanaged trust. That intersection matters wherever certificates function as machine identity rather than just transport security.
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. The goal is to make TLS available by default for short-lived systems without adding manual approval bottlenecks. Automation should be tied to identity ownership, inventory, and lifecycle rules, not just to faster delivery.
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. If scope, custody and revocation are unclear, the signing capability can be misused inside ordinary business automation before anyone notices.
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. Those are indicators that automation is working technically but failing as governance.
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.
Technical breakdown
How ACME automates certificate issuance and renewal
ACME defines a machine-readable workflow for proving control of a domain or service and then requesting, renewing, or revoking certificates without human ticketing. Instead of manually copying keys and certificates between teams, the client and CA exchange standard challenge and response messages. That reduces operational delay, but it also shifts trust into the enrolment and renewal path itself. The security value depends on how tightly the protocol client is bound to the workload, environment, and ownership model that is allowed to request certificates.
Practical implication: govern ACME clients as workload identities, not as convenience scripts.
Why certificate automation can create certificate sprawl
Automation removes friction, but it can also multiply certificates if issuance is easy and inventory is weak. In practice, certificate sprawl appears when short-lived operational convenience outruns policy on who may request certificates, for which domains, and under what lifecycle controls. The result is not just more certificates, but more trust anchors that security teams must track, renew, and retire. That becomes an identity governance issue because every certificate represents an authenticated machine relationship that should have an owner, scope, and offboarding path.
Practical implication: tie certificate issuance policy to inventory, ownership, and revocation workflows.
What changes when certificates become part of machine identity governance
When certificates are used as machine identity, the real control point is not the TLS handshake but the certificate lifecycle. Provisioning, renewal, rotation, and revocation determine whether the certificate still belongs to the intended service. That makes certificate automation part of broader NHI governance, especially where services, APIs, and build systems consume certificates at scale. The operational aim is to keep trust narrow and time-bound, so that automated issuance does not become a standing entitlement for every connected workload.
Practical implication: manage certificates through machine identity lifecycle controls, not only through PKI tooling.
NHI Mgmt Group 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.
Certificate sprawl is the governance failure mode that matters most. Once issuance becomes easy, organisations often discover that inventory, ownership, and retirement lag behind creation. That produces unmanaged machine trust even when the protocol works exactly as intended. The right question is whether teams can prove where each certificate belongs and who is responsible for its lifecycle.
ACME is relevant to NHI governance because certificates are machine credentials, not just transport artefacts. Where services authenticate with certificates, renewal automation becomes part of non-human identity control. That means lifecycle discipline, not just cryptographic strength, is what limits exposure. Practitioners should align ACME use with certificate ownership, revocation, and environment scoping.
Managed issuance requires managed scope. If ACME clients can request certificates broadly across pipelines or environments, automation can quietly expand trust faster than governance can review it. The practical lesson is that certificate automation must be bounded by policy, inventory, and clear offboarding, or it becomes another source of hidden machine privilege.
What this signals
Certificate automation should be assessed as a control surface, not a convenience feature. ACME reduces manual handling, but it also makes issuance easier to scale beyond the organisation's ability to track ownership and retirement. The practical question for security leaders is whether the same governance used for other machine credentials also covers automated certificate workflows.
Machine identity governance becomes the deciding factor once certificates are routinely issued by protocol rather than by ticket. If the lifecycle is not tied to inventory and environment scoping, the organisation can accumulate trust relationships it never meaningfully reviews. That is where certificate automation shifts from operational efficiency to governance debt.
For practitioners
- 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.
- Separate issuance policy from deployment convenience Keep ACME policy decisions in governance controls rather than letting application teams expand certificate issuance privileges informally.
Key takeaways
- ACME changes the operational model for certificates, but the governance problem remains ownership, scope, and lifecycle control.
- Automated issuance can reduce manual friction while still increasing certificate sprawl if inventory and revocation are weak.
- The most important control is not the protocol itself but the discipline around workload identity, certificate retirement, and offboarding.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Automated certificate lifecycles can still leave long-lived certificates in place if renewal and retirement are not governed. |
| NHI-05 — Overprivileged NHI | ACME clients become overprivileged when they can request certificates too broadly across workloads or environments. | |
| Recommendation — Use NHI-07 to enforce short-lived certificate lifetimes and retirement rules for workload identities. Apply NHI-05 to restrict certificate issuance permissions to named workloads and approved domains. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificates are authenticators whose issuance, renewal, and revocation require lifecycle control. |
| Recommendation — Implement IA-5 to govern certificate lifecycle, rotation, and revocation as managed authenticators. | ||
| CIS Controls v8 | CIS-5 — Account Management | Certificate automation depends on knowing which identities are allowed to request and keep credentials. |
| Recommendation — Use CIS-5 to maintain authoritative ownership and deprovisioning for certificate-bearing service identities. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Automated certificate issuance is governed by entitlement scope and authorization boundaries. |
| Recommendation — Apply PR.AA-05 to constrain certificate request entitlements to the minimum approved scope. | ||
Key terms
- ACME: ACME is a protocol used to automate certificate issuance and renewal between a client and a certificate authority. For practitioners, it reduces manual renewal work, but it also introduces a dependency on correct client configuration, credential handling, and monitoring of the automation path.
- Certificate Sprawl: Certificate sprawl is the uncontrolled growth of certificates across systems, services, and environments. It creates operational risk because each certificate becomes another trust object that can expire, duplicate, or remain unowned, making outages and governance failures more likely.
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
- Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect certificate lifecycle control to broader identity and access decisions across modern environments.
Published by the NHIMG editorial team on July 12, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org