The honest answer to “should we build or buy certificate lifecycle management” is that it depends, and any vendor who tells you otherwise is selling. For a great many situations, building is the right call. Certbot renews Let’s Encrypt certificates reliably and for free. cert-manager handles certificates inside Kubernetes clusters well. step-ca gives you a capable internal CA with ACME built in. These tools are mature, free, and genuinely sufficient for the problems they were designed to solve. An organization with a modest certificate estate that reaches for a commercial platform before it needs one is spending money to solve a problem it does not yet have.
But there is a line, and crossing it changes the answer. The free tools solve the issuance and renewal of certificates you already know about, in the environments they were built for. They do not solve discovery of certificates you do not know about, unified inventory across many sources, ownership and accountability, policy enforcement across multiple CAs, or compliance reporting. For a small estate those gaps do not matter, because you can hold the whole picture in your head and a spreadsheet. For a large, heterogeneous estate they become the dominant problem, and the free tools, excellent at their job, simply do not do that job.
This post is a decision framework for finding the line. It covers what the build approach genuinely does well, where it stops, how to think about the real total cost of the DIY path versus a platform, and the concrete criteria, certificate count, CA count, team size, compliance exposure, that tell you which side of the line you are on.
3-Year TCO: Enterprise vs Mid-Market CLM
Cumulative cost for 1,500 certificates across 3 CAs
$685K
Venafi 3yr
$615K
Keyfactor 3yr
$200K
Mid-Market 3yr
$170K*
DIY (+ outage risk)
What Building Actually Gets You
It is worth being specific and generous about what the open-source and scripting approach delivers, because dismissing it is as much a mistake as over-relying on it.
certbot is the canonical ACME client. Pointed at Let’s Encrypt or another ACME CA, it obtains and renews certificates automatically, handles the common challenge types, and runs reliably from a cron job or timer. For a server or a handful of servers serving public web traffic, certbot is a complete solution with nothing to buy.
cert-manager is the standard for certificates inside Kubernetes. It issues and rotates certificates for workloads and ingress, integrates with ACME and internal issuers, and automates the whole lifecycle within the cluster. For certificate needs that live inside Kubernetes, cert-manager is genuinely excellent and purpose-built.
step-ca is a lightweight open-source CA that speaks ACME natively. It lets you run your own internal CA with modern automation, issuing short-lived internal certificates without per-certificate cost. For an organization that wants an internal CA and has the skills to run one, step-ca covers the issuance side well.
Together these tools can automate a large volume of certificate work for free. The build approach is not a weak option; within its scope it is strong, and many organizations run on it for years without needing anything more. The framework is not about whether these tools work. They do. It is about whether the scope they cover is the scope you need.
Where Building Stops
The build tools share a boundary, and it is the same boundary in every case. They act on certificates you point them at, in the environment they run in. Everything outside that, the parts of certificate management that are about knowing and governing rather than issuing, is where the build approach stops.
Discovery is not covered. certbot renews the certificate you configured it to renew. It has no idea about the certificate a developer created by hand on another server, the one a SaaS platform provisioned for your domain, or the one a cloud load balancer issued. The tools manage what they are told about and are blind to everything else, which means the certificates most likely to cause an outage, the untracked ones, are exactly the ones the build tools never see.
Unified inventory is not covered. Each tool knows its own certificates. certbot knows its renewals, cert-manager knows its cluster, step-ca knows what it issued. Nothing stitches these into one view. An organization running all three has three partial inventories and no single answer to “what certificates do we have and which are at risk,” which is the question that actually matters at scale.
Ownership and accountability are not covered. The tools renew certificates; they do not record who owns each one, who to alert when something goes wrong, or who is accountable for a service’s certificate health. For a small team where everyone knows everything, this is fine. For a large organization, the absence of ownership data is how a failed renewal becomes an outage with no clear responder.
Policy enforcement across CAs is not covered. If your policy says certificates must use certain key sizes, come from approved CAs, and not exceed a maximum lifetime, the build tools do not enforce that across your estate. Each tool does what it is configured to do; nothing checks the whole estate against a single policy or reports where it diverges.
Compliance reporting is not covered. When an auditor asks for evidence that every certificate meets policy, that none are expired, and that each has an owner, the build approach offers scattered logs and manual collation. Producing that evidence by hand across many tools and sources is a recurring project in itself.
These are not defects in the tools. certbot was never meant to be an inventory, and criticizing it for not being one misunderstands it. The point is that these functions are real needs at scale, and the build tools do not provide them, so a build-only strategy leaves them to be solved some other way, usually by people and spreadsheets.
The Real Total Cost of DIY
The build approach is called free because the software is free, but the total cost of ownership is not the software. The TCO comparison chart above contrasts the real cost of the DIY path against a platform, and the DIY line is higher than the zero-dollar license suggests because the cost moved from licensing to labor and risk.
The DIY path costs engineering time to build and maintain the glue. certbot and cert-manager and step-ca do their jobs, but tying them together, scripting the inventory, writing the monitoring, building the reporting, and keeping all of it working as tools version and environments change, is ongoing engineering work. That work is a maintenance burden that never ends, because the environment never stops changing, and it competes with every other demand on the same engineers.
It costs staff attention to the gaps the tools do not cover. Someone has to do the discovery the tools do not do, maintain the inventory the tools do not maintain, chase the ownership the tools do not track, and assemble the compliance evidence the tools do not produce. This labor is often invisible in a build-vs-buy comparison because it is spread across people’s existing roles, but it is real cost, and it scales with the estate.
And it costs the risk of the coverage gaps. The DIY approach’s blind spot, the certificates it does not know about, is not a neutral absence. It is the source of the outages and the audit findings that have their own cost, sometimes a large one. A build approach that saves a license fee and then suffers a certificate outage on an untracked certificate may have spent far more on the incident than the platform would have cost. The TCO chart’s honest message is that the free path is free in licensing and expensive in labor and risk, and whether that trade is worth it depends entirely on scale.
The Decision Criteria
The line between build and buy is not a single number but a combination of factors. Each pushes toward building or buying, and the decision is where they net out.
Certificate Count
Small counts favor building. A few dozen certificates can be tracked in a spreadsheet and renewed with certbot, and the overhead of a platform is not justified. As the count climbs into the hundreds and thousands, the human-tracking approach breaks down, discovery becomes a real problem, and the inventory and monitoring that a platform provides stop being luxuries. High certificate count is the single strongest signal toward buying, because it is the factor that most directly overwhelms manual and scripted management.
CA Count
A single CA favors building, because one tool against one CA is simple. Multiple CAs, a public CA for external certificates, a commercial CA for organization-validated ones, an internal CA for internal services, each with its own tool and its own process, is where the lack of a unified layer hurts. The more CAs you use, the more a platform’s single-pane management and cross-CA policy enforcement earn their cost, because the build approach gives you one disconnected tool per CA and no coordination between them.
Team Size
A small team favors building in one sense and buying in another. A small team can hold a small estate in its collective head, which favors building. But a small team managing a large estate is exactly the situation where a platform pays off most, because the platform substitutes for headcount the team does not have. The question is not team size alone but the ratio of estate size to team size. A large estate on a small team is the strongest case for buying, because the alternative is hiring people to do by hand what the platform does automatically.
Compliance Exposure
Light compliance obligations favor building. Heavy ones, regulated industries, frequent audits, strict policy requirements with evidence, favor buying, because the compliance reporting and policy enforcement that the build approach does not provide are precisely what auditors demand. When producing audit evidence is a recurring, high-stakes exercise, a platform that generates that evidence continuously is worth its cost on the compliance dimension alone, independent of the operational one.
How the Criteria Net Out
Read together, the criteria describe a spectrum. A small estate, one CA, a team that knows it all, and light compliance is squarely build territory, and spending on a platform there is premature. A large estate across multiple CAs, managed by a team too small to track it by hand, under real audit pressure, is squarely buy territory, and insisting on building there means paying in labor and risk what you saved in license, usually at a loss. Most organizations are somewhere between, and the honest exercise is to place yourself on each criterion and see where the weight falls, rather than deciding by ideology about open source or by a vendor’s urgency.
The framework’s real value is permission to stay on the build side when you belong there and clarity about when you have crossed the line. Building is not a failure to be corrected by buying, and buying is not a surrender of engineering virtue. Each is correct for a range of situations, and the mature decision is knowing which range you are in and revisiting it as the estate grows, because the estate that was build territory last year may have crossed the line this year without anyone noticing.
FAQ
Q: Are open-source tools like certbot and cert-manager actually good enough? Within their scope, yes. certbot reliably renews ACME certificates, cert-manager handles Kubernetes certificates well, and step-ca runs a capable internal CA. For a modest estate on a single CA, these tools are a complete and free solution. They stop being enough when you need discovery, unified inventory, ownership, cross-CA policy, and compliance reporting, which they were never designed to provide.
Q: If the open-source tools are free, why would I pay for a platform? Because the license is only part of the cost. The DIY path costs ongoing engineering time to build and maintain the glue between tools, staff attention to the discovery, inventory, ownership, and reporting the tools do not cover, and the risk of outages and audit findings from the certificates the tools never see. A platform converts that labor and risk into a predictable cost, which is worth it past a certain scale.
Q: What is the single biggest signal that I should buy rather than build? Certificate count, closely followed by the ratio of estate size to team size. A few dozen certificates on a small CA are manageable by hand and script. Hundreds or thousands of certificates, especially on a team too small to track them manually, overwhelm the build approach and are where a platform most clearly earns its cost.
Q: We only use one CA. Does that mean we should build? It leans that way, because one tool against one CA is simple and a platform’s cross-CA coordination adds little. But weigh it against the other criteria. A single CA with thousands of certificates under heavy audit pressure can still justify a platform for the inventory, monitoring, and compliance reporting, even though CA count alone favors building.
Q: Is choosing to build a decision I make once? No. It is a decision to revisit as the estate grows. An organization correctly on the build side today can cross the line as certificate count rises, CAs multiply, and compliance tightens, often without anyone noticing until an outage or an audit forces the issue. The honest practice is to re-place yourself on the criteria periodically rather than treating the original choice as permanent.
About QCecuring
QCecuring helps enterprises make the build-versus-buy decision honestly and provides the platform for the situations that have crossed the line. Where open-source tools handle issuance and renewal, our platform adds the discovery, unified inventory, ownership, cross-CA policy enforcement, and compliance reporting they do not, so you adopt a platform when scale actually justifies it, not before.
Find out which side of the build-vs-buy line you are on
Tags: Certificate Lifecycle Management, Build vs Buy, TCO, certbot, cert-manager, step-ca, Open Source, PKI Automation, Certificate Inventory, Certificate Discovery, Compliance Reporting, Policy Enforcement, Multiple CAs, Total Cost of Ownership, Enterprise Security