What is Public Key Infrastructure (PKI)?

For years, PKI sat in the background of enterprise security as a specialized concern for cryptographers and certificate administrators. That has changed. As organizations adopt Zero Trust architectures and machine identities begin to outnumber human ones, PKI has moved from background utility to strategic control plane. This piece explains what it is, how it works, and where it fits in a modern security strategy.

Public key infrastructure is the framework of hardware, software, policies, and procedures used to create, manage, distribute, use, store, and revoke digital certificates. A digital certificate binds a cryptographic key pair to a verified identity, so that anyone relying on the public key can trust who owns the corresponding private key.

The underlying premise is asymmetric cryptography. Instead of one shared secret, each party holds a public key that can be freely distributed and a private key that stays under their exclusive control. PKI is what makes that model workable at scale, because it provides a trusted way to answer the question every relying party has to ask: does this public key really belong to who it claims to belong to?

By definition, a PKI framework must cover the full lifecycle of a certificate, not just its creation. A working PKI issues certificates, distributes them to the right parties, tracks them, and revokes them when they are no longer trustworthy.

At the mechanical level, PKI relies on two cryptographic operations that any asymmetric key pair can perform. One key can encrypt data that only the other key can decrypt. One key can sign data in a way that the other key can verify. Depending on the use case, the public and private keys play different roles, but the math is the same.

Consider a browser connecting to a website. When the connection begins, the server presents its digital certificate. The certificate contains the server’s public key and a signature from a certificate authority (CA) that vouches for the server’s identity. The browser checks that signature against a list of trusted root CAs it already knows. If the signature is valid and the certificate has not expired or been revoked, the browser trusts the public key and uses it to establish an encrypted session.

That verification depends on the chain of trust. A root CA sits at the top of the hierarchy and signs its own certificate. It also signs the certificates of intermediate CAs, which in turn sign the end-entity certificates issued to servers, devices, and users. When a relying party validates a certificate, it walks up the chain until it reaches a root CA it already trusts. Every link in that chain has to be valid for the certificate to be accepted.

The certificate itself moves through a defined lifecycle:

1. Key pair generation, where the requesting party creates a public and private key.
2. Certificate signing request (CSR), where the requester packages the public key with identifying information and submits it to a CA.
3. CA validation, where the CA (or a registration authority acting on its behalf) verifies the requester’s identity.
4. Issuance, where the CA signs the certificate with its own private key.
5. Distribution, where the certificate is installed on the server, device, or user account that will use it.
6. Use, where the certificate proves identity and enables encryption or signing operations.
7. Renewal, before the certificate expires.
8. Revocation, if the certificate is compromised or no longer needed.

Every one of these steps has security implications, and most of the operational challenges around PKI trace back to one of them.

A functioning PKI depends on several interlocking pieces. Each plays a specific role in issuing certificates, verifying their validity, and managing them across their lifecycle.

Certificate authority (CA)

The certificate authority is the trusted third party that issues digital certificates. A CA signs each certificate with its own private key, which is what allows relying parties to verify that the certificate is authentic. Most PKIs use a hierarchy: an offline root CA signs the certificates of intermediate CAs, which in turn sign end-entity certificates. This structure limits the exposure of the root key and gives operators a way to compartmentalize trust.

Registration authority (RA)

The registration authority verifies the identity of anyone requesting a certificate. In some deployments the CA acts as its own RA. In others, particularly at enterprise scale, a separate RA handles vetting so the CA can focus on cryptographic operations. Either way, the strength of a PKI depends on how carefully the RA does its job.

Digital certificates (X.509)

The X.509 standard defines the format of most digital certificates in use today. An X.509 certificate contains the subject’s distinguished name, the subject’s public key, the issuing CA’s name, the certificate’s issuance and expiration dates, a serial number, allowed uses, and the CA’s signature. That signature is what turns a chunk of identifying data into a verifiable credential.

Certificate revocation list (CRL) and OCSP

Certificates sometimes need to be invalidated before they expire, because a private key was compromised, an employee left the organization, or the certificate was issued in error. A CRL is a signed list of revoked certificates that a CA publishes on a regular schedule. The Online Certificate Status Protocol (OCSP) provides a real-time alternative, letting a relying party ask a CA whether a specific certificate is still valid at the moment of use.

Certificate repository and management system

Certificates have to be stored somewhere and managed by someone. A certificate repository holds issued certificates so they can be retrieved when needed. A certificate management system handles the operational work of issuing, distributing, renewing, and revoking certificates at scale. In organizations with thousands or tens of thousands of certificates in use, this management layer is often the difference between a PKI that works and one that causes outages.

Key archival and recovery

Private keys are secrets, but they are also business-critical assets. If a private key used for data encryption is lost, the encrypted data may be unrecoverable. Key archival systems securely store copies of certain private keys so that data can be recovered when needed, while balancing that recoverability against the risk of key exposure.

Digital certificates all follow the same underlying format, but they are issued for different purposes and carry different trust implications. Understanding what each type protects is useful for anyone deciding how PKI should fit into a broader security strategy.

Secure Sockets Layer (SSL)/Transport Layer Security (TLS) certificates

Secure traffic between clients and servers on the web. This is the most familiar use of PKI, present on virtually every HTTPS website, API endpoint, and encrypted network service.

Code signing certificates

Allow software publishers to sign applications, drivers, and scripts. When a user or operating system runs signed code, it can verify the source and confirm the code has not been tampered with since it was signed.

Email and S/MIME certificates

Enable users to sign emails so recipients can verify the sender, and to encrypt emails so only intended recipients can read them. Common in regulated industries and government.

Client authentication certificates

Identify users and devices to the systems they access. Smart cards, Common Access Cards (CAC), and Personal Identity Verification (PIV) cards used across federal agencies rely on this category. Hardware security keys can also use it, such as the RSA iShield Key 2 series.

Document signing certificates

Apply cryptographic signatures to PDFs and other electronic documents, giving legal and evidentiary weight to signed contracts, filings, and records.

Device and machine identity certificates

Issue verifiable identities to IoT devices, servers, containers, and workloads. As machine identities scale into the millions in some environments, this is a rapidly growing use of PKI.

Public key infrastructure authentication is the process of using a digital certificate, and the private key that pairs with it, to prove identity. Instead of typing a password or entering a one-time code, the user or device presents a certificate and cryptographically demonstrates possession of the matching private key by responding to a challenge from the relying system.

Compared to passwords and one-time codes, certificate-based authentication has two significant properties. First, it is phishing-resistant. A private key cannot be typed into a fake login page or sent to an attacker who intercepts a message. It stays on the endpoint or in a hardware token and only ever performs cryptographic operations locally. Second, it reduces friction for the user. Once a certificate is provisioned, the authentication flow can be transparent, requiring no additional input beyond touching a smart card or unlocking a device.

Certificate-based authentication is a foundation for modern passwordless authentication and phishing-resistant multi-factor authentication, and it is one of the identity building blocks that Zero Trust architectures rely on. Rather than trusting a network location, Zero Trust requires proof of identity for every access decision, and PKI provides that proof in a form that is durable, verifiable, and hard to forge.

PKI shows up in a lot of places, but most implementations fall into a few broad categories. Each category solves a specific class of trust problem.

Securing communication

TLS is the most familiar example, protecting web traffic, API calls, and email in transit. VPNs and site-to-site tunnels also depend on PKI to authenticate the endpoints of an encrypted channel. In each case, PKI provides the identity assurance that makes the encryption meaningful.

Proving authenticity and integrity

Code signing lets software publishers prove that the binaries a user is about to run came from the expected source. Document signing does the same for PDFs and other files. Firmware and software update mechanisms use PKI to prevent attackers from pushing malicious updates to fleets of devices.

Authenticating users and devices

Smart cards, CAC/PIV cards, and certificate-based logins let organizations verify who is on the other end of a session, on a device that meets policy. This is where PKI intersects most directly with identity and access management, and it is a strong option for high-assurance environments and Zero Trust rollouts.

Machine and workload identity

Modern architectures depend on services, containers, and IoT devices being able to authenticate to one another. PKI is the mechanism that gives each workload a verifiable identity, so that access decisions can be made based on what a workload is and not just where it lives on the network.

PKI is enduring for a reason. Few other approaches to establishing trust operate at the same scale or with the same cryptographic assurances.

• Phishing-resistant authentication: Private keys never leave the endpoint and cannot be reused by an attacker who intercepts a session, making certificate-based authentication durable against the credential theft tactics that undermine passwords and push-based MFA. RSA has written elsewhere about how attackers bypass MFA and why phishing-resistant approaches matter.
• Confidentiality and integrity across untrusted networks: Data encrypted under a recipient’s public key can only be read by the holder of the matching private key, and signed data can be verified without any prior shared secret. That combination is what makes commerce, banking, and secure communication possible over the public internet.
• Non-repudiation for signed transactions:A digital signature backed by a trusted certificate provides strong evidence that a specific party approved a specific document or transaction, which matters in legal, financial, and compliance contexts.
• Scalable trust:A single certificate authority can vouch for the identities of millions of certificate holders, without every relying party needing to establish a direct trust relationship with each of them.
• A foundation for Zero Trust:Every actor in a Zero Trust architecture, human or machine, needs a verifiable identity. PKI is a durable way to issue and verify those identities, and one of the building blocks of a Zero Trust approach to security.
• Regulatory and assurance alignment:FIPS, Common Criteria, eIDAS, and sector-specific mandates in government, financial services, and healthcare all recognize PKI-based mechanisms as a strong control for identity, integrity, and confidentiality.

For all its strengths, PKI carries real operational risks. Most PKI-related incidents are not failures of the cryptography itself. They are failures of the systems and processes around it.

• Certificate outages: Expired certificates take down services. When a certificate on a load balancer, an internal API, or a public-facing website expires unnoticed, dependent systems stop working. High-profile outages traced to expired certificates are a recurring pattern.
• Private key compromise: If a private key is exposed, every certificate signed with it is at risk, and every session or signature that depends on it becomes suspect. Recovering from a private key compromise usually means revoking and reissuing at scale.
• CA compromise:An attacker who breaches a CA can issue fraudulent certificates that are trusted by browsers, operating systems, and other relying parties. Historical CA compromises have led to broad distrust actions and forced replacement of large certificate populations.
• Revocation gaps:Not every client checks CRLs, and OCSP responses can be soft-failed under network conditions that attackers can exploit. Even when revocation works as designed, there is often a window during which a revoked certificate still functions in practice.
• Certificate sprawl:Modern organizations run tens of thousands of certificates across cloud services, on-premises systems, endpoints, and machine identities. Without a central inventory, it is easy to lose track of what is issued, where it is installed, and when it expires.
• Post-quantum threat:The RSA and elliptic curve algorithms underpinning most PKI today are considered secure against classical computers but not against sufficiently large quantum computers. NIST has begun standardizing post-quantum cryptographic algorithms, and organizations that depend on PKI need to plan for a multi-year migration.

A well-run PKI is not just a set of cryptographic components. It is an operational discipline. The practices below reduce the risk of the failures described above.

Maintain a full certificate inventory

Track every certificate across cloud services, on-premises systems, endpoints, and machine identities. Manual spreadsheets rarely keep up in modern environments, and a discovery and inventory tool is worth the investment for any organization at scale.

Automate certificate lifecycle management

Automated issuance, renewal, and installation eliminate the human errors that cause most certificate outages. Automation also makes short-lived certificates practical, which reduces exposure when a key is compromised.

Enforce strong key protection

Store CA private keys in hardware security modules (HSMs) and protect end-entity keys with secure key storage on the endpoint or in a hardware token. The strength of a PKI ultimately depends on how well its private keys are protected.

Use short-lived certificates where feasible

Shorter certificate lifetimes reduce the blast radius of a compromised key and make revocation less operationally critical. Automation is a prerequisite here, because manually renewing short-lived certificates at scale is not workable.

Implement robust revocation checking

OCSP stapling, short CRL refresh intervals, and hard-fail policies where appropriate all help close the gaps that leave revoked certificates functional in practice. Revocation only works when relying parties actually check.

Plan for crypto-agility and post-quantum migration

Inventory the cryptographic algorithms in use across the environment, understand which systems depend on them, and begin evaluating post-quantum options as NIST standards mature. Migration will take years, and the organizations that start early will have the fewest unwanted surprises.

Segment CA hierarchies

Keep root CAs offline, tightly control intermediate CAs, and apply appropriate certificate policies to each tier and use case. A well-segmented hierarchy limits the impact of any single compromise.

Zero Trust has changed the assumptions security teams work under. Network location no longer implies trust, and every access request has to be evaluated on its own merits. That model only functions if every actor in the environment has an identity that can be verified with high assurance, and that is where PKI becomes foundational.

For users, PKI provides certificate-based authentication that resists phishing and works across devices and applications. For devices, it provides a verifiable identity that can be checked at every access decision. For workloads and services, it enables machine identity at the scale modern architectures require. Identity and access management (IAM),identity governance and administration(IGA), and machine identity management all sit on top of the trust that PKI provides. Without it, Zero Trust becomes a set of policies with nothing durable to enforce them against.

Public key infrastructure is the trust layer that quietly enables most of what security teams take for granted, from secure web traffic to signed software to certificate-based user authentication. As organizations move toward Zero Trust and as machine identities and other non-human identities continue to scale, PKI is becoming a strategic control plane rather than a background utility. Running it well requires an operational discipline that spans inventory, automation, key protection, and forward-looking planning for post-quantum cryptography.

RSA’s heritage in this space runs deep. The RSA algorithm itself is one of the foundational public-key cryptosystems that made modern PKI possible, and RSA continues to help organizations put that cryptography to work through certificate-based authentication, hardware authenticators, and identity solutions built for high-assurance environments. Explore how RSA supports certificate-based and phishing-resistant authentication with RSA ID Plus.