NIST finalized FIPS 203 for ML-KEM, FIPS 204 for ML-DSA, and FIPS 205 for SLH-DSA in August 2024. NIST says organizations can begin transitioning to these standards now. That does not mean an administrator should manually substitute algorithms in a camera, access panel, VPN, certificate authority, or application; protocols, implementations, interoperability, hardware, and vendor support must be ready.
\r\nNIST CSWP 39 Update 1 defines crypto agility as capabilities to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. The NCCoE Migration to Post-Quantum Cryptography project places cryptographic discovery and inventory at the center of risk management and prioritization.
\r\nSecurity systems often mix long asset lives with embedded firmware, proprietary protocols, appliance operating systems, certificates, smart credentials, signed updates, remote access, cloud services, archived evidence, and integrations that may be difficult to change independently. A product can remain mechanically useful after its cryptographic dependencies become unsupported. Replacing an algorithm may require new firmware, silicon, certificates, readers, credentials, server software, licensing, bandwidth, storage, or an entire integration path.
\r\nQuantum risk is not the only reason to build visibility. Certificates expire, trust stores age, algorithms are deprecated, libraries reach end of support, keys are exposed, and vendors change services. An inventory built for post-quantum planning also makes ordinary cryptographic transitions less disruptive.
\r\nFor each system and data flow, record:
\r\nDo not collect private keys into the inventory. Record their managed location and custody. Protect the inventory because it maps sensitive trust relationships.
\r\nStart with public-key cryptography used to protect data that must remain confidential for many years, internet-facing and remote-access paths, central identity and certificate services, signed software and firmware, high-impact services, hard-to-replace embedded products, and systems with long procurement cycles. Include stored captures and backups: information intercepted today may still be sensitive when future capabilities change the threat.
\r\nNISTIR 8547 is an initial public draft describing an expected transition approach, not a final universal deadline for every private system. DSE recommends tracking final NIST and sector guidance and mapping it to the organization’s own data lifetimes, products, obligations, and risk tolerance.
\r\nAsk which product versions and cryptographic modules are affected; whether algorithms and certificates can change without hardware replacement; which PQC standards and protocol profiles are planned or supported; whether hybrid or dual-stack modes are available; how rollback and downgrade are controlled; what performance, packet-size, storage, and interoperability testing has been completed; and how long classical and post-quantum modes will coexist. Require dated, product-specific evidence instead of a corporate quantum-ready slogan.
\r\nUse vendor-supported implementations in a representative lab. Validate enrollment, certificate issuance and renewal, mutual authentication, video and access latency, failover, signed update verification, export verification, backup and restore, monitoring, rollback, and mixed-version interoperability. Record capacity and availability effects. Never invent a hybrid construction or deploy a draft algorithm merely to claim readiness.
\r\nTurn findings into a roadmap: quick configuration changes, software upgrades, certificate-service work, vendor-dependent items, contract requirements, and hardware replacement. Assign owners and decision dates. Crypto agility is achieved when the organization can execute a tested change while preserving security and service—not when a spreadsheet merely lists algorithms.
\r\n