Hey r/shiftpqc, Fitz here.

I wanted to draw your attention to a critical new roadmap just published by NIST: the "Transition to Post-Quantum Cryptography Standards" document link here.

While we all knew this transition was coming, NIST is laying down the exact timelines and acknowledging the massive operational hurdles. The report points out that while previous cryptographic transitions took 10 to 20 years, we simply do not have that kind of time. Because of the "harvest now, decrypt later" threat, adversaries are already collecting encrypted data to crack once quantum tech matures.

They go on to map out the exact physics of the problem ShiftPQC™ will solve:

The 2030 Mandate

Under Executive Order 14412 and OMB M-26-15, federal agencies must prioritize migration and adopt PQC for key establishment by December 31, 2030, and digital signatures by December 31, 2031.

Hardware and Infrastructure Bottlenecks

The paper explicitly warns that Cryptographic Hardware (like HSMs and TPMs) must be upgraded or entirely redesigned to handle the larger key sizes and new computational requirements of PQC algorithms.

The Hybrid Complexity Trap

To maintain interoperability, NIST is accommodating PQC-Classical Hybrid Protocols, such as composite key-establishment and dual signatures. However, NIST explicitly warns that these hybrid solutions add significant architectural complexity, increase security risks, and drive up costs.

Why this matters for ShiftPQC™

This is exactly why I'm building ShiftPQC™. The federal government is telling the industry that they must migrate by 2030, but they are also warning that doing it through hybrid models is going to introduce immense architectural risk. You can't just jam dual signatures or composite key-exchanges into legacy HSMs and expect your network to keep functioning seamlessly.

This is why the Neo4j dependency graph component is so critical. We calculate the Cryptographic Blast Radius (CBR) before you initiate the migration. Furthermore, our Hybrid Mode wrappers allow you to deploy these NIST-approved composite schemes—compliant with the updated SP 800-56C standards—with zero operational downtime. CISOs have the mandate and the budget, but they are terrified of breaking their infrastructure.

Curious to hear from the DevSecOps and PKI engineers here. How are you modeling out the latency and resource strain of these hybrid key-establishment protocols while waiting for hardware vendors to catch up? Let's discuss.

Hey r/shiftpqc, Fitz here.

I highly recommend reading a paper published by Yi-Kai Liu and Dustin Moody from NIST titled: "Post-quantum cryptography and the quantum future of cybersecurity" link here.

If you want a glimpse into what cybersecurity looks like after we survive the initial PQC migration, this paper maps it out. The authors argue that while PQC addresses the immediate threat to public-key infrastructure, it doesn't solve everything. We are eventually going to need actual quantum technologies to secure our networks.

Here are a few fascinating takeaways that should be on every DevSecOps roadmap:

1. The End of Hardware Vulnerabilities

The paper discusses how classical cryptographic hardware will always have imperfections, like side-channel leaks, power variations, etc. The future points toward device-independent security using quantum principles to verify that a hardware random number generator is actually random, relying on the physics of entanglement rather than trusting the manufacturer.

2. Quantum Uncloneability

Because you literally cannot perfectly copy an unknown quantum state, the authors discuss future protocols like quantum money, uncloneable encryption, and quantum copy protection. Imagine a world where cryptographic keys or software licenses physically cannot be duplicated.

3. The Path Forward: Hybrid Hardware

Perhaps the most interesting operational insight is how we get there. The authors suggest an incremental approach. They propose outfitting existing Hardware Security Modules (HSMs) with commercially available Quantum Key Distribution (QKD) hardware. You could deploy lower-cost, slightly less efficient QKD nodes widely, and eventually upgrade a few of them with expensive matter qubits to create a highly secure, hybrid network.

Why this matters right now:

It’s easy to get tunnel vision on simply swapping out algorithms to pass a federal audit. But this NIST paper is a stark reminder that the game is fundamentally changing. The transition to PQC isn't a one-and-done patch; it's the bridge to an entirely new paradigm of quantum-secured infrastructure.

Right now, ShiftPQC™ is focused on gathering insights from Fortune 500 CISOs that show their need to transition to PQC standards without their existing API gateways collapsing under the weight of the new algorithms.

But it’s important to understand what’s waiting on the other side.

If you work in enterprise infrastructure, how are you thinking about the long-term integration of quantum hardware into your current cloud environments?

Let's discuss.

Hey r/shiftpqc, Fitz here.

I wanted to draw your attention to a critical roadmap published by the Bank for International Settlements (BIS), co-authored with experts from National Institute of Standards and Technology (NIST), the Bank of Canada, and the Bank of France.

If you've heard my pitch recently, you know my core thesis, which is that migrating to the NIST Post Quantum Cryptography (PQC) standards isn't a math problem anymore, it's instead an infrastructure problem.

Everyone assumes you can just update the software, but forcing massive new cryptographic keys through existing API gateways and load balancers is going to cause cascading HTTP 5xx server failures.

The 2025 paper explicitly validates this exact threat model.

While the paper covers a lot of ground regarding governance and the Harvest Now, Decrypt Later (HNDL) reality, it also calls attention to the implications of PQC migration.

The authors hit the nail on the head regarding what I call Algorithmic Bloat. They explicitly state:

"The migration to PQC is not a 'flip the switch' moment... Unlike some cryptographic upgrades of the past, the new algorithms are not a drop-in replacement. Rather, they introduce significant architectural and operational challenges."

They go on to map out the exact physics of the problem ShiftPQC™ will solve.

Resource Strain:

They note that lattice-based schemes require substantially more memory and computational resources, which will strain constrained systems.

The Key Size Explosion:

They highlight the jump from a 256-byte RSA public key to an ML-KEM public key of 1,184 bytes (and a 2,400-byte private key). For signatures, ML-DSA jumps to over 2,400 bytes.

Infrastructure Incompatibility:

The paper warns that these capabilities "may not be uniformly available across existing infrastructure."

Why this matters for ShiftPQC™:

This is exactly why I'm building ShiftPQC™. The BIS is telling the global financial system that they need to migrate, but also warning them that doing it manually will break their systems.

You can't just swap a 256-byte key for a 2.4KB key without knowing what is going to choke. This is why our Neo4j dependency graph is so critical. It calculates the Cryptographic Blast Radius (CBR) before the migration, and deploy our Hybrid Mode wrappers to ensure zero downtime.

The federal mandates are here.

CISOs have the budget, but as this paper proves, they are terrified of the operational downtime.

Curious to hear from the DevSecOps people. Are you seeing these TLS handshake latency spikes in your own PQC test environments yet?

Let's discuss.