What Is PKI? Public Key Infrastructure Explained

What is PKI?

PKI (Public Key Infrastructure) is a complete ecosystem of institutions, standards and procedures that makes it possible to manage digital certificates — digital identity documents for servers, devices and people on the internet. It is worth stating up front what PKI is not: it is neither a cryptographic algorithm nor a product you buy. It is a trust layer — infrastructure that answers the question: how do you know that a given public key really belongs to the entity claiming to own it?

What falls within the scope of PKI?

• Manages public keys and the digital certificates bound to them.
• Defines roles and procedures: who issues certificates, who verifies identity, who revokes.
• Builds a trust hierarchy — a chain of attestations from an end-entity certificate up to a trusted root authority.
• Does NOT manage symmetric keys (such as AES). It is, however, the foundation for protocols that use both types — TLS uses PKI for authentication, then switches to a faster symmetric cipher.

What problem does it solve?

Imagine connecting to bank Robots Atlas. The server sends you a public key. How do you know it really is bank Robots Atlas and not an impersonator? Cryptography alone cannot answer that. PKI supplies the missing link: a verifiable system of attestations that lets a browser judge, in a fraction of a second, whether a server's certificate is authentic.

Who is behind it?

PKI rests on asymmetric cryptography, whose public history begins in 1976 with New Directions in Cryptography by Whitfield Diffie and Martin Hellman. A year later Ron Rivest, Adi Shamir and Leonard Adleman at MIT produced the RSA algorithm, still one of the pillars of digital signatures.

There is, however, a second and long-suppressed version of this story. As revealed only in December 1997, the asymmetric concepts had in fact been developed years earlier behind the closed doors of the British intelligence agency GCHQ. In 1970 James Ellis formulated the idea of "non-secret encryption". In 1973 Clifford Cocks created a mathematical equivalent of today's RSA, and in 1974 Malcolm Williamson described the principle later known as Diffie-Hellman key exchange. The discoveries were immediately classified, so for more than two decades the academic world had no idea it was reinventing something that already existed. The architecture of certificates and certification authorities, in turn, is the work of standards bodies — chiefly the IETF, which codified the modern certificate format in RFC 5280.

How does it work?

PKI builds on the foundation of asymmetric cryptography: every entity has a key pair — a public key (known to everyone) and a private key (kept secret). But a key pair alone does not solve the central problem: how do you know that the public key you received really belongs to bank Robots Atlas and not to someone impersonating it? That is the problem PKI solves.

The certificate — a digital identity document

The answer is a digital certificate. Think of it as a passport: it contains identity data and the signature of an authority that issued it. A certificate works the same way:

• Public key — the mathematical identity of the entity (e.g. the bank).
• Subject data — domain name, organisation, validity period.
• Certification Authority (CA) signature — a cryptographic attestation that this data is genuine.

A certificate without a CA signature is like a piece of paper saying "I am the bank" — anyone can print one. The CA signature turns it into a verifiable document.

The Certification Authority — a trusted third party

A CA is an institution that operating systems and browsers trust by default. Vendors (Microsoft, Apple, Google, Mozilla) embed a list of trusted Root CA^?Root CA: Root Certification Authority — the top level of the PKI hierarchy. It has a self-signed certificate and its private key is stored offline in an HSM. It is trusted by default by operating systems and browsers.s directly into their software. This is the trust store^?Trust store: A built-in list of trusted Root CA certificates embedded in an operating system or browser. It is what software uses to decide which certification authorities to trust by default..

When a CA signs bank Robots Atlas's certificate, it states: "We have verified that this public key really belongs to this entity." Your browser trusts the CA — so it trusts the certificate too.

Certificate verification — step by step

What happens when you visit bank.robotsatlas.com?

1. The bank's server sends you its certificate (containing its public key and the CA's signature).
2. The browser checks the CA's signature on the certificate — is this a trusted authority from its trust store?
3. It verifies the chain of trust: the bank's certificate → intermediate CA^?Intermediate CA: A certification authority signed by the Root CA that issues end-entity certificates on its behalf. Difference from the Root CA: the Root key stays offline and almost unused (protected), while the intermediate CA operates day to day. This way a compromised intermediate does not force replacing the trusted Root CA baked into systems. → Root CA. Every link must be correctly signed by the one above it.
4. It checks validity: has the certificate expired or been revoked (CRL^?CRL (Certificate Revocation List): A CA-signed list of certificates revoked before their expiry date (e.g. after a key leak). The client downloads the whole list and checks whether a given certificate is on it./OCSP^?OCSP (Online Certificate Status Protocol): A protocol for checking certificate status in real time. Instead of downloading the whole CRL, the client asks the CA server about one specific certificate and gets a response: valid or revoked.)?
5. If everything checks out — the connection is trusted. The browser knows the public key really belongs to bank Robots Atlas.

If any link in the chain fails — the browser shows a warning. There is no middle ground.

How a certificate is created — the CSR process

The whole process starts with you — the administrator who wants a certificate for their server (e.g. bank Robots Atlas). A CA does not create a certificate out of thin air — first you have to request one using a special application called a CSR (Certificate Signing Request).

Step by step:

1. You generate a key pair on your server — public and private. The private key stays with you and never leaves the server.
2. You create the CSR — a file containing your public key and your details (e.g. the domain name robotsatlas.com). You send it to the CA.
3. The CA checks that the domain is really yours (this step is handled by the RA — the registration authority). Typically it asks you to place a specific token under your domain.
4. The CA signs your public key with its own private key and returns the finished certificate. You install it on your server.

The key point: your private key never travels to the CA. The CA signs only your public key — because that public key, stamped with the CA's signature, is what becomes the certificate your server presents to browsers.

What are its key components?

Institutions and roles

• Certification Authority (CA) — a trusted institution that signs other entities' certificates with its own private key, attesting: "this public key really belongs to this entity".
• Registration Authority (RA) — verifies the applicant's identity before the CA issues a certificate. May be integrated with the CA or operate separately.
• Repositories — databases distributing certificates and revocation lists (CRL).
• Subscribers — the entities a certificate is issued for (server, device, person).
• Relying parties — applications and browsers that verify certificates.

The X.509 certificate — what it contains

The standard is X.509 v3 (RFC 5280). Every certificate is a digitally signed document containing:

• Subject's public key — the main payload of the certificate.
• Subject identity — domain name, organisation.
• Issuer identity — who signed the certificate.
• Validity period — Not Before / Not After dates.
• Extensions — including Subject Alternative Name^?Subject Alternative Name (SAN): An X.509 certificate extension that binds a single certificate to multiple domain names (e.g. robotsatlas.com, www.robotsatlas.com, api.robotsatlas.com) and IP addresses. Today it is the SAN, not the Subject field, that determines which domains a certificate is valid for. (SAN) for multiple domains, Key Usage^?Key Usage: A certificate extension that specifies what the contained key may be used for — e.g. digital signatures, key encipherment, or signing other certificates. It restricts the key to a predefined set of operations., AIA^?AIA (Authority Information Access): A certificate extension that points to the URLs where its status can be checked (OCSP server) and where the issuer certificate needed to build the chain of trust can be downloaded. (where to find OCSP^?OCSP (Online Certificate Status Protocol): A protocol for checking certificate status in real time. The client asks the CA server about one specific certificate and gets a response: valid or revoked./issuer certificate).
• CA signature — cryptographic attestation of the entire document's authenticity.

The chain of trust

PKI operates in a three-level hierarchy:

• Root CA — the top of the hierarchy. Self-signed certificate. Private key stored offline in an HSM^?HSM (Hardware Security Module): A dedicated hardware device for storing cryptographic keys and performing operations on them internally. The private key never leaves the module — it cannot be exported or copied, even if the server is compromised. This is why Root CA keys are kept in one.. The list of Root CAs is baked into your operating system and browser (the trust store).
• Intermediate CA — signed by the Root CA. Issues end-entity certificates. Isolates daily operations from the Root CA's keys.
• End-entity (Leaf) certificate — issued for a server, device or person. Cannot sign other certificates.

Verification works bottom-up: the browser checks each link's signature until it reaches a Root CA from its trust store. One invalid link — connection rejected.

Validation levels: DV, OV and EV

Not all TLS^?TLS (Transport Layer Security): The protocol that encrypts the connection between a browser and a server. It is what powers “https” and the padlock in the address bar. The successor to the older SSL. certificates confirm the same knowledge about the domain owner:

• DV (Domain Validation) — CA^?CA (Certification Authority): A trusted institution that verifies identity and signs certificates with its own key, attesting that a given public key belongs to a specific entity. checks only control over the domain. Fast, free, automated. HTTPS padlock^?HTTPS padlock: The padlock icon in the browser’s address bar. It means the connection is encrypted (TLS) and the domain has a valid certificate — but it does NOT prove the site owner is honest or trustworthy. = encryption + domain verified. Nothing more.
• OV (Organization Validation) — CA additionally verifies company data against public registers.
• EV (Extended Validation) — highest level: detailed legal check of the organisation.

Key takeaway: the HTTPS padlock does not confirm the trustworthiness of the site owner — only that the domain has been verified (usually DV^?Usually DV: Most public TLS certificates today are DV certificates — because they are free (e.g. Let’s Encrypt) and issued automatically. They verify only domain control, not company identity.).

Automation — the ACME protocol and Let's Encrypt

For years, obtaining a certificate was a manual, paid process. Two changes turned this model upside down:

• Let's Encrypt (2016) — a non-profit offering free DV certificates for everyone.
• ACME protocol (RFC 8555) — automates the full cycle: domain verification, issuance and renewal. No human involvement required.

ACME is what makes it operationally feasible to shorten certificate lifetimes to 90 days and below. Without automation, renewing thousands of certificates every few weeks manually would be unmanageable.

Private key protection and key escrow

Compromising a private key is more dangerous than breaking the algorithm — an attacker could impersonate the owner for the entire validity period with no external signs.

• HSM (Hardware Security Module^?Hardware Security Module (HSM): A dedicated hardware device for storing cryptographic keys and performing operations on them internally. The private key never leaves the module — it cannot be exported or copied, even if the server is compromised.) — a dedicated hardware device that performs cryptographic operations internally and physically prevents key export. Mandatory for Root CA keys.
• Key escrow — an encrypted key backup held by a trusted party. Critical for S/MIME^?S/MIME: A standard for encrypting and signing email using certificates. It lets you encrypt a message body and confirm that it came from the right sender and was not altered in transit.: losing the private key means permanent loss of access to all encrypted email.

What can it be used for?

Web PKI and HTTPS

The largest and most visible use case. Every HTTPS connection relies on PKI: the server presents a certificate, the browser verifies the chain of trust and only then establishes a secure connection. PKI eliminates man-in-the-middle attacks — an impersonating server without a valid certificate will be rejected.

Beyond the browser

• S/MIME (email) — encrypts message content and signs it digitally. The recipient has proof the email came from the right sender and was not altered.
• Code signing — confirms software comes from its declared publisher and has not been modified. Used by Windows, macOS and mobile app stores.
• Internet of Things (IoT) — billions of devices authenticate via certificates in enterprise CAs, replacing weak static passwords.
• Electronic document signatures — qualified certificates give documents legal force.
• VPN and remote access — client certificates instead of passwords for employee authentication.

mTLS^?TLS (Transport Layer Security): The protocol that encrypts the connection between a client and a server. In classic TLS, only the server proves its identity with a certificate., SPIFFE^?SPIFFE: Secure Production Identity Framework for Everyone — an open standard for giving identities to services (microservices) in distributed systems. It defines how a service proves "who it is" without static passwords. and zero-trust architectures

In classic TLS, only the server presents a certificate.

• mTLS (Mutual TLS^?Mutual TLS (mTLS): A variant of TLS in which BOTH sides authenticate with a certificate — not just the server, but the client too. Each side of the connection can be sure who it is talking to.) — both parties authenticate with a certificate. Foundation of zero-trust architecture: no connection is trusted without verification.
• SPIFFE + SPIRE — standard and implementation automating the issuance of short-lived identity certificates for microservices. Tools such as Istio^?Istio: A popular service mesh — a layer that manages communication between microservices. It automatically encrypts traffic (mTLS) and gives services an identity using the SPIFFE standard. and Linkerd^?Linkerd: A lightweight service mesh for Kubernetes — like Istio, it automates mutual authentication (mTLS) and service identity management within a cluster. use SPIFFE as the identity layer.

eIDAS and qualified signatures

In the European Union, the legal framework for electronic signatures is set by the eIDAS regulation. It defines three levels:

• Simple signature — any electronic expression of intent.
• Advanced signature — linked to the signatory, detects modifications.
• Qualified signature — legally equivalent to a handwritten signature across the EU. Qualified certificates are X.509 certificates issued by accredited trust service providers listed on national Trusted Lists.

How does it differ from other approaches?

Classic X.509-based PKI is hierarchical and centralised — trust flows from the top, from certification authorities. There are alternatives that build trust differently.

The Web of Trust, familiar from PGP^?PGP (Pretty Good Privacy): A program and standard for encrypting and signing data and email. Instead of a hierarchy of certification authorities, it relies on a "web of trust" — users sign each other’s keys. and GnuPG^?GnuPG (GPG): A free, open-source implementation of the OpenPGP standard. The most popular tool for encrypting files and email in the web-of-trust model., works horizontally. Users sign each other's keys, vouching for their authenticity. This eliminates the risk of a single compromised authority, but it is hard for the average user to operate and is practically unusable for web traffic, where parties do not know each other before connecting.

DANE uses the DNSSEC^?DNSSEC: An extension of the DNS system that adds cryptographic signatures to name-server responses. It guarantees that DNS data (e.g. a domain’s address) comes from an authentic source and was not tampered with in transit.-secured DNS — a domain owner publishes the fingerprint of their certificate directly in the DNS zone, reducing reliance on hundreds of external CAs. Decentralised PKI built on blockchain shifts trust to the consensus of a distributed ledger, removing the single central point of control. None of these has displaced Web PKI, though — mainly because of the scalability and maturity of the hierarchical ecosystem.

Certificate versus token (API key, JWT, OAuth)

If I have an API key or a token, why do I need certificates? These are two different trust models. A token is a short-lived secret issued by an application’s authorisation server — it says "I hold a valid permission". A PKI certificate proves something else: identity — "I am who I claim to be", attested by a trusted authority.

They are not competitors — they often work together. In advanced architectures, mTLS authenticates the machine itself with a certificate, while a token carried inside that encrypted channel says on whose behalf and with what permissions it acts. PKI answers "who", the token answers "what it is allowed to do".

What attacks is PKI vulnerable to?

PKI effectively blocks man-in-the-middle attacks — but that does not make it immune to everything. The key observation: PKI rarely fails because of the mathematics. The algorithms are solid. What fails are people, processes and trust. Here are the main attack vectors.

Certification authority compromise

The most dangerous scenario. If an attacker takes over a CA, they can issue a valid certificate for any domain — including your bank. The browser will trust it, because that authority is in its trust store. This is exactly what the DigiNotar disaster looked like (covered in detail in the next chapter).

Certificate mis-issuance

You do not even need a break-in. A flaw in the domain validation process is enough for a CA to issue a certificate to an unauthorised party. Human error, misconfigured automation, weak validation — any of these can produce a certificate that should never have existed.

Domain validation hijacking (BGP / DNS)

To get a DV certificate, you must prove control over a domain. If an attacker hijacks the victim’s network traffic during that validation (an attack on the BGP^?BGP (Border Gateway Protocol): The protocol that controls how traffic is routed between networks on the internet. A BGP attack (BGP hijacking) involves announcing false routes to seize someone else’s traffic — e.g. during a CA’s domain validation. protocol) or their DNS, they can fool the CA and obtain a genuine, trusted certificate for someone else’s domain. This is one of the harder attacks to detect, because the certificate is technically valid.

Private key theft

A certificate is only as secure as the server’s private key. If the key leaks — through a server breach, a misconfiguration or a vulnerability like Heartbleed^?Heartbleed: A high-profile 2014 vulnerability in the OpenSSL library that allowed sensitive data — including certificate private keys — to be read from server memory. A classic case of key leakage through a code bug, not broken cryptography. — the attacker can impersonate the site until the certificate is revoked. And revocation, as we will see, can be unreliable.

Planting a rogue Root CA

If malware or an administrator adds an extra, attacker-controlled, Root CA to the trust store, the system will start trusting any certificate it signs. This is how high-profile traffic-interception cases worked, such as Superfish^?Superfish: Adware pre-installed on Lenovo laptops (2014-2015) that installed its own Root CA on the system to eavesdrop on encrypted HTTPS traffic. An example of planting a rogue trust anchor. (pre-installed on Lenovo laptops) and corporate or government TLS inspection systems.

Weak or obsolete algorithms

When a hash function^?Hash function: A function that turns arbitrary data into a short, unique "fingerprint". In certificates it is used for the signature. If two different documents can be found with the same hash (a collision), a signature can be forged. is broken, a certificate signature can be forged. This is how the Flame^?Flame: Sophisticated spyware discovered in 2012. It exploited an MD5 collision to generate a fraudulent certificate that looked as if signed by Microsoft — and impersonate Windows updates. malware (2012) exploited an MD5 collision to forge a certificate that looked as if signed by Microsoft. That is why MD5^?MD5: An old hash function, now considered broken — collisions can be generated in practice. This was used to forge a certificate (the Flame malware). Retired from use in certificates. and SHA-1^?SHA-1: A hash function, successor to MD5, also deemed unsafe after a practical collision was demonstrated (the SHAttered attack, 2017). Retired from certificates in favour of SHA-256. were retired — and today an analogous threat looms from quantum computers.

SSL stripping (downgrade)

Here the attacker does not break the certificate at all — they simply force an HTTP connection instead of HTTPS before the certificate ever comes into play. The user thinks they are on a normal site, while all traffic flows unencrypted. The HSTS^?HSTS (HTTP Strict Transport Security): A mechanism that tells the browser to connect to a given domain only over HTTPS — even if the user types an http address. It prevents SSL stripping attacks (forcing an unencrypted connection). (HTTP Strict Transport Security) mechanism forces the browser to always use HTTPS for a given domain — and prevents this.

These attacks share one thing: the weakest link in PKI is not the cryptography, but trust, processes and configuration. That is precisely why the industry built the defensive mechanisms we discuss in the next chapter.

Key limitations and challenges

The trust problem — one weak link breaks everything

If an operating system has a hundred trusted Root CAs in its trust store, the compromise of any one of them undermines the security of the entire ecosystem. Any such authority can issue a certificate for any domain — including your bank.

Case study: DigiNotar (2011)

The loudest disaster in Web PKI history. Dutch certification authority DigiNotar was breached, with global consequences:

1. The attacker exploited unpatched systems and seized the CA's infrastructure.
2. A fraudulent wildcard certificate for *.google.com and ~530 other domains was generated.
3. The certificates were used to wiretap over 300,000 Gmail users in Iran.
4. DigiNotar concealed the breach — CRLs were not updated, fraudulent certificates operated for weeks.
5. The case surfaced when the certificate pinning mechanism in Chrome detected the fraudulent certificate — an Iranian Gmail user reported the warning on Google’s support forum. Global revocation of DigiNotar’s Root CA → bankruptcy.

Certificate Transparency — a public certificate log

The industry's answer to DigiNotar is Certificate Transparency (CT) — public, immutable logs to which every issued TLS certificate must be submitted. Anyone can monitor whether an unauthorised certificate has appeared for their domain. Chrome has required CT since 2018.

Certificate lifecycle management

In large organisations, tens of thousands of certificates cover servers, microservices and devices.

• Expiry without renewal is one of the most common causes of production outages — experienced by banks, telecoms and cloud services alike.
• CLM (Certificate Lifecycle Management^?Certificate Lifecycle Management (CLM): Tooling and processes for tracking, issuing, renewing and revoking certificates at scale (from dozens to thousands). It prevents outages caused by an overlooked certificate expiry.) — dedicated tooling for tracking and rotating certificates at scale.
• Shortening lifetimes to 90 days and below forces automation (ACME) — manual management becomes impossible.

Revocation — CRL, OCSP and OCSP Stapling

When a private key leaks, the certificate must be revoked before it naturally expires. Three mechanisms:

• CRL (Certificate Revocation List^?Certificate Revocation List (CRL): A CA-signed list of certificates revoked before their expiry date (e.g. after a key leak), defined in RFC 5280. The client downloads the whole list and checks whether a given certificate is on it.) — a list of revoked certificates published by the CA. Simple, offline. Drawback: with thousands of revocations the list grows large and is fetched infrequently.
• OCSP (Online Certificate Status Protocol^?Online Certificate Status Protocol (OCSP): A protocol for checking certificate status in real time, defined in RFC 6960. Instead of downloading the whole CRL, the client asks the CA server about one specific certificate and gets a response: valid or revoked.) — the client queries the CA for the status of a specific certificate in real time. Faster, but the CA learns who visits which domain and when (privacy concern).
• OCSP Stapling — the server fetches a signed proof of its certificate's validity from the CA and attaches it to every TLS handshake. The client gets the response without contacting the CA — eliminating both latency and the privacy concern. Recommended practice.

PKI and artificial intelligence

Does PKI matter in the world of AI? Increasingly — but its role is shifting. Until now PKI authenticated mainly servers and people. AI adds a new, rapidly growing category: machines, models and autonomous agents that must prove their identity and authenticity. In some uses PKI works superbly, in others it starts to crack.

Identity of machines and AI agents

When an AI agent calls an API, connects to a database or talks to another agent, a question arises: who exactly is it, and is it allowed to? In cloud architectures, PKI answers this — through identity certificates and mTLS. Non-human identities (services, containers, agents) already outnumber human accounts in many environments, and agentic AI widens that gap further. The catch: classic PKI was designed for certificates valid for years, while agents appear and vanish in seconds. Hence standards like SPIFFE^?SPIFFE: Secure Production Identity Framework for Everyone — an open standard for giving identities to services and agents in distributed systems. It defines how software proves "who it is" without static passwords./SPIRE^?SPIRE: The reference implementation of the SPIFFE standard. A working tool that automatically issues and rotates short-lived identity certificates for every service or agent in a cluster., issuing short-lived identity certificates automatically — an area where PKI genuinely works, provided it is properly automated.

Content provenance — fighting deepfakes

This may be the most important new use of PKI in the AI era. The C2PA standard (Content Credentials^?Content Credentials: A user-facing "provenance label" for content — an implementation of the C2PA standard. It shows what generated or edited a file and when. It is the recognisable brand (the "CR" icon) backed technically by C2PA signatures.), backed by Adobe, Microsoft, Google and OpenAI among others, digitally signs images, video and audio, attaching a verifiable record of provenance: what generated the content, when, and whether it was edited. Underneath it is ordinary PKI — C2PA manifests are signed with X.509 certificates. OpenAI adds such credentials to DALL·E images and Sora material. This is PKI applied directly to the biggest trust problem generative AI created: telling real content from synthetic. One caveat, though — metadata can be stripped, so the absence of a signature proves nothing. C2PA confirms provenance, it does not detect fakes.

Model signing and the ML supply chain

An AI model is a weights file you download from somewhere — usually an open repository. How do you know nobody swapped or "poisoned" it? This is where artifact signing comes in: tools like Sigstore let you cryptographically sign a model and verify its integrity and origin, much like code signing. This use is still at an early stage — the industry is only now building ML supply-chain security practices — but the direction is clear, because poisoned-model and poisoned-dataset attacks are real.

Robotics and autonomous vehicles

This is an area where PKI is mature and critical. Vehicle-to-vehicle and vehicle-to-infrastructure communication (V2X^?V2X (Vehicle-to-Everything): Communication between a vehicle and its surroundings: other vehicles (V2V), road infrastructure (V2I) and pedestrians. It lets cars "see" around corners and warn of hazards — so every message must be signed to prevent false data from being injected.) relies on an extensive PKI described in the IEEE 1609.2 standards and SCMS^?SCMS (Security Credential Management System): A dedicated PKI infrastructure designed for vehicles. It issues and manages certificates for millions of cars, with a focus on privacy — a vehicle uses rotating, pseudonymous certificates so it cannot be tracked, while still being able to authenticate. systems — every message from a car is signed so that false data cannot be injected (e.g. "road clear" when it is not). Robot fleets, drones and IoT devices use certificates to authenticate to one another instead of weak static passwords. For embodied AI — physical machines acting in the world — PKI is the foundation of operational security.

Where PKI falls short in the AI world

PKI answers "who are you?", but not "what are you allowed to do?". When an AI agent acts on behalf of a user, proving identity is not enough — you need an authorisation and delegation layer that PKI does not provide. In practice, most language-model APIs still authenticate with simple API keys (tokens) rather than certificates — because they are more convenient, if weaker. Then there is scale and accountability: when an autonomous agent takes a harmful action with a valid certificate, who is responsible? PKI alone does not answer these — they require new layers designed specifically for AI.

The verdict: in the world of AI, PKI is not disappearing — on the contrary, it is becoming more important, but as a foundational layer rather than the whole solution. Where it is about machine identity, content provenance and robot security, it works superbly. Where it is about the permissions, intentions and accountability of autonomous agents — it is only the starting point, and one the industry is still working on.

Why does it matter?

PKI as critical infrastructure

PKI is one of those technologies we notice only when they fail. Every bank login, every card payment and every software update rests on the silent assumption that the chain of trust will hold. When that chain breaks — as DigiNotar showed — millions of users are immediately affected. This makes PKI critical infrastructure, comparable to the power grid of the digital economy.

The quantum threat and the PQC migration

A sufficiently mature quantum computer, using Shor's algorithm^?Shor's algorithm: A quantum algorithm devised by Peter Shor (1994) that, on a large enough quantum computer, can quickly factor large numbers and solve the discrete logarithm problem. This is what threatens RSA and ECDSA — the foundations of today's certificates., would break RSA and ECDSA — the mathematical foundations of today's certificates. The threat is already present: the "harvest now, decrypt later" strategy involves collecting encrypted communications today to decrypt them once quantum machines mature.

In August 2024 NIST published its first finalised post-quantum standards: ML-KEM^?ML-KEM (FIPS 203): A post-quantum key encapsulation mechanism based on lattices, formerly known as CRYSTALS-Kyber. A 2024 NIST standard — the quantum-resistant successor to classical key exchange such as ECDH., ML-DSA^?ML-DSA (FIPS 204): A post-quantum digital signature algorithm based on lattices, formerly CRYSTALS-Dilithium. A 2024 NIST standard — the successor to RSA and ECDSA for signing certificates, resistant to Shor’s algorithm. and SLH-DSA^?SLH-DSA (FIPS 205): A post-quantum digital signature algorithm based on hash functions, formerly SPHINCS+. A 2024 NIST standard — an alternative to ML-DSA, chosen when especially high assurance is needed.. The migration is already under way:

• Chrome (since 2024) and Cloudflare have deployed X25519+ML-KEM^?X25519+ML-KEM: A hybrid key-exchange mode in TLS combining the classical X25519 (ECDH) algorithm with post-quantum ML-KEM. To break it, an attacker would have to defeat BOTH mechanisms at once — so it stays secure even if one of them fails. hybrid mode in TLS — classical ECDH^?ECDH (Elliptic Curve Diffie-Hellman): A classical algorithm for agreeing on a shared session key over elliptic curves. Widely used in TLS today — but breakable by a quantum computer (Shor’s algorithm), hence the migration to hybrids with ML-KEM. and post-quantum ML-KEM running in parallel. Breaking it requires defeating both algorithms simultaneously.
• PQC certificates (ML-DSA in place of RSA/ECDSA) are the next step — requiring a rebuild of CA chains and updates across the entire software stack. Estimated time: a decade.

Understanding PKI today is the starting point for anyone who will participate in this transformation — and a prerequisite for navigating the digital world as it undergoes its deepest cryptographic shift in half a century.

Sources

• Wikipedia — Public key infrastructure — link
• Wikipedia — X.509 — link
• IETF — RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile — link
• Wikipedia — DigiNotar — link
• NIST — NIST Releases First 3 Finalized Post-Quantum Encryption Standards — link
• Cloudflare — The state of the post-quantum Internet — link