How should organisations implement PKI to secure user and device authentication across digital services?

What PKI has to do beyond encryption

PKI is the trust layer that lets a service decide whether a user or device is authentic, not just whether traffic is protected. That means certificate policy, issuance, validation, and revocation matter as much as the cryptography itself. For user sign-in and device trust, the core design question is who can obtain a certificate, how that certificate is bound to an identity, and what the verifier will accept.

In practice, PKI works best when it is treated as an identity control with explicit lifecycle ownership. If certificate issuance is loosely governed, or if validation rules differ across services, the result is inconsistent trust and weak authentication rather than strong assurance. This is why certificate policy should be defined alongside enrollment, renewal, revocation, and key custody.

For organisations building certificate-backed access, the most durable pattern is to map each certificate type to a clearly bounded use case. User certificates, device certificates, service certificates, and code-signing certificates often need different issuance rules, expiry periods, and revocation paths. A single PKI can support all of them, but only if the trust model is intentionally segmented.

How certificate trust should be operationalised across services

Authentication succeeds only when the relying service can validate both the certificate chain and the binding between the certificate and the subject it claims to represent. That is why trust anchors, intermediate CAs, revocation status, and renewal automation are not back-office details. They directly determine whether a user session or device connection is accepted, rejected, or silently trusted for too long.

Strong deployments also keep the private key lifecycle narrow. Keys should be generated, stored, rotated, and retired in a way that matches the certificate's business purpose. For high-value user and device authentication, the key lifecycle should be designed to reduce exportability, shorten exposure windows, and make renewal predictable rather than manual.

Modern certificate operations also need to account for scale. As the number of endpoints, workloads, and services grows, certificate sprawl becomes a reliability issue as well as a security issue. Organisations that automate discovery and renewal reduce the chance that authentication fails because of an expired certificate, while also reducing the temptation to overextend long-lived credentials.

For organisations that want guidance on the cryptographic side of lifecycle design, NIST SP 800-57 Key Management is useful because it ties key handling to cryptoperiod, rotation, and retention decisions.

For service-to-service and device-bound authentication, certificate-backed protocols such as mutual TLS are often the cleanest way to keep trust anchored in cryptographic proof rather than shared secrets. The most important implementation choice is whether the service validates the client certificate as an identity signal, or merely as a transport control.

Why PKI implementations fail in real environments

The most common failure mode is not broken cryptography, it is weak lifecycle control. Expired certificates, unclear ownership, stale trust anchors, and inconsistent revocation handling can all turn a sound PKI design into an unreliable authentication system. When that happens, teams often compensate with exceptions, and those exceptions become the new trust model.

Another frequent failure is mismatching the strength of the certificate with the value of the access path. A certificate used for administrative sign-in or device admission should be governed more tightly than one used for a low-risk internal service. If all certificates are treated the same, the organisation loses the ability to express different levels of assurance across different services.

Public trust ecosystems add a further dependency. If the organisation relies on publicly trusted certificates, issuance and revocation must track external policy requirements as well as internal controls. The CA/Browser Forum is relevant here because its baseline requirements shape how publicly trusted certificates are issued and revoked.

For device and user authentication, PKI also fails when certificate issuance is not tied to strong proofing or device registration. A certificate is only as trustworthy as the process that binds it to the right subject. If an attacker can obtain a valid certificate for the wrong user or unmanaged device, the rest of the trust chain is undermined.

Practitioner Guidance

What to prioritise: Start with the certificate classes that can create the biggest authentication failure, usually admin users, managed devices, and any service that can reach sensitive systems. Those are the trust points where bad issuance, stale certificates, or poor revocation handling will have the broadest blast radius.

What to verify: Confirm that each certificate has a named owner, an explicit expiry policy, a working renewal path, and a defined revocation process. If any of those four elements is missing, the PKI is not yet operationally ready for authentication, even if the certificates technically validate.

What good looks like: The organisation can prove which identity a certificate represents, can revoke it quickly, and can rotate it before expiry without manual rescue work. Trust anchors are controlled, renewal is automated where appropriate, and exceptions are rare enough to be visible.

What practitioners underestimate: Certificate management is often treated as a one-time deployment task, but authentication assurance decays over time. The real control is not issuance alone, it is the ongoing discipline of validation, renewal, revocation, and monitoring.

Practitioner takeaway: A secure PKI is judged by how reliably it binds identity over time, not by how elegantly it encrypts traffic on day one.

Related resources from NHI Mgmt Group

• How should organisations implement two-factor authentication in high-risk digital services without creating unnecessary user friction?
• How should organisations use PKI to secure documents and digital identities across regulated workflows?
• How should organisations implement PKI to secure digital identities at cloud and IoT scale?
• How should organisations govern reusable digital identity across multiple services?