Private PKI cost: build, partner or SaaS

The one-time costs of a self-hosted CA sit at the front of the project. Hierarchy design, the root key ceremony, HSM or cloud KMS integration, platform automation and migration from any existing CA are the work that must be done before the first production certificate is issued. Ask each bidder to price these as separate line items with named deliverables, such as a signed hierarchy document, a recorded ceremony with witnesses, a tested key-custody procedure and a documented cutover plan. Confirm whether the quote covers integration with your existing inventory and monitoring, because that work is easy to leave out and expensive to add later.

The recurring costs are less visible and usually larger over the life of the CA. Renewals, provisioner and certificate template changes, monitoring of expiry, retention of audit evidence and on-call coverage for issuance failures all continue for as long as the CA runs. Patching the CA servers and the platform itself is also recurring. The OpenBao release line and step-ca updates keep arriving, so your team or partner needs standing upgrade capacity, including test environments, change windows and regression checks on issuance and renewal paths. Ask for a written support model that states who performs each recurring task, how often, and what it costs when an upgrade is urgent.

Treat the recurring work as a budget line in every year of the model, not as a footnote to the build. A managed service moves much of this work to the provider under its contract terms, while a self-hosted design keeps it with your staff or your implementation partner. Compare the two options over the same period, and confirm which operations are covered by an ongoing retainer and which are billed as separate change requests. A short pilot that measures how long a routine renewal or template change takes in your environment will give you a more accurate estimate than any list of tasks.

An expired certificate is one of the few cost items in a private PKI budget that can be priced only after it fails. The cost of the outage depends on which services the certificate protects, how many users or machines lose access, how many hours the team needs to find the expired certificate and replace it, and whether the fix requires an emergency change outside the normal release window. Before comparing build, partner or SaaS options, list every service that depends on a certificate issued by your CA, then estimate the business impact of each one losing trust for a day, a weekend and a full business week. That exercise, not a generic figure from a vendor or article, is the number to take into the comparison.

The exposure drops when three controls are in place: an inventory that records every certificate, its owner, its expiry date and the service it protects; expiry monitoring that alerts well before the renewal window closes; and automated renewal through ACME, cert-manager or a similar client so that no person has to remember a renewal date. Each control has a running cost in engineering time and monitoring tooling, which belongs in your self-hosted estimate. Under a managed PKI service, part of this exposure moves to the provider's contractual support model. Read the service level terms closely: confirm the response and restoration commitments, who is accountable for renewals that fail on the provider's side, and whether credits or remedies apply to an outage caused by a certificate the provider issued. Those terms rarely cover your downstream services, so the outage cost still sits with you.

Quotes for a private CA rarely describe the same system, so the first step is to normalize them against one written scope. Ask every bidder, whether your own team, an implementation partner or a managed PKI provider, to state the certificate types in scope (TLS server, mutual TLS, client and device, document signing and SSH), the number of issuing CAs and the hierarchy they sit under, the expected issuance volume by certificate type, and the platforms that must be automated, such as Kubernetes clusters, load balancers, Linux hosts and network devices. Ask each bidder to state its assumptions about certificate lifetimes, including whether leaf certificates are short-lived and how renewal is handled for systems that cannot run an ACME client. Without these inputs, a low figure may simply cover fewer platforms or assume longer lifetimes than your policy will allow.

Next, make key custody and handover explicit. Ask whether root and issuing CA keys will sit in an HSM, a cloud KMS or a hardware token, who performs key ceremonies, who holds the administrative and recovery credentials, and what happens to those credentials at handover. Confirm who operates the CA after go-live and whether the quote includes runbooks, configuration exports, the audit log format and training for your operators. For SaaS, ask where keys are generated, how you obtain an exit path with usable CA material, and what the contract says about access to certificate data and audit records if the relationship ends. Each bidder should also state what documentation it will deliver, such as certificate policy and practice statements, inventory outputs and evidence for your assessors, so you can see which costs are one-time and which recur.

Finally, ask for support terms in the same format. Separate one-time implementation work from recurring operations, and ask each bidder to name what it covers for patching, upgrades, incident response for CA or renewal failures, and after-hours coverage. DeployOpen does not publish a price list. A quote follows from a written, fixed scope agreed before work starts, and ongoing support is available as a separate retainer. Ask any bidder, including DeployOpen, to list its exclusions and the change process for scope drift. Confirm the response targets in writing and check that they are measured against the certificate outage scenarios that matter most to your services. A comparison is fair only when every option is priced against the same list of platforms, lifetimes, key controls and deliverables.