Category: Cryptography & Encryption

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 electronic communications. It provides the framework that lets systems verify identities and protect data as it moves between parties. In practice, PKI is what makes trusted encryption and digital signatures possible across a network.

Formal definition

PKI is a set of policies, processes, server platforms, software, and workstations used to administer certificates and public-private key pairs, including the ability to create, manage, distribute, use, store, and revoke them. It governs the lifecycle of digital certificates and the associated public key encryption methods that underpin secure data transfers, authentication, and integrity assurance. Implementations vary in their specific roles and procedures, and readers should confirm the exact requirements and definitions against the applicable authoritative source for their environment.

Why it matters

PKI is the foundational trust layer for most modern secure communications in defense and public sector environments. Without a working infrastructure to issue, validate, and revoke digital certificates, systems cannot reliably verify who or what they are communicating with, nor protect data in transit through encryption and digital signatures. For organizations handling Controlled Unclassified Information (CUI) or operating systems under the Risk Management Framework (RMF), PKI is typically the mechanism that underpins identity assurance, secure authentication, and data integrity controls, and it commonly appears as a dependency behind identification and authentication, system and communications protection, and access control requirements.

A recurring expert concern is treating certificate issuance as a one-time event rather than a lifecycle. Certificates expire, keys can be compromised, and trust anchors change over time, so the ability to revoke and reissue certificates is as important as the ability to create them. An expired or improperly revoked certificate can silently break secure connections or, worse, leave a compromised key in circulation. Compliance officers should also avoid equating the presence of PKI with security itself: a poorly governed PKI with weak issuance policies, unprotected private keys, or unmonitored certificate inventories can create a false sense of assurance while introducing single points of failure.

Because specific PKI requirements, approved certificate policies, and trust hierarchies differ across federal civilian, defense, and national security systems, readers should confirm the exact obligations and definitions that apply to their environment against the applicable authoritative source. This entry describes the general concept and does not cover the implementation, procurement, or accreditation specifics that a given agency or program may mandate.

Who it's relevant to

Information System Security Managers (ISSMs) and system administrators

Those responsible for RMF-governed systems generally rely on PKI to satisfy identity, authentication, and communications protection objectives. They should track certificate inventories, monitor expiration and revocation, and ensure private keys are protected, treating certificate management as an ongoing operational responsibility rather than a one-time configuration task.

Authorizing Officials (AOs)

AOs evaluating a system's security posture should understand where PKI serves as a dependency for other controls. Because an Authority to Operate is time-bound and subject to continuous monitoring, the health of certificate lifecycle management can bear directly on ongoing authorization decisions.

Government contractors handling CUI

Contractors safeguarding CUI may use PKI to support encryption, authentication, and data integrity requirements. They should confirm the specific certificate policies, trust anchors, and issuance requirements that apply to their contracts and environments against the applicable authoritative sources rather than assuming a general commercial PKI implementation suffices.

Compliance officers and auditors

When assessing controls that depend on PKI, auditors should verify not just that certificates exist but that governing policies, key protection, and revocation processes are operating effectively. The presence of PKI does not by itself demonstrate security or compliance; the surrounding governance and lifecycle management must also be evidenced.

Inside PKI

Certification Authority (CA)

The trusted entity that issues, signs, and manages digital certificates binding public keys to identities. In DoD environments, PKI is generally anchored to the DoD PKI and associated root and intermediate CAs, though specifics should be verified against current DoD PKI policy.

Registration Authority (RA)

The component responsible for verifying the identity of entities requesting certificates before the CA issues them. The RA validates the subscriber's request but typically does not itself sign certificates.

Digital Certificates

Electronic credentials (commonly following the X.509 standard) that bind a public key to a subject identity and carry attributes such as validity period, issuer, and usage constraints. Certificates are time-bound and subject to expiration and renewal.

Public and Private Key Pairs

The asymmetric cryptographic keys underpinning PKI. The public key is distributed within the certificate, while the private key must remain under the sole control of its holder to preserve authentication and non-repudiation properties.

Certificate Revocation Mechanisms

Processes and data structures, such as Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) responders, used to indicate that a certificate is no longer trustworthy before its scheduled expiration.

Certificate Policy (CP) and Certification Practice Statement (CPS)

Governance documents that define the assurance level, operational rules, and practices under which certificates are issued and managed. Practitioners should confirm the applicable CP/CPS for their environment against current authoritative sources.

Repositories and Trust Anchors

Directories or stores where certificates and revocation information are published, along with the trust anchors (root certificates) that relying parties must configure to validate certificate chains.

Common questions

Answers to the questions practitioners most commonly ask about PKI.

Does implementing PKI by itself make a system compliant or secure?

No. PKI is a supporting capability, not a compliance outcome or a guarantee of security. Deploying certificates and a certificate authority may help satisfy specific control objectives (such as those related to identification, authentication, and cryptographic protection), but compliance is determined by how the implementation is assessed against the applicable control baseline and authorized. An expert would caution against equating deployment of PKI with meeting a requirement; the implementation must still be documented, assessed, and maintained under continuous monitoring, and misconfigured or poorly managed PKI can itself introduce risk.

If a PKI has been authorized or accepted for one environment, does that acceptance automatically carry over to other environments?

Not necessarily. Acceptance of a PKI or its issued credentials in one context does not automatically satisfy the requirements of another, and readers should not assume that an authorization or trust decision made by one authorizing official transfers to a different system, agency, or scope boundary. Federal civilian, defense, and national security systems may impose different trust, cross-certification, or credential requirements, and cross-domain or reciprocal acceptance generally depends on explicit policy and trust agreements. Confirm the specific acceptance and trust conditions against current authoritative sources for the environment in question.

How does PKI relate to the identification and authentication controls in a control baseline?

PKI is one mechanism organizations may use to implement identification and authentication objectives, including support for multifactor or certificate-based authentication. Whether and how PKI is used generally depends on the applicable control baseline, the system's categorization or impact level, and any agency-specific tailoring. Because control baselines and their requirements vary across revisions and by system type, verify the current applicable requirements and how PKI-based approaches are expected to be implemented and assessed.

What lifecycle activities does maintaining a PKI typically involve?

In most implementations, maintaining a PKI involves ongoing lifecycle management of certificates and keys, including issuance, renewal, revocation, and handling of expiration, as well as management of the underlying certificate authorities and their trust relationships. These activities generally continue for the life of the system and are consistent with continuous monitoring expectations rather than being a one-time setup. Specific responsibilities, intervals, and procedures should be confirmed against the governing policy and the organization's authorized security documentation.

How should revocation be handled in a PKI implementation?

Revocation allows a certificate to be treated as no longer trusted before its scheduled expiration, and mechanisms for publishing and checking revocation status are generally an expected part of a functioning PKI. The particular methods, availability requirements, and checking obligations can vary by environment and by the applicable requirements, so implementers should verify which revocation approaches and checking behaviors are required or acceptable for their system against current authoritative sources and organizational policy.

What should be documented about a PKI implementation for assessment and authorization purposes?

For assessment and authorization, organizations generally document how the PKI implements the relevant controls, including how credentials are issued and managed, how keys are protected, how trust relationships are established, and how revocation and lifecycle management are handled. Because assessment and authorization are distinct steps, this documentation supports assessors evaluating the implementation and supports an authorizing official's risk-based decision, which is time-bound and subject to continuous monitoring. Confirm the specific documentation expectations against the applicable process and current official guidance for the environment.

Common misconceptions

A digital certificate, once issued, remains valid and trusted indefinitely.

Certificates are time-bound and can be revoked before expiration. Relying parties generally must check current revocation status (for example via CRL or OCSP) rather than assuming continued validity, and expired certificates must be renewed.

Deploying PKI by itself makes a system secure or compliant.

PKI is an enabling mechanism supporting identification, authentication, and non-repudiation, not a complete security or compliance program. It must be implemented within a broader control framework, and compliance should not be equated with security. Verify how PKI maps to applicable controls in your governing framework.

Any PKI or commercial certificate is acceptable for DoD or CUI-related use.

Federal civilian, defense, and national security environments may impose specific trust anchor, assurance level, and approved-provider requirements that differ. A certificate acceptable in one context may not satisfy DoD PKI or CUI-handling obligations. Confirm accepted trust chains and assurance levels against current authoritative policy for your scope.

Best practices

Protect private keys under the sole control of their holders, using hardware tokens or hardware security modules where the applicable policy or assurance level calls for them.

Implement and monitor revocation checking (CRL and/or OCSP) so relying parties do not trust certificates that have been revoked before expiration.

Track certificate validity periods and establish a renewal and lifecycle process to prevent outages or trust failures caused by expired certificates.

Confirm that the CA hierarchy, trust anchors, and assurance levels used are accepted for your specific environment, federal civilian, DoD, or CUI-related, rather than assuming interchangeability across scopes.

Maintain and follow the applicable Certificate Policy and Certification Practice Statement, and verify their current versions against authoritative sources before relying on them.

Treat PKI as one component within your broader control framework, mapping its identification, authentication, and non-repudiation functions to the specific controls required by your governing authority.