Inventory cryptography before long-lived systems trap it

Source fact: standardized post-quantum algorithms are available

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.

NIST 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.

Why physical-security estates deserve early attention

Security 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.

Quantum 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.

DSE recommendation: inventory the use, not just the algorithm name

For each system and data flow, record:

• business service, owner, site, data classification, availability need, confidentiality lifetime, evidence-retention period, and asset replacement horizon;
• product, model, hardware revision, firmware or software, library or crypto module, vendor, support end, and management interface;
• cryptographic purpose: key establishment, encryption, digital signature, authentication, code signing, credential protection, storage, backup, or audit integrity;
• protocol and version, algorithm and parameters where observable, certificate issuer and profile, key location, trust anchor, renewal process, revocation, and recovery;
• peer or dependency: camera to recorder, reader to controller, client to server, appliance to cloud, VPN to remote user, update service to device, backup to repository, or exported evidence to verifier;
• discovery source, confidence, last verified date, migration option, test environment, vendor commitment, and unresolved exception.

Do not collect private keys into the inventory. Record their managed location and custody. Protect the inventory because it maps sensitive trust relationships.

Prioritize by exposure and time

Start 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.

NISTIR 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.

Make vendors show their migration boundary

Ask 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.

Test transition as an operational change

Use 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.

Turn 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.

Official sources

• NIST CSWP 39 Update 1, Considerations for Achieving Crypto Agility
• NCCoE Migration to Post-Quantum Cryptography
• NIST PQC Migration FAQ, updated June 30, 2026
• Draft NISTIR 8547, Transition to Post-Quantum Cryptography Standards
• NIST Post-Quantum Cryptography program and finalized standards