Skip to main content
Digital Compliance Bureau
Commerce Security logo, "All 12 PCI DSS Requirements in Plain English," "Get it now for free," "Complete Survival Guide" and a button toclick to get it
Category: Technical Controls

Public Key Infrastructure

Also known as:
Simply put

Public Key Infrastructure (PKI) is the combination of policies, processes, hardware, and software used to create and manage the digital certificates and cryptographic key pairs that secure data on networks. It underpins common forms of internet encryption, helping to protect and authenticate traffic between systems such as web browsers and web servers. In practical terms, PKI is what allows two parties who may not know each other to establish trust when exchanging information online.

Formal definition

PKI is a set of roles, policies, processes, hardware, software, server platforms, and workstations used to create, manage, distribute, use, store, and revoke digital certificates and to administer the associated public-private key pairs. It provides a trust framework in which certificates bind public keys to identities, supporting encryption, authentication, and secure data transfer across digital networks. PKI is a framework of components and procedures rather than a single product or protocol, and specific implementations, certificate policies, and supporting standards vary by deployment and should be verified against the relevant authoritative specifications.

Why it matters

PKI is foundational to trust on digital networks because it allows parties who have no prior relationship to authenticate one another and exchange information securely. By binding public keys to verified identities through digital certificates, PKI enables the encryption and authentication that protect traffic between systems such as web browsers and web servers. For compliance and security professionals, this makes PKI a load-bearing element of many technical safeguards: without a functioning trust framework, common forms of internet encryption and secure data transfer would not be possible.

Because PKI underpins so much of everyday secure communication, weaknesses in its policies, processes, or key management can have broad consequences. A framework is only as trustworthy as the procedures governing certificate issuance, storage, use, and revocation; gaps in any of these can undermine the assurances that relying parties depend on. This matters for organizations that must demonstrate the confidentiality, integrity, and authenticity of data in transit as part of their broader security and data protection obligations.

It is worth emphasizing that PKI is a framework of components and procedures rather than a single product, protocol, or compliance requirement in itself. It is frequently a means of implementing security controls rather than an obligation imposed by any specific regulation. Whether and how a particular PKI deployment satisfies a given legal or contractual requirement is fact-specific and depends on the applicable standards, certificate policies, and risk context, which should be verified against the relevant authoritative specifications.

Who it's relevant to

Information security professionals
Those responsible for securing data in transit rely on PKI to enable encryption and authentication between systems. Understanding PKI as a framework of policies and procedures, not just a set of tools, helps them design and operate certificate issuance, storage, use, and revocation processes soundly. The specific standards and certificate policies applicable to a given deployment should be confirmed against authoritative specifications.
Auditors and assessors
When evaluating an organization's technical safeguards, auditors and assessors may need to examine how a PKI deployment is governed, including its certificate policies and key management procedures. Because PKI is a means of implementing controls rather than a control mandated by any single rule, its adequacy is assessed relative to the applicable requirements and risk context rather than against a universal benchmark.
Compliance officers and legal counsel
Professionals mapping security measures to legal or contractual obligations should treat PKI as an implementation choice that can support requirements around confidentiality, integrity, and authenticity of data, rather than as an obligation in itself. Whether a particular PKI configuration satisfies a specific requirement is fact-specific and depends on applicable standards and policies, which warrant verification against current authoritative sources.
System and identity architects
Those designing systems that must establish trust between parties with no prior relationship use PKI to bind public keys to identities and enable secure exchange. Because implementations, certificate policies, and supporting standards vary by deployment, architects should confirm design decisions against the relevant authoritative specifications rather than assuming a single standard model.

Inside PKI

Certificate Authority (CA)
The trusted entity that issues, signs, and vouches for the authenticity of digital certificates. A CA may operate as a root CA, at the top of the trust chain, or as a subordinate (intermediate) CA that issues certificates under the root's authority. The trustworthiness of the entire PKI depends on the integrity of the CA's operations and key protection.
Registration Authority (RA)
The component responsible for verifying the identity of entities requesting certificates before the CA issues them. The RA generally handles enrollment and identity vetting but does not itself sign certificates, keeping the roles of identity verification and certificate issuance separated.
Digital Certificates
Electronic credentials that bind a public key to an identity (a person, device, or service). Certificates commonly follow the X.509 standard and typically contain the public key, subject and issuer identifiers, a validity period, and the CA's digital signature. Verify specific field and format requirements against the applicable standard and profile in use.
Public and Private Key Pairs
The asymmetric cryptographic keys underpinning PKI. The public key is distributed within a certificate, while the corresponding private key must be kept confidential by its holder. The security of the system depends on the private key never being exposed.
Certificate Revocation Mechanisms
Processes for invalidating certificates before their scheduled expiry, such as Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP). These allow relying parties to check whether a previously valid certificate has been compromised, superseded, or otherwise withdrawn.
Certificate Repository and Distribution
Directories or services through which certificates and revocation information are published and made available to relying parties, enabling them to locate and validate credentials.
Certificate Policy (CP) and Certification Practice Statement (CPS)
Governance documents that define the rules under which certificates are issued and the practices a CA follows in operating the PKI. These establish the assurance level and intended uses associated with certificates and are central to assessing whether a given PKI is fit for a particular purpose.

Common questions

Answers to the questions practitioners most commonly ask about PKI.

Is deploying PKI enough to make an organization compliant with data protection or security regulations?
No. PKI is a technical mechanism for managing digital certificates and public-key cryptography; it is not itself a compliance regime. Regulations such as the GDPR (EU/EEA) or HIPAA (U.S. healthcare) impose obligations that may be supported by cryptographic controls, but implementing PKI does not by itself satisfy those obligations. Compliance depends on the full set of organizational, procedural, and technical measures appropriate to the risk, data category, and jurisdiction involved. Treat PKI as one control among many, and assess it against the applicable legal and contractual requirements with professional judgment.
Does using a well-known certificate authority mean PKI is automatically trusted and secure everywhere?
Not necessarily. Trust in a certificate authority (CA) is contextual rather than universal. A certificate is trusted only by parties whose systems include the issuing CA (or its root) in their trust stores, and trust decisions can differ across browsers, operating systems, platforms, and private ecosystems. A publicly recognized CA does not guarantee acceptance in every environment, and security also depends on how keys, certificates, and revocation are managed. Verify which trust anchors your relying parties actually rely on rather than assuming universal recognition.
How does an organization typically handle certificate lifecycle management within a PKI?
Certificate lifecycle management generally covers issuance, renewal, and revocation, along with key generation, storage, and eventual retirement. Many organizations use automated tooling to track expiry and trigger renewals, since lapsed certificates can cause outages. The specific processes, roles, and controls depend on the deployment model and organizational needs. This entry describes the concept qualitatively; readers should design lifecycle procedures to fit their own environment and verify any technical requirements against current authoritative documentation and applicable standards.
What is the difference between a public (external) and a private (internal) PKI in practice?
A public PKI relies on CAs whose roots are broadly distributed in commercial trust stores, making certificates suitable for externally facing services where relying parties are outside the organization. A private (internal) PKI issues certificates trusted only within a defined environment, such as an enterprise network or closed ecosystem, where the organization controls the trust anchors. The choice depends on who the relying parties are and the intended use. This distinction is descriptive; specific suitability should be evaluated case by case.
How is certificate revocation typically communicated to relying parties?
Revocation status is generally conveyed through mechanisms such as certificate revocation lists (CRLs) or online status-checking protocols, allowing relying parties to determine whether a certificate remains valid before trusting it. The effectiveness of revocation depends on whether relying systems actually check status and on how promptly information propagates. Implementation choices vary by environment and evolving practice. Confirm the mechanisms your systems support and consult current authoritative technical references rather than assuming a single universal approach.
What considerations arise when protecting the private keys underlying a PKI?
Private key protection is central to PKI, because the security of the system depends on keys remaining confidential and controlled. Organizations often consider where keys are generated and stored, who can access them, and how access is governed, with hardware-based protection used in some higher-assurance deployments. The appropriate measures depend on the sensitivity of the use case and applicable risk. This entry addresses the concept generally; specific control selection requires professional judgment and verification against relevant standards and documentation.

Common misconceptions

A PKI or the certificates it issues are themselves 'compliant' with a regulation.
PKI is a set of technical and operational components, not a regulation or a compliance status. It may serve as a control that helps satisfy security or electronic-signature requirements, but whether its use meets a specific legal or contractual obligation depends on the applicable rules, the assurance level, and how the PKI is deployed. Compliance is fact-specific and requires separate assessment.
A valid, unexpired certificate is always trustworthy.
Validity depends on more than the expiry date. A certificate may be revoked before expiry if the private key is compromised or the binding is no longer accurate, so relying parties should generally check current revocation status (for example via CRL or OCSP) in addition to confirming the certificate is within its validity period and chains to a trusted CA.
All Certificate Authorities offer the same level of assurance.
The assurance associated with a certificate depends on the CA's identity-vetting practices and governance, as set out in its Certificate Policy and Certification Practice Statement. Different CAs and different certificate types provide different levels of assurance, and the appropriate choice depends on the intended use and risk. Practitioners should evaluate these documents rather than assume equivalence.

Best practices

Protect private keys rigorously, using hardware security modules or equivalent controls where appropriate, and restrict access so that private keys are never exposed to unauthorized parties.
Implement and test revocation checking (CRL and/or OCSP) in relying-party systems so that compromised or superseded certificates are detected, rather than relying on expiry dates alone.
Maintain an inventory of issued certificates and their validity periods, and manage renewal proactively to avoid unexpected expirations and service disruption.
Review each CA's Certificate Policy and Certification Practice Statement to confirm the assurance level and intended uses match your requirements before relying on its certificates.
Keep the trust chain minimal and well-governed by separating root and subordinate CA roles, protecting root CA keys offline where feasible, and separating identity vetting (RA) from issuance (CA).
Verify certificate formats, revocation mechanisms, and any applicable requirements against the current authoritative standards and, where relevant, the specific regulatory or contractual rules governing your use case, since standards and schemes are periodically revised.
Promotional banner for the Pentest Readiness checklist download