PQC Migration Now Has a Deadline. Does Your DNS Estate?

• On June 22, 2026, President Trump signed Executive Order (EO) 14412, which establishes binding post-quantum cryptography (PQC) migration deadlines for federal agencies and covered contractors. For organizations outside the federal supply chain, the EO clearly signals where the broader market is heading.

• The path to quantum-safe DNSSEC is an active and unsolved problem. No production-ready migration path currently exists, but organizations can begin to build its foundation. For federal agencies and contractors, that foundation needs to be in place well before the deadline.

• Most organizations lack a clear, unified view of their DNS estate. Without knowing where DNSSEC is deployed, where it is misconfigured, and which domains carry legacy cryptographic dependencies, it is impossible to plan a migration with confidence.

• DNS fragmentation carries its own risks independent of PQC. Orphaned records, dangling CNAMEs, and abandoned subdomains create dangerous subdomain hijacking vulnerabilities that will become significantly more dangerous during the period of major cryptographic change.

• Crypto-agility is a property of your environment, not just your algorithm choices. A DNS estate that is poorly understood and inconsistently configured is not crypto-agile, regardless of which standards it eventually adopts.

Post-quantum cryptography (PQC) is usually framed as a future milestone: identify the algorithms, follow the standards, complete the migration. For our customers, part of that future is already available. Our content delivery network already supports PQC, meaning that organizations can begin enabling quantum-safe cryptography for traffic delivered across the Akamai platform now.

On June 22, 2026, President Trump signed Executive Order 14412, establishing hard deadlines requiring all high-value assets and high-impact systems to use PQC for key establishment by December 31, 2030, and for digital signatures by December 31, 2031. The order also directs the Federal Acquisition Regulatory Council (FAR) Council to publish a proposed rule requiring covered contractors to comply with the Federal Information Processing Standards (FIPS) PQC standards from the National Institute of Standards and Technology (NIST)  by the same date, extending the compliance obligation beyond federal agencies to any organization that has a contract with the federal government. For federal agencies and federal contractors, that timeline is now binding. 

For those organizations outside the federal supply chain, the EO doesn't create a direct compliance obligation today. But it does clearly signal where the broader market is heading, and it establishes a precedent that other regulatory frameworks are likely to follow. 

The bigger challenge, and one most organizations are not yet prepared for, is understanding how the broader transition will affect the infrastructure. Large-scale cryptographic transitions don’t fail at the algorithm layer. They fail at the infrastructure layer when organizations discover, under pressure, that they don’t have a clear picture of what they’re migrating, where their dependencies lie, or which parts of their environment will break first.

DNS is where that discovery tends to be most painful. In most large organizations, DNS is distributed across multiple cloud providers, authoritative nameservers, and internal resolvers, with no single team owning the full picture. 

The deployment of DNSSEC, the mechanism that adds cryptographic authentication to DNS, is frequently inconsistent; it’s misconfigured in ways that don't produce obvious failures. DNS estates accumulate years of sprawl — orphaned records, abandoned subdomains, undocumented dependencies — that only become visible when something forces you to look.

A cryptographic migration is exactly that kind of forcing function, because it requires you to locate and touch every place where a cryptographic algorithm is in use. For DNS, that means:

• Identifying every signed zone

• Mapping every dependency that relies on DNSSEC validation

• Accounting for every corner of an estate that may not have been examined in years 

That work has to happen regardless. The only question is whether it happens deliberately, at your own pace, before the migration begins — or under pressure, after the migration has already started.

The organizations that haven't examined their DNS estate before that moment arrives will spend the early stages of a time-pressured migration doing discovery work they could have done at their own pace. That is a recoverable position, but it is not a comfortable one, and the window to avoid it is open now.

For federal agencies and contractors, that window now has a deadline. For organizations outside the federal supply chain, the deadline is not much more generous. Industry is already moving: major cloud providers, browser vendors, and standards bodies have been tracking PQC adoption closely, and several key actors have committed to timelines that match or exceed the EO's mandates. Compliance frameworks in adjacent sectors are likely to follow the same trajectory. 

The organizations that treat this as a federal concern rather than as a broader infrastructure priority may find that the window to act at their own pace is shorter than they assumed.

Every digital interaction begins with a DNS lookup. DNS is the connective tissue of modern infrastructure but it is often fragmented and inconsistently managed. 

DNSSEC currently relies on RSA and ECDSA — precisely the algorithms that PQC is designed to replace. The path to quantum-safe DNSSEC is an active and genuinely open problem. 

The Internet Engineering Task Force (IETF) working groups are developing specifications, but no production-ready migration path currently exists. The new NIST-standardized algorithms, including ML-DSA, introduce signature sizes that are orders of magnitude larger than today's standards — an ECDSA signature is approximately 64 bytes; an ML-DSA signature runs between 2,420 and 4,627 bytes — and how DNS infrastructure will accommodate that change at scale remains an unsolved challenge.

Therefore, organizations cannot migrate DNSSEC to post-quantum algorithms today. But they can, and should, be building the foundation that will make migration possible as soon as the path exists. For federal agencies and contractors working toward the 2030 deadline, that foundation needs to be in place well before the migration itself begins — and, for that, they need to know what they have.

Most organizations, when they begin thinking seriously about PQC readiness of their DNSSEC deployment, run into the same obstacle: They don't have a clear, unified view of their DNS estate.

DNS visibility is fragmented by design. Organizations that run infrastructure across AWS, Azure, Google Cloud, and third-party DNS providers often have no consolidated picture of where DNSSEC is deployed, where it's misconfigured, which domains rely on vulnerable RSA-based or ECDSA-based signatures, or how services and dependencies connect across a complex multiprovider environment.

Without that picture, it's impossible to assess exposure, prioritize remediation, or plan a migration with any confidence. You can't migrate what you can't see.

EO 14412 reinforces this point directly. The order requires the Cybersecurity & Infrastructure Security Agency (CISA) to release public guidance within 270 days on the minimum elements for a cryptographic bill of materials, to enable automated assessment of cryptographic assets across hardware and software.

For federal agencies and contractors, that bill of materials will soon be a compliance requirement. For all organizations, it signals that cryptographic asset visibility is becoming a baseline expectation, not an advanced capability. 

DNS fragmentation also carries its own risks, independent of PQC. Orphaned records, dangling CNAMEs pointing to decommissioned resources, and abandoned subdomains are common in large DNS estates. These create subdomain hijacking vulnerabilities that are dangerous today and will become significantly more dangerous during the period of major infrastructure change. 

An attacker who can hijack a trusted subdomain during a cryptographic migration doesn't need to break the new algorithm. They only need to exploit the gaps left behind by the old infrastructure.

The concept of crypto-agility, the ability to swap cryptographic algorithms without rebuilding infrastructure, is central to most PQC readiness discussions. It's usually framed as a property of algorithm or protocol choices. In practice, it's a property of the environment into which those choices are deployed.

A DNS estate that is poorly understood, inconsistently configured, and spread across dozens of providers is not crypto-agile, regardless of which algorithms it eventually adopts. The technical standards can evolve, but if the infrastructure underneath them is opaque and unmaintained, the migration will be slow, risky, and reactive.

Crypto-agility has to be built before it's needed. And building it starts with the same thing: understanding what exists, how it's configured, and where the risks are concentrated.

Stop asking “Are we ready for post-quantum cryptography in DNSSEC?” The more useful question right now is “Do we understand our DNS estate well enough to migrate it?”

That means:

• Having a consolidated view of DNS configurations across every provider and environment

• Knowing where DNSSEC is deployed, where it's absent, and where it's misconfigured

• Mapping third-party dependencies before a migration surfaces them under pressure

• Addressing the hygiene issues, orphaned records, inconsistent configurations, and unknown dependencies that will complicate any large-scale infrastructure change

None of that requires waiting for the IETF to finalize a PQC migration path for DNSSEC. For federal agencies and contractors, migration planning must start now.  Everyone else should also start now so they’ll arrive at the migration in a fundamentally stronger position than those who waited.

For most organizations, the realistic starting point for PQC readiness is not algorithm replacement. It's building a clear and accurate picture of the DNS estate: what exists, how it's configured, where cryptographic exposure is concentrated, and how services and dependencies interact across a complex multiprovider environment.

Akamai DNS Posture Management is built for exactly this. It provides a unified view of DNS configurations and cryptographic exposure across your distributed cloud environment, with agentless discovery to identify which assets carry legacy cryptographic dependencies and how your DNS estate is configured across providers today.

That visibility doesn't solve the open technical challenges of DNSSEC migration to post-quantum algorithms. Instead, it ensures that when the path forward exists, your organization is ready to take it immediately, rather than spend the first months of a time-pressured migration trying to understand what you have.

The organizations that navigate this transition well will not simply be the ones that adopted new standards fastest. They'll be the ones that understood their environment clearly enough to migrate it with confidence.

Contact your Akamai representative to find out how DNS Posture Management can help your organization build that foundation today.