When should organisations use private PKI instead of public certificates for client auth?

Why This Matters for Security Teams

Client authentication choices shape trust boundaries, certificate lifecycle effort, and how much of the internal environment is exposed to public trust infrastructure. Public certificates are designed for broad interoperability, while private PKI lets security teams define issuance policy, naming, revocation, and lifetime for internal clients. For machine and service identities, that control often matters more than browser trust. The NIST Cybersecurity Framework 2.0 helps frame this as an asset, access, and risk management problem rather than a certificate-format preference.

This distinction is especially important when the client is a service account, workload, or administrative tool rather than a user browser. Internal use cases often need tighter control over which entities can request certificates and how quickly those credentials can expire or be revoked. NHI Management Group’s Ultimate Guide to NHIs — What are Non-Human Identities notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why issuance discipline matters.

In practice, many security teams realise the limits of public certificates only after internal service authentication, certificate sprawl, or revocation delays have already created an outage or exposure.

How It Works in Practice

Private PKI is usually the better fit when the relying parties are inside a controlled trust domain: internal APIs, east-west service traffic, administrative portals, bastion access, and device or workload authentication. The organisation operates the issuing CA or delegates it under policy, which makes it possible to bind certificate subjects to internal naming schemes, enforce shorter validity periods, and integrate issuance with inventory and approval workflows. For practical governance, this is often paired with NIST CSF 2.0 asset and access controls, plus lifecycle tracking from NHIMG research such as the Critical Gaps in Machine Identity Management report.

Public certificates make sense when external trust is required, such as for customer-facing TLS where browsers and external partners must trust the endpoint without custom root distribution. For client auth, though, public trust adds overhead if the client population is internal and tightly managed. In those cases, private PKI avoids dependence on public trust stores, reduces unnecessary exposure through certificate transparency, and lets teams revoke and reissue credentials without waiting on external ecosystem constraints.

• Use private PKI when certificate subjects are internal workloads, admin devices, or service-to-service clients.
• Use public certificates when external browsers, customers, or third parties must validate the server or client trust path.
• Use short-lived certificates where automation can reliably renew before expiry.
• Pair issuance with inventory, revocation, and ownership controls so private roots do not become unmanaged sprawl.

One practical sign is whether the certificate must be trusted outside the organisation. If the answer is no, the security model usually improves when the org controls the root, policy, and lifetime. These controls tend to break down when teams lack automated enrolment and revocation for high-volume workloads because manual certificate handling does not scale.

Common Variations and Edge Cases

Tighter certificate control often increases operational overhead, so organisations must balance trust isolation against the cost of running PKI well. That tradeoff is real: private PKI gives stronger governance, but only if the team can maintain enrollment, renewal, and revocation without creating fragility.

There is no universal standard for every client-auth scenario. For partner integrations, managed devices, or environments that span multiple business units, hybrid models are common: a private CA for internal workloads and a public CA for externally verified endpoints. For regulated environments, private PKI may also be preferred because it supports policy alignment, though the exact control mapping depends on the sector.

Current guidance suggests avoiding public certificates for client auth when the identity is not meant to be broadly trusted by the internet. That is especially true for internal agents and automated services, where certificate rotation, ownership, and revocation matter more than browser compatibility. If certificate issuance is manual or ownership is unclear, private PKI can still fail operationally even when the architecture is sound. NHI Management Group’s research on the Sisense breach is a reminder that identity trust breaks fastest when credentials outlive the processes meant to govern them.

Related resources from NHI Mgmt Group

• Should organisations use SSH certificates instead of long-lived keys?
• When should organisations use self-signed TLS client authentication instead of CA-signed mTLS?
• When should organisations use token exchange instead of direct client credentials?
• How should security teams implement Client ID Metadata Documents?