Seven common automation missteps that put your SSL/TLS certificates at risk
As SSL/TLS lifespans shrink to 47 days, outdated automation strategies put certificates and businesses at risk. From relying on centralized vaults to overusing wildcard certificates, PKI teams often confuse request portals with true lifecycle automation. These seven common missteps reveal why many organizations still face outages, compliance failures, and security gaps. The solution? End-to-end automation that covers discovery, issuance, deployment, and renewal reducing risk while scaling crypto agility.
Table of Contents
Executive summary
Misstep 1: Centralized key management is not automation
Misstep 2: Request-only workflows are not automation
Misstep 3: Format worries stall automation
Misstep 4: Change management bottlenecks break automation
Misstep 5: Treating ITSM as CLM blocks automation
Misstep 6: Reusing certificates across locations undermines security
Misstep 7: Trying to solve everything at once
Closing thoughts
Executive summary
As certificate lifespans shrink to 47 days, the pressure lands squarely on PKI administrators. You already know the risks: expired certificates mean outages, fire drills, and late-night calls. Our Global Director of Sales Engineering, Brendan Bonner, weighs in with seven common missteps he sees with clients that are putting their certificates at risk.
The problem is that teams are tackling today’s 47-day certificate challenge with outdated, one-year solutions. They stitch together portals, scripts, or IT service management (ITSM) workflows that resemble automation but fall short. Too often, it’s “automation” only for the PKI administrator. Certificates land in a central vault, but system, cloud, and network admins still have to retrieve and install them manually. That may check a box for PKI, but it doesn’t solve the real issue for the business.
There is also the false economy of wildcards. A $100 wildcard may appear cost-effective compared to single-domain or multi-domain certificates, but those savings can quickly evaporate. When a wildcard expires or gets compromised, it can easily escalate into a million-dollar outage or breach. In fact, some businesses, such as private equity firms, now demand their portfolio companies remove wildcard certificates entirely after repeated costly failures.
I have seen this firsthand. In one instance, a large enterprise believed they had automation until Sectigo pulled it apart and found they only had a portal for certificate requests. No deployment. No renewals. Just requests.
The reality is that true end-to-end automation already exists. For many administrators, the breakthrough comes the first time they see a certificate deployed directly from an interface without ever logging into the web server. The next realization is that setting up automation is often faster than continuing with manual installations.
This blog explores seven common automation missteps that slow teams down, and how to approach automation in a way that is practical, forward-thinking, and sustainable.
Misstep 1: Centralized key management is not automation
The problem: Centralized key vaults worked when certificates lasted a year or more. PKI administrators could stash certificates, and application teams pulled them when needed.
Where it falls short: In practice, most organizations do not have certificates deployed to endpoints with automation. Instead, system administrators, cloud administrators, and network administrators still must pull the certificate from the vault, download it, and install it manually. That may feel like automation to the PKI administrator, but it does not scale in a 30-to-47-day renewal world. It also spreads the private key into multiple locations instead of keeping it bound to the device.
A better path: Push automation to the edge. True automation issues certificates directly to the device. The private key never leaves, the certificate signing request (CSR) goes securely to the Certificate Authority (CA), and renewal and installation happen end-to-end.
Misstep 2: Request-only workflows are not automation
The problem: Many organizations call themselves “automated,” but in reality what they have built is faster requests. A CSR may auto-generate and flow to the CA, but someone still must log in, download, and install the certificate.
Where it falls short: It is progress, but only halfway. Certificates pile up waiting for clicks, and outages happen when that “last mile” does not get finished. One large enterprise I worked with believed they were automated until we discovered their process was only a request portal. No deployment. No renewal.
A better path: Automation should cover the full lifecycle: request, issuance, installation, and renewal. If your team is still logging in every cycle, you have only solved part of the problem.
Misstep 3: Format worries stall automation
The problem: Teams stall automation because of certificate formats: PFX, PEM, PKCS#12. They worry about incompatibility or lock-in.
Where it falls short: This “format paralysis” delays progress while certificates continue to expire.
A better path: Use a certificate lifecycle manager (CLM) that supports multiple formats natively. Automation should deliver certificates in whatever format the device requires without extra work from your team. Simply don’t worry about it, automate it.
Misstep 4: Change management bottlenecks break automation
The problem: Change management is essential but often applied too literally to certificates. Some organizations create change requests for every renewal, requiring administrators to log in and approve or install a certificate every 30 to 40 days.
Where it falls short: That is not governance: it is button-click automation. It creates delays, wastes administrator time, and breaks completely during change freezes, when certificates can still expire.
A better path: Keep change management where it belongs: approving automation workflows during setup, with the right checks and balances. Once automation is approved, let it run.
A real-world example: Sectigo worked with a PKI administrator who understood the risks of tying renewals to change management, but their InfoSec team pushed back. They believed every renewal approval was necessary for security. In theory, they were not wrong: governance matters. In reality, the process they enforced created more risk with certificates still expiring during freezes. After careful discussion and weighing the trade-offs, they recognized that automation with strong logging was the safer path forward.
Misstep 5: Treating ITSM as CLM blocks automation
The problem: Many organizations try to rebuild certificate management inside ITSM platforms like ServiceNow or Remedy. It feels logical to track certificates like other assets, but ITSM platforms were not built for full certificate lifecycle management.
Where it falls short: ITSM systems can log certificates and tie them to inventory, but they cannot discover, renew, or deploy them at the speed of 47-day cycles. I have worked with clients who invested in custom ITSM workflows, only to abandon them later because of the development and management overhead.
A better path: Use ITSM for governance and visibility but let CLM do what it is built for: discovery, issuance, deployment, and renewal. Sectigo, for example, integrates directly with ServiceNow (and other ITSMs through APIs) so you get the best of both worlds: records in ITSM, automation in CLM, and less overhead overall. Use as many off the shelf integrations as possible.
Misstep 6: Reusing certificates across locations undermines security
The problem: Some organizations still use the same certificate and key pair across multiple servers. They will automate to one server, then copy it to others.
Where it falls short: This undermines both security and automation. It is like a hotel where every room has the same key card: convenient, but risky.
A better path: Treat each endpoint with unique private key. If you need the same common name in different places, say, an F5 load balancer and an IIS server, provision separate certificates and key pairs for each.
A special note on wildcard certificates
Wildcard certificates have historically been used to save time even stretching a single wildcard across a thousand-plus devices. It used to be common practice; I was guilty of using them in the past too.
With automation, that shortcut no longer makes sense. A wildcard creates a single point of failure. If it expires or is compromised, every device that shares it is impacted.
Can we automate a wildcard certificate? Absolutely.
Does it make sense? No.
That $100 wildcard might look cheap compared to single-domain or multi-domain certificates, but the false savings can turn into a million-dollar outage or breach. The bottom line? Treat each endpoint with unique private key.
Misstep 7: Trying to solve everything at once
The problem: Some teams believe certificate automation has to be tackled in one massive project, issuing and replacing every certificate all at once.
Where it falls short: That approach usually leads to paralysis. The scope feels overwhelming and nothing moves forward while certificates continue to expire.
A better path: You do not need to flip your PKI overnight. With the right automation in place, you can let certificates renew naturally, replacing them automatically as they come up. Breaking the problem into smaller steps makes the transition smoother, faster, and less risky. True automation is about momentum, not boiling the ocean.
One common myth: Automation is harder than manual
The fear: Many administrators assume real automation requires huge resources.
The reality: In practice, it is often faster. In my lab, I compared manual deployment (4 minutes 12 seconds) versus full automation (2 minutes 44 seconds including agent setup). In real-world environments, manual installs often take hours because of missing pre-validation or trust anchors.
What surprises administrators most is deployment. Historically, they have had to hunt down servers, figure out the install process, schedule downtime, and plan around risk. With automation, deployment happens in seconds: no guesswork, no scheduling, and no downtime.
The takeaway: Automation does not add work; it removes it. Once it is in place, every renewal happens without you lifting a finger.
Closing thoughts
If you still have manual steps anywhere in your process, it’s time to look into ways to automate. If you do not have automation, you do have risk. I have watched administrators’ eyes light up the first time they see a certificate deployed directly to a device without touching the server, and then realize it is actually faster than doing it manually. That is the “aha moment” that changes everything. That said, it is not realistic to automate every certificate today. Some processes and programs do not yet have APIs or hooks for full automation, and that is fine. What matters is automating the bulk of your certificates.
When you are ready to take the next step, explore our 47-Day Survival Guide to see exactly what real automation should look like in practice or calculate the average ROI of switching to an automated CLM platform with our 47-Day ROI Calculator.