Should organisations build PKI in-house or use a managed service?

When In-House PKI Makes Sense, and When It Does Not

Building PKI in-house is less about buying technology and more about whether the organisation can run a trust service as an operational discipline. The decision turns on certificate issuance, renewal, revocation, key custody, policy enforcement, auditability, and the ability to keep root and intermediate trust under control over time.

In-house PKI usually fits organisations that need deep policy control, unusual trust boundaries, or strict integration with internal systems. It also suits teams that can own certificate lifecycle work as a repeatable service, not a one-time project. The hard part is not initial deployment, it is keeping issuance, rotation, and revocation reliable as environments change.

A managed service shifts much of the operational burden to a provider, which can be valuable when the internal team cannot absorb 24/7 availability, monitoring, and renewal automation. That said, delegation does not remove enterprise responsibility for trust policy, approval paths, and the consequences of a bad certificate decision. You are outsourcing operations, not accountability.

What Changes Operationally Between Self-Managed and Managed PKI

The most important distinction is where control ends and where execution begins. In a self-managed model, your team owns the CA hierarchy, cryptoperiods, issuance rules, access to signing keys, logging, and the incident response steps if trust is compromised. In a managed model, the provider may operate those mechanics, but you still need to define who may request certificates, what systems may trust them, and how exceptions are approved.

That division matters because PKI failures are usually lifecycle failures, not cryptography failures. Expired certificates, orphaned intermediates, weak enrollment practices, and poor revocation handling tend to create outages and trust breaks long before any attacker breaks the math. A mature team can reduce that risk through automation and monitoring; an immature team often inherits it as recurring operational debt.

For most organisations, the practical question is whether PKI is a core competency or a supporting utility. If certificates are widespread across customer-facing services, internal services, devices, or code-signing workflows, in-house PKI demands strong ownership and process discipline. If certificate usage is narrower and standardised, a managed service may deliver better reliability with less internal overhead.

How to Decide Based on Key Custody, Governance, and Lifecycle Control

Key custody is the central control point in the decision. If the organisation needs direct custody of private keys, fine-grained approval workflows, or a custom trust model, in-house PKI gives more control but also more responsibility. If the organisation is comfortable with a provider operating the CA while the enterprise retains policy authority, a managed service can be the cleaner model.

Governance should be explicit either way. The best outcome is not "own everything" or "outsource everything", it is clear separation between policy, operations, and oversight. Policy should define who can issue, what can be issued, what gets logged, and how compromise is handled. Operations should prove those rules are enforced continuously, not only during audit season.

Lifecycle control is where many teams underestimate the workload. Certificate inventory, renewal timing, emergency replacement, revocation, and root or intermediate rollover all need routine attention. If the organisation cannot reliably see what depends on each certificate, any model becomes risky. The right choice is the one that matches the team’s ability to sustain those controls without relying on heroics.

Risk and Threat Considerations

PKI creates material exposure when certificate lifecycle tasks are missed or when private keys and issuing authority are not tightly controlled. The main risks are service outage from expired certificates, trust collapse from mis-issuance, and abuse if signing keys or enrollment paths are exposed.

Failure mechanism: Renewal, revocation, or key-custody failures break trust at the certificate layer, and attackers often target the weakest operational step rather than the cryptography itself.

Impact: The result can be authentication failure, service interruption, unauthorized certificate issuance, or broad compromise of systems that trust the CA chain.

Practitioner Guidance

What to prioritise: Decide first whether you are buying operational capacity or preserving direct control. If the organisation cannot staff certificate lifecycle, monitoring, and incident handling with clear ownership, a managed service is usually the safer default.

What to verify: Whichever model you choose, verify that you can inventory every active certificate, detect impending expiry early enough to act, and prove who controls signing authority and revocation decisions. If you cannot show that evidence, the model is not mature enough yet.

Common mistake: Teams often compare PKI options as if the only variable were who runs the software. In practice, the deciding variable is whether trust governance, key custody, and lifecycle operations are dependable at scale.

Practitioner takeaway: Choose the model that your organisation can operate continuously, because PKI fails most often when ownership is unclear and lifecycle work is treated as a setup task rather than an ongoing control.

Related resources from NHI Mgmt Group

• Should organisations build an in-house threat hunting capability or buy a managed hunting service?
• Should organisations build their own authorization control plane or use managed tooling?
• Should organisations self-host a password management platform or use a managed service?
• How do organisations evaluate whether a managed PKI service preserves true control of the trust anchor?