Lessons 1.1 through 1.4 covered the solutions. This lesson covers what needs to be replaced. If you have security or networking foundations (Security+, SSCP, equivalent experience, or adjacent IT work), you already know most of the infrastructure on the migration checklist, you just haven't seen it through a migration lens yet. That is what this lesson provides.
Unit 1 progress
By the end of this lesson you will be able to
Explain what PKI is and identify its core components
Map each PKI component to its migration urgency and the specific PQC standard that addresses it
Describe what a Certificate Authority is and why CA hierarchy migration must proceed root-first
Explain what TLS does and why it is the first migration target in most environments
Explain what a hybrid certificate is and why it exists during the migration transition
Identify your three most relevant PKI migration priorities using the persona-specific framing
Part 1 — Three buckets: translating what you already know
If you already know TLS, certificates, and related infrastructure from a first security or networking baseline (Security+ is one example), you already know the systems on the migration checklist. The problem is that those courses teach the systems as they exist today, using RSA and ECC, not as they need to look in five years. This lesson provides the translation layer.
The terms from that baseline fall into three buckets when viewed through a migration lens. Use the explorer below to understand what each bucket means and which terms belong where.
Part 2 — The PKI architecture and what each layer needs
PKI, Public Key Infrastructure, is the system of digital certificates, certificate authorities, and trust relationships that underlies almost all secure digital communication. Every HTTPS connection, every digitally signed document, every code-signed application, every VPN session depends on PKI. Understanding its architecture is essential for understanding what migration requires.
Trust root
Root Certificate Authority (Root CA)
The self-signed trust anchor. Its public key is embedded in operating systems, browsers, and devices worldwide. Signs intermediate CA certificates. Root CA private keys use RSA or ECDSA today, both must migrate to ML-DSA or SLH-DSA.
Migrate first — highest value key
↓ signs ↓
Issuance
Intermediate Certificate Authority (Issuing CA)
Signs end-entity certificates on behalf of the root CA. Kept online, while root CAs are typically offline. Must be re-signed by the already-migrated root CA using ML-DSA. Generates a new ML-DSA key pair as part of migration.
The certificates your servers, applications, and users present during authentication. These expire on short lifecycles (90 days for TLS). Once the CA hierarchy above them has migrated, new certificates will automatically use ML-DSA. Existing certs expire and are replaced normally.
Migrate last — lifecycle handles it
↓ protects ↓
Protocols
Protocols using PKI: TLS, HTTPS, VPN, SSH, S/MIME, code signing
Every protocol that uses certificates for authentication or key exchange depends on this hierarchy. TLS key exchange (ML-KEM) and certificate signatures (ML-DSA) are separate migration tracks. Key exchange migration can happen independently of certificate migration.
Two parallel tracks: key exchange and signatures
Glossary terms #11 and #12
Certificate Authority (CA) & Hybrid Certificate
Certificate Authority (CA): An organization that issues digital certificates. The CA hierarchy, root, intermediate, and issuing CAs, is the trust foundation of traditional PKI. Root CAs and intermediate CAs must migrate to ML-DSA or SLH-DSA. The migration must proceed root-first.
Hybrid Certificate: A certificate that contains both a classical key (RSA or ECC) and a post-quantum key (ML-DSA), along with signatures from both algorithms. Used during the migration transition window to maintain backward compatibility while adding quantum resistance.
Part 3 — TLS: the first migration target in most environments
TLS, Transport Layer Security, is the protocol that encrypts almost all internet traffic. Every HTTPS connection, every VPN tunnel, every API call uses TLS. It is the largest surface area for PQC migration and the one where quantum-safe algorithms are already being deployed.
Glossary term #13
TLS (Transport Layer Security)
The protocol that encrypts web traffic (HTTPS), VPN connections, API calls, and most other internet communications. TLS uses two cryptographic operations that both need migration: key exchange (currently RSA or ECDH → must move to ML-KEM) and certificate authentication (currently RSA or ECDSA → must move to ML-DSA). These are separate migration tracks.
TLS migration has two independent tracks that can proceed at different speeds. Understanding this separation is one of the most practically useful insights in Unit 1.
Track 1 — Key exchange
RSA/ECDH → ML-KEM
Happens at the TLS library level. Requires updating your TLS stack (OpenSSL 3.2+, BoringSSL, etc.) and enabling hybrid key exchange. Does not require new certificates. Can be done now.
Deployable today — no CA needed
Track 2 — Certificate signatures
RSA/ECDSA certs → ML-DSA certs
Requires the full CA hierarchy to migrate first. Root CA → intermediate CA → end-entity certificates. Public CAs (DigiCert, Let's Encrypt, etc.) must update their infrastructure. Timeline: 2025–2028 for major CAs.
Requires CA migration — plan now, deploy as CAs ready
The practical implication: you can make meaningful PQC progress on your TLS infrastructure today by enabling hybrid ML-KEM key exchange, even before any CA has migrated. The session traffic is then protected against Harvest Now Decrypt Later attacks. Certificate migration follows on a separate timeline as the CA ecosystem catches up.
Part 4 — What the migration checklist actually contains
The migration checklist is not abstract. It maps to specific systems, specific priorities, and specific standards. This table gives you the full picture at Unit 1 resolution: Units 3 and 4 drill into each row.
ML-KEM + ML-DSA — constrained by firmware update capability
TLS end-entity certs
RSA-2048 or ECDSA P-256
Medium
ML-DSA — handled by CA lifecycle once CAs migrate
Part 5 — What this means for you
This is where the three personas diverge most sharply. The migration checklist above is the same for everyone, but what it means, which rows matter most, what the first action is, and what success looks like, is different depending on your context.
Part 6 — Certificate Lifecycle Management and why automation matters
PQC migration at scale requires automated certificate lifecycle management. The reason is straightforward: most large organizations have tens of thousands of certificates. Manually tracking, renewing, and replacing them during a migration is not operationally feasible. The organizations that will migrate successfully are the ones that have already automated their certificate lifecycle.
Glossary term #19
Certificate Lifecycle Management (CLM)
The automated process of issuing, renewing, revoking, and replacing digital certificates across an organization's infrastructure. CLM tools (Venafi, AppViewX, Keyfactor, EJBCA, etc.) provide visibility into the full certificate inventory and automate renewal before expiry. CLM automation is a prerequisite for PQC migration at scale, you cannot replace what you cannot see and track.
The relationship between CLM and PQC migration is direct: a CBOM (Unit 3) tells you what cryptographic assets you have; a CLM tool gives you the operational capability to replace them systematically. Organizations without CLM automation will face the migration as a manual audit-and-replace project. Organizations with CLM automation will execute it as a policy change and a workflow.
Comprehension check
Question 1 of 3
Why must CA hierarchy migration proceed from root CA to leaf certificates, rather than the other way around?
Question 2 of 3
TLS migration has two independent tracks. What is the key practical implication of their independence?
Question 3 of 3
What is a hybrid certificate and why does it exist during the PQC transition period?