Cryptography Inventory: Post-Quantum Upgrade Guide

This guide walks you through creating a complete inventory of the cryptography used across your systems and identifying which components will need upgrades when quantum computers become practical. You’ll end with a prioritized list of cryptographic assets, their locations, and a clear view of what’s vulnerable to Shor’s and Grover’s algorithms.

What You’ll Need

• Access to your organization’s asset management system (CMDB, spreadsheets, or cloud provider inventories)
• Network scanning and discovery tools (Nmap, Nessus, or your existing vulnerability scanner)
• Source code repository access (Git, SVN, etc.) for application-level analysis
• Administrative credentials for servers, databases, and network devices
• A spreadsheet or database tool to track findings
• Documentation of existing security policies and compliance requirements

Step-by-Step

1. Define your scope. Decide which systems are in scope: all production servers, cloud services, employee endpoints, IoT devices, or a specific business unit. Document the boundaries so you don’t miss anything or waste time on systems you don’t control.
2. Create a data collection template. Set up columns for: system name, owner, location (on-prem/cloud), type (server, app, network device), cryptographic function (TLS, SSH, encryption at rest, signing, hashing), algorithm and key size, protocol version, data sensitivity, and current status (active, deprecated, in development).
3. Inventory network devices and servers. Use your vulnerability scanner or network mapper to identify devices. For each device, check the running configuration or use commands like openssl s_client -connect host:port to enumerate TLS certificates and cipher suites. For SSH, check sshd_config or use ssh -vv to see the key exchange algorithms.
4. Inventory applications and APIs. Review application code for cryptographic library usage. Look for imports of libraries like OpenSSL, Bouncy Castle, or .NET’s System.Security.Cryptography. Search for functions like RSA.encrypt, ECDSA.sign, SHA256, and AES. Document the key sizes and modes used.
5. Inventory data at rest. Identify databases, file servers, backup systems, and cloud storage that use encryption. Check for Transparent Data Encryption (TDE), disk encryption (BitLocker, LUKS), and application-level encryption. Note the algorithm (AES-256, etc.) and key management system.
6. Inventory certificates and PKI. Use tools like openssl x509 -in cert.pem -text or your certificate management platform to list all TLS certificates. Note the public key algorithm (RSA, ECDSA, EdDSA), key size, and expiration date. Also inventory internal CAs and root certificates.
7. Inventory key management systems (KMS). Document your HSM (Hardware Security Module) or cloud KMS (AWS KMS, Azure Key Vault, etc.) and the keys they manage. Note the algorithms and key sizes for each key.
8. Identify quantum-vulnerable algorithms. For each entry, classify the algorithm:
   • Shor’s algorithm risk (must replace): RSA, DSA, ECDSA, ECDH, Diffie-Hellman, and any elliptic curve cryptography. These are broken by quantum computers.
   • Grover’s algorithm risk (may need to double key size): Symmetric ciphers like AES and 3DES, and hash functions like SHA-2 and SHA-3. Grover’s algorithm halves the effective security strength, so AES-128 becomes 64-bit, which is too weak. AES-256 and SHA-384/512 are generally considered safe.
   • Quantum-safe: AES-256, SHA-384/512, and post-quantum algorithms (though these are not yet standardized).
9. Prioritize by risk. Rank systems by the sensitivity of the data they protect and the likelihood of a quantum attack. Systems with long-lived data (e.g., medical records, state secrets, financial data) are at higher risk because an attacker can harvest encrypted data now and decrypt it later.
10. Document dependencies. Note which systems rely on others. For example, a TLS certificate might be used by multiple services, or a shared KMS key might protect many databases. This helps plan upgrades without breaking dependencies.
11. Create the final report. Compile your findings into a clear document that lists every cryptographic asset, its current algorithm, the risk level, and a recommended action (replace, upgrade key size, or monitor). Include a timeline for remediation based on your organization’s risk appetite and the NIST post-quantum cryptography standardization timeline.

Common Mistakes

• Forgetting about internal systems. Many organizations focus on public-facing systems and miss internal databases, legacy applications, and internal CAs that are equally vulnerable.
• Only looking at TLS. Cryptography is used for much more than HTTPS: code signing, document signing, email encryption, VPNs, and database encryption all need to be inventoried.
• Not checking key sizes. RSA-2048 and RSA-4096 are both vulnerable to Shor’s algorithm, but AES-128 and AES-256 have different post-quantum implications. Be precise about key sizes.
• Assuming all hash functions are equal. SHA-256 is vulnerable to Grover’s algorithm for some uses (like digital signatures), but SHA-512 is not. Understand the difference.
• Not documenting key management. If you don’t know where keys are stored and how they’re rotated, you can’t plan a migration.

Tips

• Use automated tools. Vulnerability scanners like Nessus or Qualys can often enumerate TLS configurations across your network. Some tools have specific post-quantum readiness checks.
• Leverage your CMDB. If you have a well-maintained configuration management database, start there and verify its data with active scanning.
• Involve developers early. Application-level cryptography is often the hardest to discover. Ask developers to review their code and document any crypto they use.
• Track certificate expirations. Use certificate transparency logs or your CA’s management portal to get a list of all issued certificates.
• Plan for hybrid crypto. When you upgrade, consider implementing hybrid schemes that use both classical and post-quantum algorithms during the transition period.

Troubleshooting

• You can’t access a system. If you lack credentials, work with the system owner. If it’s a third-party service, request their security documentation or use a third-party scanner.
• Your scanner misses application-level crypto. Static code analysis tools (like SonarQube) can help find cryptographic usage in source code. For proprietary or closed-source apps, contact the vendor for a statement on their crypto roadmap.
• The inventory is too large. Prioritize by data sensitivity. Start with systems that process payment card data, health records, or other regulated data. You can always expand scope later.
• You find unknown certificates. Use the certificate’s serial number and issuer to trace it back to your internal CA or a public CA. If it’s unknown, treat it as a security incident and investigate.
• You’re unsure about a specific algorithm. Check the NIST post-quantum cryptography FAQ or the Crypto Agility guide from the NSA. When in doubt, assume it’s vulnerable until proven otherwise.

Frequently Asked Questions

What exactly is ‘post-quantum cryptography’?

Post-quantum cryptography (PQC) refers to cryptographic algorithms that are believed to be secure against attacks from both classical and quantum computers. NIST is standardizing several PQC algorithms, including CRYSTALS-Kyber for key exchange and CRYSTALS-Dilithium for signatures.

When will quantum computers break RSA?

No one knows for sure. Estimates range from 10 to 30 years, but the risk is the ‘harvest now, decrypt later’ attack. Encrypted data stolen today could be decrypted in the future, so you should protect long-lived data now.

Do I need to replace AES-256?

No. AES-256 is considered quantum-resistant because Grover’s algorithm only reduces its effective strength to 128 bits, which is still secure. However, AES-128 should be upgraded to AES-256.

What about SHA-256 hashes?

SHA-256 is still safe for most uses, but for digital signatures, the hash is part of the signature scheme which uses RSA or ECDSA, so the signature algorithm is vulnerable. For password hashing, SHA-256 is not ideal anyway, but quantum doesn’t change that.

How do I know if a system is using post-quantum-safe algorithms?

As of now, very few systems use PQC because NIST hasn’t finalized the standards. The safest approach is to assume everything using RSA, ECDSA, or ECDH is vulnerable and plan for migration.

Should I wait for NIST to finalize standards before doing anything?

No. You should start the inventory now, because it will take time to complete. You can also begin planning for crypto agility, so that when standards are finalized, you can quickly swap out algorithms.

Related

• Remove Desktop Icons Without Deleting in Windows 11
• Discord Down? How to Fix Connection Issues
• How to Format an SSD on Windows 11 (Safe & Easy)