OS & Platform Crypto PQC
Migrate OS-level cryptography to post-quantum algorithms: system TLS policies, SSH host keys, package signing, and FIPS mode compatibility.
Why this matters: The OS crypto stack — OpenSSL, SChannel, SSH host keys, package signing — is the foundation every application above it silently depends on; get this layer wrong and every app inherits the vulnerability, whether it knows it or not.
Start here: Migrate SSH host keys to ML-DSA-65 in step 3: the sshd_config changes and the known_hosts roll-out across a fleet are laid out in order.
For your role
- Developer / Engineer
- Audit the OS crypto components, then configure system-wide TLS policy on RHEL, Ubuntu and Windows, migrate SSH host keys to ML-DSA-65 with the sshd_config changes, and move RPM and DEB signing from RSA-4096 to ML-DSA-65.
- Security Architect
- FIPS 140-3 module PQC inclusion and the hybrid FIPS design in Step 5 decide what the platform layer can offer applications; the audit in Step 1 is the inventory.
- Researcher / Academic
- The FIPS 140-3 PQC inclusion analysis and the package-signing migration are the two areas where distribution support is still moving; the module records the current state.
- IT Ops / DevOps
- System crypto-policies, sshd_config for ML-DSA host keys and package-signing keys are the three changes you roll out; Step 1's audit lists what each host runs today.
Modern operating systems rely on a layered cryptographic stack that spans from the kernel to user applications. Understanding where each layer sits is essential for a complete migration. Unlike application-layer cryptography (where you control the library), OS-level crypto changes affect every service running on the system.
PQC migration touches every layer. System TLS configuration cascades to all applications that use system OpenSSL. SSH host key migration requires new key types. Package signing requires coordinated infrastructure upgrades.
System TLS traffic (HTTPS, API calls, database connections) and SSH sessions are being recorded today for future decryption. Every TLS 1.3 session using only classical key exchange is a potential HNDL target. Hybrid X25519MLKEM768 eliminates this risk with a single config change.
RHEL, Ubuntu, Windows Server, and macOS all have active PQC roadmaps. The migration timeline differs significantly — Windows Server 2025 has ML-KEM in a FIPS 140-3 validated module today, while Linux distros are still working towards full PQC FIPS module certification.
Related Resources
Products shown here are a representative selection — not an exhaustive list. For the full vendor landscape with PQC readiness status, visit the Tools & Products tab in this module or browse the Migrate catalog →
Inventory OS crypto components, configure system TLS, migrate SSH host keys, and check FIPS compatibility.
Check off all sections and mark this reading done.
Related modules
- Secrets Management & PQCSame track · Software Infrastructure · Same migration phase · Shares ML-DSA, ML-KEM, NIST SP 800-227
- Confidential Computing & TEEsSame migration phase · Shares ML-DSA, ML-KEM, NIST SP 800-227
- Web Gateway PQCSame migration phase · Shares ML-DSA, ML-KEM, NIST SP 800-227
- Database Encryption & PQCSame track · Software Infrastructure · Same migration phase · Shares ML-DSA, ML-KEM, FIPS 140-3
Check your understanding
15 questions on Operating System & Platform Crypto PQC, each with its answer and the reason.
Take the quizNext step
Produce the artifact: Infrastructure Modernization PlannerThis module belongs to phase 6 (Infrastructure & Performance); Infrastructure Modernization Planner produces a deliverable of that phase in the Command Center.
Learning module content can be inaccurate. Please double-check its information. Report inaccuracies in PQC Today GitHub Discussions.