What Is PKI? A Practitioner's Guide to IT and OT PKI

PKI, or public key infrastructure, is the set of certificate authorities, certificates, keys, policies and processes that lets people, servers and devices prove who they are and encrypt what they send. It’s how a browser knows it’s talking to your bank, how a laptop proves it belongs on the corporate network, and how a controller on a plant floor can tell a legitimate engineering workstation from an impostor.

That’s the textbook answer. The practitioner’s answer is that PKI is a security system that most organizations run like plumbing: installed once, rarely inspected, and only noticed when it leaks. This guide covers how PKI works, what a typical enterprise setup looks like, and why I push hard to keep IT PKI and OT PKI separate.

What is PKI, in plain terms?

PKI rests on public key cryptography. Every identity gets a key pair: a private key that stays secret and a public key that can be shared. Anything signed with the private key can be verified with the public key, and anything encrypted to the public key can only be decrypted with the private key.

The problem is trust. A public key on its own is just a number. How do you know it really belongs to payroll.example.com and not to someone pretending? PKI solves that with a certificate: a signed document that binds a public key to an identity. The signature comes from a certificate authority (CA) that both sides trust.

So the whole system reduces to one question: who do you trust to vouch for identities, and how do you make sure they only vouch for the right ones? Everything else in PKI is an answer to that.

Public key infrastructure components

Component	What it does	Practitioner’s note
Root CA	The trust anchor. Its self-signed certificate is installed in trust stores	Should be offline, powered on only to sign intermediate CAs and CRLs
Intermediate / issuing CAs	Signed by the root; issue certificates to end entities	Where the day-to-day risk lives, so it’s where most of your controls belong
Registration authority (RA)	Verifies the requester’s identity and authorizes the request before the CA issues	Often a function inside the CA software or a CLM platform rather than a separate box
Certificates	Bind a public key to an identity (a hostname, a user, a device) with an expiry date	X.509 is the standard format
CRLs and OCSP	Tell relying parties that a certificate has been revoked before it expires	Revocation only works if clients actually check, and many don’t
HSMs	Hardware security modules that generate and protect CA private keys	A CA key on a VM disk is a CA key someone can copy
Certificate policy (CP) and practice statement (CPS)	Define what the PKI is for, who can get which certificate, and how the CA is operated	The documents nobody reads until an auditor asks

How a chain of trust works

When a client receives a certificate, it builds a chain: the end-entity certificate was signed by an issuing CA, which was signed by the root. If the root is in the client’s trust store, and every signature in the chain checks out, and nothing is expired or revoked, the certificate is trusted.

This is why the root matters so much and why it should be offline. Compromise an issuing CA and you revoke it and reissue. Compromise the root and you rebuild trust on every device that relies on it.

A two-tier hierarchy (offline root, one or more online issuing CAs) is the most common enterprise design. Three tiers show up in larger or more regulated environments, where a policy CA layer separates different uses or business units.

What is PKI used for?

The common uses in an enterprise:

• TLS for websites, APIs and internal services. Public certificates for internet-facing sites; private certificates for internal ones.
• Device identity for laptops, servers, mobile devices and network gear, often for Wi-Fi (802.1X) and VPN authentication.
• User authentication with smart cards, PIV cards or certificate-based sign-in.
• Code signing so operating systems and users can verify software came from who it says it did.
• Email signing and encryption with S/MIME, where it survives.
• Machine-to-machine trust for service meshes, workload identity and IoT or OT devices.

Each of these is an identity use case. That’s the lens I’d encourage: PKI isn’t a networking utility, it’s an identity provider for machines, and in some cases for people.

PKI management in a typical enterprise

In most enterprises I’ve worked with, the internal PKI is Microsoft Active Directory Certificate Services (AD CS). It’s included with Windows Server, integrates with Active Directory, and handles autoenrollment for domain-joined machines and users with very little effort. That convenience is why it’s everywhere. It’s also why it often gets set up once, by someone who has since moved on, and never revisited.

Alongside AD CS you’ll usually find:

• Public CAs for internet-facing TLS, increasingly managed through ACME
• Cloud private CAs stood up by individual teams for their own workloads
• Embedded CAs inside products (MDM platforms, firewalls, service meshes) issuing their own certificates
• A certificate lifecycle management (CLM) tool, or a spreadsheet pretending to be one

Good PKI management means knowing all of those exist, which ones are trusted where, and who’s accountable for each. With public TLS lifetimes heading to 47 days, certificate lifecycle management is now part of PKI management, not an add-on.

What this usually looks like: A first PKI assessment rarely finds one tidy hierarchy. More often it’s an offline root nobody has powered on in years, a couple of issuing CAs on server versions past their support date, and at least one CA a project stood up and forgot. Ownership tends to be implied rather than written down: the AD team assumes security owns it, and security assumes the AD team does. I’d get a named owner for each CA before touching a single template.

When a private CA makes sense

A private CA is any CA you operate (or rent) that isn’t publicly trusted. Its certificates are trusted only by devices you configure to trust them. That’s the right fit for internal services, device identity, and anything that shouldn’t appear in public Certificate Transparency logs. It also lets you set your own lifetimes and profiles.

The trade-off is that you’re now the CA. You own key protection, policy, revocation, availability and audit. A private CA run badly is worse than no private CA, because everything downstream trusts it.

PKI is a security system, not plumbing

If you want one reason to take PKI seriously, look at AD CS attack research. In 2021, SpecterOps published “Certified Pre-Owned,” which catalogued a series of AD CS misconfigurations it labelled ESC1 through ESC8. The list has grown since.

ESC1 is the one everybody should know. If a certificate template lets the requester supply their own subject name, allows client authentication, and grants enrollment to a broad group like Domain Users without manager approval, any user in that group can request a certificate claiming to be a domain admin and use it to authenticate as one. No exploit, no malware. Just a template setting.

Other paths abuse weak access controls on templates or the CA itself, or relay NTLM authentication to AD CS web enrollment. The common thread is that your PKI is a path to privileged access. If an attacker can get a certificate that says they’re someone else, your MFA and your PAM vault don’t help much.

Practical steps:

• Audit certificate templates for enrollee-supplied subjects combined with authentication EKUs
• Restrict enrollment rights to the groups that actually need each template
• Treat CA servers as Tier 0 assets, managed like domain controllers
• Protect CA keys in HSMs and monitor certificate issuance for anomalies

Where it tends to go wrong: The classic finding is a duplicated web server template that someone gave a Client Authentication EKU so an application would work, with enrollment left open to Domain Users. Nobody meant to build an ESC1, and nobody remembers the application. The other repeat offender is CA permissions: ManageCA or Manage Certificates rights granted to a broad helpdesk or server admin group long ago and never reviewed. Both are quick fixes once someone actually looks.

Why IT PKI and OT PKI should stay apart

This is the part I care about most. In many organizations, OT devices start needing certificates (for secure protocols, remote access, or IEC 62443 requirements) and the fastest path is to issue them from the corporate AD CS. It works on day one. Over time it becomes a problem.

IT and OT PKI have different needs:

	IT PKI	OT PKI
Device lifecycle	Laptops and servers replaced every few years	Controllers and field devices in service for decades
Connectivity	Always on, can reach CRLs, OCSP and enrollment services	Often segmented or intermittently connected; may never reach a CRL
Renewal	Automated, frequent, short lifetimes are fine	Change windows are rare; a failed renewal can stop a process
Device constraints	Modern OS, ACME or autoenrollment available	Limited crypto support, manual enrollment, vendor-controlled firmware
Failure impact	Outage, help desk tickets, lost revenue	Potential safety and physical consequences
Trust dependencies	Tied to Active Directory and the corporate network	Should keep working when the corporate network is down or compromised

That last row is the deciding one. If your OT trust depends on the IT domain, a ransomware event in IT can become an operational event in OT. Plants are designed to keep running when the business network goes down. Their PKI should be too.

Keeping them apart doesn’t mean two of everything forever. It means:

• A separate OT trust hierarchy, with its own root, so IT CA compromise doesn’t cascade
• Policies written for OT realities: longer lifetimes where devices can’t renew often, revocation strategies that don’t assume live CRL access, and enrollment protocols (like EST or SCEP) the devices actually support
• Issuing CAs placed at the right level of the architecture, so devices can enroll and validate without crossing back into IT. The Purdue model through an identity lens gets into where those boundaries fall.
• Clear ownership between the PKI team and OT engineering, so certificate changes go through the same change control as any other change on the plant floor

If you’re new to the OT side, start with what OT security is and why identity comes first.

The time to draw this line is before the first OT certificate is issued. Untangling a shared hierarchy later means touching devices that may only be reachable during a planned outage.

A common version of this: Picture a plant that needed certificates for a remote access gateway and an HMI upgrade, so engineering requested them from the corporate issuing CA. A few years later those devices validate against a root tied to the IT domain, and separating them means a new OT hierarchy, re-enrolling each device, and scheduling the work around production outages. My advice: if the first OT certificate is about to be issued, stand up the separate root first. It’s far cheaper than migrating later.

The short answer

PKI is how machines prove identity, and it deserves the same attention you give to human identity. Know every CA you run and who owns it. Lock down AD CS templates before someone else reads the ESC list for you. Get certificate lifecycle management automated before short-lived certificates force the issue.

And if OT is anywhere in your future, give it its own trust hierarchy now. It’s far cheaper to keep IT and OT PKI apart from the start than to pry them apart later. More on PKI and certificate management is collected in the PKI hub, and OT-specific posts are in the OT security hub.