What is PKI? A Plain-English Guide

Public Key Infrastructure (PKI) is the framework of policies, hardware, software, and procedures used to issue, manage, distribute, and revoke digital certificates. PKI binds a cryptographic identity (a public key) to a person, server, or device through a trusted Certificate Authority, so two parties that have never met can prove who they are, encrypt traffic, and sign data.

If your organisation runs websites, signs code, authenticates users, or encrypts email, you are already relying on PKI — whether you manage it directly or not. This guide explains how PKI works, the building blocks of an enterprise deployment, and the modern pressures (47-day TLS, post-quantum cryptography, machine identity) reshaping it in 2026.

The Core Idea: Two Keys Instead of One

Traditional shared-secret cryptography breaks down at scale: every pair of users needs a unique secret, and you need a secure channel to share it. PKI uses asymmetric cryptography — each identity holds a mathematically linked pair:

• A public key anyone can see
• A private key only the owner ever holds

What one key encrypts, only the other can decrypt. That single property powers both confidentiality (encrypt to my public key, only I can read it) and authenticity (I sign with my private key, anyone can verify the signature with my public key). Modern algorithms include RSA, ECDSA on the classical side, and ML-KEM / ML-DSA on the post-quantum side.

Why Digital Certificates Exist

Public keys alone don't prove identity. Anyone can generate a key pair and claim to be schutzit.com. A digital certificate solves this by binding a public key to a subject (a person, server, or device) and is signed by a trusted Certificate Authority (CA).

When your browser opens a TLS connection to schutzit.com, it:

1. Receives the server's certificate
2. Checks the CA's signature on it against a built-in trust store
3. Verifies the certificate is not expired or revoked (via CRL or OCSP)
4. Uses the public key in the certificate to negotiate a session

No trusted signature, no padlock. No padlock, no users.

The Building Blocks of an Enterprise PKI

A well-designed enterprise PKI has five layers:

1. Root CA — the offline anchor of trust. Stored in an HSM, used rarely (only to sign issuing CAs or its own CRL). The root's private key is the single most sensitive secret in your organisation.
2. Issuing CAs — online subordinates that sign day-to-day certificates for users, servers and devices. Compartmentalised by use case (TLS, code signing, device, S/MIME).
3. Registration Authority (RA) — validates the identity and authorisation of a requester before a certificate is signed.
4. Certificate revocation — Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP) so compromised or retired certificates can be rejected before they expire.
5. Lifecycle automation — discovery, inventory, renewal, and rotation. With certificate lifespans dropping to 47 days, manual processes are no longer viable.

For the design and operating model behind a modern enterprise CA, see our deeper guide on what is a Certificate Authority.

Common PKI Use Cases

• TLS/SSL for public websites and internal APIs
• Mutual TLS (mTLS) between microservices and zero-trust workloads
• Code signing for software releases, drivers, and container images
• Document and email signing (S/MIME, AdES, PDF signing)
• Device identity for IoT, OT, vehicles and AI agents
• Smart-card and certificate-based user authentication
• VPN and Wi-Fi authentication (EAP-TLS)

The list keeps growing. Every "machine identity" the industry now talks about is, under the hood, another PKI use case.

Public PKI vs Private (Enterprise) PKI

Public PKI is operated by commercial CAs (DigiCert, Let's Encrypt, Sectigo, GlobalSign) whose roots are pre-trusted by browsers and operating systems. Use it for anything that has to be trusted by the open internet.

Private / Enterprise PKI is operated by you. Roots are distributed to your endpoints via group policy or MDM. Use it for internal services, devices, users, and anything that should not be visible in public Certificate Transparency logs.

Most enterprises run both, in parallel, for different use cases. The mistake is using one where the other belongs.

Where Most PKI Programs Go Wrong

• Expired certificates taking down production — usually a service nobody knew issued them
• Sprawling shadow CAs — every team that ran openssl req is now a CA owner
• Weak key protection outside of HSMs, especially in cloud workloads
• No revocation strategy when a key is compromised
• Manual renewal processes that don't scale past a few hundred certificates
• No cryptographic agility — algorithms hard-coded, no path to post-quantum
• Auditors discovering more about your PKI than your platform team knows

A well-run PKI is invisible. A poorly-run one is the root cause of your next outage — or your next breach.

PKI in 2026: 47-Day TLS, Post-Quantum, and Machine Identity

Three forces are reshaping PKI right now:

1. 47-day TLS certificates. Apple, Google and the CA/Browser Forum are driving public TLS validity from 398 days down to 47 by 2029. Manual renewal is dead. ACME and full lifecycle automation are now table stakes. See our official 47-day TLS mandate breakdown.

2. Post-quantum cryptography (PQC). NIST has finalised ML-KEM, ML-DSA and SLH-DSA. Enterprises are starting to deploy hybrid certificates that carry both a classical and a post-quantum signature, so they keep working today and remain secure once quantum computers can break RSA/ECDSA. Our PQC migration for enterprise PKI guide covers the migration path.

3. Machine and AI-agent identity. Workloads, containers, AI agents and IoT devices now outnumber humans on most enterprise networks by 10:1 or more. Every one of them needs an identity. PKI is how you give it to them at scale.

Next Steps

If you're inheriting a PKI you didn't build, or planning a new one, start with discovery: every cert, every CA, every expiry date, every algorithm. From there, decide what to automate, what to retire, and where post-quantum needs to land.

Schutz IT designs and operates enterprise PKI solutions for regulated organisations across Australia — from greenfield Root CA design and HSM deployment through to ADCS modernisation, ACME automation, and post-quantum migration. For customer-facing logins we also implement Azure AD B2C and Microsoft Entra External ID so your workforce PKI and customer identity share a single trust model.

Talk to Schutz IT about your PKI →