What is the difference between a public key and a private key in PKI?

Public keys and private keys are the two halves of asymmetric cryptography. The public key is meant to be distributed, while the private key must remain secret. What differs in practice is not just who can see each key, but what each key is allowed to do: one exposes no secrecy and the other proves possession of it.

The public key is safe to share because it is designed for public verification and encryption, not for secrecy. A sender can use it to encrypt data to the key owner, or a verifier can use it to check a digital signature. The private key performs the reverse-sensitive operation, so any compromise of that key immediately undermines confidentiality or trust for every system that relies on it.

The operational distinction matters most when teams decide where keys live, who can access them, and how they are rotated or revoked. If a public key is copied, the usual risk is false trust or a bad key exchange. If a private key is copied, the risk is broader: impersonation, decryption, signature forgery, and often silent compromise until the key is replaced.

Why the public key can be shared but the private key cannot

The mathematical relationship between the two keys is one-way in the useful sense. Knowing the public key should not let an attacker derive the private key with feasible effort, which is why the public half can be published in certificates, directories, and trust stores. That design lets strangers encrypt data to you or validate your signatures without ever learning the secret half.

This is also why PKI works at scale. An organisation can distribute certificates broadly, but the private key stays behind a tighter boundary such as an endpoint, HSM, or controlled service environment. The security value comes from keeping the private key confidential while allowing the public key to be widely visible.

That separation is easier to explain than to maintain. Teams often confuse “public” with “harmless” and “private” with “safe if stored somewhere secure,” but the real question is whether the private key is protected against export, reuse, and unauthorized signing or decryption. Once the private key is exposed, the entire trust model around that key can fail.

What each key is used for in real PKI workflows

In encryption workflows, the public key protects confidentiality by locking data to the intended recipient, and the private key unlocks it. In signature workflows, the private key creates the signature and the public key verifies it. Those two uses are related but not interchangeable, and that is why key handling, certificate purpose, and algorithm choice matter.

In practice, PKI is usually about both identity assurance and secure communication. The certificate publishes the public key and binds it to a subject, while the private key proves that the holder can perform the corresponding cryptographic action. If that private key is used for server authentication, code signing, or client authentication, compromise can create very different blast radii even though the key type is the same.

For a deeper working view of certificate handling, PKI trust chains, and failure patterns, see the PKI Basics Guide and the Cryptography Basics Guide.

What changes when the private key is exposed or mishandled

A leaked public key usually changes little by itself. A leaked private key changes the control plane of trust. Attackers may decrypt captured traffic, impersonate a service, sign malicious content, or present themselves as the legitimate holder of the certificate or credential. That is why private key handling is treated as a high-impact secret management problem, not just a cryptography detail.

Exposure often happens through the same channels as other secrets: source repositories, container images, backup files, logs, test systems, or poorly protected export paths. Once copied outside the intended boundary, a private key can be reused long after the original incident, especially if revocation and rotation are slow.

That is also why key rotation has to be planned as an operational process, not an emergency improvisation. The key itself may be mathematically strong, but the surrounding lifecycle, storage, and revocation discipline determine whether it remains trustworthy in production.

Risk and Threat Considerations

The main risk is not that the public key is visible, it is that the private key becomes available to someone who should not have it. At that point, confidentiality, authenticity, and non-repudiation can all be affected at once, depending on how the key is used in PKI.

Failure mechanism: An attacker or careless process extracts, copies, or reuses the private key from a system, image, repository, backup, or memory location, then uses it to decrypt data or produce trusted signatures that look legitimate.

Impact: Organisations may have to assume that every certificate or token material protected by that key is compromised, then revoke trust, rotate dependent credentials, and check for misuse before the exposure is fully understood.

Practitioner Guidance

What to verify: Treat the public key as distributable material, but verify the private key is non-exportable or tightly controlled wherever the use case allows it. For high-value systems, confirm where the key is stored, who can access it, and whether the certificate lifecycle includes revocation and replacement steps that are actually executable.

Decision rule: If the private key has been exposed, rotate it first and then assess whether any signatures, encrypted data, or authenticated sessions created with that key must be considered untrusted. If only the public key changed, focus on distribution correctness and certificate validation rather than secrecy.

Practitioner takeaway: The public/private distinction is really a trust-boundary distinction, if the private half can be copied or reused outside its intended control, PKI stops being a proof system and becomes a compromise propagation problem.

Related resources from NHI Mgmt Group

• Guide: Machine Identity, PKI and Certificate Lifecycle Guide
• When should organisations use private PKI instead of public certificates for client auth?
• What is the difference between public PKI and private PKI for workload identity?
• What is the difference between private key encryption and public key encryption for practitioners?
• How should security teams govern public key vs private key management at scale?