Zero Trust PKI: Why Certificate Infrastructure Decides Success

Zero Trust requires cryptographic proof of identity for every access request. That proof comes from certificates, which means the certificate estate becomes load-bearing for the entire security model.

Most Zero Trust programmes do not fail on policy design. They stall when the organisation discovers it cannot issue certificates fast enough, cannot reach a substantial part of its estate, and has no reliable record of what is already deployed.

This article covers what Zero Trust actually demands of PKI, where implementations typically run into trouble, and what to establish before committing to a platform.

Key points

• Zero Trust replaces network location with cryptographic identity. Certificates are the mechanism.
• The constraint is rarely the policy engine. It is issuance capacity, estate coverage and inventory.
• Public certificates are being withdrawn from client authentication in 2026, which moves mTLS onto private PKI.
• Assess the certificate estate before selecting a ZTNA platform, not after.

Why Zero Trust depends on PKI

Traditional security assumed that anything inside the corporate network could be trusted. That assumption failed as cloud adoption, remote working and supply chain access dissolved the perimeter, and it failed comprehensively once attackers established that the fastest route into a network is through a legitimate credential.

Zero Trust removes the assumption. Every request is authenticated and authorised, regardless of origin. But that only works if identity can be proven, and the two signals Zero Trust exists to stop relying on — network position and passwords — are exactly the ones that cannot prove it.

Digital certificates are what replaces them. A certificate binds a public key to a verified identity and carries the signature of an authority the relying party already trusts. That produces an assertion which can be validated automatically, in milliseconds, without human involvement, and which cannot be phished or replayed in the way a password can.

The same infrastructure covers human and non-human identity. Users, devices, workloads, containers and services all authenticate through the same mechanism, which is what makes Zero Trust operationally coherent rather than a collection of separate authentication systems.

This is recognised in the frameworks. NIST's Zero Trust architecture guidance treats PKI as a core component, and the NCSC's Zero Trust principles are explicit that strong device and user identity is a prerequisite rather than an outcome.

What Zero Trust actually asks of your PKI

The requirements are more demanding than most existing PKI deployments were designed for.

Issuance at machine speed

A Zero Trust model authenticates workloads as well as people. In a containerised environment, workloads are created and destroyed continuously, and each needs an identity for the duration of its life. Certificates that take a ticket, an approval and a manual installation cannot serve that.

This is where PKI built around annual server certificate renewals meets a requirement it was never designed for. The volume difference is not marginal — an estate issuing hundreds of certificates a year may need to issue thousands a day.

Coverage across the whole estate

Zero Trust is only as strong as its weakest exemption. Every system that cannot present a certificate becomes an exception, and exceptions accumulate into the implicit trust the model was supposed to remove.

The systems that cannot comply are predictable: appliances with no modern enrolment support, operational technology with fixed configurations, legacy applications that cannot validate a chain, and third-party platforms outside your control. Identifying them early determines whether Zero Trust is achievable across the estate or only across part of it.

Protocol support that matches the estate

Different parts of the environment enrol differently. Web services use ACME. Modern devices use EST. Network hardware may support only SCEP. Complex enterprise environments may need CMP.

A PKI that supports one protocol covers one segment. Our comparison of certificate management protocols sets out which suits which environment. Notably, Microsoft AD CS has no native support for ACME, EST or CMP, which restricts organisations relying on it to SCEP and manual enrolment — a significant constraint for a Zero Trust programme.

Revocation that works where it needs to

Continuous verification means checking certificate status on every request. That depends on relying parties being able to reach revocation infrastructure, which in segmented networks and operational technology environments is frequently not the case.

OCSP stapling addresses part of this by having the server present its own status response, removing the client's need to contact the CA. But revocation is the component most often assumed to work rather than tested, and a Zero Trust model that cannot revoke effectively has a significant gap in its incident response.

Key protection proportionate to what the certificates authorise

If a certificate grants access to a system, the private key is the credential. Keys held in software on general-purpose operating systems offer limited assurance, and for high-value identities hardware security modules, TPMs or secure enclaves provide protection that software keystores cannot.

This matters more under Zero Trust than under perimeter security, because the certificate is no longer one factor among several — in many designs it is the primary assertion of identity.

What changes in June 2026

A Chrome Root Program change takes effect on 15 June 2026: publicly trusted TLS certificates will be limited to server authentication only, with the clientAuth Extended Key Usage removed.

For Zero Trust programmes this is significant. Organisations using publicly trusted certificates for mutual TLS or client authentication will need to move those use cases to private PKI. The alternative is that the authentication simply stops working.

The practical consequence is that Zero Trust implementations become more dependent on internal certificate infrastructure, not less. If mTLS appears anywhere in your architecture, audit now which certificates carry clientAuth and where they came from. Our article on choosing the right PKI hierarchy as public TLS withdraws from mTLS covers the design decisions this forces.

Where Zero Trust implementations run into trouble

The patterns are consistent across the environments we assess.

The policy engine arrives before the identity infrastructure

The most common sequencing error. A ZTNA platform is procured, policies are designed, and then the programme discovers that a significant proportion of the estate cannot present a valid certificate. The policy engine is left making decisions about identities it cannot properly validate, which is not Zero Trust — it is a more expensive version of what was there before.

No inventory, so no scope

Organisations consistently find more certificates than their records show. Until the estate is known, the Zero Trust programme cannot be scoped, priced or sequenced, and the discovery happens anyway — just later, under delivery pressure. A cryptographic inventory is the prerequisite.

Automation stops at issuance

Issuing a certificate is the easy part. A renewal is only complete when the application is actually serving the new certificate, which usually requires a restart or configuration reload. Automation that covers issuance but not deployment leaves a human in the loop at the step most likely to fail, and silent renewal failure is worse than no automation because it removes the expectation of a manual check.

Certificate lifetimes compound the volume

Public TLS certificate lifetimes are falling to 47 days by 2029. A Zero Trust programme that increases certificate volume, layered on a renewal cycle that increases frequency eightfold, produces an operational load that manual processes cannot absorb. Certificate lifecycle management stops being an improvement and becomes a dependency.

Nobody owns the certificate estate

PKI typically sits across infrastructure, identity, security operations and application teams, with each holding a dependency and none holding the whole. Zero Trust requires decisions about policy, architecture and funding that no individual team is positioned to make. Where that ownership gap is not resolved, programmes stall for organisational reasons rather than technical ones.

What Zero Trust PKI delivers when it works

The security case is straightforward. Certificate-based authentication is phishing-resistant in a way passwords and one-time codes are not, because there is no credential for a user to disclose. That removes the attack path behind the majority of successful intrusions.

Beyond authentication, the same infrastructure supports mutual TLS between services, code signing for software integrity, and S/MIME for email — which is why consolidating on PKI tends to reduce total complexity rather than add to it.

Operationally, well-implemented certificate automation removes password resets and manual credential handling from support workloads, and produces an audit trail that compliance functions require anyway. For organisations working to government and defence assurance standards, demonstrating cryptographic control over identity is increasingly an explicit expectation rather than good practice.

A sensible implementation sequence

1. Establish what you have

Certificate inventory, PKI hierarchy, key protection, revocation infrastructure and enrolment capability. A PKI health check produces this baseline and identifies which elements are sound enough to build on.

2. Identify what cannot comply

The systems that cannot present or validate certificates determine the real shape of the programme. Find them before designing policy, not after. Each one is either a compensating control, a replacement, or a permanent exemption that weakens the model.

3. Fix issuance before enforcing policy

Enrolment protocols that match the estate, automation that completes through deployment, and renewal that runs without intervention. If issuance cannot keep up, policy enforcement will be relaxed to compensate.

4. Start with privileged access

The highest-value access scenarios deliver the largest security improvement and the smallest deployment surface. They also build the operational experience the wider rollout depends on.

5. Integrate with existing identity

Certificate-based authentication needs to work alongside established provisioning and joiner-mover-leaver processes rather than beside them. Where the two are separate, certificates outlive the identities they represent.

6. Plan for cryptographic change

A Zero Trust architecture built today will still be running when post-quantum migration becomes mandatory. Crypto-agility built in at design stage is what makes that a configuration exercise rather than a rebuild of the identity layer.

How Unsung helps

We work exclusively on PKI, and Zero Trust programmes are one of the most common reasons organisations discover their certificate infrastructure needs attention.

We assess what is actually deployed, identify which systems can and cannot support certificate-based identity, and design the issuance and lifecycle capability a Zero Trust model depends on. We are vendor-neutral and hold no reseller allegiance, so the recommendation reflects the requirement rather than a platform preference.

Our consultants hold SC and DV clearance and deliver across central government, defence, financial services, healthcare and transport. PKI consultancy, design and build and certificate lifecycle management cover the work from assessment through to operation.

A PKI health check is the usual starting point, because it establishes whether the foundation can carry the programme before the platform decision is made. Talk to our team to discuss scope.