--- title: "Post-quantum questions to ask your vendors" source: "https://www.cyber.gov.au/sites/default/files/2026-07/Post-quantum%20questions%20to%20ask%20your%20vendors.pdf" collection: "asd-pqc" guidance_commit: "db3111cd9d11643ac08b34b4d75b0d0d983ca388" --- Post-quantum questions to ask your vendors Evaluating third-party readiness for post-quantum cryptography First published: July 2026 Table of contents Introduction ........................................................................................................... 1 Early engagement on post-quantum readiness ...................................................... 2 Questions to ask vendors ....................................................................................... 2 Locate and inventory cryptographic dependencies ................................................................... 3 Assess risk to individual systems ................................................................................................ 5 Triage and prioritise systems for transition ............................................................................... 7 Implement post-quantum cryptographic algorithms................................................................. 8 Communicate with vendors and educate relevant stakeholders ............................................ 10 Common concerns in vendor responses ................................................................11 Summarised list of post-quantum questions to ask vendors .................................12 Locate ....................................................................................................................................... 12 Assess........................................................................................................................................ 12 Triage ........................................................................................................................................ 13 Implement ................................................................................................................................ 13 Communicate and educate ...................................................................................................... 13 Post-quantum questions to ask your vendors Introduction Future advances in quantum computing will render traditional asymmetric cryptography vulnerable. A quantum system capable of breaking widely used public-key cryptography is referred to as a cryptographically relevant quantum computer (CRQC). Post-quantum cryptography (PQC) provides a practical and effective way to mitigate risks posed by a CRQC. Achieving a timely and secure transition to PQC will depend on effective organisational planning and on vendors whose products and services align with those plans and timelines. Many organisations rely on third-party vendor products, managed services and cloud services to deliver core business and cyber security functions. In these environments, vendors often implement and control cryptographic mechanisms rather than the organisation. As a result, vendor readiness plays a crucial role in an organisation’s ability to transition to PQC. Cryptographic exposure also exists beyond cloud and vendor-managed environments. In systems such as industrial control, access control and network devices, cryptography is often embedded, difficult to update and tied to long asset lifecycles. This can constrain transition timelines and may require vendor support or hardware replacement. These environments include: • on-premises systems • legacy systems • operational technology • Internet of Things • building management systems • physical access and security systems. To support organisations in their PQC transition, this publication provides a set of vendor-neutral readiness questions to use during procurement activities, contract renewals or ongoing vendor assurance processes. These questions help organisations assess how well a vendor: • understands quantum-related risks • maintains transparency over its cryptographic implementations • supports a secure, cost-effective and timely transition to PQC. This publication is intended for cyber security leaders, procurement and vendor management teams, and technical stakeholders responsible for assessing third-party readiness for PQC. In this publication, the term ‘vendor’ refers to third-party suppliers of products or services. The term ‘product or service’ includes any vendor-supplied software, hardware, managed service or cloud-based capability that implements or relies on cryptography. Post-quantum questions to ask your vendors Early engagement on post-quantum readiness Reliance on vendors means that an organisation’s transition to PQC will often depend on the readiness, transparency and roadmaps of its vendors. Even where an organisation has strong cryptographic expertise and a refined PQC transition plan, weaknesses or delays within the supply chain can undermine these efforts and introduce residual risk. Engaging vendors early on PQC readiness helps organisations: • understand vendor awareness and maturity levels • identify potential risks or misalignments • ensure vendor roadmaps support organisational transition plans • support consistent expectations across procurement, contract management and vendor assurance activities. Early and structured engagement also reduces the likelihood of late-stage surprises. For example, finding that a critical product, service or dependency cannot support PQC within required timeframes. Questions to ask vendors The following questions align to the high-level phases of an organisation’s PQC transition, as outlined in the Australian Signals Directorate's (ASD) LATICE framework in Planning for post- quantum cryptography: • Locate and inventory cryptographic dependencies. • Assess risk to individual systems. • Triage and prioritise systems for transition. • Implement post-quantum cryptographic algorithms. • Communicate with vendors and educate relevant stakeholders. Post-quantum questions to ask your vendors These questions are intended as a practical tool to support structured engagement with vendors. Organisations can apply them across different vendor types and risk profiles, and adapt them to reflect the risk level of products and services that the vendor provides. Organisations are not expected to ask every question of every vendor. Instead, apply the questions based on the: • risk level of the product or service • degree of cryptographic control exercised by the vendor • sensitivity and longevity of data involved • organisation’s current stage of PQC transition. Not all vendors may be able to provide detailed responses initially. However, a vendor’s willingness to engage transparently, discuss constraints and demonstrate progress can indicate maturity in both PQC and overall cyber security. Each question includes an explanation of its relevance, along with key considerations to help evaluate vendor responses. Locate and inventory cryptographic dependencies The goal of this phase is to identify where and how a vendor uses cryptography within their products and services, including for authentication, key exchange, signing, data in transit and data at rest. This may include vendor-managed or cloud-based services that rely on cryptography to authenticate, protect or access organisational systems, such as: • Software as a Service • managed service providers • identity services • backup services • other third-party platforms. Gaining early visibility of cryptographic dependencies helps organisations avoid unexpected constraints during PQC transition. Particularly where dependencies are embedded, inherited or difficult to change. Organisations should prioritise these questions early in vendor engagement. This is particularly important during the early stages of PQC planning, or before entering long-term contracts or cloud service agreements, where cryptographic choices may be difficult to change. Post-quantum questions to ask your vendors Question Why it matters Key response considerations Do you maintain a Inventorying cryptographic A complete and current current inventory of dependencies helps identify and inventory (such as a CBOM) that cryptographic manage algorithms, libraries, lists algorithms, protocols, dependencies, such protocols, parameters and libraries, parameters and as a cryptographic configurations across a system. This configurations, including third- bill of materials includes where cryptography party and embedded (CBOM) or underpins authentication, signing, components. The inventory equivalent artefacts? and data protection (in transit or at should be actively maintained rest). and kept up to date. Where is Cryptography may exist across Clear identification of cryptography multiple layers such as application, cryptographic use across all implemented? operating system, middleware, layers, with no reliance on hardware and firmware. assumptions. Understanding where it is implemented helps assess PQC transition complexity and feasibility. Is any cryptography Cryptography embedded in Confirmation that no such hard- hardcoded, fixed or software, firmware, or hardware can coded, fixed or hardware-bound hardware bound? be difficult to replace and may cryptography exists. dictate transition timelines. Otherwise, identification of Identifying these dependencies early affected components across reduces the risk of delays or forced products or services, along with system replacement. a feasible remediation roadmap such as patching, firmware upgrades, or replacement. Do third-party Supply chain components frequently Transparent disclosure of all dependencies define cryptographic behaviour. dependencies that introduce introduce Visibility of inherited cryptography cryptography, including the cryptography? helps prevent hidden blockers, cryptographic libraries they rely support coordination across on. dependencies, and reduce PQC Standardised libraries are transition complexity. preferred over bespoke or proprietary implementations and should be tracked within a CBOM or equivalent inventory. Post-quantum questions to ask your vendors Question Why it matters Key response considerations How is cryptography Patch-based cryptographic updates Updates delivered through updated? support cryptographic agility, reduce supported patches or operational disruption and help maintenance releases, with clear avoid large-scale system long-term support replacements during PQC transition. commitments. Do your products or Hardware trust anchors can lock in Identification of hardware trust services rely on cryptographic choices and constrain anchors and their role in hardware roots of transition pathways, particularly cryptographic operations. For trust? where cryptographic functions example, Trusted Platform depend on fixed hardware Module, Hardware Security capabilities. Module, and secure enclave usage. How is firmware Firmware signing mechanisms are Clear description of firmware authenticity verified? long-lived and difficult to change, signing mechanisms, such as making them a key constraint for Secure Boot or Unified PQC transition. Extensible Firmware Interface. Are firmware and Firmware and boot-chain Evidence that firmware and boot boot processes cryptography may require device processes can be updated updatable to support replacement if not designed for without hardware replacement. PQC signature cryptographic agility. Otherwise, a roadmap for schemes? supporting PQC-compatible signature schemes. Assess risk to individual systems The goal of this phase is to understand which data and trust decisions rely on traditional asymmetric cryptography, how sensitive and long-lived that data is, and how the vendor assesses the risks posed by a CRQC. Organisations should use these questions to assess how quantum-related risks apply to a vendor’s products or services. This phase is particularly relevant for systems that protect sensitive or long- lived data, or that are externally exposed. Post-quantum questions to ask your vendors Question Why it matters Key response considerations Which customer data Explicit mapping of authentication, Clear mapping of customer data flows rely on key exchange, and signing pathways flows that use traditional traditional is needed to assess exposure, select asymmetric cryptography across asymmetric appropriate transition approaches interfaces and protocols, cryptography? and identify edge cases during including whether those flows testing. protect authentication, key establishment or data integrity. What data lifetime Data with long-lived confidentiality Clear articulation of data lifetime assumptions does requirements is at risk from future assumptions, default retention your product or CRQC-enabled attacks, such as behaviours and customer service make for the ‘harvest now, decrypt later’, and controls. These are reflected in data it processes or may require earlier transition to the vendor’s PQC roadmap and stores, and how can PQC. customer configuration customers configure guidance. or manage those lifetimes? Do you have a Demonstrates that the vendor A documented internal documented, understands quantum-related assessment that clearly states product- or service- cryptographic risks, anticipated scope, assumptions and specific assessment timelines and mitigation strategies outcomes. It also demonstrates of risks posed by a in line with ASD guidance. consideration of authoritative CRQC? guidance. Do you distinguish Signing, encryption and Clear separation of signing, between signing, authentication failures have encryption and authentication encryption and different impacts and timelines. use cases, with distinct risk authentication risks? Integrity and authentication risks assessments, transition timelines may require different transition and mitigation strategies for sequences and controls compared each. to confidentiality risks. Can customers Using stronger traditional Higher security strength options choose stronger cryptographic settings, such as are available as supported, cryptographic larger key sizes, may provide documented configurations settings today? marginal, short-term risk reduction. rather than bespoke or one-off However, these measures do not implementations. mitigate the impact of a CRQC and are not a substitute for PQC transition. Post-quantum questions to ask your vendors Question Why it matters Key response considerations What authentication Authentication systems often have Identification of authentication mechanisms rely on long replacement cycles and may mechanisms, such as certificates, traditional become critical bottlenecks. smartcards and tokens, including asymmetric their lifecycle and replacement cryptography? timelines. Triage and prioritise systems for transition The goal of this phase is to ensure that the vendor’s transition sequence aligns with organisational risk priorities and ASD’s recommended PQC milestones. This should be guided by a risk-based approach to prioritisation. This phase includes identifying hard blockers early and ensuring that any use of post- quantum/traditional (PQ/T) hybrid approaches is limited to a short-term transition period. Organisations should prioritise these questions once they understand key cryptographic dependencies and risks. This helps determine whether vendor transition plans and timelines align with organisational risk-based priorities and PQC transition milestones. Question Why it matters Key response considerations Which products or Concrete vendor readiness dates Product- or service-specific and services will be PQC- enable organisations to plan testing, versioned commitments for ready early enough transition and procurement activities PQC-ready releases. Offerings to support customer in time to complete PQC transition by should be available in advance of rollout before the the end of 2030. 2030 to allow for customer end of 2030? testing, staged transition, and production rollout. Which components Components requiring hardware Transparent disclosure of require hardware replacement or re-architecture, components requiring hardware replacement or re- rather than straightforward updates, replacement or re-architecture, architecture? are typically long-lead items and can including the reasons for significantly affect timelines, cost and redesign, known constraints or interoperability during PQC bottlenecks, and any resulting transition. impacts on delivery timelines. Post-quantum questions to ask your vendors Question Why it matters Key response considerations Do you support PQ/T hybrid schemes may support Hybrid schemes, if supported, PQ/T hybrid modes short-term interoperability or are clearly defined as a as a temporary resiliency, but are not recommended transitional measure only. transition as a long-term solution. The presence Responses should include a mechanism, and of a CRQC would render the documented plan and timeline how and when will traditional elements obsolete, for de-hybridisation and you transition to requiring transition to purely post- transition to PQC-only. PQC-only? quantum cryptographic algorithms. How do you Risk-based prioritisation helps ensure A documented and risk-based consider customer that customers with higher exposure prioritisation approach that risk when or more sensitive data are not considers factors such as system prioritising PQC delayed due to purely commercial or exposure, data sensitivity and transition activities? operational considerations. transition complexity, rather than customer size or revenue. What internal Clear governance and executive Defined governance structures governance accountability reduce with executive ownership, arrangements implementation risk and support documented decision forums, oversee your PQC consistent prioritisation across and regular review cycles transitions? products or services. This includes overseeing PQC planning, products and services delivered delivery and customer impact through managed or shared across products or services. platforms. Implement post-quantum cryptographic algorithms The goal of this phase is to ensure post-quantum cryptographic algorithms are implemented securely. This includes: • avoiding premature, proprietary or experimental cryptography • adopting standardised and reputable libraries • planning for performance, key management and safe rollback. Organisations should apply these questions when evaluating a vendor’s technical readiness to deliver PQC in production. This phase is particularly important before enabling PQC in live environments or committing to major upgrades that would be difficult to reverse. Post-quantum questions to ask your vendors Question Why it matters Key response considerations Which post-quantum Support for standards-based post- A clear commitment to cryptographic quantum cryptographic algorithms standards-based, ASD-approved algorithms will you underpins interoperability, algorithms with defined support, and when assurance and the long-term timelines outlining when support will support be sustainability of PQC deployments. will be available to customers. generally available to customers? Is your PQC Production-ready implementations Availability as a supported, implementation minimise operational risk and help customer-deployable release, production-ready organisations avoid relying on with defined support and available for preview, experimental or arrangements (such as service- customer use? unsupported cryptographic level agreements) and functionality during PQC transition. documented guidance for production deployments and operation. How do you validate Using reputable and well- Use of reputable and actively and maintain maintained cryptographic libraries maintained cryptographic cryptographic reduces security, compliance and libraries with evidence of libraries? long-term maintenance risks, and validation or independent supports the secure adoption of scrutiny. Bespoke or proprietary PQC. cryptographic implementations should be avoided, where possible. How will key PQC can increase key and certificate Clear explanation of changes to management, sizes, affecting operational key and certificate sizes, certificate sizes and processes and system performance. lifecycles and operational lifecycle processes Poor planning may lead to processes, including any impacts change under PQC? performance or compatibility issues. on existing systems and how these will be supported in production. How do customers Clear and supported enablement Documented configuration and enable PQC in your processes reduce deployment risk deployment steps, including product or service? and help ensure predictable and prerequisites and known safe transitions to PQC. compatibility or interoperability considerations for relevant protocols and integrations. Post-quantum questions to ask your vendors Question Why it matters Key response considerations Is PQC included in Including PQC in base licensing Confirmation PQC functionality base licensing? avoids security controls being is included under standard paywalled, which could delay licensing terms, without adoption and lead to uneven risk additional licensing fees or across customers. premium add-ons. Communicate with vendors and educate relevant stakeholders This phase helps institutionalise change and sustain security posture beyond initial PQC transition timeframes. The goal of this phase is to ensure: • clear communication with vendors • well-defined cryptographic deprecation roadmaps • appropriately trained support staff. Organisations should use these questions throughout the PQC transition to maintain effective vendor engagement. This phase is critical for managing cryptographic change, minimising customer impact, and supporting long-term operational readiness. Question Why it matters Key response considerations How are customers Proactive notification of cryptographic Formal and predictable notified of changes enables organisations to assess communication mechanisms, cryptographic impact, schedule testing, and maintain such as security advisories, changes? security and compliance requirements. pre-release notes and transition notices. Do you provide Clear and practical transition guidance Clear and customer-ready customer-ready reduces integration effort and errors. instructions for enabling and transition guides for This supports safer and more efficient validating PQC, including PQC? adoption of PQC. examples and testing guidance. How will traditional Phased deprecation with clear notice Clear deprecation timelines cryptography be periods helps avoid abrupt change, covering warning periods, deprecated, including supports parallel testing, and ensures support windows, any any temporary use of hybrid approaches remain temporary interim hybrid use, and final PQ/T hybrid during transition. removal of traditional approaches? cryptography, with a defined path to PQC-only operation. Post-quantum questions to ask your vendors Question Why it matters Key response considerations Are your support and Trained teams reduce support risk and Evidence of staff training, engineering teams accelerate incident resolution during updated runbooks, and trained to support transition. documentation of known PQC? issues. Does your roadmap Alignment with authoritative guidance Roadmaps that reference align with ASD helps avoid dead-ends and ensures relevant ASD guidance with guidance and customer transition plans can be clear milestones supporting support PQC completed within expected timeframes. customer testing, transition transition by the end and production rollout of 2030? before the end of 2030. Do you contribute to Engagement with standards bodies Evidence of participation in, or track relevant PQC supports alignment with emerging PQC or tracking of, relevant standards bodies, standards, reduces incompatibility risks, standards bodies and how and how does this and enables vendors to share this informs product influence your implementation challenges to improve roadmaps and roadmap? practicality and interoperability. implementation decisions. Common concerns in vendor responses When engaging vendors on PQC readiness, organisations may encounter responses that indicate differing levels of maturity, visibility or preparedness. These concerns do not necessarily indicate unacceptable risk. However, they may warrant additional follow-up, risk treatment or attention depending on the risk level of the vendor and the products or services provided. Organisations should consider these concerns in context, including the risk level of the vendor, the sensitivity and lifetime of data involved, and the vendor’s willingness to engage transparently. Used alongside the questions in this publication, these considerations support risk-informed decisions when managing cryptographic dependencies across the supply chain. Some common concerns in vendor responses may include: • limited visibility of cryptographic use • reliance on general assurances • unclear or deferred transition timelines • use of proprietary or opaque cryptography • treatment of PQC as an optional or premium function • over-reliance on compensating controls • lack of governance or ownership. Post-quantum questions to ask your vendors Summarised list of post-quantum questions to ask vendors Use these questions, which align to the key phases of ASD’s LATICE framework, to assess vendor readiness for PQC. Organisations are not expected to ask every question of every vendor. Instead, apply the questions based on the vendor’s risk level, the degree of cryptographic control exercised by the vendor, data sensitivity and longevity, and the organisation’s current stage of PQC transition. Locate • Do you maintain a current inventory of cryptographic dependencies, such as a CBOM or equivalent artefacts? • Where is cryptography implemented? • Is any cryptography hardcoded, fixed or hardware bound? • Do third-party dependencies introduce cryptography? • How is cryptography updated? • Do your products rely on hardware roots of trust? • How is firmware authenticity verified? • Are firmware and boot processes updatable to support PQC signature schemes? Assess • Which customer data flows rely on traditional asymmetric cryptography? • What data lifetime assumptions does your product or service make for the data it processes or stores, and how can customers configure or manage those lifetimes? • Do you have a documented, product- or service-specific assessment of risks posed by a CRQC? • Do you distinguish between signing, encryption and authentication risks? • Can customers choose stronger cryptographic settings today? • What authentication mechanisms rely on traditional asymmetric cryptography? Post-quantum questions to ask your vendors Triage • Which products or services will be PQC-ready early enough to support customer rollout before the end of 2030? • Which components require hardware replacement or re-architecture? • Do you support PQ/T hybrid modes as a temporary transition mechanism, and how and when will you transition to PQC-only? • How do you consider customer risk when prioritising PQC transition activities? • What internal governance arrangements oversee your PQC transitions? Implement • Which post-quantum cryptographic algorithms will you support, and when will support be generally available to customers? • Is your PQC implementation production-ready and available for customer use? • How do you validate and maintain cryptographic libraries? • How will key management, certificate sizes and lifecycle processes change under PQC? • How do customers enable PQC in your product or service? • Is PQC included in base licensing? Communicate and educate • How are customers notified of cryptographic changes? • Do you provide customer-ready transition guides for PQC? • How will traditional cryptography be deprecated, including any temporary use of PQ/T hybrid approaches? • Are your support and engineering teams trained to support PQC? • Does your roadmap align with ASD guidance and support PQC transition by the end of 2030? • Do you contribute to or track relevant PQC standards bodies, and how does this influence your roadmap? Post-quantum questions to ask your vendors Disclaimer The material in this guide is of a general nature and should not be regarded as legal advice or relied on for assistance in any particular circumstance or emergency situation. In any important matter, you should seek appropriate independent professional advice in relation to your own circumstances. The Commonwealth accepts no responsibility or liability for any damage, loss or expense incurred as a result of the reliance on information contained in this guide. Copyright © Commonwealth of Australia 2026 With the exception of the Coat of Arms and where otherwise stated, all material presented in this publication is provided under a Creative Commons Attribution 4.0 International license (https://creativecommons.org/licenses/by/4.0/). For the avoidance of doubt, this means this license only applies to material as set out in this document. The details of the relevant license conditions are available on the Creative Commons website as is the full legal code for the CC BY 4.0 license (https://creativecommons.org/licenses/by/4.0/legalcode.en). Use of the Coat of Arms The terms under which the Coat of Arms can be used are detailed on the Department of the Prime Minister and Cabinet website (https://www.pmc.gov.au/resources/commonwealth-coat-arms-information-and- guidelines).