Public key infrastructure (PKI) is a comprehensive framework for assigning, identifying and verifying user identity through digital certificates used for enabling trustworthy and secure digital communications.
It uses a combination of cryptography, trusted roles, systems and operating rules to bind a public key to an identity (a person, AI, server, application, device or organization).
PKI relies on asymmetric cryptography (or public key cryptography). Each entity—such as www.example.com, an employee or a workload—has a mathematically related key pair:
When, for instance, a browser connects to an HTTPS site, the site proves control of its private key during a Transport Layer Security (TLS) handshake—a sequence of messages exchanged when a client and server establish a secure connection. The browser then uses the public key in the site’s certificate to validate that proof.
Digital certificates—also known as PKI certificates or public key certificates—act as virtual passports. Paired with asymmetric cryptography and proof of private key possession, they bind an asserted identity to a public key and support authenticated communications.
PKI helps organizations achieve several distinct security outcomes. It supports authentication by enabling people, devices and workloads to prove control of a private key. It supports the integrity of signed data and content by enabling recipients to detect changes to signed data or software. And depending on the protocol and use case, it can support confidentiality by helping entities establish authenticated, encrypted connections.
In some controlled instances, PKI can also support nonrepudiation—the ability to link a signature to a key holder—which makes later denial more difficult.
Cryptographic systems can be vulnerable to man-in-the-middle (MitM) attacks, where a malicious eavesdropper intercepts secure data during transmission. Without authenticated key distribution and correct certificate validation, an attacker can substitute their own public key for the intended party’s key and impersonate that party.
If an entity accepts an attacker-controlled or improperly validated key, the hacker can intercept encrypted messages sent over the compromised cryptosystem, decrypt and read the contents, reencrypt the messages and forward the now‑compromised communication. Everything would appear the same to the end user, and that attack would go undetected.
PKI, an essential component of internet security, provides a framework for assigning authenticated ownership of cryptographic keys. It enables systems to authenticate the identity associated with a public key, verify the integrity of signed information and establish secure communications with the intended party.
PKI also provides the trust and management system that makes public key cryptosystems usable at scale.
Stay up to date on the most important—and intriguing—industry trends on AI, automation, data and beyond with the Think newsletter. See the IBM Privacy Statement.
Cybersecurity specialists rely on cryptography practices to securely transmit data over potentially vulnerable or insecure networks. Cryptography enables users and systems to encrypt (scramble) and decrypt (unscramble) data, transforming readable plain text into unreadable ciphertext, to mask sensitive information from unauthorized users.
Encryption protocols facilitate secure transfers of data between users, entities and devices across e-commerce and banking platforms, enable Internet of Things (IoT)-connected devices to operate safely, and establish confidential lines of communication for secure email and web server communications.
There are two primary types of data encryption: public key cryptography and private key cryptography.
Also known as public key cryptography or public key encryption, asymmetric cryptography uses a public key for encryption, and a private key is used for decryption. The exact role of a key can vary (based on the protocol), but every identity has its own private key. Key pairs should be uniquely controlled by their intended subject or security boundary.
Symmetric cryptography—also called private key cryptography or secret key cryptography—uses one key for both encryption and decryption. For these types of systems to work, each user must already have access to the same secret key.
Symmetric keys might be shared through a previously established, trusted communication channel, such as a private courier or secured line. More practically, they can be exchanged by using a secure key exchange method, such as the Diffie–Hellman key agreement (where two parties establish the same secret value over an untrusted network without sending that secret itself).
Symmetric encryption is generally much faster than public key cryptography, but public key cryptography is often more practical and secure. In practice, both types of cryptosystems are often used together. For example, a system can encrypt bulk data with a randomly generated symmetric key and then protect that key using the recipient’s public key.
The Transport Layer Security (TLS) protocol—and its predecessor, Secure Socket Layer (SSL)—uses cryptographic algorithms to establish protected connections between web browsers and servers. It relies on X.509 certificates to validate users, servers and nonhuman identities (NHIs). These protocols establish trusted channels that keep data shared between a user’s browser and a website’s server private and protected from interception by hackers.
Cryptography is also used for popular messaging applications, such as WhatsApp, to provide end-to-end encryption (E2EE) and maintain the privacy of users’ conversations. With E2EE, only the sender and intended recipient can decrypt and read their messages, making it nearly impossible for third parties—including users’ own service providers—to access the content.
Public key infrastructure provides the people, processes, technologies and policies used to manage digital certificates. It adds a scalable trust model to these systems by cryptographically binding certificates to unique users, institutions and entities.
PKI comprises five key components.
Importantly, asymmetric encryption helps ensure that a user can know the public key without being able to derive the private key from it.
Certificates do not contain the holder’s private key. They contain the public key and the CA’s signed assertion about who—or what—that public key belongs to.
Trust authorities and hierarchy in PKI describe who is authorized to vouch for digital identities, and how that authority is organized rom trust anchors to subordinate issuers.
A trust authority is an entity that helps issue, validate or support trust in certificates. PKI trust authorities include:
The certificate authority is the trusted entity responsible for issuing and signing digital certificates. The CA uses its own private key to sign digital certificates and attest that it followed the appropriate identity validation and issuance procedures before binding the stated identity to the public key.
CAs in PKI often use a hierarchy.
The root CA is the trust anchor. Its self-signed certificate is installed or otherwise trusted by operating systems, browsers, enterprises or applications. An intermediate CA (or subordinate CA) receives delegated authority through a certificate signed by the root CA or another intermediate CA and usually issues certificates to end entities. It reduces exposure of the highly sensitive root CA key and permits separate issuance policies for different purposes. An end entity—or leaf—certificate is issued to the entity that needs to authenticate or sign.
The relying party builds and validates the entire certificate path, from the leaf certificate through any intermediate CA certificates to the trust anchor. Every link in the chain must be correctly signed and permitted to act as a CA.
The registration authority is responsible for identity verification and authorization of certificate applicants. For example, the RA might verify that a person requesting a smart card certificate is an active employee or that a workload requesting a machine identity is authorized by its cloud account or workload attestation mechanism.
An RA might be a separate service, a human-assisted enrollment function or part of the CA platform itself. However, separating RA and CA responsibilities can improve governance, because identity proofing and certificate signing are distinct trust functions.
A relying party is the person, browser, operating system, application, application programming interface (API) gateway or device that decides whether to trust a certificate. The relying party does more than check that a certificate “looks valid.” Depending on the application and certificate policy, the relying party might also check revocation status.
Relying parties are essential, because a certificate can only create useful trust if the system consuming it validates it correctly.
Lifecycle and status services manage certificates from beginning to end and let other systems determine whether a certificate should still be trusted in the current moment. They include:
PKIs need an enrollment process through which subjects can generate or receive a key pair and submit a certificate signing request (CSR). The request normally includes the public key and proposed identity information. After validating the applicant’s identity and authorization (and verifying proof of possession, where required), the CA creates and signs the certificate.
Modern environments often automate this process, because manual certificate issuance is not scalable to large fleets of web services, cloud workloads, devices, containers and short-lived machine identities.
A mature PKI uses approved enrollment protocols, platform integrations and policy controls to let eligible systems request, receive, install, renew and replace certificates without requiring a person to handle private keys or manually upload certificate files.
Importantly, enrollment protocols can automate issuance and renewal, but revocation and incident response are separate lifecycle functions that require policy, monitoring and often, human decision making.
Like a person or device, a workload might need an identity so that other systems can determine whether to trust it.
A workload certificate should not be issued just because a process can reach a certificate request endpoint. Before issuance, the PKI or its registration function needs evidence that the workload is the entity it claims to be and that it is authorized to receive the requested identity. This process is called workload attestation.
Attestation evidence varies by platform. It can include a cloud workload identity, virtual machine (VM) identity, Kubernetes service account, container orchestrator attributes or hardware measurements. The issuer evaluates that evidence against policy and then issues a certificate containing an identity appropriate to the workload’s purpose.
Workload identity is especially important for mutual TLS (mTLS). In mTLS, each side of a connection presents a certificate and proves possession of its corresponding private key. A service can therefore authenticate both the server it contacted and the calling workload, rather than authenticating only one side of the connection.
A certificate repository, directory or database stores and distributes certificates and relevant metadata. Depending on the PKI, it can publish issued end-entity and CA certificates; CA certificates that help construct certification paths; certificate revocation lists; policy documents; and certificate status information.
Directories make public certificates available to systems that need them, while access to private keys remains tightly restricted.
Certificates have expiration dates, but expiration alone is insufficient. A certificate might need to be invalidated early if its private key is compromised, its subject identity changes, an employee leaves, a device is decommissioned or the certificate was issued improperly.
Teams can use a certificate revocation list (CRL), a CA-signed list of revoked certificate serial numbers; an Online Certificate Status Protocol (OCSP), which enables a relying party to query an authorized responder about a specific certificate’s status; or OCSP stapling, where a server obtains an OCSP response and supplies it to connecting clients.
Some PKIs also use a validation authority (VA), which is responsible for publishing or providing revocation status information.
Certificate management systems manage digital certificates throughout their useful life, including discovery, issuance, storage, deployment, renewal, replacement, revocation and retirement. This is especially important because certificates expire by design and because an expired or improperly renewed certificate can cause an outage, and a compromised private key can create an identity security incident.
The first requirement is visibility. Organizations need a continuously updated inventory of certificates and, where appropriate, their associated key management records.
The second requirement is ownership. Ownership is essential, because a certificate is rarely “owned” by the PKI team alone. A certificate might support a public website, a virtual private network (VPN) gateway, a load balancer or a code signing process or cloud workload. The team responsible for that service needs to know which certificate it depends on, how renewal occurs and what to do if the certificate or private key is compromised.
Certificate management is not just an administrative function. It’s a reliability and platform engineering capability. A mature program treats certificate lifecycle management as automated operational capability across DevOps, security, infrastructure and application teams.
These are the safeguards, rules and day-to-day practices that make a PKI trustworthy. Certificates and cryptography alone cannot suffice. A PKI can have correctly designed certificates, but it’s not secure if someone can steal the CA’s private key or certificates expire unnoticed.
PKI protection, policy and operations include:
Private keys require strong protection at both the CA and end-entity levels.
Key management practices govern the generation, storage, activation, rotation, recovery and destruction of cryptographic keys. They often involve the use of hardware security modules (HSMs), trusted platform modules (TPMs), cloud key management services (KMSs) and identity and access management (IAM) systems.
In practice, these systems work together. The PKI issue a certificate; the HSM, TPM or cloud KMS protects the corresponding private key; an IAM tool supplies identity evidence during enrollment; and an application or policy engine authorizes the authenticated identity to perform a specific action.
Certificate policies define the rules and assurance requirements under which certificates are issued and used. They dictate what identities the PKI supports, how applicants are validated, what key protections are required, and which applications might rely on the certificates.
Policies are important because trust is not absolute. A certificate might be suitable for internal device authentication but not for signing public software releases or proving the identity of a public-facing commercial website.
Certification practice statements (CPSs) describe how the CA actually implements certificate policies.
In addition to CA servers and a collection of certificates, PKI encompasses the operational environment required to keep the trust system reliable. This includes network controls, monitoring practices, security teams and administrators, auditors, key generation procedures and decommissioning protocols.
Because cryptography alone cannot establish trustworthy identity, successful PKIs demand a broad scope. The surrounding controls determine whether the asserted identity was verified correctly and whether private keys remain protected throughout their lifecycle.
The terms “public trust” and “private trust” might seem parallel to the public and private keys used in asymmetric cryptography, but they actually describe the scope of recognition for a certificate authority. Every PKI uses public-private key pairs; the distinction is whether the root CA is trusted broadly by the public or only within a defined organization or system.
In a publicly trusted PKI, the root CA is part of the truststores maintained by major browsers, operating systems and devices. When a public CA issues a certificate for a domain, the visitor’s browser can build a certificate chain from that website’s certificate, through any intermediate CAs, to a root CA it already trusts. This model is generally used for public websites and other internet-facing services that have to work for customers, partners and other unmanaged external users without special configuration.
In a privately trusted PKI, an organization chooses which devices, applications and workloads trust its root CA. It distributes the root certificate using enterprise device management, operating system configuration, application configuration or infrastructure automation. As a result, certificates issued by the organization’s private CA are trusted by its managed systems, but they are not automatically trusted by ordinary browsers or unmanaged devices.
Private trust is commonly used for internal applications, VPNs, wifi and network access, employee and device certificates, internal APIs, certificate databases, containers, cloud workloads and mTLS between services. It gives businesses more control over certificate profiles, identity validation procedures and access policies within their own environment.
Public key infrastructure is designed to support long-lived trust relationships, but the cryptographic algorithms that underpin those relationships can change. New attacks, advances in computing and changes in security standards can render an algorithm or certificate profile unsuitable over time.
Therefore, many enterprises prioritize crypto-agility—the ability to identify, change and deploy cryptographic algorithms and keys (and their supporting software) without causing widespread disruption.
Post-quantum cryptography (PQC) is a major driver of cryptographic agility. Large-scale quantum computers have the potential to undermine widely used public key algorithms, so PKI environments that use quantum-vulnerable algorithms might consider transitioning to quantum-resistant digital signatures and key establishment mechanisms.
This transition is not simply a matter of replacing one certificate template. PKIs depend on many connected components: root and intermediate CAs, certificate management platforms, HSMs, operating systems, browsers, application libraries, network devices, service meshes, APIs, endpoint agents and certificate validation logic. All of these components need to interoperate with the selected algorithms and certificate formats.
Organizations can prepare for post-quantum migration by:
PKI supports far more than browser-to-website encryption and employee VPN access. Businesses use certificate-based identities and digital signatures to secure NHI communications across cloud, on-premises and edge environments.
Modern networks rely on and interact with thousands of NHIs—digital identities that belong to software instead of a human being. NHIs include microservices, APIs, VMs, continuous integration/continuous delivery (CI/CD) jobs, Kubernetes workloads, IoT devices and more recently, artificial intelligence (AI) agents. These identities now significantly outnumber human users (estimates range from 45:1 to 92:1).
The challenge is that machine identities often change more quickly than human identities. A workload in a container platform, for example, might exist only for minutes or be re-created multiple times each day. To address this challenge, modern workload PKIs typically combine automated identity attestation, short-lived certificates, automatic renewal and policy-based authorization.
The PKI certificate can bind a workload, device or service identity to a public key. And during a mTLS handshake, for example, both sides present certificates and prove possession of their private keys so that each service can authenticate the other before exchanging data. This enables networks to facilitate secure, scalable, least-privilege, workload-to-workload access without relying on long-lived shared secrets or manual certificate management.
Let’s use the example of a company issuing a client certificate to an employee for VPN access. The process might go as follows:
Protect secrets, manage machine identities and issue dynamic credentials for agentic AI and hybrid cloud.
Secure non-human identities with dynamic credentials, runtime enforcement, delegation and audit trails.
Strengthen security with modern identity and access management.