The best starting point for transitioning from today's static, local spreadsheet tracking of cryptographic inventory is to automate and develop a Crypto Bill of Materials (CBOM), used to document your organization's Crypto Assets - the assets we can identify as "Shadow Cryptography", or hard-coded cryptographic libraries within your 3rd Party integrations that have historically evaded capture due to manual audit processes. Only through identification of the location of the apparatus which provide you RSA Signatures vulnerable to Quantum Attack and ECC Signatures vulnerable to Quantum Attack can you begin the Pilot Process of transitioning to PQC. During assessments of legacy middleware, we have corroborated that very few employees actually realize that the buffer sizes of legacy systems are inherently fixed. Classical algorithms utilize relatively small key sizes whereas PK algorithm (formerly called PQC such as ML-KEM - formerly called Kyber) have much larger payload sizes for public keys and ciphertexts. After deploying the larger payload sizes to assess and validate on these legacy systems, they have 'choked' or dropped packets as a result of buffer limitations which do not exist, only upon achieving full deployment, to address the realities of the physical restraints. In order to eliminate this potential interaction with the memory limits of legacy systems, through collaboration and discussion to develop a plan, we chose to deploy a hybrid key exchange to extend the perimeter of the network, rather than implementing a complete 'rip and replace' or complete re-coding of legacy systems. Instead of wrapping legacy traffic in the single layer protective tunnel enabling 'Harvest Now, Decrypt Later' mitigation strategy, and allowing for the continued functionality of legacy systems working only in classical protocols - until replacement/refactoring of legacy systems can occur with Crypto Agility for the appropriate Quantum Resilience.
We started with a hybrid Kyber pilot. It failed in week one. TLS 1.3 with X25519+Kyber-768 worked fine in the lab. Production? Half our traffic died. Legacy firewalls couldn't handle 1216-byte key shares. ClientHello exceeded MTU. Packets fragmented. Dropped. The inventory we should have done first would have flagged this. Instead, we learned 40% of edge appliances choked on post-quantum handshakes. Firmware too old. No upgrade path. Vendor EOL. Now the sequence is locked: inventory first, pilot second. Scan every segment for crypto dependencies. TLS versions. Key exchange. Cert chains. HSMs. Everything. The constraint that bit us hardest: hardcoded RSA-2048 in payment terminal firmware. No software path. Mitigation: segment those boxes, accelerate hardware swap, hybrid-only for everything else. NIST says 2030 for deprecation. 2035 for disallowance. We're not waiting.
The single most effective first step in our post quantum cryptography migration was doing a brutally honest cryptography inventory. Before pilots or algorithms, we needed to know where cryptography actually lived, not where documentation claimed it lived. That inventory changed everything. We cataloged TLS endpoints, internal service to service traffic, VPNs, SDKs, hardware appliances, and even third party integrations. What surprised me was not how much crypto we used, but how unevenly it was controlled. The biggest dependency this surfaced was legacy TLS termination on older load balancers and embedded devices that could not support hybrid key exchanges like X25519 plus CRYSTALS Kyber without firmware or OS upgrades. In a few cases, the vendor roadmap was vague or nonexistent. That discovery shaped our strategy. Instead of forcing a full TLS hybrid rollout everywhere, we started with a scoped pilot on east west traffic between services we fully controlled. We deployed hybrid key exchange only on a subset of internal endpoints where we owned the full stack and could roll back safely. That gave us performance data, operational confidence, and political capital internally. The mitigation for the legacy constraint was pragmatic isolation. We fronted unupgradeable systems with modern terminating proxies that could handle hybrid handshakes externally while maintaining classical crypto internally. It was not pure, but it reduced exposure without breaking production systems. The biggest lesson for me was that post quantum migration is less about math and more about plumbing. The inventory step was unglamorous, but it surfaced the real blockers early and prevented us from treating PQC like a simple algorithm swap.
Being deeply involved in cryptography advisory projects, I've seen that the single most effective first step in a post-quantum cryptography migration is almost always taking a comprehensive inventory of all cryptographic assets, rather than jumping straight into pilots or algorithm swaps. I remember working with a mid-sized enterprise that had dozens of services, legacy APIs, and client integrations, all relying on different key lengths and cipher suites. Without a full inventory, any pilot whether it was a TLS hybrid exchange with CRYSTALS-Kyber or a PQ-secured database risked hitting unexpected failures mid-deployment. During the inventory process, we quickly surfaced dependencies that were not immediately obvious, such as internal systems still relying on deprecated libraries or third-party SaaS integrations that only supported classical key exchanges. In one instance, a vendor used for secure messaging could not accommodate hybrid TLS handshakes, which meant our Kyber-based experiment couldn't propagate through the entire stack without breaking compatibility. That single discovery reshaped our migration roadmap, making us realize we had to approach PQ integration in phases. To mitigate this, we pragmatically layered a hybrid strategy. Classical ECC or RSA keys remained operational for services where vendor or protocol limitations existed, while PQ algorithms were piloted on internal services and client-facing APIs we controlled. One unexpected benefit of starting with inventory was how it informed internal policy and tooling. We automated reporting of crypto usage and key lifetimes, which made compliance audits far easier and gave us visibility into hidden vulnerabilities. In hindsight, this inventory-first approach made subsequent hybrid TLS pilots far more predictable. Rather than forcing a blunt replacement across the board, we could selectively enable CRYSTALS-Kyber where it was feasible, while maintaining classical fallbacks for constrained systems. It's a step that sounds simple but surfaces the messy realities of legacy dependencies, integration gaps, and operational constraints, allowing pragmatic mitigation before serious failures occur. At spectup, we often advise clients that these upfront visibility exercises save months of troubleshooting later and ensure that PQ adoption is gradual, safe, and strategically aligned with business-critical services.
The most effective first step is a reliability-style security game day that exercises key rotation, mTLS, and encryption paths in CI before introducing PQC. In our key-rotation drill, we uncovered a nightly ETL decrypting with a cached data key, so jobs appeared to succeed while producing unreadable downstream outputs. We mitigated it by adding noisy alerts, having the job re-fetch keys per batch, and verifying reads after writes, a pragmatic pattern for similar hidden dependencies.