EO 14409: The 2030 PQC Clock is Ticking - How's Your Crypto Inventory?
Just saw the news regarding the executive order signed on June 22. EO 14409 finally puts hard dates on the Post-Quantum Cryptography (PQC) migration: 2030 for Key Establishment (think CRYSTALS-Kyber) and 2031 for Digital Signatures (likely Dilithium/SPHINCS+).
While 2030 feels like a comfortable buffer, the "Harvest Now, Decrypt Later" threat landscape isn't waiting. If you aren't inventorying your high-value assets (HVAs) now, you're already behind. The biggest hurdle I see isn't just swapping algorithms, but identifying where legacy RSA-2048 and ECDSA are hardcoded in older embedded systems and legacy apps that can't easily be patched.
If you're in the Fed space or a contractor, you need to start flagging these systems now. Here is a quick Nmap script I'm using to identify weak key exchanges on external-facing assets during recon to see what needs replacing:
nmap --script ssl-enum-ciphers -p 443 | grep -E "RSA|ECDSA"
For internal automation, I'm using a Python wrapper to flag RSA keys in our cert store before we even think about moving to hybrid certificates:
import subprocess
from cryptography.hazmat.primitives import serialization
def check_crypto_strength(cert_path):
with open(cert_path, "rb") as f:
cert = serialization.load_pem_x509_certificate(f.read())
pubkey = cert.public_key()
if hasattr(pubkey, 'key_size'):
print(f"{cert_path}: {pubkey.__class__.__name__} - {pubkey.key_size} bits")
The national security systems (NSS) exemption is interesting—likely they are already further down this road. For the rest of us, are you planning for a hybrid rollout (classic + PQC) to mitigate risks during the transition, or are you waiting for pure-play PQC standards to mature?
The hybrid approach is the only sane way forward. We tested pure PQC on our load balancers and saw a 15% latency spike due to the larger handshake sizes. We're sticking to hybrid mode until NIST finalizes the implementation guides for FIPS 203. Also, don't forget your PKI infrastructure; upgrading your CA signing keys is going to be a nightmare if you don't have a solid revocation plan.
Great script. From a SOC perspective, we're looking for network anomalies that might indicate 'store now' attacks. We're flagging any large volume outbound TLS handshakes that look like passive collection. While there isn't a specific CVE for 'quantum decryption' yet, if your threat model includes state actors, you have to assume RSA-2048 is effectively already broken.
Anyone looked at Cloudflare's implementation? They rolled out X25519Kyber768Draft00 a while back. It seems the industry standard is converging on Kyber for KEM. Just make sure your hardware acceleration (HSMs/TPMs) supports it, otherwise, you'll be doing software crypto on your CPUs and that kills throughput on high-traffic servers.
Inventory is the hardest part. We found that automated scanning often misses shadow IT or custom hardware. I recommend checking your external perimeter for weak algorithms first. You can use Nmap to enumerate current ciphers and key exchange methods to establish a migration baseline:
nmap --script ssl-enum-ciphers -p 443 192.168.1.0/24
This helps identify where you are still relying on RSA-2048 so you can prioritize the rollout of hybrid KEMs like Kyber.
Don't forget to audit the keys already in use alongside network traffic. You might find legacy RSA keys hiding on servers that need priority replacement. Run this to check your SSH host key sizes:
find /etc/ssh -name "host_key*" -exec ssh-keygen -lf {} \;
Finding these now prevents a migration bottleneck later. Is anyone seeing resistance from dev teams regarding key rotation?
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access