The G7 recently moved post-quantum cryptography out of the “future problem” category, and for state, local, education, public safety, and critical infrastructure organizations, the practical question is no longer whether PQC will matter, it’s how to prepare without creating unnecessary cost, complexity, or procurement confusion before the market is ready. In this context, understanding post-quantum cryptography for SLED is becoming increasingly urgent.
What many people casually call “quantum cryptography” is more accurately described as post-quantum cryptography, or PQC. This is not about using quantum computers to encrypt data. It’s about replacing today’s cryptographic methods that may become vulnerable once sufficiently powerful quantum computers exist.
Why the G7 Statement Matters
The G7 is a group of major democratic economies that collaborate on global economic, security, and technology issues. When the G7 addresses cybersecurity, it typically signals that a topic has moved beyond technical research and into international policy coordination.
The recent G7 Cybersecurity Working Group statement on post-quantum cryptography doesn’t create a new mandate for state and local government, nor does it replace national guidance from NIST, CISA, NSA, or other authorities. Instead, it does something more subtle but important: it validates that post-quantum migration is becoming a coordinated global priority.
For SLED organizations, this matters because the public sector holds data with long confidentiality lifecycles, such as criminal justice information, student records, tax records, public health information, benefits data, and sensitive infrastructure documentation. Some of this information needs to remain protected not just for months or years, but for decades. If adversaries collect encrypted data today and store it, they may be able to decrypt it later once quantum computing becomes capable enough. This is often called “harvest now, decrypt later.” For data with a short shelf life, that risk may be limited. For CJIS, education, healthcare, tax, legal, and infrastructure data, the exposure starts now, even if the quantum capability arrives later.
A Flashy Commercial Market Is Coming
The vendor market is going to get loud. There will be “quantum-safe” products, “PQC-ready” labels, migration platforms, new appliances, managed services, and plenty of marketing language that sounds more mature than the ecosystem really is. Some of these solutions will be useful. Some will be early. Some will solve one narrow technical problem while creating another operational dependency. The danger for SLED organizations is assuming that purchasing a new product is equivalent to solving the post-quantum problem, because post-quantum cryptography is not a single tool—it’s a migration across protocols, applications, certificates, identity systems, VPNs, cloud platforms, hardware security modules, databases, software supply chains, and vendor-managed systems.
It’s also worth separating the AI discussion from the quantum discussion. AI is not the reason RSA or elliptic curve cryptography become vulnerable. Quantum computing is the concern. AI may help attackers find exposed systems, automate reconnaissance, identify weak implementations, or accelerate misuse of stolen data, but it doesn’t break well-implemented modern cryptography on its own. Where AI may help defenders is in discovery and planning such as reviewing code, configuration files, logs, asset inventories, certificates, and vendor documentation to identify where cryptography is being used. That said, AI shouldn’t be treated as an autopilot for PQC migration. Replacing cryptography isn’t the same as replacing a bad password rule or updating a software package. Cryptographic changes can affect interoperability, performance, compliance, and whether systems can communicate with each other at all.
What Actually Changes
Quantum risk is most urgent for the public-key side of modern cryptography. Algorithms such as RSA and elliptic curve cryptography are widely used for key exchange, authentication, certificates, digital signatures, secure software updates, and trust relationships between systems. That’s where migration planning is most important, and it’s where SLED organizations should be asking practical question like:
- Where do we use TLS, VPNs, SSH, S/MIME, digital signatures, certificates, identity federation, secure boot, code signing, HSMs, and key management systems?
- Which of those systems protect long-lived sensitive data?
- Which vendors control those systems?
- Which systems are too old to support new cryptographic algorithms?
- Which data would be damaging if collected today and decrypted years from now?
For public safety and CJIS environments, this is especially important because criminal justice data often has a long, useful life and strict handling expectations. For K–12 and higher education, student records may be retained for years. For health and human services, protected information can remain sensitive for a lifetime. For utilities and transportation agencies, infrastructure documentation and operational data can create long-term risk if exposed. The longer the data must remain confidential, the earlier it should appear in a PQC planning conversation.
What Works in Practice
The organizations that will handle this transition well are the ones building a disciplined plan rather than chasing the latest quantum-safe product.
- The first step is cryptographic inventory: identifying where cryptography exists across systems, applications, cloud services, devices, and third-party platforms, including algorithms, certificates, key lengths, protocols, libraries, and vendor-managed dependencies where possible This exercise is going to be hard.
- The second step is data and system prioritization, since not every system needs to move at the same speed. A public-facing website with low sensitivity is different from a system protecting criminal justice records, health data, student records, tax data, identity systems, or infrastructure controls.
- The third step is vendor alignment, because many SLED organizations depend on commercial software, SaaS platforms, managed services, legacy ERP systems, and specialized operational technology, Even if an organization wants to move quickly, it may not be able to move faster than its vendors.
- The fourth step is testing, since PQC support is not simply a checkbox. A product may support a new algorithm without being able to interoperate with every browser, endpoint, operating system, middleware layer, certificate authority, API gateway, or legacy application in the environment.
A quantum-safe VPN, for example, doesn’t automatically make the applications behind it quantum-safe. A cloud provider’s roadmap doesn’t automatically solve local identity, endpoint, database, or third-party integration issues. The right posture is controlled preparation: start with visibility, build a roadmap, prioritize high-value and long-lived data, engage vendors, test before changing production, and document the plan.
Procurement Guidance for SLED Leaders
This isn’t the moment to add broad, rigid PQC requirements into every procurement. The market is still maturing, standards are still emerging, and vendor roadmaps are uneven. Some products will claim readiness before the broader ecosystem can support reliable deployment. Instead, procurement teams should begin asking better questions. For new technology purchases, especially systems that use encryption, certificates, authentication, digital signatures, VPNs, identity, key management, or long-term data storage it is reasonable to ask vendors about their post-quantum cryptography roadmap, which NIST PQC standards they are tracking or planning to support, whether they maintain a cryptographic inventory or bill of materials for their product, how customers will be able to update cryptographic algorithms in the future, whether PQC support will require a new product, license, appliance, firmware update, or service migration, and what their expected timeline is for production-ready support.
These questions don’t force a premature technical requirement. They create market pressure, expose vendor maturity, and help SLED organizations avoid buying systems that will become expensive to retrofit later. For now, the best procurement language is not “PQC required”, It’s closer to: “Vendor must describe its approach to cryptographic agility, post-quantum cryptography readiness, and future support for NIST-standardized algorithms.”
The Bottom Line
Post-quantum cryptography will arrive as a long, uneven transition across infrastructure, applications, vendors, standards, and procurement cycles. For SLED organizations, the work should start now, but it should start with planning rather than panic.
The most important near-term actions are:
- Building a cryptographic inventory, identifying data that must remain confidential into the 2030s and beyond.
- Prioritizing CJIS, student records, health data, tax records, identity systems, and critical infrastructure information, asking vendors how they are preparing, and favoring crypto-agile products that can adapt as standards, operating systems, and applications evolve.
The G7 statement matters because it confirms the direction of travel, but the public sector does not need to solve the entire PQC migration today, it needs to stop treating it as someone else’s future problem.
References
- Source: G7 Cybersecurity Working Group PQC Statement
- Source: Canadian Centre for Cyber Security Frontier AI Guidance
About the author
Justin is the founder and CEO of nuHarbor, where he continues to advance modern integrated cybersecurity services. He has over 20 years of cybersecurity experience, much of it earned while leading security efforts for multinational corporations, most recently serving as global CISO at Keurig Green Mountain Coffee. Justin serves multiple local organizations in the public interest, including his board membership at Champlain College.
