CISA, NSA, and Australian Signals Directorate issue post-quantum vendor readiness guidance

CISA, the Australian Signals Directorate‘s Australian Cyber Security Centre, and the National Security Agency released joint guidance and a quick-reference checklist for checking vendor readiness for post-quantum cryptography. These algorithms resist attacks from ordinary computers and quantum-enabled systems.

The agencies warn that quantum computing progress will break widely used public-key cryptography. Organizations should get ready and adopt post-quantum cryptography before quantum computers capable of breaking current cryptography arrive.

Data meant to stay secret for years is at risk from harvest now, decrypt later attacks, and may need to shift to post-quantum cryptography earlier. Cryptography sits in systems that are difficult to update and remain in service for long periods, such as industrial control systems and internet-connected equipment, and those systems often depend on vendor support or replacement.

The guidance titled Post-quantum questions to ask your vendors supplies vendor-neutral questions for buying decisions, contract reviews, and checking vendor assurance. They help organizations judge how well a vendor understands quantum-related risks, whether the vendor is transparent about cryptographic implementations, and whether its shift to post-quantum cryptography will be secure, affordable, and on schedule.

The agencies asked vendors to set firm dates for post-quantum-ready product and service releases by the end of 2030. They should also prove roadmaps align with relevant guidance and cover customer testing, transition, and rollout by the end of 2030.

For vendors that offer post-quantum/traditional hybrid modes, organizations should treat those modes as temporary steps for short-term interoperability or resilience rather than a lasting answer. Vendors must also provide a written plan and schedule for moving to post-quantum-only operation, and should confirm that base licensing includes post-quantum cryptography at no extra charge and without premium add-ons.

Organizations depend heavily on third-party vendors that supply managed services, cloud capabilities, and other products built on cryptography. Organizations should understand their cryptographic dependencies and supplier-related risks, then build post-quantum considerations into procurement, contract renewals, and vendor assurance activities. Successful post-quantum transition depends on vendor readiness, and early, structured contact with suppliers is essential for planning.

Step one is finding and cataloging where a supplier uses cryptography. Suppliers should identify where and how they apply cryptography to verify identity, exchange keys, sign data, and protect information in transit and at rest. Vendors should keep a live, regularly refreshed list of cryptographic dependencies, for example a cryptographic bill of materials.

A cryptographic bill of materials builds on a software bill of materials by adding protocols, parameters, libraries, algorithms, and configurations. Vendors should identify where cryptography resides across application, operating system, middleware, hardware, and firmware layers rather than guessing.

When vendors hardcode, fix, or tie cryptography to hardware, it can dictate transition timelines and force organizations to replace systems. They should show that none exists, or list affected parts with a practical fix plan covering patches, firmware upgrades, or replacement.

Vendors should disclose each third-party dependency that adds cryptography, record it in an inventory or cryptographic bill of materials, and pick standardized libraries over bespoke or proprietary implementations. They should explain how they update cryptography via patch-based updates in supported maintenance releases backed by clear long-term support commitments.

Vendors should identify hardware roots of trust and explain the role those roots play in cryptographic operations. They should describe how they verify firmware authenticity using the Unified Extensible Firmware Interface or Secure Boot, because signing mechanisms meant to last are a core post-quantum constraint.

Vendors should split risks for signing, encryption, and authentication into separate risk assessments, schedules, and mitigation plans for each category. Larger keys and settings offered today provide at best limited short-term defense against quantum threats and cannot shield against future quantum computers capable of breaking current cryptography.

Vendors should name authentication methods based on traditional asymmetric cryptography, such as certificates, smart cards, and tokens, and provide their life cycles and replacement dates. They should identify which parts require hardware replacement or redesign, with reasons, constraints, bottlenecks, and delivery effects.

Vendors should use a documented, risk-based approach to prioritize post-quantum work, assessing how vulnerable systems are, how sensitive the data is, and how difficult the transition will be, rather than customer size or revenue. They should describe internal oversight for the transition, including executive ownership, minuted decision meetings, and scheduled reviews.

Vendors should name the post-quantum algorithms they intend to support and tell customers when they will be available, relying solely on standards-based algorithms approved by the relevant authorizing body. They should confirm the implementation is production-ready, offered as a supported release customers can deploy, backed by clear support terms and written deployment instructions.

Vendors should explain how shifting to post-quantum cryptography will change certificate sizes, key management, and lifecycle processes for current systems and production support. Larger keys and certificates may strain operations and system performance, and poor planning could cause performance or compatibility issues.

Vendors should show customers how to enable post-quantum cryptography, including how to set it up, deploy it, meet requirements, and handle known compatibility or interoperability issues. They should explain how customers hear about cryptographic changes through formal channels such as security advisories, transition notices, and pre-release notes.

Vendors should provide post-quantum transition guides written for customers, with clear instructions and examples plus testing guidance. They should explain the phaseout of traditional cryptography, laying out timelines for warnings, support, temporary hybrid use, and final removal, plus a defined path to post-quantum-only operation.

Vendors should show trained support and engineering teams working from current runbooks and records of known issues. They should show evidence of contributing to or tracking relevant post-quantum standards bodies, and explain how that involvement shapes roadmaps and implementation decisions.

Frequent weaknesses in vendor answers include little insight into cryptographic usage and reliance on sweeping assurances. Problems include vague or postponed transition schedules, secret or nonstandard cryptography, and treating post-quantum cryptography as optional or a paid extra. More concerns include leaning too heavily on compensating controls and lacking governance or ownership, and such worries do not by themselves equal unacceptable risk.

Organizations should weigh these issues based on vendor risk level, how sensitive and long-lived the data is, and whether the vendor engages openly. Resources are available on CISA‘s post-quantum initiative page.