Public key infrastructure (PKI) is the set of hardware, software, policies, and procedures used to create, distribute, manage, and revoke digital certificates that bind cryptographic public keys to verified identities. So what is PKI in practice? It's the trust system that lets a browser confirm it's really talking to your bank, lets a build server verify that a software package hasn't been tampered with, and lets two machines that have never met establish an encrypted connection without a shared secret. PKI relies on asymmetric cryptography — a public key that can be shared freely and a private key that never leaves its owner's control — plus a hierarchy of certificate authorities (CAs) that vouch for who owns which public key. Without PKI, the modern internet's encryption (TLS/SSL), code signing, and identity verification would have no reliable way to establish trust between strangers.
What Is PKI, and Why Does Modern Software Depend on It?
PKI is the trust framework that makes public-key cryptography usable at scale, and modern software depends on it because encryption alone doesn't solve the identity problem. Anyone can generate a mathematically valid key pair in seconds — the hard part is proving that a specific public key actually belongs to the entity claiming it. PKI solves this by having a trusted certificate authority cryptographically sign a certificate that binds an identity (a domain name, an organization, a code-signing entity) to a public key. When your CI/CD pipeline pulls a container image over TLS, when a Kubernetes API server authenticates a client, or when a signed npm package is verified before installation, PKI is the invisible machinery confirming that the key presented actually belongs to the party it claims to represent. In software supply chains specifically, PKI underpins artifact signing, mutual TLS between services, and the certificate-based identities that tools like SPIFFE/SPIRE and Sigstore build on top of.
How Does a PKI Certificate Chain Actually Work?
A PKI certificate chain works by linking an end-entity certificate back to a trusted root through one or more signatures, each verifiable without contacting the original signer. When your browser connects to a website, the server presents a chain: its own "leaf" certificate, one or more intermediate certificates, and (implicitly) a root certificate that's already stored in your operating system's or browser's trust store. Each certificate in the chain is signed by the private key of the certificate above it. Your browser verifies the leaf's signature using the intermediate's public key, then verifies the intermediate's signature using the root's public key, and stops once it reaches a root it already trusts. If any link is broken — an expired certificate, an unknown intermediate, a signature that doesn't match — the chain fails validation and you get a browser warning. For example, when you visit a site secured by Let's Encrypt, your browser typically receives the site's leaf certificate plus an intermediate like R10 or R11, chaining up to the publicly trusted ISRG Root X1 that ships in major operating systems.
What Is the PKI Trust Hierarchy, and Who Sits at the Top?
The PKI trust hierarchy is a tree structure with a small number of highly protected root certificate authorities at the top, intermediate CAs in the middle, and end-entity certificates at the bottom. Root CAs — operated by organizations like DigiCert, Sectigo, or the Internet Security Research Group (which runs Let's Encrypt) — are the ultimate anchors of trust; their public keys are pre-installed in operating systems, browsers, and language runtimes as "trusted roots." Because compromising a root CA would let an attacker mint a valid certificate for any domain on earth, root keys are kept offline in hardware security modules, often air-gapped and used only a few times a year to sign intermediate CAs. Everything below the root inherits trust downward: a root signs intermediates, intermediates sign leaf certificates, and any party holding the browser's or OS's trust store implicitly trusts every certificate that chains up correctly. This hierarchy is why a single misissued or compromised root has industry-wide consequences — it isn't just one certificate at risk, it's every certificate that chain ever signed.
What's the Difference Between a Root and Intermediate CA?
A root CA is the self-signed, maximally trusted authority at the top of the hierarchy, while an intermediate CA is a subordinate authority the root has certified to issue certificates on its behalf — and the split exists specifically to protect the root's private key from exposure. Root CAs almost never sign end-entity (leaf) certificates directly; instead they sign one or a handful of intermediate CA certificates, then get taken offline and locked away. Intermediates handle the day-to-day work of issuing and revoking certificates for actual websites, services, and code-signing identities, because if an intermediate is ever compromised, it can be revoked and replaced without invalidating the root or forcing every operating system to ship a new trust store update. This root and intermediate CA separation is the same principle behind privileged-access design elsewhere in security: keep the most powerful credential offline and rarely used, and delegate routine operations to a scoped-down, more disposable credential. It's why enterprise PKI deployments for internal service identity (think internal CAs for Kubernetes, HashiCorp Vault PKI secrets engines, or SPIFFE trust domains) almost always mirror this same two-or-three-tier structure rather than issuing everything straight from a root.
What Happens When PKI Trust Breaks Down?
PKI trust breaks down when a CA — root or intermediate — issues a certificate it shouldn't have, or when its private key is stolen, and the fallout can cascade across the entire hierarchy beneath it. The clearest real-world example is the 2011 DigiNotar breach: attackers compromised the Dutch CA's systems and issued more than 500 fraudulent certificates, including one for *.google.com, which was then used to intercept traffic for an estimated 300,000 users, most in Iran. Because DigiNotar's root was embedded in every major browser's trust store, the only real fix was removing DigiNotar entirely from those trust stores — instantly invalidating every legitimate certificate it had ever issued along with the fraudulent ones. A similar, slower-moving example played out between 2017 and 2018, when Google and Mozilla distrusted Symantec's CA business after years of certificate misissuance. Both cases illustrate the same structural risk: trust in PKI is only as strong as the least-careful CA anywhere in a chain you rely on, which is why certificate transparency logs, CA/Browser Forum baseline requirements, and continuous certificate monitoring now exist as compensating controls.
How Safeguard Helps
Safeguard treats PKI as a first-class part of software supply chain security rather than something to assume works silently in the background. Certificates, signing keys, and the CAs that issue them are high-value targets precisely because compromising one upstream trust anchor — a root, an intermediate, or an internal signing CA — can quietly poison everything downstream of it, from TLS connections to signed build artifacts. Safeguard continuously discovers the certificates, keys, and CA relationships in use across your build pipelines, container registries, and service mesh, and maps them against the actual PKI trust hierarchy protecting your software — flagging expired or soon-to-expire certificates, orphaned private keys, self-signed certificates masquerading as internally trusted CAs, and weak signing algorithms before they become incidents. When a package or container image arrives with a code-signing certificate, Safeguard validates the full PKI certificate chain back to a trusted root or intermediate CA rather than trusting a lone signature in isolation, and correlates that identity against known-good publishers. If a CA in your dependency graph is later revoked, distrusted, or implicated in a breach — as happened with DigiNotar and Symantec — Safeguard can retroactively surface every artifact in your environment that ever depended on that trust chain, so security teams aren't left manually auditing years of build history to answer a simple question: were we exposed, and to what.