June 12, 2026

Cryptographic Agility: The Only Defense Against Quantum

As quantum computing moves from theory toward reality, many organizations are focusing on replacing RSA and ECC with post-quantum cryptography. But in this episode of M365.fm, Mirko Peters argues that simply choosing a new algorithm is not enough. The real challenge is cryptographic agility: the ability to rapidly adapt, replace, and evolve cryptographic systems as threats, standards, and technologies change.

The discussion explores why most enterprise environments are deeply dependent on cryptography in ways many organizations don't fully understand. Certificates, identity systems, VPNs, TLS connections, APIs, cloud workloads, IoT devices, and long-lived data all rely on cryptographic foundations that may become vulnerable in a post-quantum world. The biggest risk is not that quantum computers arrive tomorrow—it is that organizations cannot adapt quickly when change becomes necessary.

The episode examines how crypto-agility shifts the conversation from algorithm selection to architectural design. Instead of hard-coding security assumptions into applications and infrastructure, organizations must build systems capable of supporting multiple cryptographic standards, automated certificate rotation, key lifecycle management, and future migrations with minimal disruption.

Mirko also explores the practical implications for Microsoft 365, Azure, enterprise identity, cloud security, and long-term data protection. The conversation highlights why organizations should begin inventorying cryptographic dependencies today, identifying vulnerable systems, and preparing migration strategies before regulatory requirements or technological breakthroughs force emergency changes.

You face a real challenge as quantum computing advances. Most current encryption methods rely on assumptions that no longer hold true. In fact, 63% of organizations believe these methods are vulnerable to quantum attacks.

Percentage	Description
63%	Organizations that believe quantum advancements could break current encryption methods.

Experts predict cryptographically relevant quantum computers may emerge within 5-15 years.

The 'Harvest Now, Decrypt Later' tactic is becoming more common.
You need cryptographic agility to switch algorithms quickly and stay secure.
Microsoft 365 helps you adapt and protect your data as threats evolve.

Key Takeaways

Quantum computing poses a serious threat to current encryption methods. Prepare now to protect your data.
Cryptographic agility allows you to switch encryption algorithms quickly, keeping your systems secure against evolving threats.
Regular upgrades are not enough. Quantum risks require a proactive approach to cryptography.
Build a complete inventory of your cryptographic assets. Knowing what you have is the first step to managing risk.
Assess your risks regularly. Identify which data needs to stay secure for the long term.
Use automation tools to streamline cryptographic updates. This reduces errors and speeds up your response to threats.
Create clear policies and governance for managing cryptography. Strong governance helps your organization adapt quickly.
Collaborate across departments and with external organizations. Sharing knowledge enhances your readiness for quantum threats.

Why Cryptographic Agility Matters

Quantum Threats to Encryption

You face a new era of risk as quantum computing grows stronger. Many encryption methods that protect your data today will not stand up to quantum attacks. Quantum computers use special algorithms that can break these protections much faster than any traditional computer. For example, Shor’s algorithm can easily factor large numbers, which makes RSA and ECC encryption weak. Grover’s algorithm can speed up brute-force attacks, making even strong symmetric encryption less secure.

Here is a table that shows how quantum advancements threaten common encryption methods:

Encryption Method	Vulnerability	Quantum Threat
RSA	Factoring large integers	Shor's algorithm makes it trivial
ECC	Discrete logarithms	Shor's algorithm makes it trivial
AES-128	Reduced to 64-bit security	Grover's algorithm speeds up brute-force
AES-256	Reduced to 128-bit security	Grover's algorithm speeds up brute-force

Almost all security experts now see quantum as a very high risk to current cryptography. You cannot ignore this threat. Even if you use AES-256, you should know that its strength may not last as quantum technology advances. Experts once thought you had more time, but recent progress in quantum computing has made the need for new cryptographic standards urgent.

Limits of Traditional Upgrades

You might think that regular upgrades can keep your systems safe. In the past, you could update your cryptographic protocols every few years and stay ahead of most threats. This approach does not work against quantum risks. Many organizations struggle to update their systems quickly enough. Legacy systems, limited processing power, and the need for larger keys make upgrades slow and complex.

Some post-quantum algorithms need more computing power and bigger keys, which can slow down devices.
Older systems often cannot support new cryptographic methods without major changes.
Upgrading every system at once is hard, especially when you have to keep everything running smoothly.

You also face operational complexity. New algorithms can affect performance and may not work well with all your devices. Pilot programs and testing take time. This delay gives attackers a window to exploit weaknesses. Regular updates alone cannot keep up with the speed of quantum threats.

Crypto-Agility as a Solution

Crypto-agility gives you the power to adapt quickly. Instead of waiting for the next big upgrade, you can switch to stronger algorithms as soon as you need them. Crypto-agility means you can phase out weak encryption and bring in new protections with minimal changes to your systems. This approach keeps your data safe, even as threats change.

Crypto-agility is not just a technical feature. It is a strategy that involves your whole organization. You need developers, IT staff, and leaders to work together. You also need clear policies and regular reviews. Many leading organizations, like Bank of America, have started crypto-agility programs. They update cryptographic libraries, train staff, and plan for quick transitions.

Governments now require crypto-agility. The US Department of Homeland Security and the UK National Cyber Security Centre both say you must prepare for quantum threats by building crypto-agility into your systems. Cloudflare, a major internet company, showed how this works by testing post-quantum cipher suites. They could switch back to older methods if needed, proving that crypto-agility lets you respond fast without risking your operations.

Crypto-agility is your best defense. It lets you stay ahead of attackers and protect your data, no matter how fast quantum computing evolves.

What Is Crypto Agility

Core Principles of Crypto Agility

You need to understand the core principles that make cryptographic agility effective. These principles help you build systems that can adapt to new threats and standards. The table below shows the main ideas behind cryptographic agility:

Principle	Description
Operation Independence	The API defines cryptographic operations without tying them to specific algorithms.
Temporal Decoupling	You can make cryptographic decisions at different stages of your application’s lifecycle.
Intent-Based Specification	You set your security goals without locking into one algorithm, giving you more flexibility.

These principles let you change encryption methods without breaking your applications. You can update your security as new threats appear. This approach keeps your data safe and your systems running smoothly.

Agility vs. Static Cryptography

You face a choice between cryptographic agility and static cryptography. Static cryptography locks you into one algorithm or protocol. This makes it hard to respond when attackers find new weaknesses. Cryptographic agility gives you the power to switch algorithms and update protocols quickly.

Cryptographic agility lets you respond fast to new vulnerabilities and compliance needs.
Static cryptography creates rigid systems that resist change.
With cryptographic agility, you can switch to stronger protections without major disruptions.

Attackers move quickly. They can change their tools and methods almost instantly. You need cryptographic agility to keep up. Defenders often face delays because they must check compliance, test changes, and coordinate teams. Crypto agility helps you close this gap and protect your data.

Tip: Build cryptographic agility into your systems now. This will help you stay ahead of attackers and avoid costly downtime.

Future-Proofing Security

You want to protect your data not just today, but also in the future. Cryptographic agility helps you do this by making your security flexible and adaptable. You can prepare for quantum threats by keeping track of your cryptographic assets and planning for upgrades.

Crypto agility shifts your focus from one-time upgrades to ongoing adaptability. You can respond quickly to new threats and protect your critical data as technology changes. Most organizations do not have a solid plan for quantum computing. By using cryptographic agility, you can create a roadmap for post-quantum migration, prioritize risks, and keep your security strong.

Crypto agility gives you visibility and control over your encryption.
You can design systems with replaceable cryptography and monitor them for new threats.
Integrating cryptography into your incident response helps you recover faster from attacks.

You need cryptographic agility to stay ready for whatever comes next. This approach makes your organization stronger and more resilient in a changing world.

Quantum Risks and Urgency

How Quantum Breaks Encryption

Quantum computing changes how you need to think about security. You rely on encryption to keep your data safe. Today’s systems use math problems that are hard for regular computers to solve. Quantum computers can solve these problems much faster. This means your current protections could fail when quantum computers become powerful enough.

Shor’s Algorithm Impact

Shor’s algorithm is a tool that quantum computers use to break encryption. It can factor large numbers very quickly. RSA and ECC, two common encryption methods, depend on the fact that factoring is hard. Shor’s algorithm makes this easy for quantum computers. Here is how it works:

The quantum computer changes the factoring problem into a search for a repeating pattern.
It uses quantum states to test many possibilities at once.
The computer finds the right pattern and uses it to break the encryption.
This process takes minutes, not years.

You can see the risk in this table:

Encryption Type	Vulnerability	Impact
RSA	Breakable by Shor's algorithm	Can factor 2048-bit keys in minutes
ECC	Breakable by Shor's algorithm	Compromises secure communications

If you use cryptographic agility, you can switch to quantum-safe cryptography before attackers use Shor’s algorithm against you.

Grover’s Algorithm Impact

Grover’s algorithm is another quantum tool. It does not break encryption completely, but it makes brute-force attacks much faster. For example, AES-256 is strong today. Grover’s algorithm cuts its strength in half. This means a 256-bit key only gives you 128 bits of security against quantum attacks.

Grover’s algorithm reduces the time needed to guess keys.
Symmetric encryption becomes less secure.
You need cryptographic agility to upgrade your keys and algorithms quickly.

Encryption Type	Vulnerability	Impact
AES-256	Reduced strength by Grover's algorithm	Equivalent to 128-bit security against quantum attacks

Harvest-Now, Decrypt-Later Attacks

You face a new kind of threat called "harvest-now, decrypt-later." Attackers can steal your encrypted data today and wait until quantum computers arrive. When they do, they can use quantum tools to unlock your secrets. This risk is real, even if quantum computers are not ready yet. Many governments and companies have started to plan for this. The U.S. government has a roadmap for moving to post-quantum cryptography. Major tech companies now use hybrid systems to protect data during the post-quantum transition.

Note: You should not wait for quantum computers to become common. Start using cryptographic agility now to protect your data from future attacks.

Timeline for Action

You need to act soon. Experts say quantum computers that can break today’s encryption could appear in 10 to 20 years. Some believe this could happen as early as 2028. Studies show that you should not expect safety after the 2030s. You must start your post-quantum transition now. Cryptographic agility gives you the power to change your defenses as soon as new threats appear. By planning ahead, you make sure your data stays safe, even as technology changes.

Start your cryptographic agility journey today.
Track your assets and update your systems.
Move toward quantum-safe cryptography before it is too late.

Cryptographic agility is your best tool for staying ahead of quantum risks.

Achieving Cryptographic Agility

Asset Inventory and Visibility

You cannot achieve crypto-agility without knowing what you have. Start by building a complete inventory of your cryptographic assets. This step gives you the visibility you need to manage risk and plan upgrades. Follow these steps to create a strong foundation for cryptographic agility:

Define the scope and objectives for your inventory. Decide which systems, applications, and data you will include.
Discover all cryptographic assets. Look for certificates, keys, algorithms, and libraries across your environment.
Centralize and normalize your data. Use a single platform to collect and organize information about your cryptographic materials.
Classify assets and assess their risk. Identify which assets protect sensitive data or critical systems.
Integrate your inventory with existing processes and policies. Make sure your asset management supports your cryptographic governance.
Continuously monitor and update your inventory. Crypto-agility requires you to keep your records current as your environment changes.

Microsoft 365 and Azure Key Vault can help you centralize key management and gain visibility into your cryptographic landscape. These tools support your cryptographic agility initiatives by making it easier to track and manage assets.

Tip: A complete inventory is the first step in your cryptographic agility journey. You cannot protect what you cannot see.

Risk Assessment Steps

Once you have visibility, you need to assess your risks. Crypto-agility depends on understanding which assets face the greatest threats from quantum computing. Use these best practices to guide your risk assessment:

Identify sensitive data. Find out which data needs to stay confidential for 5, 10, or even 20 years.
Inventory your cryptography. List all algorithms, libraries, and key lengths in use.
Assess the quantum impact. Think about what would happen if a quantum attacker broke your encryption for each system and data category.
Estimate the threat timeline. Stay updated on quantum computing progress. Decide the "last safe year" for each algorithm.

This process helps you prioritize your crypto-agility efforts. For example, the financial services sector often holds data that must remain secure for decades. You need to focus on these high-risk areas first. Crypto-agility gives you the flexibility to respond as new threats appear.

Note: Risk assessment is not a one-time task. You must review and update your analysis as technology and threats evolve.

Upgrading and Automation

You need to upgrade your cryptographic systems to support crypto-agility. Manual updates are slow and error-prone. Automation makes the transition to crypto agility faster and more reliable. Many organizations use tools and platforms to streamline this process.

Tool/Platform	Functionality Description
HashiCorp Vault	Automated key management, including key generation, rotation, and revocation.
AWS Key Management Service (KMS)	Automated cryptographic key management, integrates with CI/CD pipelines for seamless updates.
Jenkins	CI/CD tool that automates deployment of updated cryptographic libraries or configurations.
GitLab CI	Automation in deployment, ensuring consistency across environments.
CircleCI	CI/CD tool supporting automated deployment of cryptographic updates.
Keyfactor	Comprehensive platform for managing cryptographic agility across enterprise infrastructure.

You should use automation tools to manage cryptographic resources. Integrate cryptographic management into your CI/CD pipelines. Implement version control for cryptographic configurations. These steps help you respond quickly to new threats and reduce the challenges of crypto agility.

Microsoft 365 and Azure Key Vault offer automation features that support your crypto-agility goals. They help you rotate keys, update algorithms, and enforce cryptographic governance across your organization. Keyfactor also provides a robust platform for managing your cryptographic agility journey, covering all essential steps from inventory to automation.

Crypto-agility is not just about technology. It is about building a framework for implementing crypto agility that includes people, processes, and tools. Automation helps you keep pace with the post-quantum transition and maintain strong cryptographic governance.

Policy and Governance

You need strong policies and governance to achieve true cryptographic agility. Good governance helps you control how your organization uses cryptography. It also ensures that you can adapt quickly when new threats appear.

You should start by creating clear policies for how your organization manages cryptographic systems. These policies set the rules for using, updating, and retiring encryption methods. They also define who is responsible for each part of your cryptographic environment. When you have clear roles, you avoid confusion and reduce mistakes.

A centralized approach works best for large organizations. You can set up a Cryptographic Center of Excellence (CCoE). This team brings together security leaders, IT staff, and business managers. The CCoE creates policies, shares best practices, and makes sure everyone follows the same rules. You get better results when all stakeholders work together.

You should include these key elements in your governance plan:

Regular training and certification for staff who manage cryptographic systems.
Audits to check if your teams follow cryptographic policies.
Standard operating procedures (SOPs) for using and updating cryptographic tools.
Automated tools for key management and compliance monitoring, such as Microsoft 365 and Azure Key Vault.
Real-time monitoring and feedback to improve your policies over time.

You must also understand how your organization uses cryptography. This means tracking all cryptographic assets and making sure you have visibility into every system. You should include third-party vendors and supply chain partners in your governance plan. This helps you spot risks that come from outside your organization.

You need to align your policies with industry standards and regulatory requirements. This keeps your organization compliant and ready for audits. You should review your policies often and update them as technology changes.

Tip: Strong governance is not just about rules. It is about building a culture of security and awareness. When everyone understands their role, your organization can respond faster to new threats.

By focusing on policy and governance, you create a foundation for cryptographic agility. You make it easier to switch algorithms, manage risks, and protect your data in a changing world.

Real-World Crypto-Agility

Industry Standards and Frameworks

You need to follow industry standards to build strong cryptographic agility. These frameworks help you stay compliant and ready for quantum threats. Many organizations use guidelines from trusted sources to guide their crypto-agility journey.

NIST guidelines
Cryptography Bill of Materials (CBOM)
ISO/IEC 27001/27002
NIST SP800
HIPAA
GDPR

These standards set clear rules for managing cryptography. You should work with CISOs, security architects, and developers to define and enforce your crypto-agility policies. This teamwork ensures you meet compliance requirements and protect your data.

Note: Crypto-agility is not just about technology. It is about people working together to keep your organization safe.

Microsoft 365 as a Case Study

Microsoft 365 shows how you can use cryptographic agility to defend against quantum risks. The platform uses a phased approach to upgrade its security. You can see how this works in the table below:

Phase	Description
1. Foundational security components	Integration of post-quantum cryptography (PQC) algorithms into foundational components like SymCrypt, ensuring consistent cryptographic security across platforms.
2. Core infrastructure services	Updating core services such as authentication and key management to provide quantum safety, prioritizing the most sensitive components.
3. All services and endpoints	Integrating PQC into all Microsoft services, including Windows, Azure, and Microsoft 365, to ensure comprehensive quantum protection across the ecosystem.

Microsoft 365 works with industry leaders to assess risks and update cryptographic protocols. This proactive approach helps you identify weaknesses and move to quantum-safe technologies smoothly. You can trust that Microsoft 365 keeps your data secure and compliant as standards change.

Overcoming Implementation Challenges

You may face challenges when you start your crypto-agility journey. These challenges include regulatory non-compliance, operational disruptions, higher costs, loss of customer trust, and competitive disadvantage. You can see some common challenges in the table below:

Challenge	Description
Regulatory Non-Compliance	Organizations must adapt to new cryptographic standards to avoid penalties and legal repercussions, especially with emerging quantum computing regulations.
Operational Disruptions	Updating cryptographic systems can lead to significant downtime and resource allocation challenges, negatively impacting business operations.
Higher Costs	Manual updates are resource-intensive and expensive, but crypto-agility can streamline the process, reducing costs.
Loss of Customer Trust	Failing to adapt quickly can erode customer trust, especially after a data breach, risking long-term business success.
Competitive Disadvantage	Organizations that are slow to adopt new standards risk falling behind competitors, losing market share and positioning.

You can overcome these obstacles by engaging stakeholders, automating policies, providing comprehensive training, and upgrading your technology. Start by gaining visibility into your cryptographic assets. Support diverse algorithms and ensure systems work together. Use crypto-agility to reduce migration costs and minimize downtime.

Tip: Crypto-agility gives you the flexibility to adapt, meet compliance, and protect your reputation. You can respond quickly to new threats and stay ahead in your industry.

You will see measurable benefits after adopting cryptographic agility. These include enhanced security, flexibility to adapt to new threats, and compliance with regulations like GDPR and NIST. Crypto-agility prepares you for the quantum future and keeps your organization strong.

Preparing for the Quantum Future

Continuous Monitoring

You need to monitor your cryptographic systems constantly to stay ahead of quantum threats. Automated discovery tools help you keep an accurate inventory of your cryptographic assets. Continuous monitoring lets you oversee cryptographic implementations across your organization. Vulnerability assessments show which assets are most at risk from quantum attacks. Centralized crypto management supports policy enforcement and keeps your processes organized.

Component	Description
Automated Discovery Tools	Essential for maintaining an accurate inventory of cryptographic assets.
Continuous Monitoring	Enables ongoing oversight of cryptographic implementations across the organization.
Vulnerability Assessment	Identifies assets' susceptibility to quantum attacks.
Centralized Crypto Management	Supports the management and policy enforcement of cryptographic processes.

Crypto-agility allows you to quickly add new cryptographic protocols. You can adapt your security systems to new threats without changing your entire infrastructure. Continuous updates are important because algorithms can become vulnerable as quantum computing advances. You should adopt quantum-safe cryptography and assess your cybersecurity infrastructure for weaknesses.

Team Training and Awareness

You must train your team to understand quantum risks. Role-based learning tailors training to each team member’s responsibilities. Foundational knowledge ensures everyone knows basic quantum concepts and their impact on security. Security integration brings post-quantum cryptography into your curriculum, showing why it matters for protecting data. Specific training goals help you measure progress, such as making sure a certain percentage of staff can explain key quantum concepts by a set date.

Training Focus Area	Description
Role-Based Learning	Tailors training to the specific needs of different roles within the team.
Foundational Knowledge	Ensures all team members have a basic understanding of quantum concepts and their implications.
Security Integration	Incorporates security considerations into the curriculum, emphasizing the importance of post-quantum cryptography.
Specific Training Goals	Sets measurable objectives, such as ensuring a percentage of staff can explain key quantum concepts by a certain date.

You should provide regular training and update your team as new threats emerge. The financial services sector often leads in this area because it must protect sensitive data for many years.

Collaboration and Updates

You need to work together with different departments and outside organizations to stay updated on quantum-safe cryptography. Start by identifying key stakeholders from across your company. Define roles and responsibilities so everyone knows their duties. Encourage open communication and regular updates among team members. Provide access to training and resources about quantum computing and cryptography.

Identify key stakeholders from various departments.
Define roles and responsibilities for each team member.
Foster collaboration through open communication and regular updates.
Provide training and resources on quantum computing and cryptography.
Monitor progress and adjust strategies as needed.
Engage with external organizations like NIST, national cybersecurity agencies, and universities.

You must recognize that moving to post-quantum cryptography is a multi-year business initiative. This transition requires a clear understanding of your cryptographic footprint and a structured approach. You should plan a phased migration timeline and communicate it to your team. Collaboration helps you share knowledge, stay compliant, and respond quickly to new developments.

Tip: Preparing for the quantum future means acting now. Build strong monitoring, train your team, and foster collaboration to protect your organization.

You face a rapidly changing threat landscape. Cryptographic agility stands as your only sustainable defense against quantum risks. Experts urge you to act now—start with a full inventory, assess your risks, and prioritize post-quantum readiness. Microsoft 365 helps you transition smoothly with automated key management and modular systems. Stay alert by monitoring your cryptographic posture, updating strategies, and training your team. Your ongoing vigilance will keep your data secure in the quantum era.

FAQ

What is cryptographic agility?

Cryptographic agility means you can change encryption methods quickly. You do not need to rebuild your systems. This helps you stay safe as new threats appear.

Why do you need to worry about quantum computers?

Quantum computers can break many types of encryption. They use special algorithms that solve hard math problems fast. You need to prepare now to protect your data.

How does Microsoft 365 help with crypto-agility?

Microsoft 365 lets you manage and update your cryptographic keys and algorithms easily. You can switch to new standards as they become available. This keeps your data secure.

What is a "harvest-now, decrypt-later" attack?

Attackers steal your encrypted data today. They wait until quantum computers can break the encryption. Then, they decrypt your secrets. You need crypto-agility to defend against this risk.

How do you start building cryptographic agility?

Start by making a list of all your cryptographic assets. Assess which ones are most at risk. Use tools like Microsoft 365 to manage and update your encryption.

What is post-quantum cryptography?

Post-quantum cryptography uses new algorithms that quantum computers cannot break easily. You need these algorithms to protect your data in the future.

How often should you review your cryptographic systems?

You should review your cryptographic systems at least once a year. Update your inventory and check for new threats. Regular reviews keep your defenses strong.

🚀 Want to be part of m365.fm?

Then stop just listening… and start showing up.

👉 Connect with me on LinkedIn and let’s make something happen:

🎙️ Be a podcast guest and share your story
🎧 Host your own episode (yes, seriously)
💡 Pitch topics the community actually wants to hear
🌍 Build your personal brand in the Microsoft 365 space

This isn’t just a podcast — it’s a platform for people who take action.

🔥 Most people wait. The best ones don’t.

👉 Connect with me on LinkedIn and send me a message:
"I want in"

Let’s build something awesome 👊

1
00:00:00,000 --> 00:00:02,040
The encryption protecting your enterprise data

2
00:00:02,040 --> 00:00:03,280
will become obsolete.

3
00:00:03,280 --> 00:00:06,080
This isn't hypothetical, and it isn't a distant future problem.

4
00:00:06,080 --> 00:00:08,040
It's already happening, because adversaries

5
00:00:08,040 --> 00:00:10,240
are harvesting your encrypted traffic today

6
00:00:10,240 --> 00:00:12,640
to decrypt it when quantum computers arrive.

7
00:00:12,640 --> 00:00:14,960
And the single factor that determines whether your organization

8
00:00:14,960 --> 00:00:17,520
survives that transition isn't which algorithm you pick.

9
00:00:17,520 --> 00:00:19,840
It's whether your infrastructure can change algorithms

10
00:00:19,840 --> 00:00:22,480
without breaking, and that's the part most organizations

11
00:00:22,480 --> 00:00:23,400
aren't ready for.

12
00:00:23,400 --> 00:00:25,160
Because the threat isn't what you think it is.

13
00:00:25,160 --> 00:00:27,440
It's not a future computer breaking your encryption.

14
00:00:27,440 --> 00:00:29,880
It's a present-day theft, data being stolen now,

15
00:00:29,880 --> 00:00:30,960
decrypted later.

16
00:00:30,960 --> 00:00:32,920
And the fix isn't just a new algorithm.

17
00:00:32,920 --> 00:00:35,360
It's a structural change to how your infrastructure handles

18
00:00:35,360 --> 00:00:36,200
cryptography.

19
00:00:36,200 --> 00:00:37,240
The algorithms exist.

20
00:00:37,240 --> 00:00:38,520
NIST has standardized them.

21
00:00:38,520 --> 00:00:39,760
Microsoft is shipping them.

22
00:00:39,760 --> 00:00:41,680
Browsers are enabling them by default.

23
00:00:41,680 --> 00:00:42,720
The technology is moving.

24
00:00:42,720 --> 00:00:45,720
What isn't moving fast enough is the architecture underneath it.

25
00:00:45,720 --> 00:00:47,520
Because most enterprises have cryptography

26
00:00:47,520 --> 00:00:50,840
that's hard-coded, undocumented, and scattered across systems

27
00:00:50,840 --> 00:00:52,640
that nobody's audited in years.

28
00:00:52,640 --> 00:00:55,480
When an algorithm needs to change, the change can't propagate

29
00:00:55,480 --> 00:00:56,680
fast enough to matter.

30
00:00:56,680 --> 00:00:58,520
So let's walk through the entire picture.

31
00:00:58,520 --> 00:01:01,200
The threat, the replacement algorithms, the performance costs,

32
00:01:01,200 --> 00:01:03,440
the hidden dependencies in your infrastructure,

33
00:01:03,440 --> 00:01:05,520
the architectural shift that makes the transition

34
00:01:05,520 --> 00:01:08,240
survivable, and what's already available in the Microsoft

35
00:01:08,240 --> 00:01:09,560
stack today.

36
00:01:09,560 --> 00:01:12,120
And by the end, the question won't be whether you

37
00:01:12,120 --> 00:01:14,320
need to migrate to post-quantum cryptography.

38
00:01:14,320 --> 00:01:16,040
The question will be whether your infrastructure

39
00:01:16,040 --> 00:01:18,560
is built to handle any algorithm transition, not just

40
00:01:18,560 --> 00:01:19,400
this one.

41
00:01:19,400 --> 00:01:20,840
The harvest now problem.

42
00:01:20,840 --> 00:01:22,960
So let's start with what's actually happening right now.

43
00:01:22,960 --> 00:01:24,360
Because the threat isn't theoretical,

44
00:01:24,360 --> 00:01:26,640
and it isn't waiting for a quantum computer to exist.

45
00:01:26,640 --> 00:01:28,760
It's called harvest now decrypt later.

46
00:01:28,760 --> 00:01:30,320
And the mechanism is straightforward.

47
00:01:30,320 --> 00:01:32,680
An adversary intercepts your encrypted network traffic,

48
00:01:32,680 --> 00:01:34,800
whether that's TLS sessions connecting your users

49
00:01:34,800 --> 00:01:38,800
to Microsoft 365, VPN tunnels running between branch offices

50
00:01:38,800 --> 00:01:39,800
and headquarters.

51
00:01:39,800 --> 00:01:42,720
SSH sessions used for remote server administration,

52
00:01:42,720 --> 00:01:45,120
or API calls from power-automate connectors

53
00:01:45,120 --> 00:01:46,520
to external services.

54
00:01:46,520 --> 00:01:49,320
They can't decrypt any of it today, because the encryption works.

55
00:01:49,320 --> 00:01:52,520
RSA and ECC are still hard to break on classical computers.

56
00:01:52,520 --> 00:01:54,440
The mathematical problems they rely on,

57
00:01:54,440 --> 00:01:57,480
factoring large integers and solving discrete logarithms

58
00:01:57,480 --> 00:02:00,440
remain computationally infeasible at the key sizes we use.

59
00:02:00,440 --> 00:02:02,200
But they don't need to decrypt it today.

60
00:02:02,200 --> 00:02:03,000
They store it.

61
00:02:03,000 --> 00:02:05,320
They hold on to it for years, sometimes a decade or more,

62
00:02:05,320 --> 00:02:07,280
waiting for the day when a quantum computer can run

63
00:02:07,280 --> 00:02:09,240
shows algorithm against the key exchange

64
00:02:09,240 --> 00:02:10,760
that protected those sessions.

65
00:02:10,760 --> 00:02:13,640
Once that happens, every captured session key gets

66
00:02:13,640 --> 00:02:15,400
derived retroactively.

67
00:02:15,400 --> 00:02:17,560
And all the data that was supposed to stay confidential

68
00:02:17,560 --> 00:02:20,240
for 10 or 20 years is suddenly exposed.

69
00:02:20,240 --> 00:02:23,080
Health records, trade secrets, classified information,

70
00:02:23,080 --> 00:02:25,200
intellectual property with multi-decade value,

71
00:02:25,200 --> 00:02:27,680
legal documents covered by a Tony Klein privilege,

72
00:02:27,680 --> 00:02:30,440
financial histories that regulators require you to retain,

73
00:02:30,440 --> 00:02:32,440
all of it becomes readable by the adversary

74
00:02:32,440 --> 00:02:33,960
who had the patience to wait.

75
00:02:33,960 --> 00:02:35,560
And to understand why this is credible,

76
00:02:35,560 --> 00:02:38,240
you need to understand the basic mechanics of quantum computing

77
00:02:38,240 --> 00:02:40,120
and where the technology actually stands.

78
00:02:40,120 --> 00:02:43,280
Quantum computing derives its power from the physics of qubits,

79
00:02:43,280 --> 00:02:45,480
quantum bits that can occupy superpositions

80
00:02:45,480 --> 00:02:47,480
of states and exhibit entanglement.

81
00:02:47,480 --> 00:02:50,680
In classical computing, bits are strictly zero or one.

82
00:02:50,680 --> 00:02:54,440
And algorithms operate by sequentially evaluating discrete states.

83
00:02:54,440 --> 00:02:56,680
A 64-bit register can represent one out of two

84
00:02:56,680 --> 00:02:59,360
to the 64th power possibilities at any instant

85
00:02:59,360 --> 00:03:01,920
and a classical algorithm must effectively traverse

86
00:03:01,920 --> 00:03:04,120
or sample that space step by step.

87
00:03:04,120 --> 00:03:05,960
In contrast, a small register of qubits

88
00:03:05,960 --> 00:03:09,040
can encode a superposition over many possible states at once

89
00:03:09,040 --> 00:03:11,400
and appropriately designed quantum algorithms

90
00:03:11,400 --> 00:03:14,680
can use interference to amplify amplitudes of correct answers

91
00:03:14,680 --> 00:03:16,240
while cancelling incorrect ones,

92
00:03:16,240 --> 00:03:19,280
achieving speedups on specific problem classes.

93
00:03:19,280 --> 00:03:21,320
This doesn't mean quantum computers are universally

94
00:03:21,320 --> 00:03:22,960
faster than classical machines.

95
00:03:22,960 --> 00:03:25,440
Their advantage is problem-dependent and typically arises

96
00:03:25,440 --> 00:03:28,240
when the structure of the problem allows a quantum algorithm

97
00:03:28,240 --> 00:03:30,480
to exploit superposition and entanglement

98
00:03:30,480 --> 00:03:34,440
to reduce complexity from exponential to polynomial time.

99
00:03:34,440 --> 00:03:37,800
Quantum computers aren't expected to replace classical computers,

100
00:03:37,800 --> 00:03:40,440
but to coexist as specialized accelerators,

101
00:03:40,440 --> 00:03:42,960
accessed through cloud platforms and APIs

102
00:03:42,960 --> 00:03:47,080
in much the same way that organizations consume GPU-accelerated AI

103
00:03:47,080 --> 00:03:48,520
services today.

104
00:03:48,520 --> 00:03:50,840
But for security professionals, the relevant point

105
00:03:50,840 --> 00:03:52,520
is that public key cryptography relies

106
00:03:52,520 --> 00:03:54,320
on mathematical problems that are known

107
00:03:54,320 --> 00:03:57,800
to be efficiently solvable on a sufficiently large fault-tolerant

108
00:03:57,800 --> 00:04:00,120
quantum computer using Schauss algorithm.

109
00:04:00,120 --> 00:04:01,960
And the distinction between physical qubits

110
00:04:01,960 --> 00:04:05,000
and logical qubits matters for understanding the timeline.

111
00:04:05,000 --> 00:04:08,040
Physical qubits are the noisy error-prone hardware units.

112
00:04:08,040 --> 00:04:10,160
Logical qubits are the error corrected,

113
00:04:10,160 --> 00:04:14,280
reliable computational units built from many physical qubits.

114
00:04:14,280 --> 00:04:16,040
Current quantum processors have hundreds

115
00:04:16,040 --> 00:04:19,200
to thousands of physical qubits, but the error rates are high enough

116
00:04:19,200 --> 00:04:20,800
that logical qubits are scarce.

117
00:04:20,800 --> 00:04:23,400
IBM's Nighthawk processor announced for 2026

118
00:04:23,400 --> 00:04:27,040
operates 120 logical qubits, which is a significant milestone,

119
00:04:27,040 --> 00:04:31,920
but still far below the roughly 2,330 to 4,099 logical qubits

120
00:04:31,920 --> 00:04:36,240
estimated to be necessary to break P256 or RSA to 248.

121
00:04:36,240 --> 00:04:38,000
Palo Alto Network's characterizes harvest

122
00:04:38,000 --> 00:04:41,040
now decrypt later as the most immediate quantum related danger

123
00:04:41,040 --> 00:04:44,280
because it exploits vulnerabilities that exist right now

124
00:04:44,280 --> 00:04:46,560
in your key exchange and long term storage.

125
00:04:46,560 --> 00:04:48,280
The encryption itself isn't broken yet,

126
00:04:48,280 --> 00:04:50,880
but the confidentiality of the data is already on a timer.

127
00:04:50,880 --> 00:04:54,240
And that timer is shorter than most enterprise planners assume.

128
00:04:54,240 --> 00:04:56,880
The Global Risk Institute published their 2025

129
00:04:56,880 --> 00:05:00,240
Quantum Threat Timeline Report, surveying 26 experts

130
00:05:00,240 --> 00:05:00,840
in the field.

131
00:05:00,840 --> 00:05:04,720
The respondents estimated a 28% to 49% probability

132
00:05:04,720 --> 00:05:07,160
that a cryptographically relevant quantum computer

133
00:05:07,160 --> 00:05:08,840
would exist within 10 years.

134
00:05:08,840 --> 00:05:12,840
For the 15-year horizon, the probability jump to 51% to 70%

135
00:05:12,840 --> 00:05:15,600
that survey reflects expert judgment rather than physical proof,

136
00:05:15,600 --> 00:05:18,480
but it's worth noting that a substantial fraction of specialists

137
00:05:18,480 --> 00:05:22,680
view a sub 15-year timeline as likely rather than speculative.

138
00:05:22,680 --> 00:05:25,040
And the overall conclusion was that the threat timeline

139
00:05:25,040 --> 00:05:27,560
has accelerated relative to prior years.

140
00:05:27,560 --> 00:05:29,840
Industry roadmaps reinforce that acceleration

141
00:05:29,840 --> 00:05:31,080
from different angles.

142
00:05:31,080 --> 00:05:32,880
IBM announced its on track to demonstrate

143
00:05:32,880 --> 00:05:35,560
verified quantum advantage by the end of 2026

144
00:05:35,560 --> 00:05:37,240
using its Nighthawk processor.

145
00:05:37,240 --> 00:05:39,040
Google's Quantum AI Roadmap aspires

146
00:05:39,040 --> 00:05:42,360
to a useful error corrected quantum computer by 2029,

147
00:05:42,360 --> 00:05:45,520
building on its 2019 Quantum Supremacy Experiment.

148
00:05:45,520 --> 00:05:48,680
Google also accelerated its post-quantum cryptography migration

149
00:05:48,680 --> 00:05:51,960
timeline in April 2026, signalling that the company

150
00:05:51,960 --> 00:05:53,800
views the risk window as compressing.

151
00:05:53,800 --> 00:05:57,040
Quantum's Roadmap sets a target of universal, fault-tolerant

152
00:05:57,040 --> 00:05:58,840
quantum computing by 2030.

153
00:05:58,840 --> 00:06:00,360
Pascal's neutral atom roadmap aims

154
00:06:00,360 --> 00:06:03,600
at 10,000 qubit devices by 2027, oriented

155
00:06:03,600 --> 00:06:05,880
toward optimization and simulation rather

156
00:06:05,880 --> 00:06:08,080
than specifically cryptanalytic workloads.

157
00:06:08,080 --> 00:06:10,360
IONQ has reported quantum advantage results

158
00:06:10,360 --> 00:06:11,920
on specific problem classes.

159
00:06:11,920 --> 00:06:13,520
The milestones vary, and none of them

160
00:06:13,520 --> 00:06:15,520
claim a precise date for breaking RSA,

161
00:06:15,520 --> 00:06:17,280
but the direction is consistent.

162
00:06:17,280 --> 00:06:20,240
Now, some vendors have put more aggressive stakes in the ground.

163
00:06:20,240 --> 00:06:23,080
Post-quantum, a quantum safe vendor, published in analysis

164
00:06:23,080 --> 00:06:26,640
arguing that 2030 is a plausible year for RSA 2048

165
00:06:26,640 --> 00:06:29,800
to be broken by a sufficiently advanced quantum computer.

166
00:06:29,800 --> 00:06:31,640
That claim isn't universally endorsed

167
00:06:31,640 --> 00:06:33,000
and should be treated as a scenario

168
00:06:33,000 --> 00:06:35,840
from a motivated vendor rather than an accepted prediction.

169
00:06:35,840 --> 00:06:37,720
Security vendors like Palo Alto Networks

170
00:06:37,720 --> 00:06:40,640
frame Q-Day as likely arriving in the 2030s,

171
00:06:40,640 --> 00:06:43,760
citing forecasts from Forester and Google Quantum AI,

172
00:06:43,760 --> 00:06:46,800
and noting that advances in logical, qubit error correction

173
00:06:46,800 --> 00:06:49,320
have shortened earlier 2035 estimates,

174
00:06:49,320 --> 00:06:50,920
although these remain projections

175
00:06:50,920 --> 00:06:53,920
rather than empirically confirmed dates.

176
00:06:53,920 --> 00:06:55,360
And then there's the regulatory pressure,

177
00:06:55,360 --> 00:06:57,800
which is arguably the most concrete signal available

178
00:06:57,800 --> 00:07:00,440
because governments don't set mandatory transition timelines

179
00:07:00,440 --> 00:07:02,080
for hypothetical threats.

180
00:07:02,080 --> 00:07:05,160
The European Union's Post-Quantum Roadmap Directs member states

181
00:07:05,160 --> 00:07:07,480
to begin transitioning to post-quantum cryptography

182
00:07:07,480 --> 00:07:10,480
by the end of 2026 with critical infrastructure

183
00:07:10,480 --> 00:07:12,960
to be transitioned no later than 2030

184
00:07:12,960 --> 00:07:15,760
and full transition by 2035.

185
00:07:15,760 --> 00:07:19,600
The US CNSA 2.0 timeline issued by the NSA

186
00:07:19,600 --> 00:07:23,880
sets specific milestones, 2025 for new software and firmware

187
00:07:23,880 --> 00:07:26,120
signatures as well as web browsers, servers,

188
00:07:26,120 --> 00:07:29,840
and cloud services adopting CNSA 2.0 algorithms.

189
00:07:29,840 --> 00:07:32,120
2026 for traditional networking equipment,

190
00:07:32,120 --> 00:07:35,160
including VPNs and routers, 2027 and beyond

191
00:07:35,160 --> 00:07:37,880
for operating systems and new national security systems,

192
00:07:37,880 --> 00:07:41,120
and 2035 for complete transition across all national security

193
00:07:41,120 --> 00:07:43,560
systems with traditional asymmetric crypto

194
00:07:43,560 --> 00:07:45,560
not to be used beyond end of 2030

195
00:07:45,560 --> 00:07:47,680
for relevant national security users.

196
00:07:47,680 --> 00:07:49,960
Canada requires initial departmental migration plan

197
00:07:49,960 --> 00:07:52,960
starting April 2026 with annual reporting

198
00:07:52,960 --> 00:07:55,680
high-risk systems complete by end of 2031

199
00:07:55,680 --> 00:07:57,880
and remaining systems by 2035.

200
00:07:57,880 --> 00:08:00,760
Australia's ASD mandates that traditional asymmetric crypto

201
00:08:00,760 --> 00:08:03,920
must not be used beyond end of 2030 in certain contexts

202
00:08:03,920 --> 00:08:07,120
with a refined transition plan due by end of 2026

203
00:08:07,120 --> 00:08:10,520
and transition of critical systems beginning by end of 2028.

204
00:08:10,520 --> 00:08:13,800
The UK and CSEs phased approach calls for discover and plan

205
00:08:13,800 --> 00:08:18,520
around 2028, prioritize and pilot from 2028 to 2031

206
00:08:18,520 --> 00:08:21,840
and complete adoption from 2031 to 2035

207
00:08:21,840 --> 00:08:24,160
with strong emphasis on centrally managed,

208
00:08:24,160 --> 00:08:27,080
non-rushed migration and hybrid solutions.

209
00:08:27,080 --> 00:08:29,920
These timelines create external pressure on every cloud vendor,

210
00:08:29,920 --> 00:08:33,080
including Microsoft, to have mature PQC options available

211
00:08:33,080 --> 00:08:36,600
by the late 2020s with pilot and early adopter capabilities

212
00:08:36,600 --> 00:08:40,480
in the mid-2020s, including right now in 2026.

213
00:08:40,480 --> 00:08:42,320
And the pressure is not just regulatory,

214
00:08:42,320 --> 00:08:43,480
it's also competitive.

215
00:08:43,480 --> 00:08:45,920
Organizations that can demonstrate PQC readiness

216
00:08:45,920 --> 00:08:48,640
to their customers, especially in regulated industries

217
00:08:48,640 --> 00:08:51,840
like finance, healthcare and government contracting

218
00:08:51,840 --> 00:08:53,360
have a market advantage.

219
00:08:53,360 --> 00:08:56,040
Organizations that can't demonstrate readiness

220
00:08:56,040 --> 00:08:59,040
face procurement disadvantage because customers

221
00:08:59,040 --> 00:09:01,600
with their own PQC compliance requirements

222
00:09:01,600 --> 00:09:04,240
will select vendors that can meet them.

223
00:09:04,240 --> 00:09:06,240
The migration to post-quantum cryptography

224
00:09:06,240 --> 00:09:09,120
is becoming a differentiator, not just a compliance checkbox.

225
00:09:09,120 --> 00:09:10,400
So the question for enterprise planners

226
00:09:10,400 --> 00:09:12,360
isn't really when will QD arrive.

227
00:09:12,360 --> 00:09:14,280
The question is whether the math works out

228
00:09:14,280 --> 00:09:16,400
for your specific data.

229
00:09:16,400 --> 00:09:18,320
Isaka's quantum risk assessment guidance

230
00:09:18,320 --> 00:09:20,040
frames this as an inequality.

231
00:09:20,040 --> 00:09:23,200
X is the data retention period for a given asset,

232
00:09:23,200 --> 00:09:25,520
how long the data needs to stay confidential.

233
00:09:25,520 --> 00:09:27,280
Who is the estimated migration time

234
00:09:27,280 --> 00:09:30,280
to get that asset protected by post-quantum cryptography?

235
00:09:30,280 --> 00:09:32,560
Z is the projected collapse time

236
00:09:32,560 --> 00:09:35,040
when a quantum computer can break the encryption.

237
00:09:35,040 --> 00:09:37,880
When x plus y exceeds z, the asset is at risk

238
00:09:37,880 --> 00:09:40,040
under a harvest now decrypt later scenario

239
00:09:40,040 --> 00:09:41,120
and should be prioritized.

240
00:09:41,120 --> 00:09:43,480
Because many enterprises retain highly sensitive data

241
00:09:43,480 --> 00:09:45,160
for 10 to 20 years or more.

242
00:09:45,160 --> 00:09:47,320
And because large-scale cryptographic migrations

243
00:09:47,320 --> 00:09:50,200
can themselves take many years, the prudent stance

244
00:09:50,200 --> 00:09:52,840
is to assume that some data being protected today

245
00:09:52,840 --> 00:09:54,880
will still need to remain confidential

246
00:09:54,880 --> 00:09:58,480
when quantum computers become cryptographically relevant.

247
00:09:58,480 --> 00:10:00,400
Insurers with long tail claims histories

248
00:10:00,400 --> 00:10:02,680
that stretch back decades, healthcare providers

249
00:10:02,680 --> 00:10:05,000
with lifetime medical records, manufacturers

250
00:10:05,000 --> 00:10:06,800
with long term intellectual property

251
00:10:06,800 --> 00:10:09,200
that underpins revenue streams for product cycles

252
00:10:09,200 --> 00:10:10,600
lasting 15 years.

253
00:10:10,600 --> 00:10:13,200
Financial institutions with regulatory retention requirements

254
00:10:13,200 --> 00:10:16,240
spanning 7 to 25 years depending on the record type,

255
00:10:16,240 --> 00:10:18,080
government agencies with classified information

256
00:10:18,080 --> 00:10:20,560
that must remain secret for 30 years or more.

257
00:10:20,560 --> 00:10:23,240
All of these organizations face the inequality right now

258
00:10:23,240 --> 00:10:25,160
even though the quantum computer doesn't exist yet.

259
00:10:25,160 --> 00:10:28,200
Now, symmetric cryptography faces a different quantum thread

260
00:10:28,200 --> 00:10:29,960
that's worth understanding.

261
00:10:29,960 --> 00:10:32,160
Grover's algorithm provides a quadratic speed up

262
00:10:32,160 --> 00:10:34,040
for searching an unstructured space,

263
00:10:34,040 --> 00:10:36,880
which translates into harving the effective security level

264
00:10:36,880 --> 00:10:38,880
of symmetric ciphers.

265
00:10:38,880 --> 00:10:43,440
A 128-bit AES key would offer roughly 64 bits of quantum security,

266
00:10:43,440 --> 00:10:44,520
which is insufficient.

267
00:10:44,520 --> 00:10:48,720
A 256-bit AES key would still offer approximately 128 bits

268
00:10:48,720 --> 00:10:52,000
of quantum security, which still holds up against quantum attacks.

269
00:10:52,000 --> 00:10:53,680
Security guidance from vendors including

270
00:10:53,680 --> 00:10:57,560
Palo Alto Networks and Fortinet recommends favoring AES 256

271
00:10:57,560 --> 00:11:01,440
and stronger hash functions like SHA 384 or SHA 512

272
00:11:01,440 --> 00:11:06,640
over weaker 128-bit keys and deprecated hashes like MD5 or SHR1

273
00:11:06,640 --> 00:11:08,400
as part of quantum readiness.

274
00:11:08,400 --> 00:11:10,720
But the main systemic shock arises from the breakage

275
00:11:10,720 --> 00:11:13,120
of asymmetric primitives used for key exchange

276
00:11:13,120 --> 00:11:15,120
and digital signatures because those are what

277
00:11:15,120 --> 00:11:17,880
establish the secure channels and verify identities

278
00:11:17,880 --> 00:11:20,480
across every layer of your infrastructure.

279
00:11:20,480 --> 00:11:22,480
Symmetric algorithms are less vulnerable,

280
00:11:22,480 --> 00:11:24,640
but the protocols that negotiate the symmetric keys

281
00:11:24,640 --> 00:11:26,960
depend on asymmetric algorithms that are.

282
00:11:26,960 --> 00:11:29,160
But there's a counter-argument worth acknowledging

283
00:11:29,160 --> 00:11:32,000
because it's not wrong and it brings important nuance.

284
00:11:32,000 --> 00:11:34,560
A discussion hosted by the ISC-2 Security Community

285
00:11:34,560 --> 00:11:37,160
contends that HarvestNow decrypt later attacks

286
00:11:37,160 --> 00:11:40,280
are only efficient for highly targeted, high-value intelligence

287
00:11:40,280 --> 00:11:42,600
campaigns, capturing and storing vast amounts

288
00:11:42,600 --> 00:11:44,600
of encrypted traffic for a decade or more,

289
00:11:44,600 --> 00:11:47,560
and then breaking thousands or millions of key exchanges

290
00:11:47,560 --> 00:11:49,880
is extremely costly and uncertain.

291
00:11:49,880 --> 00:11:51,720
The storage alone is non-trivial,

292
00:11:51,720 --> 00:11:53,920
and the compute required to break each key exchange

293
00:11:53,920 --> 00:11:55,640
individually would be significant even

294
00:11:55,640 --> 00:11:57,760
with the capable quantum computer.

295
00:11:57,760 --> 00:12:00,120
That analysis suggests that losing confidentiality

296
00:12:00,120 --> 00:12:02,800
of most enterprise data 10 to 15 years in the future

297
00:12:02,800 --> 00:12:04,880
would rarely cause operational damage.

298
00:12:04,880 --> 00:12:07,240
And that for many organizations, real-time threats

299
00:12:07,240 --> 00:12:09,160
like HarvestNow decrypt now attacks,

300
00:12:09,160 --> 00:12:12,040
which exploit cryptographic technical debt and weak protocols

301
00:12:12,040 --> 00:12:14,920
that are already breakable today are more pressing.

302
00:12:14,920 --> 00:12:17,920
Both perspectives can be reconciled in a risk-based framework.

303
00:12:17,920 --> 00:12:20,880
For enterprises holding data whose compromise in 10 to 20 years

304
00:12:20,880 --> 00:12:22,440
would still be highly damaging,

305
00:12:22,440 --> 00:12:24,920
HarvestNow decrypt later is a material risk

306
00:12:24,920 --> 00:12:27,840
that should influence near-term post-quantum priorities.

307
00:12:27,840 --> 00:12:30,800
For other data, the more relevant risks are second-order.

308
00:12:30,800 --> 00:12:33,560
The collapse of PKI undermining software updates

309
00:12:33,560 --> 00:12:37,000
and identity systems, the need to replace vulnerable algorithms

310
00:12:37,000 --> 00:12:39,960
rapidly in response to new crypt analytic results

311
00:12:39,960 --> 00:12:42,760
and the challenge of doing so without destabilizing business

312
00:12:42,760 --> 00:12:44,640
operations.

313
00:12:44,640 --> 00:12:48,520
CureSecure, a quantum-safe vendor, frames a key business question

314
00:12:48,520 --> 00:12:51,240
as the value horizon of sensitive data.

315
00:12:51,240 --> 00:12:54,240
If information will remain valuable beyond about 2030,

316
00:12:54,240 --> 00:12:57,240
then organizations should begin implementing quantum safe

317
00:12:57,240 --> 00:13:00,680
protections now, because data stolen before migration

318
00:13:00,680 --> 00:13:03,120
can't be retroactively protected.

319
00:13:03,120 --> 00:13:05,680
In this view, trade secrets with multi-decade value,

320
00:13:05,680 --> 00:13:08,560
long-lived personal data subject to regulatory protection,

321
00:13:08,560 --> 00:13:10,880
classified information, and intellectual property

322
00:13:10,880 --> 00:13:13,680
underpinning future revenue streams are particularly attractive

323
00:13:13,680 --> 00:13:16,400
targets for HarvestNow decrypt later campaigns,

324
00:13:16,400 --> 00:13:19,080
justifying immediate action to deploy PQC

325
00:13:19,080 --> 00:13:21,320
at least for high-value assets.

326
00:13:21,320 --> 00:13:23,240
IBM and other vendors echo this logic

327
00:13:23,240 --> 00:13:25,920
in their warning that any TLS data snooped and stored today

328
00:13:25,920 --> 00:13:28,440
could be decrypted in the future when quantum computers

329
00:13:28,440 --> 00:13:31,560
can run shores algorithm against the classical key exchange

330
00:13:31,560 --> 00:13:32,520
mechanisms.

331
00:13:32,520 --> 00:13:33,880
The risk isn't theoretical.

332
00:13:33,880 --> 00:13:35,720
It's a consequence of the mathematical fact

333
00:13:35,720 --> 00:13:38,280
that RSA and ECC key exchange can be broken

334
00:13:38,280 --> 00:13:40,680
by a sufficiently large quantum computer,

335
00:13:40,680 --> 00:13:43,440
combined with the practical fact that encrypted data

336
00:13:43,440 --> 00:13:45,720
can be stored indefinitely at low cost.

337
00:13:45,720 --> 00:13:47,720
And that last point is the one that matters most

338
00:13:47,720 --> 00:13:49,040
for this conversation.

339
00:13:49,040 --> 00:13:51,800
Because in all cases, focusing solely on HarvestNow

340
00:13:51,800 --> 00:13:53,840
to crypto later obscures the broader lesson.

341
00:13:53,840 --> 00:13:55,800
Quantum computing merely accelerates the need

342
00:13:55,800 --> 00:13:57,560
for cryptographic agility that's already

343
00:13:57,560 --> 00:14:00,920
apparent from past algorithm deprecations and protocol shifts.

344
00:14:00,920 --> 00:14:03,040
Think about the deprecation of Shachar 1, which

345
00:14:03,040 --> 00:14:05,360
was deprecated in 2017 and organizations

346
00:14:05,360 --> 00:14:08,800
are still cleaning up SGA1 dependencies in 2026.

347
00:14:08,800 --> 00:14:11,640
The forced migration from TLS 1.0 and 1.1, which

348
00:14:11,640 --> 00:14:13,960
were deprecated in 2021 and legacy systems

349
00:14:13,960 --> 00:14:15,560
still running those protocols are still

350
00:14:15,560 --> 00:14:17,680
being discovered in enterprise networks.

351
00:14:17,680 --> 00:14:20,080
The ongoing retirement of 3DS, none of those

352
00:14:20,080 --> 00:14:21,240
were quantum related.

353
00:14:21,240 --> 00:14:23,880
All of them caused years of painful, expensive remediation

354
00:14:23,880 --> 00:14:26,640
because infrastructure was rigid and couldn't adapt quickly.

355
00:14:26,640 --> 00:14:28,440
The quantum thread makes the next deprecation

356
00:14:28,440 --> 00:14:30,280
existential rather than inconvenient,

357
00:14:30,280 --> 00:14:32,160
but the structural problem is the same.

358
00:14:32,160 --> 00:14:34,760
The real problem isn't that a future computer will break

359
00:14:34,760 --> 00:14:35,680
your encryption.

360
00:14:35,680 --> 00:14:37,320
The real problem is that when that happens

361
00:14:37,320 --> 00:14:39,240
or when the next algorithm gets deprecated

362
00:14:39,240 --> 00:14:41,200
or when the next compliance mandate drops,

363
00:14:41,200 --> 00:14:43,360
your infrastructure probably can't adapt fast enough.

364
00:14:43,360 --> 00:14:45,480
And that's the shift in framing that matters.

365
00:14:45,480 --> 00:14:48,840
Most conversations about quantum risk focus on the timeline.

366
00:14:48,840 --> 00:14:51,200
When will the quantum computer arrive?

367
00:14:51,200 --> 00:14:52,920
But the timeline is uncertain.

368
00:14:52,920 --> 00:14:55,480
What's certain is that your infrastructure is rigid

369
00:14:55,480 --> 00:14:58,080
and that rigidity is what turns a manageable algorithm

370
00:14:58,080 --> 00:15:00,080
transition into an existential crisis.

371
00:15:00,080 --> 00:15:03,240
Whether QDay arrives in 2030 or 2040 or 2050,

372
00:15:03,240 --> 00:15:05,440
your organization will face algorithm transitions

373
00:15:05,440 --> 00:15:06,560
between now and then.

374
00:15:06,560 --> 00:15:09,160
Deprecations happen, protocols get retired,

375
00:15:09,160 --> 00:15:10,720
compliance requirements change,

376
00:15:10,720 --> 00:15:13,480
the quantum transition is the one with the highest stakes.

377
00:15:13,480 --> 00:15:15,880
But it's not the only one your infrastructure will face.

378
00:15:15,880 --> 00:15:17,160
And there's something else worth knowing

379
00:15:17,160 --> 00:15:18,360
before we go further.

380
00:15:18,360 --> 00:15:20,680
Most organizations are already partially protected

381
00:15:20,680 --> 00:15:23,160
against this threat and they don't even realize it.

382
00:15:23,160 --> 00:15:24,240
We'll come back to that.

383
00:15:24,240 --> 00:15:25,040
The new math.

384
00:15:25,040 --> 00:15:26,520
So the data is being stolen now.

385
00:15:26,520 --> 00:15:27,920
But here's what makes this different

386
00:15:27,920 --> 00:15:30,000
from every other security threat you've dealt with.

387
00:15:30,000 --> 00:15:32,840
The fix isn't a patch and it isn't a configuration change.

388
00:15:32,840 --> 00:15:34,320
It's a mathematical shift.

389
00:15:34,320 --> 00:15:37,360
The public key cryptography that protects your entire digital

390
00:15:37,360 --> 00:15:40,520
infrastructure relies on two mathematical problems.

391
00:15:40,520 --> 00:15:43,080
Integer factorization, which is the basis of RSA.

392
00:15:43,080 --> 00:15:46,440
And discrete logarithms over finite fields or elliptic curves,

393
00:15:46,440 --> 00:15:48,360
which underpin Diffie-Hellman and ECC.

394
00:15:48,360 --> 00:15:51,120
These problems are believed to be hard for classical computers.

395
00:15:51,120 --> 00:15:53,360
Meaning no efficient algorithm is known to solve them

396
00:15:53,360 --> 00:15:55,080
at the key sizes we use today.

397
00:15:55,080 --> 00:15:59,120
RSA 2048, RSA 3172, P256, P384, all of these

398
00:15:59,120 --> 00:16:00,920
are secure against classical attacks

399
00:16:00,920 --> 00:16:03,280
because the best known algorithms for factoring

400
00:16:03,280 --> 00:16:05,960
and discrete logarithms require exponential time

401
00:16:05,960 --> 00:16:07,720
relative to the key size.

402
00:16:07,720 --> 00:16:10,760
But Schauer's algorithm changes the equation entirely.

403
00:16:10,760 --> 00:16:13,840
Once a quantum computer can reliably control enough logical

404
00:16:13,840 --> 00:16:17,120
qubits with sufficiently low error rates, factoring large integers

405
00:16:17,120 --> 00:16:19,120
and solving discrete logarithms can be performed

406
00:16:19,120 --> 00:16:20,640
in polynomial time.

407
00:16:20,640 --> 00:16:23,880
The hardness assumptions that RSA and ECC depend on collapse.

408
00:16:23,880 --> 00:16:28,400
And because these algorithms underpin TLS, VPNs, SSH, software

409
00:16:28,400 --> 00:16:31,480
updates, code signing, and the entire PKI-based identity

410
00:16:31,480 --> 00:16:33,480
and access infrastructure, the arrival

411
00:16:33,480 --> 00:16:35,720
of a cryptographically relevant quantum computer

412
00:16:35,720 --> 00:16:38,200
would cause a systemic collapse of existing public key

413
00:16:38,200 --> 00:16:40,760
infrastructure if defenses aren't in place.

414
00:16:40,760 --> 00:16:43,360
This is worth emphasizing because it's not just one protocol

415
00:16:43,360 --> 00:16:44,840
or one service that breaks.

416
00:16:44,840 --> 00:16:47,800
It's the entire trust model that modern computing is built on.

417
00:16:47,800 --> 00:16:50,760
Your TLS connections break, which means your web traffic,

418
00:16:50,760 --> 00:16:53,640
your API calls, your SAS access, your cloud management

419
00:16:53,640 --> 00:16:54,960
interfaces are all exposed.

420
00:16:54,960 --> 00:16:57,200
Your VPN tunnels break, which means your remote access

421
00:16:57,200 --> 00:16:59,040
inside to side connectivity are compromised.

422
00:16:59,040 --> 00:17:01,720
Your SSH sessions break, which means your server administration

423
00:17:01,720 --> 00:17:02,680
is exposed.

424
00:17:02,680 --> 00:17:05,160
Your code signing breaks, which means the integrity

425
00:17:05,160 --> 00:17:07,480
of your software updates can no longer be verified.

426
00:17:07,480 --> 00:17:09,160
Your certificate infrastructure breaks, which

427
00:17:09,160 --> 00:17:11,800
means identity verification at every layer fails.

428
00:17:11,800 --> 00:17:13,760
The problem isn't isolated to any single system.

429
00:17:13,760 --> 00:17:16,280
It's systemic because asymmetric cryptography

430
00:17:16,280 --> 00:17:18,520
is the foundation that everything else builds on.

431
00:17:18,520 --> 00:17:22,040
So the question becomes, what replaces the broken algorithms?

432
00:17:22,040 --> 00:17:25,200
In 2016, NIST launched an open international process

433
00:17:25,200 --> 00:17:28,360
to evaluate and standardize new post-quantum cryptographic

434
00:17:28,360 --> 00:17:29,080
algorithms.

435
00:17:29,080 --> 00:17:31,240
The core requirement was that candidate algorithms

436
00:17:31,240 --> 00:17:32,800
be based on mathematical problems

437
00:17:32,800 --> 00:17:35,840
believed to be hard for both classical and quantum computers,

438
00:17:35,840 --> 00:17:38,560
thereby avoiding the specific vulnerabilities exploited

439
00:17:38,560 --> 00:17:41,360
by Shore's algorithm and other known quantum techniques.

440
00:17:42,360 --> 00:17:45,160
The process ran through multiple rounds of evaluation

441
00:17:45,160 --> 00:17:47,400
with submissions from cryptographers worldwide.

442
00:17:47,400 --> 00:17:50,600
In the first round, 69 candidate algorithms were evaluated.

443
00:17:50,600 --> 00:17:52,280
Many were broken in the early rounds,

444
00:17:52,280 --> 00:17:53,960
some within weeks of submission.

445
00:17:53,960 --> 00:17:55,640
The second round narrowed the field.

446
00:17:55,640 --> 00:17:58,400
The third round identified the finalists and alternates.

447
00:17:58,400 --> 00:18:00,920
This wasn't a quick process and it wasn't supposed to be.

448
00:18:00,920 --> 00:18:03,520
The rigor of the evaluation was the entire point.

449
00:18:03,520 --> 00:18:06,280
In August 2022, NIST announced an initial selection

450
00:18:06,280 --> 00:18:07,640
of four algorithms.

451
00:18:07,640 --> 00:18:09,680
Crystal's Kiber for key encapsulation,

452
00:18:09,680 --> 00:18:12,440
Crystal's Dylithium and Falcon for digital signatures,

453
00:18:12,440 --> 00:18:15,560
and Sphinx Plus as a hash-based backup signature scheme.

454
00:18:15,560 --> 00:18:18,640
And in August 2024, the first three finalized

455
00:18:18,640 --> 00:18:21,840
federal information processing standards were released.

456
00:18:21,840 --> 00:18:26,520
FIPS 203 defines MLKM, a module lattice-based key encapsulation

457
00:18:26,520 --> 00:18:29,040
mechanism derived from Crystal's Kiber intended

458
00:18:29,040 --> 00:18:31,800
to serve as the primary standard for general encryption,

459
00:18:31,800 --> 00:18:34,200
particularly for establishing shared symmetric keys

460
00:18:34,200 --> 00:18:35,960
over insecure networks.

461
00:18:35,960 --> 00:18:39,560
FIPS 204 defines MLDSA, a module lattice-based

462
00:18:39,560 --> 00:18:42,760
digital signature algorithm derived from Crystal's Dylithium,

463
00:18:42,760 --> 00:18:45,200
designed as the primary standard for digital signatures

464
00:18:45,200 --> 00:18:47,840
used in identity authentication, code signing,

465
00:18:47,840 --> 00:18:49,800
and certificate issuance.

466
00:18:49,800 --> 00:18:54,480
FIPS 205 defines SLH, DSA, a stateless hash-based digital

467
00:18:54,480 --> 00:18:56,920
signature algorithm derived from Sphinx Plus,

468
00:18:56,920 --> 00:18:59,520
which uses a fundamentally different mathematical approach

469
00:18:59,520 --> 00:19:01,600
as a backup in case lattice-based schemes

470
00:19:01,600 --> 00:19:03,480
are later found vulnerable.

471
00:19:03,480 --> 00:19:07,200
A fourth-draft standard, FIPS 206, is planned around Falcon,

472
00:19:07,200 --> 00:19:10,560
which will be named FNDSA, and will offer another lattice-based

473
00:19:10,560 --> 00:19:13,000
signature option optimized for different performance

474
00:19:13,000 --> 00:19:14,400
and size trade-offs.

475
00:19:14,400 --> 00:19:18,120
As of June 2026, FNDSA has been submitted for draft approval

476
00:19:18,120 --> 00:19:19,400
but hasn't been finalized yet.

477
00:19:19,400 --> 00:19:22,440
Falcon produces smaller signatures than MLDSA

478
00:19:22,440 --> 00:19:25,160
at comparable security levels, which makes it attractive

479
00:19:25,160 --> 00:19:27,200
for bandwidth-constrained applications,

480
00:19:27,200 --> 00:19:29,640
but the implementation complexity is higher.

481
00:19:29,640 --> 00:19:32,760
And the verification process involves floating-point arithmetic

482
00:19:32,760 --> 00:19:35,520
that requires careful handling to avoid side-channel

483
00:19:35,520 --> 00:19:36,640
vulnerabilities.

484
00:19:36,640 --> 00:19:38,360
So the replacement algorithms exist,

485
00:19:38,360 --> 00:19:40,520
and they're built on a completely different mathematical

486
00:19:40,520 --> 00:19:43,840
foundation, RSA and ECC rely on number theoretic problems

487
00:19:43,840 --> 00:19:45,880
in relatively low-dimensional spaces.

488
00:19:45,880 --> 00:19:47,800
You're factoring a single large integer,

489
00:19:47,800 --> 00:19:50,160
or solving a discrete logarithm over a curve.

490
00:19:50,160 --> 00:19:52,200
The math is elegant and well understood,

491
00:19:52,200 --> 00:19:54,560
but it has the specific algebraic structure

492
00:19:54,560 --> 00:19:56,440
that shows algorithm exploits.

493
00:19:56,440 --> 00:19:59,120
Quantum computers can use superposition and entanglement

494
00:19:59,120 --> 00:20:01,000
to efficiently navigate that structure,

495
00:20:01,000 --> 00:20:03,120
reducing what should take exponential time

496
00:20:03,120 --> 00:20:05,480
on a classical computer, to polynomial time

497
00:20:05,480 --> 00:20:07,720
on a sufficiently large quantum computer.

498
00:20:07,720 --> 00:20:09,280
The new algorithms rely on problems

499
00:20:09,280 --> 00:20:12,120
in high-dimensional geometric structures called lattices.

500
00:20:12,120 --> 00:20:13,840
A lattice is a regular grid of points

501
00:20:13,840 --> 00:20:15,240
in a multidimensional space.

502
00:20:15,240 --> 00:20:17,840
You can think of it as a crystal structure in a space

503
00:20:17,840 --> 00:20:19,440
with hundreds or thousands of dimensions,

504
00:20:19,440 --> 00:20:21,360
rather than the three dimensions we're used to.

505
00:20:21,360 --> 00:20:22,840
The security relevant problem is finding

506
00:20:22,840 --> 00:20:24,520
the shortest vector in that space,

507
00:20:24,520 --> 00:20:26,000
the point closest to the origin.

508
00:20:26,000 --> 00:20:28,760
This is called the shortest vector problem, or SVP.

509
00:20:28,760 --> 00:20:30,880
In two or three dimensions, finding the shortest vector

510
00:20:30,880 --> 00:20:31,520
is easy.

511
00:20:31,520 --> 00:20:32,360
You can see it.

512
00:20:32,360 --> 00:20:35,200
In a thousand dimensions, it becomes extraordinarily difficult

513
00:20:35,200 --> 00:20:37,320
because the search space grows exponentially

514
00:20:37,320 --> 00:20:38,840
with a number of dimensions.

515
00:20:38,840 --> 00:20:41,960
And there's no known technique, classical or quantum

516
00:20:41,960 --> 00:20:43,920
that can efficiently navigate that space

517
00:20:43,920 --> 00:20:46,720
to find the shortest vector.

518
00:20:46,720 --> 00:20:49,640
The best known algorithms for solving SVP in high dimensions

519
00:20:49,640 --> 00:20:52,760
still require exponential time, even with quantum assistance.

520
00:20:52,760 --> 00:20:56,000
The reason Schauer's algorithm works against RSA and ECC

521
00:20:56,000 --> 00:20:57,960
is that factoring and discrete logarithms

522
00:20:57,960 --> 00:20:59,760
have exploitable algebraic structure.

523
00:20:59,760 --> 00:21:01,800
The problem can be decomposed into subproblems

524
00:21:01,800 --> 00:21:03,800
that a quantum computer can solve in parallel

525
00:21:03,800 --> 00:21:05,560
using the quantum Fourier transform.

526
00:21:05,560 --> 00:21:08,880
Latus problems don't have that kind of decomposable structure.

527
00:21:08,880 --> 00:21:11,040
The shortest vector problem is a geometric search

528
00:21:11,040 --> 00:21:12,560
in a high-dimensional space.

529
00:21:12,560 --> 00:21:14,720
And there's no known quantum algorithm

530
00:21:14,720 --> 00:21:16,840
that can exploit the structure to find a speed up

531
00:21:16,840 --> 00:21:19,720
beyond what classical lattice reduction algorithms already

532
00:21:19,720 --> 00:21:20,600
achieve.

533
00:21:20,600 --> 00:21:22,440
That's the mathematical shift in one sentence.

534
00:21:22,440 --> 00:21:24,600
You're moving from problems with exploitable algebraic

535
00:21:24,600 --> 00:21:27,040
structure to problems that resist it.

536
00:21:27,040 --> 00:21:29,600
NIST emphasizes that these PQC algorithms

537
00:21:29,600 --> 00:21:31,400
are ready for immediate implementation

538
00:21:31,400 --> 00:21:34,040
and that organizations should begin migrating now,

539
00:21:34,040 --> 00:21:36,920
both because the timing of a cryptographically relevant quantum

540
00:21:36,920 --> 00:21:39,880
computer is uncertain and because modern infrastructures

541
00:21:39,880 --> 00:21:42,120
require many years to transition.

542
00:21:42,120 --> 00:21:44,600
The algorithms are designed to address two core tasks

543
00:21:44,600 --> 00:21:46,360
for which encryption is typically used,

544
00:21:46,360 --> 00:21:48,840
general encryption, covering key establishment,

545
00:21:48,840 --> 00:21:50,920
and confidentiality of data and transit,

546
00:21:50,920 --> 00:21:54,080
and digital signatures, covering identity, integrity,

547
00:21:54,080 --> 00:21:55,960
and non-repudiation.

548
00:21:55,960 --> 00:21:59,040
Unlike RSA and ECC, which rely on integer factorization

549
00:21:59,040 --> 00:22:02,000
and discrete logarithms, the new algorithms use structured

550
00:22:02,000 --> 00:22:03,880
lattices and hash-based constructions

551
00:22:03,880 --> 00:22:06,360
that currently resist all known classical and quantum

552
00:22:06,360 --> 00:22:07,200
attacks.

553
00:22:07,200 --> 00:22:09,520
Although ongoing crypt analysis remains essential

554
00:22:09,520 --> 00:22:11,960
to validate their robustness over time,

555
00:22:11,960 --> 00:22:13,760
and that last point is worth pausing on.

556
00:22:13,760 --> 00:22:16,280
The phrase currently resist all known attacks

557
00:22:16,280 --> 00:22:19,440
is not the same as will resist or future attacks.

558
00:22:19,440 --> 00:22:21,120
Latiss cryptography is relatively young

559
00:22:21,120 --> 00:22:24,360
compared to RSA and ECC, which have been studied for decades.

560
00:22:24,360 --> 00:22:26,680
The possibility that a future cryptanalytic breakthrough

561
00:22:26,680 --> 00:22:28,800
could weaken lattice-based schemes is real,

562
00:22:28,800 --> 00:22:31,080
which is exactly why NIST, standardized,

563
00:22:31,080 --> 00:22:34,080
SLH-DSA as a hash-based backup built

564
00:22:34,080 --> 00:22:35,880
on entirely different mathematics.

565
00:22:35,880 --> 00:22:38,240
And it's exactly why cryptographic agility matters more

566
00:22:38,240 --> 00:22:40,000
than any single algorithm choice.

567
00:22:40,000 --> 00:22:42,120
If you build your infrastructure to be agile,

568
00:22:42,120 --> 00:22:44,560
a future cryptanalytic result against lattices

569
00:22:44,560 --> 00:22:47,280
would trigger an algorithm rotation, not an infrastructure

570
00:22:47,280 --> 00:22:48,160
rebuild.

571
00:22:48,160 --> 00:22:49,520
And there's a practical implication

572
00:22:49,520 --> 00:22:51,560
of this shift that matters for the migration,

573
00:22:51,560 --> 00:22:54,040
because the new algorithms use a different mathematical

574
00:22:54,040 --> 00:22:54,920
foundation.

575
00:22:54,920 --> 00:22:57,240
They require different implementation techniques.

576
00:22:57,240 --> 00:23:00,080
RSA and ECC rely on big integer arithmetic,

577
00:23:00,080 --> 00:23:02,880
which is well optimized in existing hardware and software.

578
00:23:02,880 --> 00:23:05,280
Latiss algorithms rely on polynomial arithmetic

579
00:23:05,280 --> 00:23:07,040
and number theoretic transforms, which

580
00:23:07,040 --> 00:23:09,320
require different optimization strategies.

581
00:23:09,320 --> 00:23:12,720
This means that existing RSA and ECC hardware accelerators

582
00:23:12,720 --> 00:23:15,000
can't be reused for lattice operations.

583
00:23:15,000 --> 00:23:17,520
New hardware designs and standards are needed for FPGA,

584
00:23:17,520 --> 00:23:20,560
ASIC, and HSM implementations of post-quantum algorithms.

585
00:23:20,560 --> 00:23:22,040
The existing decades of engineering

586
00:23:22,040 --> 00:23:24,320
that went into optimizing RSA and ECC

587
00:23:24,320 --> 00:23:26,360
don't transfer to the new algorithms.

588
00:23:26,360 --> 00:23:29,080
This is a one-time cost of the transition, but it's a real one.

589
00:23:29,080 --> 00:23:30,640
Now, there's an important distinction

590
00:23:30,640 --> 00:23:32,800
within lattice cryptography between structured

591
00:23:32,800 --> 00:23:34,440
and unstructured lattices.

592
00:23:34,440 --> 00:23:37,480
MLKM and MLDSA use module lattices, which

593
00:23:37,480 --> 00:23:39,240
have a certain amount of algebraic structure

594
00:23:39,240 --> 00:23:41,920
that enables smaller keys and faster operations.

595
00:23:41,920 --> 00:23:44,280
This structure introduces slightly stronger assumptions

596
00:23:44,280 --> 00:23:46,800
than unstructured lattice schemes like Frodo-Kem,

597
00:23:46,800 --> 00:23:48,720
which relies on plain learning with errors

598
00:23:48,720 --> 00:23:52,240
and has larger keys, around 19 kilobytes for a key exchange

599
00:23:52,240 --> 00:23:54,320
at 128-bit security.

600
00:23:54,320 --> 00:23:58,600
Compared to about 1.2 kilobytes for MLKM 768.

601
00:23:58,600 --> 00:24:01,400
The trade-off is between efficiency and conservative assumptions.

602
00:24:01,400 --> 00:24:03,880
Nists selected the structured schemes as primary standards

603
00:24:03,880 --> 00:24:05,640
because the efficiency gains are essential

604
00:24:05,640 --> 00:24:07,960
for practical deployment at internet scale,

605
00:24:07,960 --> 00:24:11,680
while also standardizing SLH-DSA as a hash-based backup

606
00:24:11,680 --> 00:24:14,920
that relies on entirely different mathematics.

607
00:24:14,920 --> 00:24:16,160
Now, each of these algorithms

608
00:24:16,160 --> 00:24:18,280
serves a different role in your infrastructure

609
00:24:18,280 --> 00:24:20,080
and understanding those roles is necessary

610
00:24:20,080 --> 00:24:21,760
for planning the transition.

611
00:24:21,760 --> 00:24:25,320
MLKM is a key encapsulation mechanism, meaning it's

612
00:24:25,320 --> 00:24:27,760
used to establish a shared secret between parties

613
00:24:27,760 --> 00:24:29,280
over an insecure channel.

614
00:24:29,280 --> 00:24:30,520
The workflow works like this.

615
00:24:30,520 --> 00:24:32,840
The client and server agree on public parameters.

616
00:24:32,840 --> 00:24:35,720
The server publishes an MLKM public key.

617
00:24:35,720 --> 00:24:37,240
The client generates a random secret

618
00:24:37,240 --> 00:24:40,280
and encapsulates it using the public key to produce a ciphertext.

619
00:24:40,280 --> 00:24:42,080
The server decapsulates the ciphertext

620
00:24:42,080 --> 00:24:44,600
with its private key to recover the same secret.

621
00:24:44,600 --> 00:24:48,000
Both parties then derive a symmetric key using a key derivation

622
00:24:48,000 --> 00:24:48,720
function.

623
00:24:48,720 --> 00:24:50,480
This shared secret becomes the session key

624
00:24:50,480 --> 00:24:52,920
for symmetric encryption, typically AES.

625
00:24:52,920 --> 00:24:54,960
MLKM replaces the RSA key transport

626
00:24:54,960 --> 00:24:58,880
and ECDH key agreement in your TLS handshakes, VPN negotiations,

627
00:24:58,880 --> 00:25:00,560
and SSH key exchanges.

628
00:25:00,560 --> 00:25:02,800
MLDSA is a digital signature algorithm

629
00:25:02,800 --> 00:25:04,680
used to sign messages so that any verifier

630
00:25:04,680 --> 00:25:07,360
with the public key can check authenticity and integrity.

631
00:25:07,360 --> 00:25:09,440
This is what replaces RSA signatures

632
00:25:09,440 --> 00:25:11,920
and ECDSA in your certificate chains, your code signing

633
00:25:11,920 --> 00:25:15,240
processes, your document signing workflows, your identity tokens,

634
00:25:15,240 --> 00:25:16,960
and your software update verification.

635
00:25:16,960 --> 00:25:19,520
When you enroll a certificate from a certificate authority,

636
00:25:19,520 --> 00:25:21,720
the CA signs it using its private key.

637
00:25:21,720 --> 00:25:24,480
When you sign a power shell script for execution policy,

638
00:25:24,480 --> 00:25:26,480
you're creating a digital signature.

639
00:25:26,480 --> 00:25:29,840
When EntraID issues and access token, that token is signed,

640
00:25:29,840 --> 00:25:31,600
all of these signing operations will eventually

641
00:25:31,600 --> 00:25:34,800
use MLDSA instead of RSA or ECDSA.

642
00:25:34,800 --> 00:25:36,680
SLHDSA is the insurance policy.

643
00:25:36,680 --> 00:25:38,560
It's hash-based, not lattice-based,

644
00:25:38,560 --> 00:25:41,920
meaning it relies on an entirely different mathematical foundation.

645
00:25:41,920 --> 00:25:44,040
Hash-based signatures derive their security

646
00:25:44,040 --> 00:25:46,360
from the collision resistance and pre-image resistance

647
00:25:46,360 --> 00:25:48,160
of hash functions, which are not known

648
00:25:48,160 --> 00:25:52,760
to be vulnerable to quantum attacks beyond Grover's quadratic speedup.

649
00:25:52,760 --> 00:25:54,400
If someone discovers a quantum algorithm

650
00:25:54,400 --> 00:25:57,840
that breaks lattice problems, SLHDSA still stands.

651
00:25:57,840 --> 00:25:59,840
The trade-off is that SLHDSA signatures

652
00:25:59,840 --> 00:26:02,520
are significantly larger and slower than MLDSA,

653
00:26:02,520 --> 00:26:04,160
which is why it's positioned as a backup

654
00:26:04,160 --> 00:26:05,880
rather than the primary standard.

655
00:26:05,880 --> 00:26:08,720
SLHDSA signatures at the smallest parameter set

656
00:26:08,720 --> 00:26:10,760
are still around 8 kilobytes compared

657
00:26:10,760 --> 00:26:13,960
to roughly 2.4 kilobytes for MLDSA 65.

658
00:26:13,960 --> 00:26:16,520
And that architectural choice having a backup algorithm

659
00:26:16,520 --> 00:26:18,560
built on different math is itself a form

660
00:26:18,560 --> 00:26:20,200
of cryptographic agility.

661
00:26:20,200 --> 00:26:22,440
List is already practicing what they're preaching.

662
00:26:22,440 --> 00:26:24,760
Don't bet everything on one mathematical assumption.

663
00:26:24,760 --> 00:26:26,520
Build redundancy at the algorithm layer

664
00:26:26,520 --> 00:26:29,160
so that a single crypt analytic breakthrough doesn't collapse

665
00:26:29,160 --> 00:26:30,360
the entire system.

666
00:26:30,360 --> 00:26:31,760
But here's what most enterprises miss

667
00:26:31,760 --> 00:26:33,560
when they read about these new standards.

668
00:26:33,560 --> 00:26:34,880
These aren't drop-in replacements.

669
00:26:34,880 --> 00:26:36,720
The keys and ciphertexts for MLKM

670
00:26:36,720 --> 00:26:39,200
are measured in kilobytes, not hundreds of bytes.

671
00:26:39,200 --> 00:26:42,160
The signatures for MLDSA are four to 10 times larger

672
00:26:42,160 --> 00:26:44,920
than RSA signatures at comparable security levels.

673
00:26:44,920 --> 00:26:45,880
The math is different.

674
00:26:45,880 --> 00:26:47,480
The performance profile is different

675
00:26:47,480 --> 00:26:49,280
and the infrastructure impact is different.

676
00:26:49,280 --> 00:26:51,480
And that's the part that turns a theoretical migration

677
00:26:51,480 --> 00:26:52,840
into an engineering problem

678
00:26:52,840 --> 00:26:55,080
because the algorithm swap itself is straightforward

679
00:26:55,080 --> 00:26:56,440
at the mathematical level,

680
00:26:56,440 --> 00:26:58,720
but the deployment of larger keys and signatures

681
00:26:58,720 --> 00:27:01,360
across an infrastructure that was designed for small ones

682
00:27:01,360 --> 00:27:03,840
creates friction at every layer, the network layer,

683
00:27:03,840 --> 00:27:05,960
the protocol layer, the certificate layer,

684
00:27:05,960 --> 00:27:08,800
the hardware layer and the application layer.

685
00:27:08,800 --> 00:27:10,720
Each layer can be addressed individually

686
00:27:10,720 --> 00:27:13,320
but the coordination across all of them simultaneously

687
00:27:13,320 --> 00:27:15,160
is what makes the migration hard.

688
00:27:15,160 --> 00:27:16,760
The performance reality check.

689
00:27:16,760 --> 00:27:19,440
And this is where the post quantum transition gets expensive

690
00:27:19,440 --> 00:27:22,440
because the bottleneck isn't compute, it's bandwidth.

691
00:27:22,440 --> 00:27:23,680
Let's look at the numbers in detail

692
00:27:23,680 --> 00:27:26,040
because the specific size is matter for planning.

693
00:27:26,040 --> 00:27:29,560
A standard X25519 elliptic curve key exchange,

694
00:27:29,560 --> 00:27:31,560
which is what most TLS connections use today

695
00:27:31,560 --> 00:27:35,120
requires 64 bytes of communication between client and server.

696
00:27:35,120 --> 00:27:38,160
That's 32 bytes for the client's public key contribution

697
00:27:38,160 --> 00:27:39,680
and 32 bytes for the servers.

698
00:27:39,680 --> 00:27:40,600
It's tiny.

699
00:27:40,600 --> 00:27:43,000
It fits comfortably in a single TCP segment

700
00:27:43,000 --> 00:27:45,680
with room to spare for the rest of the client hello message.

701
00:27:45,680 --> 00:27:48,760
MLKM768, which is the NIST recommended replacement

702
00:27:48,760 --> 00:27:50,360
at a comparable security level,

703
00:27:50,360 --> 00:27:54,120
requires roughly 2,272 bytes for the same key exchange.

704
00:27:54,120 --> 00:27:57,200
That's about 37 times larger than X25519.

705
00:27:57,200 --> 00:28:00,120
The public key alone is around 1,084 bytes,

706
00:28:00,120 --> 00:28:02,880
compared to 32 bytes for X25519.

707
00:28:02,880 --> 00:28:04,360
The cipher text is similar in size.

708
00:28:04,360 --> 00:28:06,840
On the CPU side, the story is actually positive.

709
00:28:06,840 --> 00:28:09,520
MLKM decapsulation is often faster than RSA

710
00:28:09,520 --> 00:28:12,000
private key operations, especially for the server side,

711
00:28:12,000 --> 00:28:14,440
which is where the computational burden typically lands.

712
00:28:14,440 --> 00:28:16,920
The lattice operations use polynomial multiplications

713
00:28:16,920 --> 00:28:19,360
and matrix vector products over small modulo,

714
00:28:19,360 --> 00:28:23,000
typically 11 to 13 bit primes, which are highly parallelizable

715
00:28:23,000 --> 00:28:24,840
and benefit from modern CPU features

716
00:28:24,840 --> 00:28:28,720
like SIMD instructions and number theoretic transforms.

717
00:28:28,720 --> 00:28:30,920
Cloudflare has noted that lattice-based key exchange

718
00:28:30,920 --> 00:28:33,560
is often as fast and sometimes faster

719
00:28:33,560 --> 00:28:36,760
in terms of CPU time than elliptic curve operations.

720
00:28:36,760 --> 00:28:38,640
RSA private key operations are generally

721
00:28:38,640 --> 00:28:40,840
slower than either ECC or lattice cams

722
00:28:40,840 --> 00:28:42,600
at comparable security levels, especially

723
00:28:42,600 --> 00:28:45,480
on constrained devices without dedicated RSA hardware.

724
00:28:45,480 --> 00:28:47,280
But CPUs B doesn't matter when the handshake

725
00:28:47,280 --> 00:28:49,080
doesn't fit in a single network packet.

726
00:28:49,080 --> 00:28:51,080
TLS operates over TCP.

727
00:28:51,080 --> 00:28:54,000
And TCP has a maximum segment size determined by the path

728
00:28:54,000 --> 00:28:58,960
M-T-U, typically around 1,460 bytes on a standard ether network.

729
00:28:58,960 --> 00:29:01,720
When the client hello message grows from a few hundred bytes

730
00:29:01,720 --> 00:29:05,120
to over 2 kilobytes, you hit fragmentation issues.

731
00:29:05,120 --> 00:29:07,960
The handshake splits across multiple TCP segments.

732
00:29:07,960 --> 00:29:09,960
Each additional segment requires another round trip

733
00:29:09,960 --> 00:29:12,120
on the network and on high latency connections

734
00:29:12,120 --> 00:29:13,680
that adds measurable delay.

735
00:29:13,680 --> 00:29:15,520
On lossy networks, each additional packet

736
00:29:15,520 --> 00:29:17,200
is another chance for a retransmission

737
00:29:17,200 --> 00:29:18,920
that could add hundreds of milliseconds

738
00:29:18,920 --> 00:29:20,680
to the handshake time.

739
00:29:20,680 --> 00:29:22,840
The quick protocol, which underlies HTTP3,

740
00:29:22,840 --> 00:29:24,480
adds another dimension to this problem.

741
00:29:24,480 --> 00:29:26,760
QC runs over UDP and handles its own encryption

742
00:29:26,760 --> 00:29:27,960
and congestion control.

743
00:29:27,960 --> 00:29:30,360
Larger client, hello messages in quicks

744
00:29:30,360 --> 00:29:32,280
can cause the initial data gram to exceed

745
00:29:32,280 --> 00:29:35,120
the typical UDP M-T-U, forcing a fallback

746
00:29:35,120 --> 00:29:36,840
to a more expensive handshake flow

747
00:29:36,840 --> 00:29:39,760
that sends the initial message in multiple data grams.

748
00:29:39,760 --> 00:29:41,960
This is one of the areas where the post quantum transition

749
00:29:41,960 --> 00:29:44,040
creates protocol level complexity

750
00:29:44,040 --> 00:29:47,160
that goes beyond simply swapping algorithm implementations.

751
00:29:47,160 --> 00:29:49,200
On middle boxes that inspect TLS traffic,

752
00:29:49,200 --> 00:29:51,720
larger handshakes can trigger bugs or timeout failures

753
00:29:51,720 --> 00:29:54,720
that were never tested with post quantum cipher suites.

754
00:29:54,720 --> 00:29:57,400
Enterprise firewalls, intrusion detection systems,

755
00:29:57,400 --> 00:30:00,800
and TLS inspection appliances often have hard coded expectations

756
00:30:00,800 --> 00:30:03,120
about the maximum size of TLS messages.

757
00:30:03,120 --> 00:30:05,080
When those expectations are violated,

758
00:30:05,080 --> 00:30:07,400
the middle box may drop the connection, reset it,

759
00:30:07,400 --> 00:30:11,040
or silently strip the unknown cipher suite from the client, hello,

760
00:30:11,040 --> 00:30:13,640
forcing a fallback to classical only key exchange

761
00:30:13,640 --> 00:30:16,800
and defeating the post quantum protection entirely.

762
00:30:16,800 --> 00:30:18,480
This is not a theoretical failure mode.

763
00:30:18,480 --> 00:30:21,960
It's been observed in practice during early PQC TLS testing,

764
00:30:21,960 --> 00:30:23,960
and it's one of the reasons the migration requires

765
00:30:23,960 --> 00:30:26,360
careful canary testing before broad rollout.

766
00:30:26,360 --> 00:30:28,480
The canary testing approach matters for this audience

767
00:30:28,480 --> 00:30:31,560
because many organizations deploy TLS inspection appliances

768
00:30:31,560 --> 00:30:35,160
as part of their Microsoft 365 security architecture.

769
00:30:35,160 --> 00:30:37,600
These appliances intercept and inspect TLS traffic

770
00:30:37,600 --> 00:30:39,880
between users and M365 services,

771
00:30:39,880 --> 00:30:42,080
which means they sit in the path of every browser

772
00:30:42,080 --> 00:30:43,280
to cloud connection.

773
00:30:43,280 --> 00:30:45,520
If your TLS inspection appliance doesn't handle

774
00:30:45,520 --> 00:30:47,760
larger post quantum handshakes correctly,

775
00:30:47,760 --> 00:30:50,800
it becomes a single point of failure for the PQC upgrade.

776
00:30:50,800 --> 00:30:52,400
And because these appliances are typically

777
00:30:52,400 --> 00:30:54,320
managed by a different team than the one managing

778
00:30:54,320 --> 00:30:56,760
the browser deployment, the coordination problem is real.

779
00:30:56,760 --> 00:30:58,120
And then there's the state management,

780
00:30:58,120 --> 00:31:00,360
a server terminating millions of TLS connections per day,

781
00:31:00,360 --> 00:31:03,320
think Azure front doors, Microsoft 365 load balancers,

782
00:31:03,320 --> 00:31:04,960
API gateways for power platform,

783
00:31:04,960 --> 00:31:07,480
has to maintain state for each handshake in progress.

784
00:31:07,480 --> 00:31:10,520
Larger handshake messages mean more memory per connection,

785
00:31:10,520 --> 00:31:12,640
more buffer management, and more pressure

786
00:31:12,640 --> 00:31:14,280
on the TLS state machine.

787
00:31:14,280 --> 00:31:16,080
At the scale of a major cloud provider,

788
00:31:16,080 --> 00:31:18,480
this compounds into real infrastructure cost,

789
00:31:18,480 --> 00:31:21,800
more rampers server, more connection tracking capacity,

790
00:31:21,800 --> 00:31:24,320
more careful tuning of TCP parameters

791
00:31:24,320 --> 00:31:26,000
like the initial congestion window.

792
00:31:26,000 --> 00:31:28,520
Cloudflare has noted that accommodating letters overhead

793
00:31:28,520 --> 00:31:31,600
in TLS involves dealing with TCP fragmentation

794
00:31:31,600 --> 00:31:33,520
and reworking the protocol stack and PKI

795
00:31:33,520 --> 00:31:35,520
to handle larger keys and messages.

796
00:31:35,520 --> 00:31:38,000
For signatures, the overhead is even more pronounced.

797
00:31:38,000 --> 00:31:40,760
An RSA 248 signature is 256 bytes.

798
00:31:40,760 --> 00:31:43,840
An RSA 3072 signature is 384 bytes.

799
00:31:43,840 --> 00:31:47,240
An MLDSA 65 signature at a comparable security level

800
00:31:47,240 --> 00:31:49,680
is roughly 2,420 bytes.

801
00:31:49,680 --> 00:31:52,360
An MLDSA 87 signature at a higher security level

802
00:31:52,360 --> 00:31:54,560
is about 4,195 bytes.

803
00:31:54,560 --> 00:31:56,800
That's a four to 10 times increase per signature

804
00:31:56,800 --> 00:31:59,000
depending on the security level you're comparing.

805
00:31:59,000 --> 00:32:01,520
Now think about what that means for certificate chains.

806
00:32:01,520 --> 00:32:03,960
An X509 certificate carries the public key

807
00:32:03,960 --> 00:32:06,560
and the signature from the issuing certificate authority.

808
00:32:06,560 --> 00:32:10,000
A typical TLS certificate chain today has two or three certificates.

809
00:32:10,000 --> 00:32:12,960
The end entity certificate, an intermediate CA certificate,

810
00:32:12,960 --> 00:32:15,280
and optionally a root CA certificate.

811
00:32:15,280 --> 00:32:22,040
With RSA 2948 or ECDSA P256, each certificate is roughly 1 to 1.5 kilobytes,

812
00:32:22,040 --> 00:32:24,360
so the full chain is about 2 to 4 kilobytes.

813
00:32:24,360 --> 00:32:30,880
With MLDSA, each certificate carries a public key of roughly 1,312 to 2,992 bytes

814
00:32:30,880 --> 00:32:35,240
and a signature of roughly 2,420 to 4,995 bytes,

815
00:32:35,240 --> 00:32:36,720
depending on the parameter set.

816
00:32:36,720 --> 00:32:39,680
A single certificate could easily be 4 to 7 kilobytes.

817
00:32:39,680 --> 00:32:41,760
The full chain for a single TLS connection

818
00:32:41,760 --> 00:32:45,560
could grow from roughly 3 kilobytes to 12 to 20 kilobytes or more.

819
00:32:45,560 --> 00:32:47,720
Some proposals favor hybrid certificates

820
00:32:47,720 --> 00:32:50,240
that carry both a classical and a PQ signature

821
00:32:50,240 --> 00:32:53,000
during the transition, which further inflate sizes.

822
00:32:53,000 --> 00:32:55,080
On constrained clients, on IoT devices,

823
00:32:55,080 --> 00:32:57,360
on mobile networks with limited bandwidth and high

824
00:32:57,360 --> 00:32:59,520
per megabyte costs, that's a real problem.

825
00:32:59,520 --> 00:33:01,840
Flash and RAM constraints on embedded devices

826
00:33:01,840 --> 00:33:05,200
limit how much certificate data can be stored and passed.

827
00:33:05,200 --> 00:33:10,400
Latest schemes, code and key tables can be bigger than compact RSA or ECC implementations,

828
00:33:10,400 --> 00:33:14,080
which creates deployment challenges on devices with tight memory budgets.

829
00:33:14,080 --> 00:33:15,760
There is active research into lightweight

830
00:33:15,760 --> 00:33:18,560
Latest implementations tailored to embedded environments,

831
00:33:18,560 --> 00:33:21,800
but the trade-offs remain significant, and it compounds at scale.

832
00:33:21,800 --> 00:33:23,400
If you're a CDN or a cloud provider

833
00:33:23,400 --> 00:33:26,160
terminating billions of TLS handshakes per day,

834
00:33:26,160 --> 00:33:29,480
the aggregate bandwidth increase from larger keys and signatures is measured

835
00:33:29,480 --> 00:33:31,720
in terabits per second of additional traffic.

836
00:33:31,720 --> 00:33:34,480
That's not a rounding error, that's an infrastructure redesign.

837
00:33:34,480 --> 00:33:37,560
The research on lattice-based versus RSA performance shows

838
00:33:37,560 --> 00:33:40,320
that the trade-off is consistent across security levels.

839
00:33:40,320 --> 00:33:43,280
Latest schemes generally have higher bandwidth and memory overhead,

840
00:33:43,280 --> 00:33:46,360
but comparable or better CPU performance than RSA

841
00:33:46,360 --> 00:33:48,360
at similar classical security levels,

842
00:33:48,360 --> 00:33:52,000
while also providing resistance against quantum attacks.

843
00:33:52,000 --> 00:33:53,680
For signatures and key exchange,

844
00:33:53,680 --> 00:33:57,160
current standardized lattice schemes use keys and ciphertexts or signatures

845
00:33:57,160 --> 00:33:59,920
measured in kilobytes rather than hundreds of bytes,

846
00:33:59,920 --> 00:34:02,920
yet often run faster than RSA on modern CPUs,

847
00:34:02,920 --> 00:34:05,120
because they use structured linear operations

848
00:34:05,120 --> 00:34:08,760
that are amenable to optimization and parallelization.

849
00:34:08,760 --> 00:34:11,720
The important nuance is that the comparison point matters.

850
00:34:11,720 --> 00:34:15,680
Compared to X255-9, which is the current standard for key exchange,

851
00:34:15,680 --> 00:34:19,200
ML cam is much larger and roughly comparable in CPU time.

852
00:34:19,200 --> 00:34:23,640
Compared to RSA 3072, which is the RSA equivalent at similar security levels,

853
00:34:23,640 --> 00:34:27,280
ML cam is larger in bandwidth, but faster on the CPU,

854
00:34:27,280 --> 00:34:29,320
especially for server-side decapsulation

855
00:34:29,320 --> 00:34:32,520
where the RSA private key operation dominates latency.

856
00:34:32,520 --> 00:34:34,800
So the performance picture depends on what you're replacing

857
00:34:34,800 --> 00:34:36,440
and what you're comparing against.

858
00:34:36,440 --> 00:34:41,240
For organizations currently using RSA key transport rather than ECDH key exchange,

859
00:34:41,240 --> 00:34:44,720
the CPU improvement from migrating to ML cam is a genuine benefit.

860
00:34:44,720 --> 00:34:48,280
For organizations already using ECDH with X255-9,

861
00:34:48,280 --> 00:34:51,720
the migration adds bandwidth cost without improving CPU performance.

862
00:34:51,720 --> 00:34:54,760
The security improvement, protection against quantum attacks,

863
00:34:54,760 --> 00:34:56,720
is the motivation in both cases,

864
00:34:56,720 --> 00:35:00,240
but the performance trade-off looks different depending on your starting point.

865
00:35:00,240 --> 00:35:01,880
For the Microsoft Centric Enterprise,

866
00:35:01,880 --> 00:35:04,960
the impact lands on specific workloads you manage every day.

867
00:35:04,960 --> 00:35:09,440
Microsoft Teams media streams rely on TLS for signaling and media establishment.

868
00:35:09,440 --> 00:35:13,400
Every Teams call involves multiple TLS handshakes for the signaling channel,

869
00:35:13,400 --> 00:35:15,920
the media relay and the authentication flow.

870
00:35:15,920 --> 00:35:20,480
SharePoint file access and one drive sync operations use TLS for every file transfer,

871
00:35:20,480 --> 00:35:24,160
and large organizations generate millions of these operations daily.

872
00:35:24,160 --> 00:35:28,000
Exchange Online Mailflow uses TLS for message submission and retrieval

873
00:35:28,000 --> 00:35:31,080
with start TLS upgrades on connections that start unencrypted.

874
00:35:31,080 --> 00:35:35,280
Azure API calls from Power Automate Connectors, Power Apps and Custom Applications

875
00:35:35,280 --> 00:35:39,000
all use TLS handshakes that would need to accommodate larger messages.

876
00:35:39,000 --> 00:35:43,360
Entra ID token exchanges which happen on every authentication and every token refresh

877
00:35:43,360 --> 00:35:47,760
use TLS and carry sign tokens that would eventually use ML/DSA signatures

878
00:35:47,760 --> 00:35:50,680
and at higher security levels the comparison shifts somewhat.

879
00:35:50,680 --> 00:35:53,880
RSA key sizes grow super linearly with security level.

880
00:35:53,880 --> 00:35:56,240
To match AES 256 equivalent security,

881
00:35:56,240 --> 00:35:59,560
you need RSA with a 15, 360-bit modulus or larger,

882
00:35:59,560 --> 00:36:03,720
which means keys over 1.9 kilobytes and dramatically slower expenentiations.

883
00:36:03,720 --> 00:36:05,600
Latest parameters grow more modestly,

884
00:36:05,600 --> 00:36:07,200
so at very high security levels,

885
00:36:07,200 --> 00:36:10,640
the size gap between RSA and lattice schemes actually narrows,

886
00:36:10,640 --> 00:36:14,320
and the CPU advantage of lattice schemes becomes more pronounced.

887
00:36:14,320 --> 00:36:17,320
But most enterprise deployments operate at the AES 128

888
00:36:17,320 --> 00:36:21,280
to AES 192 security level, where the bandwidth penalty is most acute.

889
00:36:21,280 --> 00:36:23,120
That's where your infrastructure is right now.

890
00:36:23,120 --> 00:36:26,720
One area that deserves special attention for this audience is the impact on

891
00:36:26,720 --> 00:36:29,400
Entra ID and Azure AD authentication flows.

892
00:36:29,400 --> 00:36:34,320
Every authentication to Microsoft 365 involves multiple TLS handshakes and token exchanges.

893
00:36:34,320 --> 00:36:38,560
When a user signs into teams, the process includes a TLS connection to the login endpoint,

894
00:36:38,560 --> 00:36:42,520
a token request to Entra ID, a token response with assigned access token

895
00:36:42,520 --> 00:36:46,520
and subsequent TLS connections to each service the token grants access to.

896
00:36:46,520 --> 00:36:50,240
At enterprise scale, millions of these authentication flows happen every day.

897
00:36:50,240 --> 00:36:54,600
Larger handshakes and larger token signatures compound across all of these flows,

898
00:36:54,600 --> 00:36:57,480
increasing both latency and bandwidth consumption,

899
00:36:57,480 --> 00:37:00,800
on the authentication path that users experience directly.

900
00:37:00,800 --> 00:37:03,240
A 50 millisecond increase in authentication latency,

901
00:37:03,240 --> 00:37:05,560
which is plausible given the handshake size inflation,

902
00:37:05,560 --> 00:37:08,640
is perceptible to users and effects productivity at scale.

903
00:37:08,640 --> 00:37:12,800
For power platforms specifically, the impact manifests through API call volume.

904
00:37:12,800 --> 00:37:17,480
A power automate flow that runs 10,000 times per day and makes five API calls per run

905
00:37:17,480 --> 00:37:21,040
generates 50,000 TLS handshakes per day for that single flow.

906
00:37:21,040 --> 00:37:25,720
An organization with hundreds of flows generates millions of API call TLS handshakes per day.

907
00:37:25,720 --> 00:37:30,760
Larger post quantum handshakes increase the aggregate bandwidth consumed by these automated processes

908
00:37:30,760 --> 00:37:33,560
and on network connections with limited capacity.

909
00:37:33,560 --> 00:37:37,560
This can introduce latency that affects the reliability of time sensitive automations.

910
00:37:37,560 --> 00:37:41,280
So the performance reality is this, the new algorithms are fast enough on the CPU.

911
00:37:41,280 --> 00:37:42,680
The problem is everything else.

912
00:37:42,680 --> 00:37:46,160
Larger keys, larger signatures, larger handshakes, more bandwidth, more memory,

913
00:37:46,160 --> 00:37:48,560
more fragmentation risk, more middle box failures.

914
00:37:48,560 --> 00:37:51,800
And you can't just flip a switch to deploy them because the TLS ecosystem,

915
00:37:51,800 --> 00:37:55,080
the PKI, the certificate authorities, the browsers, the operating systems,

916
00:37:55,080 --> 00:37:59,280
the load balances, the HSMs, all of them need to coordinate on the transition.

917
00:37:59,280 --> 00:38:02,800
And that's why you can't just swap algorithms, which brings us to the real problem.

918
00:38:02,800 --> 00:38:06,600
It's not the math, it's not even the bandwidth, it's that your infrastructure is rigid.

919
00:38:06,600 --> 00:38:08,920
And everything we've discussed so far, the harvest now threat,

920
00:38:08,920 --> 00:38:11,160
the new lattice algorithms, the bandwidth inflation,

921
00:38:11,160 --> 00:38:13,160
all of it points to the same structural floor.

922
00:38:13,160 --> 00:38:16,040
Your encryption is hard coded, your certificates are hard coded,

923
00:38:16,040 --> 00:38:17,640
your key types are hard coded,

924
00:38:17,640 --> 00:38:21,840
and when the algorithm needs to change, the change can't propagate fast enough to matter.

925
00:38:21,840 --> 00:38:24,840
There's a way to bridge from where you are to where you need to be,

926
00:38:24,840 --> 00:38:27,400
but it requires a fundamentally different architecture

927
00:38:27,400 --> 00:38:29,440
for how cryptography works in your systems.

928
00:38:29,440 --> 00:38:34,000
The hidden dependency problem, your enterprise has cryptographic dependencies you don't know about,

929
00:38:34,000 --> 00:38:35,560
not some of them, most of them.

930
00:38:35,560 --> 00:38:39,200
And that's the problem that makes the post quantum transition fundamentally different

931
00:38:39,200 --> 00:38:41,440
from a patch deployment or a certificate renewal.

932
00:38:41,440 --> 00:38:43,200
You can't fix what you can't see.

933
00:38:43,200 --> 00:38:45,960
And most organizations have remarkably poor visibility

934
00:38:45,960 --> 00:38:49,760
into where and how cryptography is actually used across their infrastructure.

935
00:38:49,760 --> 00:38:51,760
Think about what's running in your environment right now.

936
00:38:51,760 --> 00:38:55,520
You've got Federation Service authenticating users to Microsoft 365

937
00:38:55,520 --> 00:38:58,360
using certificates for token signing and SAML assertions.

938
00:38:58,360 --> 00:38:59,960
Active Directory Certificate Services,

939
00:38:59,960 --> 00:39:01,720
issuing certificates for domain controllers,

940
00:39:01,720 --> 00:39:04,000
for VPN authentication, for document signing,

941
00:39:04,000 --> 00:39:06,920
for 802.1x network access.

942
00:39:06,920 --> 00:39:09,640
Each of these use cases with different key types,

943
00:39:09,640 --> 00:39:13,040
expiration policies and renewal workflows.

944
00:39:13,040 --> 00:39:15,880
Azure AD connects syncing identities between on-premises,

945
00:39:15,880 --> 00:39:18,920
Active Directory and Entra ID using TLS connections

946
00:39:18,920 --> 00:39:20,960
and potentially encrypted credential stores.

947
00:39:20,960 --> 00:39:25,000
Custom Power Automate Connectors calling external APIs over TLS

948
00:39:25,000 --> 00:39:28,400
where the TLS configuration lives in the connector definition

949
00:39:28,400 --> 00:39:32,160
and may not be auditable through your standard security tooling.

950
00:39:32,160 --> 00:39:34,760
Self-signed certificates on internal web applications

951
00:39:34,760 --> 00:39:36,240
that nobody's updated in three years

952
00:39:36,240 --> 00:39:38,200
because there's no certificate management process

953
00:39:38,200 --> 00:39:40,240
that covers internal only services.

954
00:39:40,240 --> 00:39:43,160
Hard-coded API keys in application configuration files

955
00:39:43,160 --> 00:39:46,800
stored in source control alongside the code with no rotation mechanism.

956
00:39:46,800 --> 00:39:48,920
Certificates baked into IoT firmware

957
00:39:48,920 --> 00:39:50,440
that can't be updated in the field

958
00:39:50,440 --> 00:39:54,320
because the device manufacturer never implemented a certificate renewal path.

959
00:39:54,320 --> 00:39:57,680
SSH keys on administrative jump boxes with no rotation policy

960
00:39:57,680 --> 00:39:59,720
because the operations team set them up five years ago

961
00:39:59,720 --> 00:40:01,200
and nobody's touched them since.

962
00:40:01,200 --> 00:40:02,800
And that's just what you know about.

963
00:40:02,800 --> 00:40:07,240
The ones you don't know about are the ones that will break the transition.

964
00:40:07,240 --> 00:40:10,080
Cryptographic dependencies buried in CI/CD pipelines

965
00:40:10,080 --> 00:40:12,480
in build scripts in deployment automation.

966
00:40:12,480 --> 00:40:15,760
Code signing certificates used in build processes that run on schedule

967
00:40:15,760 --> 00:40:18,120
and would fail silently if the signing key expired

968
00:40:18,120 --> 00:40:20,120
or the algorithm was deprecated.

969
00:40:20,120 --> 00:40:22,120
Certificates embedded in container images

970
00:40:22,120 --> 00:40:23,680
that get rebuilt from cashed layers

971
00:40:23,680 --> 00:40:25,560
so the certificate version in production

972
00:40:25,560 --> 00:40:27,520
doesn't match what's in the repository.

973
00:40:27,520 --> 00:40:30,440
TLS configurations in legacy on-premises applications

974
00:40:30,440 --> 00:40:33,440
that were set up by someone who left the company five years ago

975
00:40:33,440 --> 00:40:36,600
with no documentation and no change management record.

976
00:40:36,600 --> 00:40:39,080
VPN concentrators with hard-coded cipher suites

977
00:40:39,080 --> 00:40:41,120
that can't be upgraded without a hardware refresh

978
00:40:41,120 --> 00:40:43,440
because the vendor no longer supports the firmware.

979
00:40:43,440 --> 00:40:46,280
Third party SAS integrations that terminate TLS on their side

980
00:40:46,280 --> 00:40:48,720
where you have no visibility into which algorithms they use

981
00:40:48,720 --> 00:40:50,840
or whether they've started supporting PQC.

982
00:40:50,840 --> 00:40:53,760
Database connection strings with hard-coded TLS parameters

983
00:40:53,760 --> 00:40:57,080
in application config files that span hundreds of microservices.

984
00:40:57,080 --> 00:41:00,760
Couping a call and analyst firm focused on identity and security

985
00:41:00,760 --> 00:41:03,960
characterizes crypto agility as a missing operational discipline.

986
00:41:03,960 --> 00:41:06,120
Organizations have pockets of capability

987
00:41:06,120 --> 00:41:09,000
but lack end-to-end governance and operationalization.

988
00:41:09,000 --> 00:41:09,920
And the reason is simple.

989
00:41:09,920 --> 00:41:13,160
Without continuous discovery, crypto agility is a slogan.

990
00:41:13,160 --> 00:41:15,720
You can't be agile if you don't know where the crypto is.

991
00:41:15,720 --> 00:41:17,520
That's why the cryptographic bill of materials

992
00:41:17,520 --> 00:41:20,240
or C-borm is becoming a regulatory expectation

993
00:41:20,240 --> 00:41:21,760
rather than a nice to have.

994
00:41:21,760 --> 00:41:25,760
NIST's CSWP39, published in December 2025,

995
00:41:25,760 --> 00:41:29,040
explicitly frames crypto agility as part of broader risk management

996
00:41:29,040 --> 00:41:31,320
and cybersecurity governance and emphasizes

997
00:41:31,320 --> 00:41:34,760
C-borms as a tool for inventories and vendor risk management.

998
00:41:34,760 --> 00:41:37,680
The EU's in-ease guidance includes similar expectations

999
00:41:37,680 --> 00:41:40,400
and the regulatory trend across multiple jurisdictions

1000
00:41:40,400 --> 00:41:43,000
is moving toward requiring cryptographic inventories

1001
00:41:43,000 --> 00:41:45,400
as part of standard security governance.

1002
00:41:45,400 --> 00:41:47,240
The practical challenge with inventory

1003
00:41:47,240 --> 00:41:49,320
is that it's not a one-time exercise.

1004
00:41:49,320 --> 00:41:52,760
Cryptographic dependencies change every time a new application is deployed.

1005
00:41:52,760 --> 00:41:55,440
A certificate is renewed, a library is updated

1006
00:41:55,440 --> 00:41:57,320
or a configuration is modified.

1007
00:41:57,320 --> 00:42:00,000
A point in time inventory becomes stale within weeks.

1008
00:42:00,000 --> 00:42:01,920
That's why the emphasis across all the guidance

1009
00:42:01,920 --> 00:42:05,120
is on continuous discovery, not static documentation.

1010
00:42:05,120 --> 00:42:07,520
Continuous discovery means running scanning tools

1011
00:42:07,520 --> 00:42:10,480
on a regular cadence, integrating cryptographic findings

1012
00:42:10,480 --> 00:42:12,720
into your configuration management database

1013
00:42:12,720 --> 00:42:14,800
and flagging any changes that introduce new

1014
00:42:14,800 --> 00:42:17,040
or deprecated algorithm usage.

1015
00:42:17,040 --> 00:42:19,320
A C-borm is essentially a software bill of materials

1016
00:42:19,320 --> 00:42:21,880
but focused specifically on cryptographic components.

1017
00:42:21,880 --> 00:42:23,440
It tracks which algorithms are used,

1018
00:42:23,440 --> 00:42:25,640
where they're implemented, which libraries provide them,

1019
00:42:25,640 --> 00:42:27,160
what key sizes are in play,

1020
00:42:27,160 --> 00:42:30,160
whether those implementations are configurable or hard coded

1021
00:42:30,160 --> 00:42:33,520
and what the supply chain looks like for each component.

1022
00:42:33,520 --> 00:42:35,080
When an algorithm gets deprecated,

1023
00:42:35,080 --> 00:42:36,480
whether that's because of quantum risk

1024
00:42:36,480 --> 00:42:38,600
or a classical crypt analytic breakthrough,

1025
00:42:38,600 --> 00:42:42,160
the C-borm tells you exactly where the remediation work needs to happen.

1026
00:42:42,160 --> 00:42:44,560
Without it, you're doing the equivalent of vulnerability scanning

1027
00:42:44,560 --> 00:42:45,880
without an asset inventory.

1028
00:42:45,880 --> 00:42:47,800
You're guessing at the scope of the problem

1029
00:42:47,800 --> 00:42:50,080
and this connects directly back to the Isaka inequality

1030
00:42:50,080 --> 00:42:51,560
we talked about in the first section.

1031
00:42:51,560 --> 00:42:53,160
X plus Y greater than Z.

1032
00:42:53,160 --> 00:42:55,440
You can't estimate why the migration time

1033
00:42:55,440 --> 00:42:57,680
if you don't know the scope of what needs to be migrated.

1034
00:42:57,680 --> 00:43:00,360
You can't prioritize which assets to protect first

1035
00:43:00,360 --> 00:43:02,960
if you can't see which ones use vulnerable algorithms.

1036
00:43:02,960 --> 00:43:05,000
The inventory isn't just a governance checkbox.

1037
00:43:05,000 --> 00:43:08,200
It's the mathematical prerequisite for rational decision making.

1038
00:43:08,200 --> 00:43:10,080
For Microsoft's centric enterprises,

1039
00:43:10,080 --> 00:43:12,280
the hidden dependency problem has a specific shape

1040
00:43:12,280 --> 00:43:13,440
that's worth detailing.

1041
00:43:13,440 --> 00:43:15,440
Your M365 environment is managed,

1042
00:43:15,440 --> 00:43:17,840
so the TLS termination points and certificate chains

1043
00:43:17,840 --> 00:43:20,920
on Microsoft's side are largely Microsoft's responsibility.

1044
00:43:20,920 --> 00:43:22,880
But your hybrid infrastructure isn't.

1045
00:43:22,880 --> 00:43:24,640
Your on-premises active directory,

1046
00:43:24,640 --> 00:43:26,440
which still holds the primary identity store

1047
00:43:26,440 --> 00:43:29,240
for many organizations and uses Kerberos encryption

1048
00:43:29,240 --> 00:43:31,320
that depends on specific algorithm suites.

1049
00:43:31,320 --> 00:43:33,440
Your ADFS servers which sign SAML tokens

1050
00:43:33,440 --> 00:43:36,320
for Federation to M365 and other cloud services

1051
00:43:36,320 --> 00:43:38,840
with token signing certificates that may be RSA based

1052
00:43:38,840 --> 00:43:40,360
and not easily rotated.

1053
00:43:40,360 --> 00:43:43,480
Your custom applications calling M365 APIs

1054
00:43:43,480 --> 00:43:45,640
using the Microsoft Graph SDK,

1055
00:43:45,640 --> 00:43:47,560
where the TLS configuration may be buried

1056
00:43:47,560 --> 00:43:49,240
in the SDK's default settings

1057
00:43:49,240 --> 00:43:52,480
and may not be overridable without code changes.

1058
00:43:52,480 --> 00:43:55,280
Your network equipment, terminating VPN tunnels

1059
00:43:55,280 --> 00:43:58,240
that connect remote offices to your Azure Virtual Network,

1060
00:43:58,240 --> 00:44:01,760
where the VPN firmware may not support MLKam Cypher suites.

1061
00:44:01,760 --> 00:44:03,520
Your third party SaaS integrations,

1062
00:44:03,520 --> 00:44:05,560
where the authentication and data exchange parts

1063
00:44:05,560 --> 00:44:07,560
may use cryptography that you've never audited.

1064
00:44:07,560 --> 00:44:10,880
Your Power BI dashboards connecting to on-premises data gateways,

1065
00:44:10,880 --> 00:44:12,880
where the gateway certificate may be self-signed

1066
00:44:12,880 --> 00:44:14,320
with no rotation policy.

1067
00:44:14,320 --> 00:44:16,840
Your Azure DevOps pipelines that sign build artifacts

1068
00:44:16,840 --> 00:44:19,640
using code signing certificates stored in Azure Key Vault,

1069
00:44:19,640 --> 00:44:21,000
where the key type determines

1070
00:44:21,000 --> 00:44:24,040
whether the signed artifact can use a post-quantum algorithm.

1071
00:44:24,040 --> 00:44:26,360
All of these contain cryptographic dependencies

1072
00:44:26,360 --> 00:44:28,200
that you own and that you need to discover

1073
00:44:28,200 --> 00:44:29,960
before you can plan the transition.

1074
00:44:29,960 --> 00:44:31,720
And the discovery process itself requires

1075
00:44:31,720 --> 00:44:33,720
specific tooling and methodology.

1076
00:44:33,720 --> 00:44:36,920
Network level scanning can identify TLS Cypher suites,

1077
00:44:36,920 --> 00:44:38,960
certificate chains and protocol versions

1078
00:44:38,960 --> 00:44:41,240
across your external and internal endpoints.

1079
00:44:41,240 --> 00:44:43,280
Certificate management platforms can inventory

1080
00:44:43,280 --> 00:44:45,160
every certificate across your PKI,

1081
00:44:45,160 --> 00:44:48,200
flagging expiration dates, key types, and issuing CAs.

1082
00:44:48,200 --> 00:44:49,880
Application security testing tools

1083
00:44:49,880 --> 00:44:52,320
can identify hard-coded cryptographic parameters

1084
00:44:52,320 --> 00:44:54,480
in source code and configuration files.

1085
00:44:54,480 --> 00:44:56,200
But these tools need to work together

1086
00:44:56,200 --> 00:44:58,920
because no single tool covers all three dimensions,

1087
00:44:58,920 --> 00:45:02,160
the network layer, the certificate layer, and the code layer.

1088
00:45:02,160 --> 00:45:04,520
The CBOM is the integration point

1089
00:45:04,520 --> 00:45:06,880
that connects the findings from all of these sources

1090
00:45:06,880 --> 00:45:09,200
into a single view of your cryptographic posture.

1091
00:45:09,200 --> 00:45:11,020
One pattern that works well for Microsoft's

1092
00:45:11,020 --> 00:45:13,480
centric organizations is to start the inventory

1093
00:45:13,480 --> 00:45:14,960
at the edges and work inward.

1094
00:45:14,960 --> 00:45:17,080
Begin with your internet facing endpoints

1095
00:45:17,080 --> 00:45:18,480
because those are the most exposed

1096
00:45:18,480 --> 00:45:20,240
and typically the easiest to scan.

1097
00:45:20,240 --> 00:45:21,880
Then move to your internal network segments

1098
00:45:21,880 --> 00:45:24,600
using passive monitoring of TLS negotiations

1099
00:45:24,600 --> 00:45:26,880
to identify Cypher suites and certificate chains

1100
00:45:26,880 --> 00:45:28,760
without disrupting traffic.

1101
00:45:28,760 --> 00:45:31,240
Then tackle the application layer using source code scanning

1102
00:45:31,240 --> 00:45:33,280
and configuration auditing to find hard-coded

1103
00:45:33,280 --> 00:45:34,800
cryptographic parameters.

1104
00:45:34,800 --> 00:45:36,280
This outside-in-approach gives you

1105
00:45:36,280 --> 00:45:38,040
the highest impact findings first,

1106
00:45:38,040 --> 00:45:41,040
while building the methodology for the harder inner layers.

1107
00:45:41,040 --> 00:45:42,800
So you can't fix what you can't see.

1108
00:45:42,800 --> 00:45:44,440
And even if you could see everything,

1109
00:45:44,440 --> 00:45:46,920
your infrastructure probably isn't built to change,

1110
00:45:46,920 --> 00:45:50,360
which is exactly what cryptographic agility is designed to fix.

1111
00:45:50,360 --> 00:45:54,240
The agility architecture, and that's the real problem,

1112
00:45:54,240 --> 00:45:56,600
not the quantum computer, not the bandwidth overhead,

1113
00:45:56,600 --> 00:45:57,560
the rigidity.

1114
00:45:57,560 --> 00:45:59,080
Your infrastructure is hard-coded

1115
00:45:59,080 --> 00:46:00,840
to use specific algorithms.

1116
00:46:00,840 --> 00:46:03,480
Application specify RSA or ECC directly

1117
00:46:03,480 --> 00:46:04,720
in their configuration.

1118
00:46:04,720 --> 00:46:06,960
Libraries pin specific Cypher suites.

1119
00:46:06,960 --> 00:46:09,400
Certificates are issued with specific key types

1120
00:46:09,400 --> 00:46:11,960
and can't be re-issued without manual intervention.

1121
00:46:11,960 --> 00:46:14,840
HSMs are programmed with specific algorithm support

1122
00:46:14,840 --> 00:46:17,200
that requires firmware updates to change.

1123
00:46:17,200 --> 00:46:19,720
And the entire PKI from root certificates down

1124
00:46:19,720 --> 00:46:22,040
to leaf certificates is built on the assumption

1125
00:46:22,040 --> 00:46:24,680
that the algorithms in use today will remain in use

1126
00:46:24,680 --> 00:46:26,880
for the lifetime of the certificate chain.

1127
00:46:26,880 --> 00:46:28,720
When NIST standardizes a new algorithm

1128
00:46:28,720 --> 00:46:30,960
or when an existing algorithm gets deprecated,

1129
00:46:30,960 --> 00:46:32,880
every one of those hard-coded dependencies

1130
00:46:32,880 --> 00:46:34,240
needs to be updated.

1131
00:46:34,240 --> 00:46:36,600
And in most enterprises, that update process

1132
00:46:36,600 --> 00:46:39,240
is manual, slow, error-prone

1133
00:46:39,240 --> 00:46:41,080
and runs across organizational boundaries

1134
00:46:41,080 --> 00:46:42,560
that don't coordinate well.

1135
00:46:42,560 --> 00:46:44,440
Cryptographic agility is the structural fix

1136
00:46:44,440 --> 00:46:45,320
for this problem.

1137
00:46:45,320 --> 00:46:48,360
And it's not a one-time migration to post-quantum algorithms.

1138
00:46:48,360 --> 00:46:50,480
It's a permanent operational discipline.

1139
00:46:50,480 --> 00:46:53,800
NIST's CSWP39 defines cryptoagility

1140
00:46:53,800 --> 00:46:55,800
as the organizational, architectural,

1141
00:46:55,800 --> 00:46:58,600
and operational capability to discover, replace,

1142
00:46:58,600 --> 00:47:01,200
and evolve cryptography across complex systems

1143
00:47:01,200 --> 00:47:04,120
without destabilizing critical services.

1144
00:47:04,120 --> 00:47:05,920
Couping a call defines it as the ability

1145
00:47:05,920 --> 00:47:08,680
to replace or adapt cryptographic infrastructure

1146
00:47:08,680 --> 00:47:10,680
without disrupting operations or security,

1147
00:47:10,680 --> 00:47:13,880
treating crypto as a modular, manageable system property

1148
00:47:13,880 --> 00:47:15,720
rather than hard-wired code.

1149
00:47:15,720 --> 00:47:17,880
Both definitions converge on the same point.

1150
00:47:17,880 --> 00:47:20,120
Cryptoagility means you can change the cryptography

1151
00:47:20,120 --> 00:47:21,600
without breaking the system.

1152
00:47:21,600 --> 00:47:23,280
And that capability has to persist

1153
00:47:23,280 --> 00:47:25,280
after the quantum transition is complete

1154
00:47:25,280 --> 00:47:27,560
because there will be another algorithm deprecation,

1155
00:47:27,560 --> 00:47:30,400
another crypt analytic result, another compliance mandate.

1156
00:47:30,400 --> 00:47:31,920
The question isn't whether your cryptography

1157
00:47:31,920 --> 00:47:33,400
will need to change again.

1158
00:47:33,400 --> 00:47:35,240
The question is whether your infrastructure

1159
00:47:35,240 --> 00:47:36,320
can handle it when it does.

1160
00:47:36,320 --> 00:47:37,920
So how do you build that capability?

1161
00:47:37,920 --> 00:47:39,400
There are four architectural pillars.

1162
00:47:39,400 --> 00:47:40,960
The first is modularity.

1163
00:47:40,960 --> 00:47:43,720
Algorithms must be separated from application logic.

1164
00:47:43,720 --> 00:47:45,720
Instead of an application implementing RSA

1165
00:47:45,720 --> 00:47:48,680
directly in its code base, it calls a cryptographic library,

1166
00:47:48,680 --> 00:47:52,120
a sidecar, or a gateway that provides the encryption service.

1167
00:47:52,120 --> 00:47:55,080
The application asks for a secure channel or assigned token

1168
00:47:55,080 --> 00:47:57,600
and the crypto layer decides which algorithm to use

1169
00:47:57,600 --> 00:47:58,720
based on policy.

1170
00:47:58,720 --> 00:48:00,400
When the algorithm needs to change,

1171
00:48:00,400 --> 00:48:03,120
you update the library or the policy, not the application.

1172
00:48:03,120 --> 00:48:04,480
Think about how this works in practice.

1173
00:48:04,480 --> 00:48:07,360
Today, an application that needs to make a TLS connection

1174
00:48:07,360 --> 00:48:09,200
might directly configure the cipher suite,

1175
00:48:09,200 --> 00:48:11,000
the key type, and the signature algorithm

1176
00:48:11,000 --> 00:48:12,720
in its code or configuration.

1177
00:48:12,720 --> 00:48:15,680
If RSA is deprecated, you have to find and update

1178
00:48:15,680 --> 00:48:17,760
every application that specifies RSA

1179
00:48:17,760 --> 00:48:19,320
across your entire code base.

1180
00:48:19,320 --> 00:48:21,240
In a modular architecture, the application

1181
00:48:21,240 --> 00:48:24,360
calls a TLS library and says, give me a secure connection.

1182
00:48:24,360 --> 00:48:26,240
The library's configuration managed centrally

1183
00:48:26,240 --> 00:48:28,720
through enterprise policy determines which cipher suite

1184
00:48:28,720 --> 00:48:30,000
and key type to use.

1185
00:48:30,000 --> 00:48:33,360
When the policy changes from RSA to MLCam,

1186
00:48:33,360 --> 00:48:35,560
you update the library configuration once

1187
00:48:35,560 --> 00:48:38,480
and every application that uses the library picks up the change.

1188
00:48:38,480 --> 00:48:40,640
The second is abstraction via APIs.

1189
00:48:40,640 --> 00:48:42,560
Applications request cryptographic services

1190
00:48:42,560 --> 00:48:45,520
through well-defined interfaces that hide algorithm details.

1191
00:48:45,520 --> 00:48:48,480
An internal API for key exchange returns a shared secret

1192
00:48:48,480 --> 00:48:50,480
without the caller knowing whether it was established

1193
00:48:50,480 --> 00:48:55,160
using X25519, MLCam, or a hybrid of both.

1194
00:48:55,160 --> 00:48:57,320
An internal API for signing accepts a message

1195
00:48:57,320 --> 00:48:59,920
and returns a signature without the caller specifying

1196
00:48:59,920 --> 00:49:02,440
whether MLDSA or RSA was used.

1197
00:49:02,440 --> 00:49:04,280
The algorithm choice is a policy decision,

1198
00:49:04,280 --> 00:49:05,680
not a code-level decision.

1199
00:49:05,680 --> 00:49:07,360
This is the same pattern that's already used

1200
00:49:07,360 --> 00:49:09,360
in well-architected identity systems.

1201
00:49:09,360 --> 00:49:12,280
When your application calls EntraID to get an access token,

1202
00:49:12,280 --> 00:49:15,320
it doesn't specify which signing algorithm should be used.

1203
00:49:15,320 --> 00:49:17,840
EntraID decides based on its own policy.

1204
00:49:17,840 --> 00:49:20,120
Your application just validates the token signature

1205
00:49:20,120 --> 00:49:22,480
using the public key from the open ID

1206
00:49:22,480 --> 00:49:24,400
connect discovery endpoint.

1207
00:49:24,400 --> 00:49:26,400
The open ID connect discovery endpoint,

1208
00:49:26,400 --> 00:49:29,240
which publishes the signing keys used by the identity provider

1209
00:49:29,240 --> 00:49:32,680
already supports key rotation through the jukes-urie endpoint.

1210
00:49:32,680 --> 00:49:35,560
This is the same mechanism that would enable a transparent transition

1211
00:49:35,560 --> 00:49:39,320
from RSA to MLDSA signatures on identity tokens

1212
00:49:39,320 --> 00:49:41,360
as long as the token validation libraries

1213
00:49:41,360 --> 00:49:43,880
support the new algorithm identifiers.

1214
00:49:43,880 --> 00:49:46,640
The same abstraction applies to every cryptographic operation

1215
00:49:46,640 --> 00:49:47,840
in your infrastructure.

1216
00:49:47,840 --> 00:49:50,000
The third is policy and mechanism separation.

1217
00:49:50,000 --> 00:49:52,200
The algorithms, key sizes and cipher suites

1218
00:49:52,200 --> 00:49:55,240
are defined in configuration files, management consoles,

1219
00:49:55,240 --> 00:49:57,560
or policy engines, not in application code.

1220
00:49:57,560 --> 00:50:00,400
When this publishes a new standard, you update the policy

1221
00:50:00,400 --> 00:50:02,440
and the crypto layer picks up the change.

1222
00:50:02,440 --> 00:50:05,800
When a vulnerability is discovered in a specific implementation,

1223
00:50:05,800 --> 00:50:09,200
you rotate to an alternative implementation of the same algorithm

1224
00:50:09,200 --> 00:50:10,800
without touching the application.

1225
00:50:10,800 --> 00:50:12,360
In a Microsoft centric environment,

1226
00:50:12,360 --> 00:50:14,160
this maps to familiar patterns.

1227
00:50:14,160 --> 00:50:16,560
Azure API management policies can control which

1228
00:50:16,560 --> 00:50:18,560
TLS cipher suites are accepted.

1229
00:50:18,560 --> 00:50:20,320
EntraID conditional access policies

1230
00:50:20,320 --> 00:50:22,160
can enforce authentication requirements

1231
00:50:22,160 --> 00:50:23,840
without changing application code.

1232
00:50:23,840 --> 00:50:25,840
Azure Key Vault access policies determine

1233
00:50:25,840 --> 00:50:28,200
which key types and operations are permitted.

1234
00:50:28,200 --> 00:50:30,560
These are all examples of policy and mechanism separation

1235
00:50:30,560 --> 00:50:32,320
applied to security decisions.

1236
00:50:32,320 --> 00:50:33,720
The same principle needs to be extended

1237
00:50:33,720 --> 00:50:36,360
to cryptographic algorithm selection at every layer.

1238
00:50:36,360 --> 00:50:38,080
The fourth is hybrid mechanisms.

1239
00:50:38,080 --> 00:50:39,480
During the transition period,

1240
00:50:39,480 --> 00:50:42,080
you combine classical and post-quantum algorithms

1241
00:50:42,080 --> 00:50:44,600
so that security holds if either one remains secure.

1242
00:50:44,600 --> 00:50:46,400
This is the bridge from the current state

1243
00:50:46,400 --> 00:50:48,120
to the post-quantum state,

1244
00:50:48,120 --> 00:50:50,960
and it's the approach that's already being deployed in production.

1245
00:50:50,960 --> 00:50:53,600
The specific hybrid mechanism that matters most right now

1246
00:50:53,600 --> 00:50:57,880
is called X25519MLKEM768.

1247
00:50:57,880 --> 00:51:01,200
It combines a classical X255-muntank key agreement

1248
00:51:01,200 --> 00:51:04,720
with an MLKEM768 key encapsulation.

1249
00:51:04,720 --> 00:51:06,280
Both contribute to the shared secret

1250
00:51:06,280 --> 00:51:08,160
through a key derivation function.

1251
00:51:08,160 --> 00:51:11,040
If X25519 is broken by a quantum computer,

1252
00:51:11,040 --> 00:51:13,720
MLKEM768 still protects the session.

1253
00:51:13,720 --> 00:51:16,480
If a future cryptanalytic result breaks MLKEM,

1254
00:51:16,480 --> 00:51:20,000
X25519 still protects the session against classical attacks.

1255
00:51:20,000 --> 00:51:22,000
You don't need to trust one algorithm entirely.

1256
00:51:22,000 --> 00:51:24,200
You get defense in depth at the key exchange layer,

1257
00:51:24,200 --> 00:51:26,920
and this hybrid approach is already live in the ecosystem.

1258
00:51:26,920 --> 00:51:29,520
OpenSL3.5 added support for MLKEM

1259
00:51:29,520 --> 00:51:32,160
and changed default TLS group preferences

1260
00:51:32,160 --> 00:51:34,520
to include hybrid PQC-cam groups,

1261
00:51:34,520 --> 00:51:38,200
meaning that any server running open SSL3.5 or later

1262
00:51:38,200 --> 00:51:39,880
can negotiate hybrid key exchange

1263
00:51:39,880 --> 00:51:41,520
without custom configuration.

1264
00:51:41,520 --> 00:51:43,880
Microsoft Edge removed the post-quantum key agreement

1265
00:51:43,880 --> 00:51:46,480
enabled policy starting with Edge 147

1266
00:51:46,480 --> 00:51:48,680
because post-quantum key agreement became enabled

1267
00:51:48,680 --> 00:51:50,840
by default and could no longer be disabled.

1268
00:51:50,840 --> 00:51:53,520
Chrome has the same hybrid key exchange default.

1269
00:51:53,520 --> 00:51:56,440
Firefox supports PQC through configuration flags.

1270
00:51:56,440 --> 00:51:59,480
Cloudflare and Akamai have deployed PQC TLS support

1271
00:51:59,480 --> 00:52:01,360
across their CDN edges, which means

1272
00:52:01,360 --> 00:52:02,960
that a large portion of internet traffic

1273
00:52:02,960 --> 00:52:05,240
is already being protected by hybrid key exchange,

1274
00:52:05,240 --> 00:52:07,200
whether the origin servers know it or not.

1275
00:52:07,200 --> 00:52:08,640
But hybrid isn't the end state.

1276
00:52:08,640 --> 00:52:09,480
It's the on-ramp.

1277
00:52:09,480 --> 00:52:12,680
Full post-quantum cryptography comes when the ecosystem is ready.

1278
00:52:12,680 --> 00:52:16,080
When certificate authorities can issue MLDSA certificates,

1279
00:52:16,080 --> 00:52:19,040
when HSMs can generate and store MLKEM keys,

1280
00:52:19,040 --> 00:52:21,160
when every client and server in your infrastructure

1281
00:52:21,160 --> 00:52:25,200
can negotiate a post-quantum cipher suite without fallback.

1282
00:52:25,200 --> 00:52:27,040
Agility means you can move from hybrid

1283
00:52:27,040 --> 00:52:30,080
to pure post-quantum without rebuilding the architecture.

1284
00:52:30,080 --> 00:52:32,440
The policy changes, the libraries update,

1285
00:52:32,440 --> 00:52:34,200
the infrastructure keeps running.

1286
00:52:34,200 --> 00:52:36,520
And the practical reality of hybrid key exchange

1287
00:52:36,520 --> 00:52:39,080
is worth understanding because it's not without cost.

1288
00:52:39,080 --> 00:52:41,920
Hybrid TLS hand shakes are larger than either pure classical

1289
00:52:41,920 --> 00:52:46,240
or pure PQC hand shakes because they carry both the X25519

1290
00:52:46,240 --> 00:52:48,600
and the MLKEM components.

1291
00:52:48,600 --> 00:52:50,320
The client hello message with a hybrid key share

1292
00:52:50,320 --> 00:52:53,800
is larger than a client hello with only X25519,

1293
00:52:53,800 --> 00:52:56,760
though smaller than a client hello with only MLKEM

1294
00:52:56,760 --> 00:52:58,360
plus a classical fallback.

1295
00:52:58,360 --> 00:53:01,400
The server response carries both the X25519 share

1296
00:53:01,400 --> 00:53:03,280
and the MLKEM cipher text.

1297
00:53:03,280 --> 00:53:06,560
The total hand shake communication is larger than either pure approach,

1298
00:53:06,560 --> 00:53:08,360
but you get the security benefit of both.

1299
00:53:08,360 --> 00:53:10,040
The additional hand shake size has been observed

1300
00:53:10,040 --> 00:53:11,760
to cause issues with older middle boxes

1301
00:53:11,760 --> 00:53:13,640
and some TLS inspection appliances

1302
00:53:13,640 --> 00:53:15,560
as we discussed in the performance section.

1303
00:53:15,560 --> 00:53:18,360
But the trade off is favorable for most organizations.

1304
00:53:18,360 --> 00:53:21,360
Slightly larger hand shakes in exchange for immediate protection

1305
00:53:21,360 --> 00:53:25,120
against harvest now decrypt later for the negotiated session.

1306
00:53:25,120 --> 00:53:26,720
The data in transit today is protected

1307
00:53:26,720 --> 00:53:28,560
even though the data that was captured yesterday

1308
00:53:28,560 --> 00:53:30,720
isn't and that's the structural shift that matters.

1309
00:53:30,720 --> 00:53:32,200
The current model is static.

1310
00:53:32,200 --> 00:53:35,040
You pick an algorithm, you hard-coded, and you hope it lasts.

1311
00:53:35,040 --> 00:53:36,600
The agile model is adaptable.

1312
00:53:36,600 --> 00:53:39,480
You define a policy, the crypto layer executes it,

1313
00:53:39,480 --> 00:53:41,720
and when the policy changes, the crypto layer

1314
00:53:41,720 --> 00:53:44,320
adapts without breaking the applications above it.

1315
00:53:44,320 --> 00:53:45,640
This is the same structural shift

1316
00:53:45,640 --> 00:53:48,480
that other parts of enterprise security have already gone through.

1317
00:53:48,480 --> 00:53:51,000
Identity used to be managed locally on each server

1318
00:53:51,000 --> 00:53:53,640
with local accounts and local password policies.

1319
00:53:53,640 --> 00:53:55,440
Then it moved to centralized directories

1320
00:53:55,440 --> 00:53:58,160
like Active Directory where policy was defined once

1321
00:53:58,160 --> 00:53:59,560
and propagated everywhere.

1322
00:53:59,560 --> 00:54:00,800
When the password policy changed,

1323
00:54:00,800 --> 00:54:02,520
you didn't update every server individually.

1324
00:54:02,520 --> 00:54:04,680
You updated the group policy and every server

1325
00:54:04,680 --> 00:54:06,000
picked up the change.

1326
00:54:06,000 --> 00:54:07,800
The same centralization needs to happen

1327
00:54:07,800 --> 00:54:09,800
for cryptographic algorithm selection.

1328
00:54:09,800 --> 00:54:11,320
And there's an organizational dimension

1329
00:54:11,320 --> 00:54:13,760
to this architectural shift that's easy to miss.

1330
00:54:13,760 --> 00:54:16,240
Modularity, abstraction, and policy separation

1331
00:54:16,240 --> 00:54:18,960
require coordination between the teams that build applications,

1332
00:54:18,960 --> 00:54:20,640
the teams that manage infrastructure,

1333
00:54:20,640 --> 00:54:22,680
and the teams that set security policy.

1334
00:54:22,680 --> 00:54:24,680
In most organizations, these teams

1335
00:54:24,680 --> 00:54:26,160
don't have a natural coordination point

1336
00:54:26,160 --> 00:54:27,400
for cryptographic decisions.

1337
00:54:27,400 --> 00:54:30,320
Application teams specify algorithms in their code.

1338
00:54:30,320 --> 00:54:32,080
Infrastructure teams configure TLS

1339
00:54:32,080 --> 00:54:33,760
on load balances and proxies.

1340
00:54:33,760 --> 00:54:35,800
Security teams set compliance requirements,

1341
00:54:35,800 --> 00:54:37,040
but nobody connects the three.

1342
00:54:37,040 --> 00:54:39,760
The result is a patchwork of cryptographic implementations

1343
00:54:39,760 --> 00:54:41,680
that nobody can change without breaking something.

1344
00:54:41,680 --> 00:54:44,160
The agility architecture creates that coordination point.

1345
00:54:44,160 --> 00:54:46,480
The crypto layer, whether it's a library, a sidecar,

1346
00:54:46,480 --> 00:54:48,480
or a gateway, becomes the single place

1347
00:54:48,480 --> 00:54:50,040
where policy meets implementation.

1348
00:54:50,040 --> 00:54:51,880
Security teams define the policy.

1349
00:54:51,880 --> 00:54:54,200
Infrastructure teams manage the crypto layer.

1350
00:54:54,200 --> 00:54:56,120
Application teams call the API.

1351
00:54:56,120 --> 00:54:57,920
And when the algorithm needs to change,

1352
00:54:57,920 --> 00:54:59,640
the change happens at the policy layer,

1353
00:54:59,640 --> 00:55:01,240
propagates through the crypto layer,

1354
00:55:01,240 --> 00:55:02,520
and reaches the application layer

1355
00:55:02,520 --> 00:55:04,520
without requiring any code changes.

1356
00:55:04,520 --> 00:55:06,880
The broader PQC migration program across industry

1357
00:55:06,880 --> 00:55:08,920
consistently follows a phased approach.

1358
00:55:08,920 --> 00:55:12,400
Phase one is hybrid key exchange for confidentiality

1359
00:55:12,400 --> 00:55:14,080
in live network protocols.

1360
00:55:14,080 --> 00:55:16,120
This is where you get immediate protection for data

1361
00:55:16,120 --> 00:55:18,680
and transit without waiting for every endpoint

1362
00:55:18,680 --> 00:55:20,800
and certificate chain to be upgraded.

1363
00:55:20,800 --> 00:55:23,160
Phase two is migration of certificates, signatures,

1364
00:55:23,160 --> 00:55:26,080
and PKI to post quantum or composite approaches.

1365
00:55:26,080 --> 00:55:29,440
This is the harder part because PKI changes affect issuance,

1366
00:55:29,440 --> 00:55:31,480
validation, revocation, device enrollment,

1367
00:55:31,480 --> 00:55:34,400
and trust distribution across many systems.

1368
00:55:34,400 --> 00:55:37,640
Phase three is full retirement of legacy RSA and ECC,

1369
00:55:37,640 --> 00:55:39,560
where ecosystem support allows it.

1370
00:55:39,560 --> 00:55:42,200
This sequencing appears across major migration frameworks

1371
00:55:42,200 --> 00:55:44,000
because signatures and certificates

1372
00:55:44,000 --> 00:55:47,040
tend to be more operationally complex than key exchange,

1373
00:55:47,040 --> 00:55:50,280
especially in enterprise PKI, device identity,

1374
00:55:50,280 --> 00:55:51,880
and trust anchor management.

1375
00:55:51,880 --> 00:55:54,080
One reason phase two is harder than phase one

1376
00:55:54,080 --> 00:55:55,560
is that certificate infrastructure

1377
00:55:55,560 --> 00:55:58,000
has a longer dependency chain than key exchange.

1378
00:55:58,000 --> 00:55:59,880
When you upgrade a TLS termination point

1379
00:55:59,880 --> 00:56:01,600
to support hybrid key exchange,

1380
00:56:01,600 --> 00:56:03,720
you're changing the configuration of a single component.

1381
00:56:03,720 --> 00:56:05,720
When you migrate your PKI to MLDSA,

1382
00:56:05,720 --> 00:56:07,640
you're changing the trust anchor for every system

1383
00:56:07,640 --> 00:56:09,800
that relies on certificates issued by that PKI.

1384
00:56:09,800 --> 00:56:11,720
You need to update the root CA key,

1385
00:56:11,720 --> 00:56:13,640
reissue intermediate CA certificates,

1386
00:56:13,640 --> 00:56:15,480
reissue end entity certificates,

1387
00:56:15,480 --> 00:56:17,840
update trust stores on every client device,

1388
00:56:17,840 --> 00:56:20,000
update revocation checking mechanisms,

1389
00:56:20,000 --> 00:56:22,160
and validate that every application in the chain

1390
00:56:22,160 --> 00:56:24,240
can handle the larger certificate sizes

1391
00:56:24,240 --> 00:56:26,320
and different signature algorithms.

1392
00:56:26,320 --> 00:56:27,480
This is a multi-year program

1393
00:56:27,480 --> 00:56:29,200
even in a well-managed environment,

1394
00:56:29,200 --> 00:56:31,800
and it's why the phased approach starts with key exchange

1395
00:56:31,800 --> 00:56:34,960
and defers the PKI work until the ecosystem is more mature.

1396
00:56:34,960 --> 00:56:37,200
The PKI migration also requires coordination

1397
00:56:37,200 --> 00:56:38,920
with external certificate authorities,

1398
00:56:38,920 --> 00:56:41,040
whose timelines may not align with yours.

1399
00:56:41,040 --> 00:56:42,880
If your internal CA supports MLDSA,

1400
00:56:42,880 --> 00:56:44,480
but your external CA doesn't,

1401
00:56:44,480 --> 00:56:46,560
you face a split PKI where internal certificates

1402
00:56:46,560 --> 00:56:49,640
are post-quantum and external certificates are still classical.

1403
00:56:49,640 --> 00:56:52,120
Managing that split state adds operational complexity

1404
00:56:52,120 --> 00:56:54,240
until the external CA's catch up.

1405
00:56:54,240 --> 00:56:57,200
Another reason is that certificate validity periods create a leg.

1406
00:56:57,200 --> 00:57:00,160
If you issue a three-year certificate today using RSA,

1407
00:57:00,160 --> 00:57:02,840
that certificate will still be in circulation in 2029,

1408
00:57:02,840 --> 00:57:05,880
even if you start deploying MLDSA certificates next year.

1409
00:57:05,880 --> 00:57:09,160
The coexistence period where RSA and MLDSA certificates

1410
00:57:09,160 --> 00:57:11,880
are both in use requires hybrid certificate chains

1411
00:57:11,880 --> 00:57:13,360
or dual signing approaches,

1412
00:57:13,360 --> 00:57:15,520
both of which add complexity and size

1413
00:57:15,520 --> 00:57:17,480
to the certificate infrastructure.

1414
00:57:17,480 --> 00:57:20,160
The deployment pattern that enterprises are following right now

1415
00:57:20,160 --> 00:57:21,280
is consistent.

1416
00:57:21,280 --> 00:57:24,080
Start with internet-facing TLS termination points,

1417
00:57:24,080 --> 00:57:27,280
CDN edges, load balances, ingress controllers,

1418
00:57:27,280 --> 00:57:30,000
API gateways, because these are the most exposed

1419
00:57:30,000 --> 00:57:32,800
to passive traffic collection and the easiest to update

1420
00:57:32,800 --> 00:57:35,280
since they're typically under centralized control.

1421
00:57:35,280 --> 00:57:38,560
Then move to operational access channels like SSH and VPN,

1422
00:57:38,560 --> 00:57:40,400
which protect privileged administration

1423
00:57:40,400 --> 00:57:42,000
and long-lived sessions.

1424
00:57:42,000 --> 00:57:43,600
Then tackle PKI and signatures,

1425
00:57:43,600 --> 00:57:45,400
which are the most operationally complex,

1426
00:57:45,400 --> 00:57:48,480
but also the highest payoff for identity protection.

1427
00:57:48,480 --> 00:57:50,160
And there's a pattern that's worth highlighting

1428
00:57:50,160 --> 00:57:51,000
for this audience.

1429
00:57:51,000 --> 00:57:53,320
In many cases, the first phase of PQC deployment,

1430
00:57:53,320 --> 00:57:55,240
hybrid TLS, is already happening

1431
00:57:55,240 --> 00:57:57,160
without the enterprise doing anything.

1432
00:57:57,160 --> 00:57:59,280
When a user connects to Microsoft 365

1433
00:57:59,280 --> 00:58:03,040
through a browser that supports X25519 MLKM78

1434
00:58:03,040 --> 00:58:06,080
and Azure's TLS infrastructure supports the same hybrid group,

1435
00:58:06,080 --> 00:58:09,000
the connection automatically uses post-quantum key exchange.

1436
00:58:09,000 --> 00:58:10,520
The enterprise didn't configure this.

1437
00:58:10,520 --> 00:58:12,960
The browser and the cloud service coordinated on the upgrade.

1438
00:58:12,960 --> 00:58:16,040
This is the standard-sled vendor default rollout approach

1439
00:58:16,040 --> 00:58:17,920
and it means that a portion of your infrastructure

1440
00:58:17,920 --> 00:58:19,200
is already post-quantum ready

1441
00:58:19,200 --> 00:58:20,480
without any action on your part,

1442
00:58:20,480 --> 00:58:22,920
but that doesn't mean you can skip the architecture work.

1443
00:58:22,920 --> 00:58:25,440
The vendor default rollout covers the paths

1444
00:58:25,440 --> 00:58:27,400
where both ends are modern and cloud-managed.

1445
00:58:27,400 --> 00:58:30,280
It doesn't cover the paths where one end is on premises

1446
00:58:30,280 --> 00:58:32,600
or where the TLS configuration is managed locally

1447
00:58:32,600 --> 00:58:35,680
or where a middle box strips the PQC cipher suite.

1448
00:58:35,680 --> 00:58:37,680
And it definitely doesn't cover the certificate

1449
00:58:37,680 --> 00:58:40,120
and signature migration that comes in phase two.

1450
00:58:40,120 --> 00:58:41,720
For that, you need the architectural agility

1451
00:58:41,720 --> 00:58:43,760
to change algorithms in your own infrastructure

1452
00:58:43,760 --> 00:58:45,720
and that requires the modularity abstraction

1453
00:58:45,720 --> 00:58:47,960
and policy separation we've been talking about.

1454
00:58:47,960 --> 00:58:51,040
The practical question for most organizations is where to start

1455
00:58:51,040 --> 00:58:53,480
and the answer is the same as the deployment pattern.

1456
00:58:53,480 --> 00:58:55,280
Start where the exposure is highest

1457
00:58:55,280 --> 00:58:56,800
and the control is tightest.

1458
00:58:56,800 --> 00:58:58,760
External TLS termination points first,

1459
00:58:58,760 --> 00:59:01,200
then SSH and VPN, then PKI and signatures

1460
00:59:01,200 --> 00:59:03,640
and at each step build the architectural patterns

1461
00:59:03,640 --> 00:59:05,200
that make the next step easier.

1462
00:59:05,200 --> 00:59:07,760
Modularity in phase one makes phase two faster.

1463
00:59:07,760 --> 00:59:10,640
Abstraction in phase two makes phase three manageable.

1464
00:59:10,640 --> 00:59:13,800
Policy separation throughout makes every phase configurable

1465
00:59:13,800 --> 00:59:15,600
rather than requiring code changes.

1466
00:59:15,600 --> 00:59:17,880
Now architecture is only part of the equation.

1467
00:59:17,880 --> 00:59:19,760
The keys themselves need to evolve too.

1468
00:59:19,760 --> 00:59:22,440
HSMs and key management for the quantum era.

1469
00:59:22,440 --> 00:59:24,720
Hardware security modules have been the trust anchors

1470
00:59:24,720 --> 00:59:27,160
of enterprise cryptography for years.

1471
00:59:27,160 --> 00:59:29,640
They store private keys, perform cryptographic operations

1472
00:59:29,640 --> 00:59:31,200
in temper-resistant hardware

1473
00:59:31,200 --> 00:59:33,640
and provide the root of trust for certificate issuance

1474
00:59:33,640 --> 00:59:34,680
and code signing.

1475
00:59:34,680 --> 00:59:36,160
And for the post-quantum transition,

1476
00:59:36,160 --> 00:59:37,440
they need to change fundamentally.

1477
00:59:37,440 --> 00:59:40,920
The current generation of HSMs was designed around RSA and ECC.

1478
00:59:40,920 --> 00:59:42,800
The firmware supports specific key types

1479
00:59:42,800 --> 00:59:44,040
and algorithm operations

1480
00:59:44,040 --> 00:59:46,680
and adding support for MLK or MLDSA

1481
00:59:46,680 --> 00:59:49,480
requires firmware updates or hardware replacements.

1482
00:59:49,480 --> 00:59:52,160
This matters because HSMs are deployed at the root of trust

1483
00:59:52,160 --> 00:59:54,120
and upgrading them touches every system

1484
00:59:54,120 --> 00:59:55,120
that depends on that root.

1485
00:59:55,120 --> 00:59:58,080
If your code signing HSM doesn't support MLDSA,

1486
00:59:58,080 --> 01:00:00,880
you can't sign software updates with a post-quantum algorithm

1487
01:00:00,880 --> 01:00:03,440
and every downstream system that verifies those signatures

1488
01:00:03,440 --> 01:00:07,200
is stuck on RSA or ECC until the HSM is updated.

1489
01:00:07,200 --> 01:00:09,520
The industry is responding and HSMs are evolving

1490
01:00:09,520 --> 01:00:11,680
from static vaults to what some vendors call

1491
01:00:11,680 --> 01:00:13,360
crypto agile trust anchors.

1492
01:00:13,360 --> 01:00:15,640
Devices that support hybrid key exchanges,

1493
01:00:15,640 --> 01:00:17,200
multiple algorithm families

1494
01:00:17,200 --> 01:00:19,520
and firmware updateable algorithm support.

1495
01:00:19,520 --> 01:00:22,000
This evolution matters because the alternative is replacing

1496
01:00:22,000 --> 01:00:25,960
your entire HSM fleet every time NIST standardizes a new algorithm,

1497
01:00:25,960 --> 01:00:28,240
which is neither practical nor sustainable.

1498
01:00:28,240 --> 01:00:29,800
Given that NIST has already signaled,

1499
01:00:29,800 --> 01:00:32,480
it will continue developing additional PQC standards

1500
01:00:32,480 --> 01:00:34,560
beyond the initial four.

1501
01:00:34,560 --> 01:00:36,240
The crypto agile HSM model means

1502
01:00:36,240 --> 01:00:38,280
that when NIST finalizes FNDSA

1503
01:00:38,280 --> 01:00:40,120
or standardizes additional algorithms,

1504
01:00:40,120 --> 01:00:42,240
you can add support through firmware updates

1505
01:00:42,240 --> 01:00:44,400
rather than hardware procurement cycles.

1506
01:00:44,400 --> 01:00:47,560
The key management implications of post-quantum cryptography

1507
01:00:47,560 --> 01:00:50,160
go beyond just supporting new key types.

1508
01:00:50,160 --> 01:00:52,560
MLK and MLDSA keys require higher entropy

1509
01:00:52,560 --> 01:00:53,920
than their classical counterparts

1510
01:00:53,920 --> 01:00:55,680
at equivalent security levels

1511
01:00:55,680 --> 01:00:58,840
and the key generation process needs to account for that.

1512
01:00:58,840 --> 01:01:00,640
The larger key and signature sizes

1513
01:01:00,640 --> 01:01:02,840
mean that HSMs need more storage capacity

1514
01:01:02,840 --> 01:01:04,880
per key object and the operations

1515
01:01:04,880 --> 01:01:07,560
that process these larger objects need more memory

1516
01:01:07,560 --> 01:01:10,280
and bandwidth within the HSM boundary.

1517
01:01:10,280 --> 01:01:12,720
Existing RSA and ECC hardware accelerators

1518
01:01:12,720 --> 01:01:14,680
can't be reused for lattice operations,

1519
01:01:14,680 --> 01:01:17,080
requiring new hardware designs and standards.

1520
01:01:17,080 --> 01:01:18,520
For Microsoft's centric enterprises,

1521
01:01:18,520 --> 01:01:20,640
the practical path runs through as your key vault

1522
01:01:20,640 --> 01:01:22,560
and as your managed HSM.

1523
01:01:22,560 --> 01:01:26,520
The current PQC support status includes MLK and MLDSA key types

1524
01:01:26,520 --> 01:01:29,080
in preview with key rotation automation for both.

1525
01:01:29,080 --> 01:01:30,680
The key rotation capability matters

1526
01:01:30,680 --> 01:01:32,160
more than most organizations realize

1527
01:01:32,160 --> 01:01:34,920
because post-quantum key management demands shorter lift

1528
01:01:34,920 --> 01:01:36,560
keys and more frequent rotation

1529
01:01:36,560 --> 01:01:39,080
than the current RSA and ECC practice

1530
01:01:39,080 --> 01:01:41,440
of multi-year certificate lifetimes.

1531
01:01:41,440 --> 01:01:42,640
The reason is structural.

1532
01:01:42,640 --> 01:01:46,240
Classical keys like RSA 2.28 can be used for years

1533
01:01:46,240 --> 01:01:49,280
without significant risk of compromise through crypt analysis

1534
01:01:49,280 --> 01:01:51,120
because the best known attacks still require

1535
01:01:51,120 --> 01:01:53,360
astronomical amounts of compute.

1536
01:01:53,360 --> 01:01:55,080
Post-quantum algorithms are newer

1537
01:01:55,080 --> 01:01:56,760
with less crypt analytic history

1538
01:01:56,760 --> 01:01:58,280
and the risk of a future breakthrough

1539
01:01:58,280 --> 01:02:00,960
that reduces their security margin is non-trivial.

1540
01:02:00,960 --> 01:02:03,960
shorter key lifetimes mean that if a vulnerability is discovered,

1541
01:02:03,960 --> 01:02:05,560
the exposure window is smaller.

1542
01:02:05,560 --> 01:02:07,600
Automated rotation through Azure Key Vault

1543
01:02:07,600 --> 01:02:11,240
means that key replacement doesn't require manual intervention

1544
01:02:11,240 --> 01:02:13,000
and the application using the key

1545
01:02:13,000 --> 01:02:14,680
doesn't need to be reconfigured.

1546
01:02:14,680 --> 01:02:16,440
The operational principle is straightforward.

1547
01:02:16,440 --> 01:02:18,800
De-couple key lifetime from certificate lifetime

1548
01:02:18,800 --> 01:02:21,240
so that a key rotation doesn't require a full certificate

1549
01:02:21,240 --> 01:02:22,800
reissuance and a certificate renewal

1550
01:02:22,800 --> 01:02:24,760
doesn't require a key rotation.

1551
01:02:24,760 --> 01:02:26,640
Automated rotation so that key replacement

1552
01:02:26,640 --> 01:02:28,400
doesn't require manual intervention

1553
01:02:28,400 --> 01:02:29,960
reducing the risk of human error

1554
01:02:29,960 --> 01:02:32,400
and ensuring that rotation happens on schedule

1555
01:02:32,400 --> 01:02:35,280
even when the responsible person is unavailable.

1556
01:02:35,280 --> 01:02:37,200
And ensure that the key management infrastructure

1557
01:02:37,200 --> 01:02:39,320
can support algorithm changes without requiring

1558
01:02:39,320 --> 01:02:41,920
a full reissuance of every certificate in the chain,

1559
01:02:41,920 --> 01:02:44,960
which means designing your PKI so that changing a key type

1560
01:02:44,960 --> 01:02:47,280
in key vault doesn't cascade into a rebuild

1561
01:02:47,280 --> 01:02:50,520
of every certificate that depends on that key.

1562
01:02:50,520 --> 01:02:52,560
Azure Key Vaults manage key generation

1563
01:02:52,560 --> 01:02:56,120
handles the entropy requirements for MLKM and MLDSA automatically,

1564
01:02:56,120 --> 01:02:58,360
but organizations running their own HSMs

1565
01:02:58,360 --> 01:03:00,600
need to verify that their entropy sources

1566
01:03:00,600 --> 01:03:03,440
and key generation procedures meet the requirements

1567
01:03:03,440 --> 01:03:05,320
for post-quantum key pairs.

1568
01:03:05,320 --> 01:03:08,840
But the NIST standards specify minimum entropy thresholds

1569
01:03:08,840 --> 01:03:11,160
and some older HSM models may not meet them

1570
01:03:11,160 --> 01:03:12,760
without firmware updates.

1571
01:03:12,760 --> 01:03:14,960
So the architecture is modular and the keys are agile

1572
01:03:14,960 --> 01:03:17,080
but who decides what gets changed and when.

1573
01:03:17,080 --> 01:03:18,920
And there's a deeper point about HSMs

1574
01:03:18,920 --> 01:03:21,760
and key management that ties back to the governance theme.

1575
01:03:21,760 --> 01:03:23,920
When you rotate a key in Azure Key Vault,

1576
01:03:23,920 --> 01:03:26,120
there should be a policy that triggers the rotation,

1577
01:03:26,120 --> 01:03:28,080
a process that validates the new key works

1578
01:03:28,080 --> 01:03:30,440
across all dependent systems and a rollback plan

1579
01:03:30,440 --> 01:03:31,560
in case it doesn't.

1580
01:03:31,560 --> 01:03:33,280
The key rotation itself is automated

1581
01:03:33,280 --> 01:03:35,520
but the governance around it, the decision to rotate

1582
01:03:35,520 --> 01:03:38,080
the validation of the result and the accountability

1583
01:03:38,080 --> 01:03:40,640
for any failures, that's organizational discipline,

1584
01:03:40,640 --> 01:03:41,840
not technology.

1585
01:03:41,840 --> 01:03:44,000
The HSM or Key Vault provides the mechanism.

1586
01:03:44,000 --> 01:03:46,760
The governance playbook provides the decision-making structure.

1587
01:03:46,760 --> 01:03:47,920
Both are necessary.

1588
01:03:47,920 --> 01:03:49,520
The Microsoft stack right now,

1589
01:03:49,520 --> 01:03:52,080
this is where the conversation shifts from theory to practice

1590
01:03:52,080 --> 01:03:53,560
because for this audience,

1591
01:03:53,560 --> 01:03:55,800
the transition will largely be mediated through

1592
01:03:55,800 --> 01:03:57,640
what Microsoft actually ships.

1593
01:03:57,640 --> 01:03:59,640
And in 2026, there's more available

1594
01:03:59,640 --> 01:04:01,000
than most people realize.

1595
01:04:01,000 --> 01:04:03,680
Let's start with what's already live and generally available.

1596
01:04:03,680 --> 01:04:06,000
Microsoft announced general availability of post-quantum

1597
01:04:06,000 --> 01:04:09,400
cryptography APIs on Windows and PassNet in late 2025.

1598
01:04:09,400 --> 01:04:11,120
The SIM-crypt cryptographic library,

1599
01:04:11,120 --> 01:04:13,400
which underpins Windows and Azure's crypto operations,

1600
01:04:13,400 --> 01:04:15,400
now supports MLKM and MLDSA.

1601
01:04:15,400 --> 01:04:17,400
Developers can build quantum safe applications

1602
01:04:17,400 --> 01:04:19,600
on the Microsoft stack today using the same APIs

1603
01:04:19,600 --> 01:04:21,840
they already use for cryptographic operations.

1604
01:04:21,840 --> 01:04:24,440
The SIM-crypt implementation passed NIST validation

1605
01:04:24,440 --> 01:04:27,800
and it's available in Windows 11, Windows Server 2025

1606
01:04:27,800 --> 01:04:29,440
and the Bonnet 9 runtime.

1607
01:04:29,440 --> 01:04:31,120
This means that any application running

1608
01:04:31,120 --> 01:04:33,560
on a current Windows platform can invoke MLKM

1609
01:04:33,560 --> 01:04:35,960
for key exchange or MLDSA for signing

1610
01:04:35,960 --> 01:04:38,680
without installing additional libraries or SDKs.

1611
01:04:38,680 --> 01:04:42,200
And in May 2026, Microsoft Active Directory Certificate Services

1612
01:04:42,200 --> 01:04:44,040
added MLDSA support.

1613
01:04:44,040 --> 01:04:46,360
This is a significant milestone because ADCS

1614
01:04:46,360 --> 01:04:49,520
is the backbone of enterprise PKI in Windows environments.

1615
01:04:49,520 --> 01:04:52,000
Organizations can now issue post-quantum certificates

1616
01:04:52,000 --> 01:04:54,440
from their on-premises PKI without waiting

1617
01:04:54,440 --> 01:04:57,400
for third party certificate authorities to support MLDSA.

1618
01:04:57,400 --> 01:05:00,000
The certificate templates support MLDSA key pairs

1619
01:05:00,000 --> 01:05:03,120
and the enrollment process works through the same ADCS workflows

1620
01:05:03,120 --> 01:05:04,840
that administrators already use.

1621
01:05:04,840 --> 01:05:07,360
This means you can start deploying MLDSA certificates

1622
01:05:07,360 --> 01:05:10,760
for internal use cases like document signing, code signing

1623
01:05:10,760 --> 01:05:13,560
and 802.1x network authentication

1624
01:05:13,560 --> 01:05:16,720
without any dependency on external CA timelines.

1625
01:05:16,720 --> 01:05:19,920
The ADCS MLDSA support includes enrollment,

1626
01:05:19,920 --> 01:05:21,720
via certificate auto-enrollment,

1627
01:05:21,720 --> 01:05:23,720
certificate enrollment web services

1628
01:05:23,720 --> 01:05:26,840
and the standard MMC certificate templates interface.

1629
01:05:26,840 --> 01:05:30,000
CRL Partitioning, which was added in late 2025,

1630
01:05:30,000 --> 01:05:31,760
helps manage the larger CRL sizes

1631
01:05:31,760 --> 01:05:34,120
that result from MLDSA certificates.

1632
01:05:34,120 --> 01:05:36,840
This is particularly important because MLDSA certificates

1633
01:05:36,840 --> 01:05:39,080
are larger than RSA certificates,

1634
01:05:39,080 --> 01:05:40,880
which means the certificate revocation lists

1635
01:05:40,880 --> 01:05:43,080
that aggregate them are also larger.

1636
01:05:43,080 --> 01:05:47,200
And CRL Partitioning allows ADCS to serve partition CRLs

1637
01:05:47,200 --> 01:05:49,120
that reduce the download size for clients

1638
01:05:49,120 --> 01:05:51,120
checking revocation status.

1639
01:05:51,120 --> 01:05:53,320
On the browser side, the news is even more concrete.

1640
01:05:53,320 --> 01:05:55,720
Microsoft Edge removed the post-quantum key agreement

1641
01:05:55,720 --> 01:05:59,160
enabled policy in Edge 147 because post-quantum key exchange

1642
01:05:59,160 --> 01:06:00,640
became enabled by default.

1643
01:06:00,640 --> 01:06:03,000
Chrome has the same default when you connect to a website

1644
01:06:03,000 --> 01:06:07,560
that supports X25519MLKEM768.

1645
01:06:07,560 --> 01:06:09,600
Your browser automatically negotiates

1646
01:06:09,600 --> 01:06:12,840
a hybrid key exchange that includes post-quantum protection.

1647
01:06:12,840 --> 01:06:14,040
You didn't configure anything.

1648
01:06:14,040 --> 01:06:15,120
You didn't enable a setting.

1649
01:06:15,120 --> 01:06:15,920
It just happens.

1650
01:06:15,920 --> 01:06:19,600
Firefox supports PQC key exchange through configuration flags

1651
01:06:19,600 --> 01:06:22,400
with default support expected in an upcoming release.

1652
01:06:22,400 --> 01:06:24,560
And that means something important for the harvest

1653
01:06:24,560 --> 01:06:26,720
now to crypt later threat we discussed at the beginning.

1654
01:06:26,720 --> 01:06:30,040
When you access Microsoft 365 through a modern browser,

1655
01:06:30,040 --> 01:06:32,920
your TLS session already uses hybrid key exchange

1656
01:06:32,920 --> 01:06:34,320
if the server supports it.

1657
01:06:34,320 --> 01:06:37,600
Azure's TLS infrastructure has been deploying PQC support

1658
01:06:37,600 --> 01:06:38,920
across its services.

1659
01:06:38,920 --> 01:06:41,440
Cloud Flair and Akamai, which front a large portion

1660
01:06:41,440 --> 01:06:43,240
of the internet's TLS termination

1661
01:06:43,240 --> 01:06:45,040
have PQC support enabled by default.

1662
01:06:45,040 --> 01:06:47,480
So a significant portion of your encrypted traffic

1663
01:06:47,480 --> 01:06:50,280
to SAS platforms, CDNs and cloud services

1664
01:06:50,280 --> 01:06:53,080
is already protected by post-quantum key exchange.

1665
01:06:53,080 --> 01:06:55,600
Most organizations are already partially protected against

1666
01:06:55,600 --> 01:06:58,040
harvest now decrypt later and they don't know it.

1667
01:06:58,040 --> 01:07:00,200
That's the payoff I promised in the first section.

1668
01:07:00,200 --> 01:07:01,520
But, and this is critical.

1669
01:07:01,520 --> 01:07:03,880
This protection is partial and asymmetric.

1670
01:07:03,880 --> 01:07:05,320
It covers browser to cloud traffic

1671
01:07:05,320 --> 01:07:07,360
where both side support hybrid key exchange.

1672
01:07:07,360 --> 01:07:10,480
It leaves out your on-premises server to server communications,

1673
01:07:10,480 --> 01:07:13,400
your VPN tunnels, where the concentrator may not support

1674
01:07:13,400 --> 01:07:18,160
PQC cipher suites, your SSH sessions with RSA or ECDSA host

1675
01:07:18,160 --> 01:07:22,920
keys, your internal PKI still issuing RSA or ECC certificates,

1676
01:07:22,920 --> 01:07:25,680
and your custom applications running on older TLS clients

1677
01:07:25,680 --> 01:07:27,640
that can't handle MLKM.

1678
01:07:27,640 --> 01:07:30,160
And any traffic traversing middle boxes or legacy network

1679
01:07:30,160 --> 01:07:32,400
equipment that strips unknown cipher suites

1680
01:07:32,400 --> 01:07:34,040
loses the protection entirely.

1681
01:07:34,040 --> 01:07:36,720
So the infrastructure is moving, but it's moving unevenly.

1682
01:07:36,720 --> 01:07:39,120
And the gaps are exactly where your most sensitive operations

1683
01:07:39,120 --> 01:07:39,640
live.

1684
01:07:39,640 --> 01:07:41,960
Let me be specific about what you can do right now

1685
01:07:41,960 --> 01:07:44,760
in 2026 with the tools that are already available.

1686
01:07:44,760 --> 01:07:46,760
First, verify your PQC coverage.

1687
01:07:46,760 --> 01:07:48,520
Check which browsers your users are running.

1688
01:07:48,520 --> 01:07:52,360
If they're on edge 147 or later or Chrome 124 or later,

1689
01:07:52,360 --> 01:07:54,480
they're already using hybrid key exchange

1690
01:07:54,480 --> 01:07:56,520
for connections to servers that support it.

1691
01:07:56,520 --> 01:07:57,720
Check your Azure services.

1692
01:07:57,720 --> 01:08:00,440
Azure has been rolling out PQC TLS support

1693
01:08:00,440 --> 01:08:01,800
across its services.

1694
01:08:01,800 --> 01:08:04,520
And you can verify whether your specific Azure endpoints

1695
01:08:04,520 --> 01:08:10,000
support X25519 MLKEM768 by checking the negotiated cipher suite

1696
01:08:10,000 --> 01:08:11,680
in your TLS connections.

1697
01:08:11,680 --> 01:08:13,560
Second, build your CBIOM.

1698
01:08:13,560 --> 01:08:15,880
You don't need a sophisticated tool to start.

1699
01:08:15,880 --> 01:08:18,160
Begin with a spreadsheet that lists every certificate

1700
01:08:18,160 --> 01:08:21,560
in your environment, where it's used, what key type it uses,

1701
01:08:21,560 --> 01:08:24,880
who issued it, when it expires, and whether the underlying system

1702
01:08:24,880 --> 01:08:26,680
supports algorithm change.

1703
01:08:26,680 --> 01:08:30,360
Include your on-premises ADCS certificates, your Azure key vault

1704
01:08:30,360 --> 01:08:33,440
keys, your VPN certificates, your code signing certificates,

1705
01:08:33,440 --> 01:08:35,680
your internal web application certificates,

1706
01:08:35,680 --> 01:08:38,440
and your third party SAS integration certificates.

1707
01:08:38,440 --> 01:08:41,680
This inventory is the foundation for every subsequent decision.

1708
01:08:41,680 --> 01:08:44,960
Third, start testing PQC in non-production environments.

1709
01:08:44,960 --> 01:08:49,840
With SIMCRIP supporting MLKEM and MLDSA on Windows 11 and Windows Server 2025,

1710
01:08:49,840 --> 01:08:52,960
you can set up a test environment that uses post-quantum algorithms

1711
01:08:52,960 --> 01:08:55,200
for TLS and certificate enrollment.

1712
01:08:55,200 --> 01:08:58,960
Use the ADCS MLDSA support to issue test certificates.

1713
01:08:58,960 --> 01:09:01,880
Use Azure key vaults MLKEM and MLDSA key types

1714
01:09:01,880 --> 01:09:04,480
in preview to test PQC key management.

1715
01:09:04,480 --> 01:09:06,880
Run canary tests on low-risk internal services

1716
01:09:06,880 --> 01:09:08,760
to measure the performance impact and identify

1717
01:09:08,760 --> 01:09:12,080
any middle box or compatibility issues before you expand.

1718
01:09:12,080 --> 01:09:14,480
Fourth, upgrade your TLS libraries and runtimes

1719
01:09:14,480 --> 01:09:17,280
to versions that support MLKEM and hybrid groups.

1720
01:09:17,280 --> 01:09:20,480
If you're running OpenSSL 3.5 or later on your service,

1721
01:09:20,480 --> 01:09:22,480
they can negotiate hybrid key exchange.

1722
01:09:22,480 --> 01:09:25,600
If you're running older versions, you need to plan the upgrade.

1723
01:09:25,600 --> 01:09:29,160
If you have custom applications that use their own TLS implementations,

1724
01:09:29,160 --> 01:09:32,560
verify that those implementations support PQC cipher suites

1725
01:09:32,560 --> 01:09:34,280
or can be updated to do so.

1726
01:09:34,280 --> 01:09:37,920
Fifth, establish your PQC migration plan covering M365,

1727
01:09:37,920 --> 01:09:40,800
aligned with the government timelines that apply to your organization.

1728
01:09:40,800 --> 01:09:43,440
If you're in the US and handle national security data,

1729
01:09:43,440 --> 01:09:45,480
align to CNSA 2.0.

1730
01:09:45,480 --> 01:09:48,600
If you're in the EU, align to the ANISA roadmap.

1731
01:09:48,600 --> 01:09:52,400
If you're in Canada, align to the April 2026 planning deadline.

1732
01:09:52,400 --> 01:09:56,440
If you operate across jurisdictions, map against the most aggressive timeline

1733
01:09:56,440 --> 01:09:58,200
and use that as your baseline.

1734
01:09:58,200 --> 01:10:01,240
For what's in preview or coming soon, the roadmap looks like this.

1735
01:10:01,240 --> 01:10:04,160
Entra ID is working on PQC for identity tokens,

1736
01:10:04,160 --> 01:10:06,600
federation protocols and conditional access.

1737
01:10:06,600 --> 01:10:10,640
When this lands, it changes the game for authentication to Microsoft 365

1738
01:10:10,640 --> 01:10:13,640
because the tokens that grant access to your entire collaboration suite

1739
01:10:13,640 --> 01:10:15,880
would be protected by post-quantum signatures.

1740
01:10:15,880 --> 01:10:18,360
That's a big deal for the harvest now to cripple later threat

1741
01:10:18,360 --> 01:10:21,800
because identity tokens are one of the highest value interception targets.

1742
01:10:21,800 --> 01:10:26,240
Azure Key Vault has ML, KEM and ML/DSA key types in preview,

1743
01:10:26,240 --> 01:10:28,720
which means you can start testing PQC key management

1744
01:10:28,720 --> 01:10:30,360
in non-production environments.

1745
01:10:30,360 --> 01:10:33,960
M365 workloads like SharePoint, Exchange and Teams

1746
01:10:33,960 --> 01:10:37,480
will follow Azure's infrastructure, so PQC rollout for these services

1747
01:10:37,480 --> 01:10:40,920
depends on the Azure TLS and key management layers being ready.

1748
01:10:40,920 --> 01:10:45,560
The 2026 to 2029 roadmap synthesized from Microsoft's public commitments

1749
01:10:45,560 --> 01:10:47,960
and the government timelines that pressure them looks like this.

1750
01:10:47,960 --> 01:10:51,880
In 2026, the focus is planning, inventory and enabling hybrid TLS

1751
01:10:51,880 --> 01:10:54,040
on critical paths where you control both ends.

1752
01:10:54,040 --> 01:10:58,320
You should be building your C-bomb, identifying every RSA and ECC dependency

1753
01:10:58,320 --> 01:11:03,000
in your hybrid infrastructure and designating test tenants for early PQC features.

1754
01:11:03,000 --> 01:11:06,520
In 2027 to 2028 active early adoption begins

1755
01:11:06,520 --> 01:11:09,760
with hybrid TLS production pilots and PQC certificate enrollment

1756
01:11:09,760 --> 01:11:11,680
for high value internal services.

1757
01:11:11,680 --> 01:11:16,640
By 2029 to 2035 default PQC across all Microsoft services

1758
01:11:16,640 --> 01:11:19,160
with deprecation of classical only parts for any data

1759
01:11:19,160 --> 01:11:21,400
with long term confidentiality requirements.

1760
01:11:21,400 --> 01:11:23,400
The government timelines create external pressure

1761
01:11:23,400 --> 01:11:25,400
that shapes Microsoft's priorities.

1762
01:11:25,400 --> 01:11:28,800
CNSA 2.0 targets 2026 for networking equipment,

1763
01:11:28,800 --> 01:11:32,160
which means regulated customers will demand PQC capable VPN

1764
01:11:32,160 --> 01:11:34,840
and network products from Microsoft and its partners.

1765
01:11:34,840 --> 01:11:38,480
The EU expects initial transition roadmaps by end of 2026

1766
01:11:38,480 --> 01:11:42,200
and high risk systems by 2030, which means European enterprises

1767
01:11:42,200 --> 01:11:47,760
using M365 will need PQC options in the 2027 to 2028 time frame.

1768
01:11:47,760 --> 01:11:51,520
Kanda requires departmental plans starting April 2026,

1769
01:11:51,520 --> 01:11:55,080
which means government agencies using Azure will be asking Microsoft

1770
01:11:55,080 --> 01:11:57,240
for PQC readiness documentation.

1771
01:11:57,240 --> 01:11:58,760
These deadlines are not aspirational.

1772
01:11:58,760 --> 01:12:00,600
They come with compliance requirements

1773
01:12:00,600 --> 01:12:04,040
and regulated customers will demand PQC capabilities

1774
01:12:04,040 --> 01:12:05,560
from their vendors accordingly.

1775
01:12:05,560 --> 01:12:08,680
The message from regulators is consistent across jurisdictions.

1776
01:12:08,680 --> 01:12:12,560
Start now, plan carefully, prioritize high value data

1777
01:12:12,560 --> 01:12:16,600
and build the capability to change algorithms as standards evolve.

1778
01:12:16,600 --> 01:12:18,880
That last point, the capability to change

1779
01:12:18,880 --> 01:12:21,280
is what cryptographic agility provides.

1780
01:12:21,280 --> 01:12:23,360
Without it, you're running a race against a deadline

1781
01:12:23,360 --> 01:12:25,920
you can't predict with tools you can't update fast enough.

1782
01:12:25,920 --> 01:12:27,800
With it, you're running a control program

1783
01:12:27,800 --> 01:12:30,200
that can adapt as the threat environment evolves.

1784
01:12:30,200 --> 01:12:31,400
So the tooling is moving,

1785
01:12:31,400 --> 01:12:33,800
but tooling without governance is just technology

1786
01:12:33,800 --> 01:12:36,080
waiting to be misconfigured.

1787
01:12:36,080 --> 01:12:37,360
The governance playbook,

1788
01:12:37,360 --> 01:12:39,640
and this is where most post-quantum transitions stall.

1789
01:12:39,640 --> 01:12:41,720
Not because the algorithms aren't ready,

1790
01:12:41,720 --> 01:12:43,640
not because the infrastructure can't handle it,

1791
01:12:43,640 --> 01:12:46,040
but because nobody's decided who owns the decision,

1792
01:12:46,040 --> 01:12:47,640
how to prioritize the work

1793
01:12:47,640 --> 01:12:50,040
and how to keep track of it over the years it takes to complete.

1794
01:12:50,040 --> 01:12:52,160
This is the unglamerous part of the transition.

1795
01:12:52,160 --> 01:12:54,480
No new algorithms, no performance benchmarks,

1796
01:12:54,480 --> 01:12:56,480
no vendor announcements, just governance,

1797
01:12:56,480 --> 01:12:58,520
which is the least exciting and most essential piece

1798
01:12:58,520 --> 01:12:59,880
of the entire puzzle.

1799
01:12:59,880 --> 01:13:02,720
Cryptographic agility isn't a technical capability you can buy.

1800
01:13:02,720 --> 01:13:05,160
It's an organizational discipline you have to build.

1801
01:13:05,160 --> 01:13:07,160
And that requires a governance structure

1802
01:13:07,160 --> 01:13:09,320
that treats cryptography as a strategic asset

1803
01:13:09,320 --> 01:13:11,360
rather than an implementation detail.

1804
01:13:11,360 --> 01:13:13,240
Most organizations still treat cryptography

1805
01:13:13,240 --> 01:13:15,040
as a low level implementation detail

1806
01:13:15,040 --> 01:13:17,480
instead of a strategic asset that requires governance.

1807
01:13:17,480 --> 01:13:19,520
Technical controls like libraries, HSMs,

1808
01:13:19,520 --> 01:13:21,880
and TLS configurations are low and are not enough.

1809
01:13:21,880 --> 01:13:24,640
True cryptographic agility is a systemic capability

1810
01:13:24,640 --> 01:13:27,080
spanning architecture, supply chain, and governance.

1811
01:13:27,080 --> 01:13:30,040
Enterprises now need formal enterprise cryptography programs

1812
01:13:30,040 --> 01:13:32,800
to govern strategy, inventory, agility,

1813
01:13:32,800 --> 01:13:35,000
lifecycle management, and vendor risk.

1814
01:13:35,000 --> 01:13:37,080
The first element is executive sponsorship

1815
01:13:37,080 --> 01:13:38,640
and a steering structure.

1816
01:13:38,640 --> 01:13:42,000
Enterprise cryptography needs a CISO level or higher sponsor

1817
01:13:42,000 --> 01:13:44,240
who owns it as a strategic risk domain.

1818
01:13:44,240 --> 01:13:46,720
It needs an enterprise cryptography steering committee

1819
01:13:46,720 --> 01:13:48,600
with representation from security,

1820
01:13:48,600 --> 01:13:50,720
architecture, engineering, DevOps, compliance,

1821
01:13:50,720 --> 01:13:52,960
legal procurement, and key business units.

1822
01:13:52,960 --> 01:13:55,280
The committee's mandate is to approve crypto standards,

1823
01:13:55,280 --> 01:13:58,720
set roadmaps including PQC and authorize major migrations.

1824
01:13:58,720 --> 01:14:00,720
Without this structure, crypto decisions

1825
01:14:00,720 --> 01:14:03,240
fragment across teams that don't talk to each other

1826
01:14:03,240 --> 01:14:04,680
and the inventory stays incomplete

1827
01:14:04,680 --> 01:14:06,560
because nobody's accountable for completing it.

1828
01:14:06,560 --> 01:14:08,920
The committee should establish an enterprise cryptographic

1829
01:14:08,920 --> 01:14:12,160
standards document that defines approved algorithms,

1830
01:14:12,160 --> 01:14:14,760
key strengths, and PQC strategies.

1831
01:14:14,760 --> 01:14:17,760
It should set crypto agility requirements for new systems,

1832
01:14:17,760 --> 01:14:19,360
mandating that new applications

1833
01:14:19,360 --> 01:14:21,600
must support algorithm configurability,

1834
01:14:21,600 --> 01:14:23,560
central policy control, and logging.

1835
01:14:23,560 --> 01:14:25,400
And it should create an exception process

1836
01:14:25,400 --> 01:14:27,400
for legacy or constraint systems

1837
01:14:27,400 --> 01:14:30,600
with compensating controls and time-bound remediation plans.

1838
01:14:30,600 --> 01:14:32,680
The steering committee should also own the roadmap,

1839
01:14:32,680 --> 01:14:35,000
deciding which systems get migrated in which phase

1840
01:14:35,000 --> 01:14:36,800
based on the risk prioritization model

1841
01:14:36,800 --> 01:14:38,840
and the available engineering capacity.

1842
01:14:38,840 --> 01:14:40,760
This is not a decision that can be delegated

1843
01:14:40,760 --> 01:14:42,440
to individual application teams

1844
01:14:42,440 --> 01:14:44,840
because each team will prioritize their own systems

1845
01:14:44,840 --> 01:14:47,720
rather than the organization's highest risk exposures.

1846
01:14:47,720 --> 01:14:50,360
The second element is continuous cryptographic inventory,

1847
01:14:50,360 --> 01:14:51,760
not a one-time spreadsheet.

1848
01:14:51,760 --> 01:14:53,840
Continuous discovery using network level scanning

1849
01:14:53,840 --> 01:14:56,920
of protocols, cipher suites, certificates, and algorithms

1850
01:14:56,920 --> 01:14:59,120
across internal and external endpoints,

1851
01:14:59,120 --> 01:15:01,640
machine-to-machine traffic, and APIs.

1852
01:15:01,640 --> 01:15:03,880
The inventory must tie each cryptographic instance

1853
01:15:03,880 --> 01:15:07,000
to the application, business process, and data sensitivity,

1854
01:15:07,000 --> 01:15:09,440
it protects so you can differentiate high-risk usage

1855
01:15:09,440 --> 01:15:11,880
in payment systems and regulated environments

1856
01:15:11,880 --> 01:15:14,080
from low-impact test infrastructure.

1857
01:15:14,080 --> 01:15:16,160
It must validate discovered crypto against current

1858
01:15:16,160 --> 01:15:19,240
and post-quantum standards, flagging deprecated protocols,

1859
01:15:19,240 --> 01:15:21,640
weak ciphers, and misconfigurations.

1860
01:15:21,640 --> 01:15:24,720
And it should integrate C-bombs for key products and services

1861
01:15:24,720 --> 01:15:28,120
to track embedded algorithms, libraries, and PQC readiness.

1862
01:15:28,120 --> 01:15:30,840
CryptoInventory is widely described across industry guidance

1863
01:15:30,840 --> 01:15:32,920
as the foundation of cryptoagility.

1864
01:15:32,920 --> 01:15:34,400
Without it, you're operating blind.

1865
01:15:34,400 --> 01:15:36,840
The third element is risk-based prioritization.

1866
01:15:36,840 --> 01:15:38,480
Raw inventory data isn't actionable.

1867
01:15:38,480 --> 01:15:40,520
You need a scoring model that combines severity,

1868
01:15:40,520 --> 01:15:43,480
meaning algorithm strength and protocol age, exposure,

1869
01:15:43,480 --> 01:15:45,240
meaning internet-facing versus internal

1870
01:15:45,240 --> 01:15:46,800
and business criticality.

1871
01:15:46,800 --> 01:15:49,320
That scoring produces prioritized remediation cues

1872
01:15:49,320 --> 01:15:51,200
with documented rationale that you can explain

1873
01:15:51,200 --> 01:15:52,760
to auditors and board members.

1874
01:15:52,760 --> 01:15:55,680
It should integrate with your enterprise risk taxonomy

1875
01:15:55,680 --> 01:15:57,960
so that crypto risks are expressed in business terms

1876
01:15:57,960 --> 01:16:00,760
like confidentiality risk to regulated data

1877
01:16:00,760 --> 01:16:03,680
due to deprecated cipher rather than technical terms

1878
01:16:03,680 --> 01:16:06,200
that only the security team understands.

1879
01:16:06,200 --> 01:16:08,960
The fourth element is vendor and supply chain governance.

1880
01:16:08,960 --> 01:16:11,640
Your agility is bounded by your supply chain's agility.

1881
01:16:11,640 --> 01:16:14,920
Third-party products, cloud services, and embedded components

1882
01:16:14,920 --> 01:16:18,080
hide cryptographic usage that you can't see or change.

1883
01:16:18,080 --> 01:16:20,400
Your governance needs vendor evaluation criteria

1884
01:16:20,400 --> 01:16:22,880
that include PQC readiness and road map,

1885
01:16:22,880 --> 01:16:24,960
contractual requirements for timely support

1886
01:16:24,960 --> 01:16:27,000
of deprecations and security updates,

1887
01:16:27,000 --> 01:16:28,720
and life cycle oversight that tracks

1888
01:16:28,720 --> 01:16:30,480
crypto-relevant end-of-support dates

1889
01:16:30,480 --> 01:16:33,240
and plans migrations proactively.

1890
01:16:33,240 --> 01:16:35,480
Cryptographic posture should become a standard dimension

1891
01:16:35,480 --> 01:16:38,880
in vendor risk assessments, alongside financial stability,

1892
01:16:38,880 --> 01:16:42,960
data handling practices, and incident response capability.

1893
01:16:42,960 --> 01:16:45,320
The fifth element is an operational continuous loop.

1894
01:16:45,320 --> 01:16:47,440
Cryptoagility should run as a continuous cycle,

1895
01:16:47,440 --> 01:16:49,760
not a project that pauses between assessments.

1896
01:16:49,760 --> 01:16:51,600
The loop is discovery, then validation

1897
01:16:51,600 --> 01:16:53,840
against current policy and external standards,

1898
01:16:53,840 --> 01:16:56,680
then application mapping, then risk prioritization,

1899
01:16:56,680 --> 01:17:00,280
then remediation through existing ITSM and DevOps workflows,

1900
01:17:00,280 --> 01:17:02,360
then reporting that aggregates metrics and trends

1901
01:17:02,360 --> 01:17:03,760
for executives and boards.

1902
01:17:03,760 --> 01:17:05,240
This loop aligns crypto operations

1903
01:17:05,240 --> 01:17:07,280
with standard ITSM and SecOps processes,

1904
01:17:07,280 --> 01:17:08,680
avoiding a separate silo.

1905
01:17:08,680 --> 01:17:09,840
And there's a compliance deadline

1906
01:17:09,840 --> 01:17:11,360
that reinforces all of this,

1907
01:17:11,360 --> 01:17:14,720
FIPS 142 sunsets in September, 2026.

1908
01:17:14,720 --> 01:17:16,840
Organizations working on PQC migration

1909
01:17:16,840 --> 01:17:21,120
must also address the FIPS 142 to 143 transition.

1910
01:17:21,120 --> 01:17:22,960
The dual compliance pressure, migrating

1911
01:17:22,960 --> 01:17:26,200
to post-quantum algorithms and upgrading validated modules,

1912
01:17:26,200 --> 01:17:29,200
makes cryptographic agility, not just a strategic advantage,

1913
01:17:29,200 --> 01:17:30,800
but a practical necessity.

1914
01:17:30,800 --> 01:17:32,920
Without agility, you're running two separate

1915
01:17:32,920 --> 01:17:34,800
massive compliance projects simultaneously

1916
01:17:34,800 --> 01:17:36,640
instead of one coordinated program.

1917
01:17:36,640 --> 01:17:40,480
Nists, CSWP39, published in December 2025,

1918
01:17:40,480 --> 01:17:42,440
explicitly positions crypto agility

1919
01:17:42,440 --> 01:17:44,920
as a governance requirement, rather than a technical

1920
01:17:44,920 --> 01:17:46,080
nice to have.

1921
01:17:46,080 --> 01:17:48,120
The document provides structured technical levers,

1922
01:17:48,120 --> 01:17:51,560
modularity, API abstraction, policy and mechanism separation,

1923
01:17:51,560 --> 01:17:53,680
hybrid mechanisms, and a strategic plan

1924
01:17:53,680 --> 01:17:54,960
for enterprise governance.

1925
01:17:54,960 --> 01:17:56,760
It's the closest thing to an official blueprint

1926
01:17:56,760 --> 01:17:58,200
for building this capability.

1927
01:17:58,200 --> 01:18:00,000
The metrics that matter for tracking progress

1928
01:18:00,000 --> 01:18:02,600
include inventory coverage, percentage across your systems

1929
01:18:02,600 --> 01:18:05,200
and endpoints, the percentage of crypto implementations

1930
01:18:05,200 --> 01:18:07,040
compliant with current standards,

1931
01:18:07,040 --> 01:18:09,400
the time from vulnerability or deprecation announcement

1932
01:18:09,400 --> 01:18:11,440
to full remediation, the percentage

1933
01:18:11,440 --> 01:18:14,320
of critical systems meeting crypto agility design standards,

1934
01:18:14,320 --> 01:18:17,280
and vendor PQC readiness coverage, meaning the proportion

1935
01:18:17,280 --> 01:18:20,120
of critical vendors with published PQC roadmaps.

1936
01:18:20,120 --> 01:18:22,120
Reports should be tailored to their audience,

1937
01:18:22,120 --> 01:18:24,880
risk posture and trend lines for executives and boards,

1938
01:18:24,880 --> 01:18:27,800
detailed cues and SLAs for operations and engineering,

1939
01:18:27,800 --> 01:18:31,040
an evidence of process and outcomes for audit and compliance.

1940
01:18:31,040 --> 01:18:32,440
And the maturity model matters.

1941
01:18:32,440 --> 01:18:34,440
Don't treat the post-quantum migration as a project

1942
01:18:34,440 --> 01:18:36,560
with an end date, treat crypto agility

1943
01:18:36,560 --> 01:18:38,560
as a permanent operational discipline.

1944
01:18:38,560 --> 01:18:41,600
The PQC migration is the first real test of that discipline.

1945
01:18:41,600 --> 01:18:43,840
If you pass it by building genuine agility,

1946
01:18:43,840 --> 01:18:46,040
you'll handle the next algorithm deprecation,

1947
01:18:46,040 --> 01:18:47,640
the next script analytic result,

1948
01:18:47,640 --> 01:18:48,920
and the next compliance mandate

1949
01:18:48,920 --> 01:18:50,720
without starting from scratch.

1950
01:18:50,720 --> 01:18:53,560
Capping a call characterizes the maturity gap this way.

1951
01:18:53,560 --> 01:18:56,400
Many enterprises have pockets of cryptocapability,

1952
01:18:56,400 --> 01:18:58,400
typically centered around certificate management

1953
01:18:58,400 --> 01:19:01,600
and HSM operations, but lack the end-to-end governance

1954
01:19:01,600 --> 01:19:04,440
and operationalization that makes agility a property

1955
01:19:04,440 --> 01:19:06,600
of the organization rather than a skill

1956
01:19:06,600 --> 01:19:08,520
of specific individuals.

1957
01:19:08,520 --> 01:19:11,680
The cryptography maturity action plan or CMAP

1958
01:19:11,680 --> 01:19:14,240
is one framework for assessing governance readiness,

1959
01:19:14,240 --> 01:19:16,920
inventory visibility, operational processes

1960
01:19:16,920 --> 01:19:18,560
and migration preparedness.

1961
01:19:18,560 --> 01:19:20,560
It provides a structured way to evaluate

1962
01:19:20,560 --> 01:19:23,800
where your organization stands and what needs to be built next.

1963
01:19:23,800 --> 01:19:26,480
The important thing is not which maturity model you use.

1964
01:19:26,480 --> 01:19:29,920
The important thing is that you assess where you are honestly

1965
01:19:29,920 --> 01:19:32,440
and that you build the capability in the right order.

1966
01:19:32,440 --> 01:19:35,920
Governance first, then inventory, then risk prioritization,

1967
01:19:35,920 --> 01:19:38,680
then remediation, then continuous monitoring.

1968
01:19:38,680 --> 01:19:40,960
Starting with remediation before you have governance

1969
01:19:40,960 --> 01:19:43,400
and inventory is like performing surgery

1970
01:19:43,400 --> 01:19:45,040
before you've diagnosed the patient.

1971
01:19:45,040 --> 01:19:47,280
You might fix something, but you're just as likely

1972
01:19:47,280 --> 01:19:50,280
to make things worse, securing the communication backbone.

1973
01:19:50,280 --> 01:19:52,920
And the final piece of this picture is the protocol layer.

1974
01:19:52,920 --> 01:19:55,360
The foundational protocols that hold the internet together,

1975
01:19:55,360 --> 01:19:58,880
TLS VPN protocols like IPSAC and Wireguard SSH

1976
01:19:58,880 --> 01:20:01,640
and the certificate infrastructure that underpins all of them

1977
01:20:01,640 --> 01:20:03,400
are all in the process of being upgraded

1978
01:20:03,400 --> 01:20:05,600
for post-quantum security.

1979
01:20:05,600 --> 01:20:09,040
TLS 1.3 is the primary focus and for good reason.

1980
01:20:09,040 --> 01:20:11,400
It's the protocol that protects the vast majority

1981
01:20:11,400 --> 01:20:13,840
of internet traffic, including every connection

1982
01:20:13,840 --> 01:20:17,960
to Microsoft 365 Azure and every SAS platform your organization

1983
01:20:17,960 --> 01:20:18,640
uses.

1984
01:20:18,640 --> 01:20:21,720
The IETF's hybrid design work for TLS 1.3

1985
01:20:21,720 --> 01:20:24,680
and NIST's migration guidance both support phased migration

1986
01:20:24,680 --> 01:20:26,960
and the emphasize that hybrid approaches

1987
01:20:26,960 --> 01:20:29,480
are meant to reduce risk during transition rather

1988
01:20:29,480 --> 01:20:32,040
than replace all cryptography at once.

1989
01:20:32,040 --> 01:20:35,720
The production path in 2026 is hybrid TLS 1.3

1990
01:20:35,720 --> 01:20:41,000
with groups like X25519MLKEM768, not a wholesale move

1991
01:20:41,000 --> 01:20:42,440
to a new TLS version.

1992
01:20:42,440 --> 01:20:44,960
The collaborative effort across the industry is substantial.

1993
01:20:44,960 --> 01:20:47,640
Cloudflare and Akamai have deployed PQC TLS

1994
01:20:47,640 --> 01:20:50,240
at their CDN edges, which means that traffic passing

1995
01:20:50,240 --> 01:20:51,600
through their networks is already

1996
01:20:51,600 --> 01:20:54,440
being upgraded to hybrid key exchange, where both sides

1997
01:20:54,440 --> 01:20:55,800
supported.

1998
01:20:55,800 --> 01:20:58,200
Google accelerated its migration timeline in April,

1999
01:20:58,200 --> 01:21:00,600
2026, signaling urgency from one

2000
01:21:00,600 --> 01:21:02,760
of the largest operators of internet infrastructure.

2001
01:21:02,760 --> 01:21:04,520
Microsoft's zero TLS infrastructure

2002
01:21:04,520 --> 01:21:07,160
is rolling out hybrid key exchange across its services,

2003
01:21:07,160 --> 01:21:08,800
following a phased approach that starts

2004
01:21:08,800 --> 01:21:10,640
with the highest traffic endpoints.

2005
01:21:10,640 --> 01:21:14,280
Open SSL 3.5 has made MLKEM support available in the most widely

2006
01:21:14,280 --> 01:21:15,960
used TLS library on the internet, which

2007
01:21:15,960 --> 01:21:18,720
means that any server running a current open SSL version

2008
01:21:18,720 --> 01:21:21,320
can negotiate PQC key exchange.

2009
01:21:21,320 --> 01:21:24,120
And browsers have enabled hybrid key exchange by default,

2010
01:21:24,120 --> 01:21:26,480
which means the client side of the ecosystem is already there.

2011
01:21:26,480 --> 01:21:29,080
For VPNs, the impact of post-quantum signatures

2012
01:21:29,080 --> 01:21:31,520
on handshake performance is significant and worth

2013
01:21:31,520 --> 01:21:32,840
understanding in detail.

2014
01:21:32,840 --> 01:21:36,600
Most enterprise VPNs use IKEV2 with IPsec,

2015
01:21:36,600 --> 01:21:40,000
and the IKE handshake involves both key exchange and authentication

2016
01:21:40,000 --> 01:21:41,560
through digital signatures.

2017
01:21:41,560 --> 01:21:45,120
MLDSA signatures are several times larger than RSA or ECDSA

2018
01:21:45,120 --> 01:21:47,360
signatures at equivalent security levels, which

2019
01:21:47,360 --> 01:21:49,600
inflates the IKE handshake message.

2020
01:21:49,600 --> 01:21:53,080
On site to site VPNs with stable, high bandwidth connections,

2021
01:21:53,080 --> 01:21:55,640
the overhead is manageable, because the handshake happens

2022
01:21:55,640 --> 01:21:58,720
once and the tunnel stays up for hours or days.

2023
01:21:58,720 --> 01:22:02,160
On remote access VPNs over high latency or lossy networks,

2024
01:22:02,160 --> 01:22:04,760
the larger handshake can meaningfully increase connection

2025
01:22:04,760 --> 01:22:07,240
set up time, which affects the user experience

2026
01:22:07,240 --> 01:22:10,080
for remote workers connecting to the corporate network.

2027
01:22:10,080 --> 01:22:12,880
Some VPN vendors are already shipping hybrid key exchange

2028
01:22:12,880 --> 01:22:19,200
support using the same X255-1-1-9MLKEM68 pattern

2029
01:22:19,200 --> 01:22:21,120
that browsers and CDNs use.

2030
01:22:21,120 --> 01:22:23,960
The signature side is harder, because VPN certificates

2031
01:22:23,960 --> 01:22:26,080
are typically issued by an internal CA

2032
01:22:26,080 --> 01:22:28,000
that may not yet support MLDSA.

2033
01:22:28,000 --> 01:22:30,160
The faced approach for VPNs, consistent

2034
01:22:30,160 --> 01:22:32,080
with the broader migration pattern, is

2035
01:22:32,080 --> 01:22:34,960
to upgrade key exchange first for immediate confidentiality

2036
01:22:34,960 --> 01:22:37,760
protection, then migrate certificates and signatures

2037
01:22:37,760 --> 01:22:39,000
in a later phase.

2038
01:22:39,000 --> 01:22:40,240
SSH is a similar story.

2039
01:22:40,240 --> 01:22:43,120
The key exchange can be upgraded to hybrid MLKEM groups,

2040
01:22:43,120 --> 01:22:45,160
but the host key verification step,

2041
01:22:45,160 --> 01:22:47,760
where the server presents its public key for the client

2042
01:22:47,760 --> 01:22:51,560
to authenticate, will eventually need MLDSA signatures.

2043
01:22:51,560 --> 01:22:53,760
Larger host keys and signatures mean changes

2044
01:22:53,760 --> 01:22:56,120
to the SSH protocol to the known hosts

2045
01:22:56,120 --> 01:22:58,960
files that clients maintain, and to the SSH agent

2046
01:22:58,960 --> 01:23:00,960
forwarding mechanisms that administrators use

2047
01:23:00,960 --> 01:23:02,760
for jumpbox authentication.

2048
01:23:02,760 --> 01:23:06,480
Open SSH has experimental MLKEM key exchange support,

2049
01:23:06,480 --> 01:23:09,120
and the SSH protocol is being extended to accommodate

2050
01:23:09,120 --> 01:23:12,200
larger key and signature sizes, but the deployment timeline

2051
01:23:12,200 --> 01:23:14,960
depends on SSH client and server implementations

2052
01:23:14,960 --> 01:23:17,280
being updated across the infrastructure.

2053
01:23:17,280 --> 01:23:20,440
For organizations that rely on SSH jumpbox architectures,

2054
01:23:20,440 --> 01:23:22,800
where administrators connect through a series of intermediate

2055
01:23:22,800 --> 01:23:24,640
servers to reach production systems,

2056
01:23:24,640 --> 01:23:27,760
the signature size increase compounds at each hop.

2057
01:23:27,760 --> 01:23:31,320
Each SSH connection in the chain requires a separate key exchange

2058
01:23:31,320 --> 01:23:33,000
and host key verification.

2059
01:23:33,000 --> 01:23:36,240
With MLDSA host keys, each hop carries larger signatures,

2060
01:23:36,240 --> 01:23:38,680
and the total connection setup time for a multi hop SSH

2061
01:23:38,680 --> 01:23:40,080
chain increases proportionally.

2062
01:23:40,080 --> 01:23:42,520
This is a manageable problem for interactive use,

2063
01:23:42,520 --> 01:23:44,960
but for automated operations that open thousands

2064
01:23:44,960 --> 01:23:47,280
of SSH connections per hour, the latency increase

2065
01:23:47,280 --> 01:23:48,360
can be significant.

2066
01:23:48,360 --> 01:23:50,760
The cross-border dimension adds regulatory complexity

2067
01:23:50,760 --> 01:23:53,320
that global enterprises must navigate carefully.

2068
01:23:53,320 --> 01:23:56,240
The CNSA 2.0 timeline in the US applies

2069
01:23:56,240 --> 01:23:59,720
to national security systems and the contractors that support them.

2070
01:23:59,720 --> 01:24:02,600
The ANISA roadmap in the EU applies to all member states

2071
01:24:02,600 --> 01:24:04,480
and the organizations operating within them.

2072
01:24:04,480 --> 01:24:06,960
Canada's departmental plans apply to federal agencies

2073
01:24:06,960 --> 01:24:08,240
and their service providers.

2074
01:24:08,240 --> 01:24:10,680
The UK and CSC's phased approach applies

2075
01:24:10,680 --> 01:24:13,200
to government and critical national infrastructure.

2076
01:24:13,200 --> 01:24:15,800
Australia's ASD mandates apply to specific categories

2077
01:24:15,800 --> 01:24:16,560
of systems.

2078
01:24:16,560 --> 01:24:18,080
A multinational cooperation operating

2079
01:24:18,080 --> 01:24:20,640
in multiple jurisdictions faces different timelines

2080
01:24:20,640 --> 01:24:22,360
for different categories of systems

2081
01:24:22,360 --> 01:24:26,000
and the compliance requirements overlap rather than a line.

2082
01:24:26,000 --> 01:24:28,280
A practical approach is to map your infrastructure

2083
01:24:28,280 --> 01:24:30,280
against the most aggressive applicable timeline

2084
01:24:30,280 --> 01:24:31,840
and use that as your planning baseline.

2085
01:24:31,840 --> 01:24:34,640
If you operate in the US and handle national security data,

2086
01:24:34,640 --> 01:24:37,800
CNSA 2.0's 2035 deadline is your outer bound.

2087
01:24:37,800 --> 01:24:40,560
If you operate in the EU and handle critical infrastructure,

2088
01:24:40,560 --> 01:24:43,800
ANISA's 2030 deadline for high-risk systems is more aggressive.

2089
01:24:43,800 --> 01:24:45,640
If you operate across multiple jurisdictions,

2090
01:24:45,640 --> 01:24:48,160
the earliest applicable deadline drives your planning.

2091
01:24:48,160 --> 01:24:50,600
The specific timelines from the major regulatory bodies

2092
01:24:50,600 --> 01:24:52,080
are worth knowing precisely.

2093
01:24:52,080 --> 01:24:55,360
CNSA 2.0 specifies that by 2025,

2094
01:24:55,360 --> 01:24:59,320
web browsers and cloud services must support CNSA 2.0 algorithms

2095
01:24:59,320 --> 01:25:01,240
and new software and firmware must be signed

2096
01:25:01,240 --> 01:25:03,320
with quantum-resistant signatures.

2097
01:25:03,320 --> 01:25:06,120
By 2026, traditional networking equipment,

2098
01:25:06,120 --> 01:25:10,360
including VPNs and routers, must use CNSA 2.0 algorithms.

2099
01:25:10,360 --> 01:25:13,120
By 2030, traditional asymmetric cryptography

2100
01:25:13,120 --> 01:25:15,400
must not be used for national security purposes.

2101
01:25:15,400 --> 01:25:18,080
By 2035, the transition must be complete.

2102
01:25:18,080 --> 01:25:20,800
The ANISA roadmap requires initial transition roadmaps

2103
01:25:20,800 --> 01:25:23,080
from member states by end of 2026,

2104
01:25:23,080 --> 01:25:26,320
high-risk use cases implemented by end of 2030,

2105
01:25:26,320 --> 01:25:28,480
and full transition by end of 2035.

2106
01:25:28,480 --> 01:25:31,360
Canada's roadmap requires initial departmental migration plans

2107
01:25:31,360 --> 01:25:32,920
by April 2026.

2108
01:25:32,920 --> 01:25:34,760
Annual progress reports high-risk systems

2109
01:25:34,760 --> 01:25:38,280
complete by end of 2031 and all systems by 2035.

2110
01:25:38,280 --> 01:25:39,640
These dates aren't suggestions.

2111
01:25:39,640 --> 01:25:41,520
They're compliance requirements for the organizations

2112
01:25:41,520 --> 01:25:43,280
that fall under their jurisdiction.

2113
01:25:43,280 --> 01:25:46,000
But the long-term resilience model is what matters most.

2114
01:25:46,000 --> 01:25:48,840
Cryptographic agility isn't just about the quantum transition.

2115
01:25:48,840 --> 01:25:51,480
It's about being able to respond to the next algorithm,

2116
01:25:51,480 --> 01:25:53,720
the next cryptanalytic breakthrough,

2117
01:25:53,720 --> 01:25:55,120
the next compliance mandate,

2118
01:25:55,120 --> 01:25:57,120
without starting from scratch every time.

2119
01:25:57,120 --> 01:25:59,280
The quantum transition is the forcing function

2120
01:25:59,280 --> 01:26:01,800
that exposes the rigidity in your infrastructure,

2121
01:26:01,800 --> 01:26:04,160
fix the rigidity, and you fix the problem

2122
01:26:04,160 --> 01:26:05,760
for every future transition as well.

2123
01:26:05,760 --> 01:26:06,640
Think about it this way.

2124
01:26:06,640 --> 01:26:09,080
A show one was deprecated in 2017,

2125
01:26:09,080 --> 01:26:10,800
and organizations are still cleaning up

2126
01:26:10,800 --> 01:26:12,840
show one dependencies in 2026.

2127
01:26:12,840 --> 01:26:16,440
TLS 1.0 and 1.1 were deprecated in 2021,

2128
01:26:16,440 --> 01:26:18,440
and legacy systems still running those protocols

2129
01:26:18,440 --> 01:26:20,880
are still being discovered in enterprise networks.

2130
01:26:20,880 --> 01:26:22,880
The migration to post-quantum cryptography

2131
01:26:22,880 --> 01:26:24,400
is the same type of transition,

2132
01:26:24,400 --> 01:26:27,320
but the stakes are existential rather than inconvenient.

2133
01:26:27,320 --> 01:26:28,480
If you build agility now,

2134
01:26:28,480 --> 01:26:30,520
the PQC migration becomes the first test

2135
01:26:30,520 --> 01:26:33,280
of a permanent capability rather than a one-time crisis.

2136
01:26:33,280 --> 01:26:34,400
That's the through line.

2137
01:26:34,400 --> 01:26:36,040
Cryptographic agility is the difference

2138
01:26:36,040 --> 01:26:38,240
between surviving the quantum transition

2139
01:26:38,240 --> 01:26:39,480
and being broken by it.

2140
01:26:39,480 --> 01:26:41,320
Not because agility is a magic technology,

2141
01:26:41,320 --> 01:26:43,000
because agility is the structural property

2142
01:26:43,000 --> 01:26:44,840
that makes every transition survivable.

2143
01:26:44,840 --> 01:26:47,440
And that structural property, once built,

2144
01:26:47,440 --> 01:26:49,400
doesn't just protect you from the quantum threat.

2145
01:26:49,400 --> 01:26:52,360
It protects you from every future algorithm deprecation,

2146
01:26:52,360 --> 01:26:54,120
every future crypt analytic result

2147
01:26:54,120 --> 01:26:55,640
and every future compliance mandate.

2148
01:26:55,640 --> 01:26:57,600
The transition exposes the rigidity.

2149
01:26:57,600 --> 01:26:59,480
The agility removes it.

2150
01:26:59,480 --> 01:27:01,920
Cryptographic agility is what separates organizations

2151
01:27:01,920 --> 01:27:03,480
that will navigate the quantum transition

2152
01:27:03,480 --> 01:27:05,320
from those that will be broken by it.

2153
01:27:05,320 --> 01:27:06,760
The algorithms are standardized.

2154
01:27:06,760 --> 01:27:07,960
The tools are shipping.

2155
01:27:07,960 --> 01:27:10,200
The browsers are enabling PQC by default.

2156
01:27:10,200 --> 01:27:12,720
The question is no longer whether the technology will be ready.

2157
01:27:12,720 --> 01:27:14,320
The question is whether your infrastructure

2158
01:27:14,320 --> 01:27:16,440
can adapt when the algorithm needs to change.

2159
01:27:16,440 --> 01:27:17,440
Build the agility.

2160
01:27:17,440 --> 01:27:18,800
Everything else follows.

2161
01:27:18,800 --> 01:27:21,440
If this changed how you think about your security architecture,

2162
01:27:21,440 --> 01:27:23,320
follow me, Marco Peters on LinkedIn.

2163
01:27:23,320 --> 01:27:25,320
And if you want more of this, leave a review.

2164
01:27:25,320 --> 01:27:26,720
It helps more people find it.

Mirko Peters

Founder of m365.fm, m365.show and m365con.net

Mirko Peters is a Microsoft 365 expert, content creator, and founder of m365.fm, a platform dedicated to sharing practical insights on modern workplace technologies. His work focuses on Microsoft 365 governance, security, collaboration, and real-world implementation strategies.

Through his podcast and written content, Mirko provides hands-on guidance for IT professionals, architects, and business leaders navigating the complexities of Microsoft 365. He is known for translating complex topics into clear, actionable advice, often highlighting common mistakes and overlooked risks in real-world environments.

With a strong emphasis on community contribution and knowledge sharing, Mirko is actively building a platform that connects experts, shares experiences, and helps organizations get the most out of their Microsoft 365 investments.