The CISA release frames the task around five priorities: awareness, national strategies, research and development, public-private cooperation, and making post-quantum cryptography part of cyber requirements and procurement. France’s ANSSI, which chaired the G7 Cybersecurity Working Group during the French G7 presidency, separately confirmed the publication and described the quantum threat as requiring organizations in every sector to act now.
The G7’s language is intentionally broad. It does not create a U.S. regulatory deadline, identify mandatory algorithms, or say that conventional encryption has suddenly failed. It does, however, turn an issue often deferred as a science project into a procurement, lifecycle-management, and software-compatibility problem that IT departments should already be planning around.
The risk is data that stays valuable after it is stolen
Post-quantum cryptography, or PQC, refers to algorithms designed to withstand attacks from both conventional and sufficiently powerful quantum computers. The immediate concern is public-key cryptography: the RSA and elliptic-curve systems used widely for TLS, code signing, VPNs, device authentication, certificates, secure email, and identity systems.
A cryptographically relevant quantum computer does not yet exist in public use. The G7 guidance makes clear that uncertainty about when it will arrive is not a reason to wait. Sensitive records captured today can be stored for later decryption, a scenario commonly called harvest now, decrypt later. That creates present-day exposure where confidentiality needs to last for years: health records, proprietary engineering data, government information, customer identity data, legal material, and long-lived machine credentials.
The Canadian Centre for Cyber Security’s earlier G7 guidance, which the new call builds upon, puts the distinction plainly. PQC migration has a longer runway than a response to an active ransomware outbreak, but it will take time precisely because cryptography is scattered through infrastructure and third-party products. Organizations must identify where public-key cryptography exists, determine whether each dependency can be upgraded, test the replacement, and coordinate vendors whose roadmaps they do not control.
This is why a date for “Q-Day” is a poor planning metric. An organization that must keep confidential data protected until the mid-2030s may face a decision now even if large-scale quantum attacks remain years away. The practical exposure window is the value-life of the data plus the time needed to complete a migration.
Standards exist, but deployment is still the hard part
The G7 call arrives after NIST completed its first three core post-quantum cryptography standards in August 2024. They are FIPS 203 for ML-KEM, a key-establishment mechanism; FIPS 204 for ML-DSA digital signatures; and FIPS 205 for SLH-DSA digital signatures. NIST says organizations should begin applying the standards now and expects ML-KEM, ML-DSA, and SLH-DSA to form the foundation of most deployments.
That does not mean every RSA certificate should be replaced tomorrow. In most enterprise environments, forcing a premature algorithm change risks service failures, incompatible clients, overloaded constrained devices, or certificate-management mistakes. PQC algorithms can have significantly different key, signature, and handshake sizes from the cryptography they replace. A migration therefore has to account for network overhead, TLS termination, hardware security modules, embedded firmware, older operating systems, software-development kits, and the validation behavior of internally developed applications.
The preferred early pattern is often a hybrid deployment: combining a conventional algorithm with a post-quantum one so that both contribute to security during the transition. The G7’s technical material specifically identifies hybrid TLS key exchange as one way to pair a traditional key exchange with a post-quantum key-encapsulation mechanism. That protects interoperability while organizations validate the newer technology, rather than requiring every endpoint to make a clean break on the same day.
NIST’s current transition direction also supplies a useful boundary for planning. It expects quantum-vulnerable algorithms to be deprecated and eventually removed from its standards by 2035, with high-risk systems moving earlier. That is not a blanket mandate for every private Windows deployment, but it is a concrete signal that cryptographic modernization should be treated as a multi-year program with measurable milestones.
Windows already shows where compatibility will break
Microsoft’s own current Windows guidance demonstrates why the G7 emphasis on cryptographic agility is more than policy vocabulary. In August, Microsoft warned developers and IT administrators that its Windows code-signing infrastructure is changing certificates and moving to stronger signing configurations before a planned transition to post-quantum signing in 2027.
Microsoft says applications may fail even when Windows itself considers a signed file valid and trusted. The problem is software that pins a Microsoft certificate thumbprint, issuer, key size, hashing algorithm, or certificate chain, rather than relying on supported Windows trust APIs. Code that assumes a signature must use SHA-256 or RSA-2048, or that parses Authenticode structures directly, can turn a routine security modernization into an application outage.
The nearer compatibility event is the expiration of the Microsoft Windows Production PCA 2011 certificate on October 19, 2026. Microsoft plans to replace it and to move toward RSA-3072 and SHA-384 later this year. The 2027 PQC signing move follows those steps. Administrators should read that sequence as a warning: an estate may have hidden certificate pinning problems long before it encounters a new post-quantum algorithm.
Windows has also begun exposing hybrid PQC TLS groups in preview software. Microsoft’s documentation lists X25519 with ML-KEM-768, P-256 with ML-KEM-768, and P-384 with ML-KEM-1024 for Windows 11 24H2 and later, as well as Windows Server 2025. They are available in specified Windows Insider Preview builds but disabled by default. That is a testing opportunity, not a production-wide instruction to enable PQC across an enterprise today.
The distinction matters operationally. A Windows client can only negotiate a quantum-resistant TLS connection when the relevant server, load balancer, proxy, inspection appliance, and policy path support the chosen group. Enabling a client-side capability does not make every HTTPS, VPN, or internal service quantum-safe.
Procurement is where the G7 statement becomes enforceable
The most consequential part of the CISA and G7 call may be its demand to integrate PQC into cybersecurity requirements and procurement. Cryptographic dependencies are increasingly supplied rather than built: cloud identity platforms, SaaS applications, managed firewalls, remote-access gateways, IoT fleets, industrial controllers, mobile-device management services, certificate authorities, and software-update pipelines all carry cryptographic decisions made by vendors.
The G7’s previous practical guidance recommends mapping cryptographic dependencies across internal systems and supply chains, creating governance and implementation teams, and involving procurement, legal, finance, and vendor-risk staff. It also cautions that unsupported hardware may need replacement if its supplier has no PQC transition plan. Those are ordinary enterprise disciplines, but they are rarely organized around a full cryptographic inventory.
For Windows-focused organizations, vendor questionnaires should move beyond asking whether a supplier “supports PQC.” The more useful questions are concrete:
- Does the product inventory its use of RSA, elliptic-curve cryptography, Diffie-Hellman, certificates, code signing, and hardware-backed keys?
- Which NIST-standardized PQC algorithms and hybrid modes are planned, and in which product versions?
- Can the vendor support cryptographic-policy changes without requiring a forklift replacement of older servers, endpoints, or appliances?
- Does its software pin certificates, issuers, signature algorithms, or key lengths in ways that will break during Microsoft’s certificate and signing transitions?
- Will PQC support be delivered under an existing support contract, or require new hardware, licensing, professional services, or a major version upgrade?
A vendor that cannot answer the first question is not necessarily unsafe today. It is, however, telling customers that it lacks the inventory needed to estimate migration scope. That should affect refresh decisions now, particularly for equipment intended to remain in service into the 2030s.
Start with discovery and controlled testing
The right first deliverable is a cryptographic inventory tied to business risk, not a dashboard claiming “quantum readiness.” Include external TLS services, Active Directory Certificate Services and other PKI components, device certificates, VPN and Wi-Fi authentication, signed PowerShell scripts, application update systems, code-signing workflows, cloud key-management services, backup encryption, database connections, and embedded or operational technology.
Next, identify the data whose confidentiality extends beyond a normal platform-refresh cycle. A public marketing site and a repository of long-lived personnel records do not deserve the same priority. Treating every cryptographic use as equally urgent is one way organizations turn a manageable migration into an unfunded compliance exercise.
Then establish a test path. Microsoft’s current Windows preview support for ML-KEM hybrid TLS groups offers a limited environment for validating clients, servers, proxies, monitoring tools, and performance assumptions. Separately, developers should audit validation code ahead of the Windows signing-certificate change in October, because it is an observable compatibility test of whether their software is agile enough for the larger PQC transition.
CISA and the G7 have not announced an emergency replacement of today’s encryption. They have issued something more useful: a warning that the migration clock is determined by inventory gaps, vendor contracts, and application assumptions rather than by the day a quantum computer is announced. For Windows shops, the next concrete milestone is Microsoft’s October 19, 2026 production code-signing certificate expiration—and the failures it may expose in software that was built to trust a fixed cryptographic past.