“Post-quantum cryptography is really just an overhaul. We are rolling out a new key exchange.” – Jan Schaumann
The conversation around post-quantum cryptography (PQC) often arrives wrapped in urgency and speculation. Headlines focus on future quantum machines, looming deadlines, and theoretical breakthroughs. Inside real organizations, however, the work looks very different. It surfaces through protocol upgrades, legacy systems, customer readiness, and decisions about how to change safely without disrupting critical infrastructure.
In this episode of Shielded: The Last Line of Cyber Defense, Jan Schaumann, Chief Information Security Architect at Akamai Technologies and longtime systems educator, joins host Jo Lintzen to unpack how post-quantum migration actually unfolds at internet scale. Drawing from hands-on experience running large platforms, Jan offers a grounded view of where progress happens, where it slows, and what security leaders should prioritize right now.
Jan brings a rare combination of operational depth, architectural responsibility, and teaching discipline. His perspective reframes PQC away from theory and toward execution, sequencing, and long-term crypto agility.
Post-Quantum Cryptography as Structured Upgrade Work
One of Jan’s core messages centers on reframing. Post-quantum cryptography often sounds exotic because of the word “quantum,” yet the changes introduced by PQC resemble many cryptographic transitions organizations have already lived through.
At its core, PQC introduces new key exchange mechanisms and ciphers. Jan points out that previous transitions, such as moving from TLS 1.2 to TLS 1.3, carried far more operational impact than enabling post-quantum key exchange inside TLS 1.3. The math may be new, but the deployment patterns are familiar.
This distinction matters. When teams treat PQC as a specialized or academic problem, execution slows down. But when teams treat it as disciplined crypto upgrade work, progress becomes measurable and manageable.
TLS 1.3 as the Real Foundation for PQC
Throughout the conversation, Jan returns to a foundational prerequisite that continues to shape every PQC discussion: TLS 1.3 adoption.
PQC handshakes in TLS depend on TLS 1.3. While many edge environments upgraded years ago, origin systems often lag behind. Jan describes how customer infrastructure frequently relies on legacy software, external vendors, embedded clients, and long-lived IoT devices. These systems move slowly, especially in regulated industries such as finance, healthcare, and government.
As a result, many organizations believe PQC adoption sits just one configuration away. In reality, significant portions of their environment still require protocol modernization before PQC even enters the picture.
For many teams, the largest blocker to PQC readiness remains unfinished TLS 1.3 migration.
Breaking PQC Into Traffic Paths
Rather than approaching PQC as a single migration, Jan explains how Akamai divided the work into three distinct traffic paths:
- client to edge
- edge to origin
- internal infrastructure
Each path carries a different threat model, operational cost, and upgrade timeline. Client-to-edge traffic represents the largest volume and directly addresses harvest-now-decrypt-later risk. Edge-to-origin traffic depends heavily on customer readiness and legacy constraints. Internal traffic carries a different attacker profile altogether.
This separation allowed Akamai to prioritize where PQC delivered immediate value while maintaining clarity around longer-term work. It also enabled customers to understand how PQC applied to their environment without forcing a single timeline across very different systems.
Phased Rollout and Safe Change
Jan spends significant time explaining why Akamai chose phased, opt-in rollout rather than enabling PQC everywhere at once.
Many Akamai customers operate critical infrastructure under strict regulatory oversight. For these organizations, stability carries the same weight as security. Akamai’s deployment model relied on canary networks, staged percentages, and gradual expansion to validate behavior before broad exposure.
This approach aligned with customer expectations and reduced the risk of large-scale outages. It also provided flexibility as standards evolved, allowing Akamai to adapt without locking customers into early assumptions.
For Jan, resilience and safe change form a core part of security architecture at scale.
Standards Timing and Avoiding Rework
A quieter but important theme in the episode involves standards maturity. Jan describes how Akamai tracked activity across standards bodies and browser ecosystems while preparing for PQC. This awareness shaped timing decisions around Kyber and the eventual transition to standardized ML-KEM.
Because rollout progressed in stages, Akamai avoided shipping implementations that required rapid replacement weeks later. Jan also discusses early uncertainty around FIPS compliance and how later clarification simplified key exchange support.
Careful attention to standards movement reduced complexity and saved real engineering effort.
Crypto Agility as the Outcome of Real Migration Work
As the conversation moves toward the later stages of PQC adoption, Jan returns to a pattern he sees repeatedly across large systems. Cryptographic transitions never arrive as one-time events. Each one exposes how well an organization understands where cryptography lives, how it gets negotiated, and how upgrades actually move through production environments.
In Jan’s experience, PQC work forces teams to inventory protocols, identify long-lived dependencies, and confront assumptions about how easily systems change. That work matters beyond post-quantum timelines. The same processes will be required again for certificate transitions, DNSSEC signatures, protocol deprecations, and future cryptographic shifts that have yet to surface.
Jan describes PQC less as an endpoint and more as a moment of alignment. Teams that build visibility, tooling, and repeatable upgrade paths during this transition reduce the operational burden of every cryptographic change that follows. The value compounds through preparedness rather than speed.
Where Security Leaders Can Act With Confidence
Jan’s guidance focuses on actions teams already control and can sequence safely.
Practical steps that move PQC forward:
- Complete TLS 1.3 adoption across edge, origin, and internal systems. Post-quantum key exchange depends on this foundation, and lingering TLS 1.2 dependencies slow progress long before algorithm choices matter.
- Enable post-quantum key exchange through service providers that already support it. This step reduces long-term exposure for large volumes of traffic without forcing immediate changes to certificates or PKI.
- Map cryptographic dependencies across environments to identify legacy clients and long-lived systems that shape realistic timelines.
Jan emphasizes that PQC unfolds in stages. Confidentiality upgrades come first. Certificates, signatures, PKI, and DNSSEC follow as standards and implementation guidance mature. Each phase benefits from the same operational discipline established early.
The Takeaway
Jan Schaumann brings an operator’s perspective to post-quantum migration, shaped by years of running internet-scale infrastructure. PQC appears as a sequence of manageable upgrades guided by protocol readiness, customer constraints, and safe-change practices.
Key points to carry forward:
- Post-quantum cryptography progresses through staged upgrades rather than a single migration.
- TLS 1.3 adoption sets the foundation for any meaningful PQC work.
- Customer readiness and legacy systems define realistic timelines, especially at the origin layer.
- Phased rollout and validation protect stability across regulated and high-risk environments.
- Crypto agility emerges as the durable outcome, preparing teams for future transitions beyond PQC.
You can hear the full conversation with Jan Schaumann is available on Shielded: The Last Line of Cyber Defense on Apple Podcasts, Spotify, and YouTube Podcasts.
About Jan Schaumann
Jan Schaumann is Chief Information Security Architect at Akamai Technologies, where he guides cryptographic strategy, infrastructure security, and safe-change practices across one of the internet’s most critical platforms. He previously served as Principal Architect at Akamai and has held senior security roles at companies including Yahoo, Twitter, and Etsy. Jan is also an Adjunct Professor of Computer Science at Stevens Institute of Technology, where he has taught graduate-level systems and Unix programming since 2001. He is a long-time developer with the NetBSD Foundation and describes himself, accurately, as an actual human on the internet who refuses to grow up.