Certificate Automation Considerations

The Problem

As certificate volumes increase and validity periods shorten, manual certificate management becomes increasingly unsustainable. Human-driven processes are inherently error-prone, difficult to scale, and often dependent on specialised knowledge held by a small number of individuals.

Missed renewals, misconfigurations, and inconsistent implementations can lead to service outages, security incidents, and significant business impact. In live environments, automation is no longer a convenience - it is a necessity for maintaining availability, reliability, security, and operational efficiency.

A wide range of automation approaches are now available, each offering different benefits in terms of complexity, flexibility, integration effort, and control. However, they can be placed into two main approaches: A central Push Model and the remote Pull Model. These techniques are discussed further below.

Note the term CLM (Certificate Lifecycle Manager) is used in this context to describe a technical Certificate Management platform or tool from either a commercial vendor (such as CertDog, KeyFactor Command and DigiCert Trust Lifecycle) or in-house developed scripts/applications that may provide a similar function. It does not include business/operational processes or wider technical integrations (e.g., Operational Monitoring tooling, or Security Incident and Events Management platforms).

The Options

Push Model - Advantages

• Centralised control. The CLM dictates when renewal happens, how installation works, and can enforce policies (e.g. key sizes and algorithms). Workflows can be created once for multiple end points. A single location from which to view and manage all certificates and one team can manage the certificate lifecycle process across the estate.

• Works with legacy systems. Devices that don’t support ACME, SCEP etc. can still be automated via SSH, WinRM etc.

• No endpoint configuration required. The endpoint doesn’t need a client, agent, or protocol support beyond allowing remote access.

• Removes load from end systems. The central CLM performs the all the heavy lifting.

• Immediate remediation. The CLM can push a replacement certificate instantly if something breaks.

• Ease of deployment. Agents/Sensors can be deployed to accommodate multiple network segments/domains.

• Centralised reporting, logging and alerting.

Push - Disadvantages

• High operational overhead. Requires maintaining credentials, firewall rules, remote access protocols, and endpoint connectivity.

• Agents or privileged access often required. Installing certificates usually needs elevated permissions, which complicates security posture.

• Security exposure. As device privileged accounts are held centrally, if this is compromised - so are all endpoints. WinRM/SSH/API access also increases attack surface.

• Scalability limits. Thousands of endpoints mean thousands of remote connections, retries, and orchestration complexity.

• Fragile in real-world networks. NAT, firewalls, offline devices, and network segmentation often break push workflows.

• Timings managed centrally. The central CLM decides when to renew certificates. As certificate rollover and installation may cause a disruption to services this could cause issues if the operation was not expected.

• Blurred boundaries of responsibility. When automation is introduced, it’s easy for ownership to become unclear unless it’s explicitly defined up front. You need agreement on who is accountable for certificate renewal —the team operating the CLM, the application owners, or the platform team.

• Vendor lock-in. Applications may use their own, bespoke mechanism that are not transferable between products.

Pull Advantages

• Highly scalable. Endpoints initiate requests only when needed. No CLM-to-endpoint orchestration.

• Minimal attack surface. No inbound remote access. Only outbound requests to CA/RA/CLM.

• Standards-based. ACME, SCEP, EST, and Auto‑enrolment are widely supported and vendor neutral.

• Resilient. Works even if the endpoint is offline for long periods; it renews when it comes back.

• Better for zero-trust and modern architectures. Endpoints authenticate using certificates, tokens, or device identity rather than SSH/WinRM credentials.

• Ideal for cloud, containers & IoT. Dynamic environments where push is impossible or impractical.

• Local requirements understood. Local operators will understand any specific requirements for the devices. 

• Clearer responsibilities. Operators configure the end point to obtain certificates. Misconfiguration, network changes will be flagged up by the end point during attempts to obtain certificates and can be dealt with by the operations team.

Pull Disadvantages

• Requires protocol support on the endpoint. Legacy systems may not support ACME/SCEP/EST without agents or custom integration.

• Initial onboarding may be complex. Bootstrapping trust (e.g. SCEP challenge passwords, EST bootstrap certs, ACME EAB) must be handled securely.

• Policy enforcement is indirect. You rely on the endpoint to follow renewal intervals and key-generation rules.

Considerations

When deciding on what approach to use, there are, as always, many things to consider. Below are some of the questions to ask to help decide on what approach may be best:

• Consider what resources are available. Is there a central Certificates/PKI/Crypto team who are already looking after your certificates and CAs. Could this team manage a centralised CLM.

• Consider the human elements. Do your infrastructure engineers have the knowledge and confidence to manage their system’s certificates. What would the split of responsibilities be?

• What is the make-up of the certificate consuming estate? Is it all Windows, is there a mix of operating systems, cloud and on-prem? Do hardware items also require certificate management? What level of network segregation is in place?

Ultimately, the right choice depends on the nature of your environment. If you manage a diverse estate with legacy systems and require tight central control, push may be more practical. If your infrastructure is modern, dynamic, or distributed - and you want to minimise operational overhead - pull is usually the more resilient long‑term strategy.

There is never a one-fits-all approach. A pull approach may be the right fit in certain circumstances, a pull in others and both in another.