G7 Cybersecurity Working Group Statement on preparing for a post-quantum cryptography migration

Governance

When presenting PQC to senior leadership, the following points may secure their buy-in and allow them to understand their role during the transition. It is important that senior leadership takes an active role in the promotion of PQC in their organization. They should provide direction to technical leads on the scale and pace of PQC migration. In turn, technical teams should provide senior leadership with estimates on the costs and what can be delivered within a given timeframe. They should also provide regular updates to senior leadership on progress against the timeframe.

Senior leaders are responsible for setting strategic priorities and allocating resources. It is important to note that PQC is not just a technical upgrade, but rather a core cyber security measure that should be integrated into existing organizational risk management processes and information security management systems (ISMS).

Timeframes

Unlike some cyber security threats which require rapid changes that can be disruptive and expensive, an advantage of PQC migration is its relatively long timeframe for implementation. Migration is expected to be completed in the private sector during the 2030s (specific dates will vary slightly by country; refer to your national guidelines for additional information). You should highlight to senior leadership that beginning a controlled migration early on will make migration more manageable and affordable.

Competition and excellence

Starting the PQC transition ahead of your competitors may signal to investors and customers that your organization is forward-thinking and takes cyber security seriously. To effectively engage senior leadership, you should stress the competitive advantage that early PQC adoption brings.

How to engage leadership

• Frame PQC as a business risk. For instance, emphasize the HNDL threat and the long-term impact on data confidentiality. You can also highlight that failure to act in a timely and structured manner may be more costly in the long run.
• Use the available resources from your national technical authority, including guidance relating to promoting cyber security to boards and executives. Highlight any deadlines for PQC completion.
• Position PQC migration as an opportunity for organizations to:
  • modernize infrastructure
  • improve resilience
  • demonstrate their dedication to cyber security by making PQC a part of their “normal” cyber security upgrade and refresh cycles

Practical steps

• Designate a board member accountable for PQC migration, including allocation of funding for the work. Where possible, this should be the member accountable for managing the wider cyber security risks of the organization. This individual should also be someone that is known to employees and with whom they can engage.
• Map cryptographic dependencies: Identify where PKC is used across systems and supply chains.
• Consider using consultants that specialize in PQC migration. Some countries have accreditation schemes for consultancies that have received training in this area.
• Join working groups: Collaborate with industry peers to share best practices and avoid duplication of effort. If these groups do not exist, consider establishing them to demonstrate leadership in your sector.
• Track progress: Use metrics to measure leadership awareness and decision-making impact.

Project teams

To prepare for the transition to PQC, it is recommended that organizations develop teams to oversee the work. Project teams should consist of stakeholders throughout the organization and include at least 1 member from senior management to lend necessary support. Although much of the work to be performed is technical, it is beneficial to include stakeholders in non-technical areas, including finance, project management, procurement and any other relevant stakeholders.

Below are a series of teams that your organization should consider standing up. This is not prescriptive, and you may find it works better to merge or exclude some of these teams based on your organization’s structure and requirements. You may also choose to outsource some of this work to consultants specializing in PQC. In this case, check if your national technical authority provides formal accreditation to these organizations.

Organizational awareness

As with most large projects, it is important that all affected stakeholders are aware of how PQC migration will impact them. It should be expected that the transition to PQC will affect most people in an organization and in varying ways, from the leadership who must oversee the work and provide the financing, to the employees who use the software and devices that will be transitioned.

Your communication goals should be to:

• inform senior leadership of the need to transition to PQC so that they can make necessary decisions for your organization. Discussion topics include the reason for the transition, estimated timelines, potential costs and other topics relevant to your organization.
• prepare teams within your organization that will be involved with the transition so that they are aware of their roles and responsibilities. Each team should use this information to develop or modify policies and procedures appropriately. For example, updating procurement policies to require the purchase of products that support PQC.
• inform members across the organization about what the transition to PQC is, why it is important and how it is expected to affect them and their work. This includes training on any new tools and policies that will be introduced during the transition.

Communications should continue throughout the project to ensure that all stakeholders are aware of the latest updates and can make relevant decisions.

Budget considerations

When preparing for the transition to PQC, organizations should create a financial plan. Although some transition costs can be covered through natural lifecycling of infrastructure, additional funding resources may be needed to pay for the work. The following is a list of items that an organization should consider when budgeting. Your organization may require additional financial resources in addition to those listed below.

Software

Software that uses PKC should be upgraded or replaced to use PQC algorithms. However, if your software vendor will support PQC and it is under a support contract, it may not be necessary to budget for replacement. Any changes to software should nonetheless be tested to ensure that it still meets the requirements of your organization.

Support contracts

Maintaining support contracts with vendors may be a good approach to upgrade product firmware and software. However, you should first communicate with your vendors to determine whether they will transition to PQC and will cover the PQC algorithms under existing contracts.

Employees and training

It may be necessary to train IT staff on how to use and appropriately configure any new or modified hardware and software to meet organizational requirements and to avoid introducing any vulnerabilities when deploying PQC. It may also be necessary to inform and educate other staff about new tools or changes to existing tools that may affect their work.

Contractors

For many organizations, transitioning to PQC may require more resources or cryptographic expertise than the organization has available. Augmenting staff with contractors during the transition may provide the necessary resources to complete the transition while limiting the impact on normal operations.

Outsourcing

Rather than augmenting your staff with contractors, you may wish to outsource the work to organizations that provide PQC transition expertise. You may wish to check whether your national technical authority provides formal accreditation of these organizations.

Cryptographic agility

Systems deploying cryptographic mechanisms cannot offer continuous security throughout their lifetimes. This is especially true when you consider the threat posed by state-of-the-art technology that is continuously evolving and becoming more advanced. When the underlying components of a system (or protocols) are rigid, any attempt to transition to a more secure design will always entail significant financial, time and organizational resources, while also making it harder to remain interoperable. For example, it took several decades to transition from the Data Encryption Standard (DES) block cipher to the Advanced Encryption Standard (AES), with NIST finally disallowing the use of the Triple Data Encryption Algorithm (TDEA) as of January 1, 2024.

The concept of cryptographic agility is to design protocols and systems in a modular scheme, allowing for the reconfiguration or replacement of individual components. As the migration to PQC will require a significant overhaul of the current systems in use, there is a long-term security and financial gain to be had by integrating crypto agility into the current transition.

The fundamental step to becoming cryptographically agile is the ability to detect weaknesses in deployed systems and to know where changes will need to be made. This leads to the requirement to build and continuously maintain and update a complete cryptographic inventory. This should remain a top priority going forward for all areas where cryptographic mechanisms are used.

The way cryptographic agility is implemented and the requirements for achieving it depend on the specific context—whether at the vendor or purchaser level, or within a system or protocol. For purchasers, this involves considering crypto agility when buying products and maintaining regular communication with vendors and security experts to remain secure. For a system, this could include an efficient quantum-safe update mechanism for cryptographic components realized in software, firmware or field-programmable gate arrays (FPGAs). For a protocol, a cryptographically agile design should not only facilitate inserting and switching between new algorithms and suites but also incorporate identification methods which would allow for a simple inclusion of new algorithms/suites at a later date. Additionally, for algorithms themselves, such crypto agile designs should allow changes to the parameters which determine the security level provided.

Deploying systems and protocols to be cryptographically agile provides various advantages beyond being prepared for the future. Along with offering long-term protection, crypto-agile systems and protocols can be applied in various countries and international organizations. It can also protect confidential information where there may be differing guidelines for parameters and algorithms, ensuring easier compliance for each use-case.

NIST’s Cybersecurity White Paper (CSWP) 39 and Canadian Centre for Cyber Security's (CCCS) Guidance on becoming cryptographically agile provide more detail on approaches to cryptographic agility.

Identifying cryptography

Building a detailed cryptographic inventory is an important step in an organization’s quantum-readiness plan. This is one of the resource-intensive tasks, as many organizations lack visibility into where and how cryptography is used across systems, devices, network protocols and cloud services.

In addition, identification of cryptography should be approached as an ongoing, iterative process, in which each cycle progressively refines the inventory and improves data accuracy. Ideally, this process should be repeated periodically to ensure that the information remains current and reliable.

Organizations may start by leveraging existing asset inventory data, obtained as part of standard information security management practices, to identify systems, applications and data flows that depend on cryptographic functions. This will establish a foundation basis for assessing PQC migration needs and prioritizing remediation efforts.

The cryptographic discovery and planning team, which is responsible for the cryptographic inventory, should allocate significant time and resources. Failure to identify a cryptographic asset at this stage may result in an unacceptable cyber security risk when CRQCs become available to malicious actors.

The collected information should be as detailed as possible (algorithm, key length, usage, etc.), as it will determine whether a cryptographic asset is vulnerable to quantum attack. This will allow the organization to perform an adequate risk evaluation.

The cryptographic inventory could be based on standard, machine-readable formats such as the Cryptographic Bill of Materials (CBOM). For more information, read Cryptographic inventory and the CBOM in the Appendix to this publication.

While the primary focus of the transition is migrating traditional PKC to PQC, it is also valuable to identify where cryptography is used across all systems and supply chains (for example, symmetric algorithms, hash functions, etc.) even though it is unlikely to be in scope of PQC migration to further enhance cryptographic agility within the organization (see Cryptographic agility).

Prioritization

The complete migration to PQC will be a enormous effort and it cannot be accomplished in 1 step. Therefore, organizations must apply a method of prioritization to assess which systems are more vulnerable to the rising threats and to identify an order for the migration. The most reasonable way to perform this assessment will be to carry out a quantum risk analysis once an inventory of data assets and cryptographic tools has been produced.

Risk assessment is a standard IT infrastructure technique to understand the vulnerabilities of a system and the impact of a potential breach. A quantum risk assessment should follow a similar methodology. In most cases, the functionality provided by the system will have an effect on which threats are relevant and the scope of the threat. Developing a risk assessment is not necessarily a task for one specific team, but rather an ongoing requirement throughout the PQC migration on which multiple teams may need to work in tandem.

The table below provides the main considerations that need to be taken into account for prioritization within a PQC transition plan but it is not intended as a complete list. This approach is compatible with the approach described in the European Commission’s A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography. An in-depth example of how to build a quantum risk assessment can be found in the Netherlands General Intelligence and Security Service’s The PQC Migration Handbook.

Because organizations have to work with restricted resources and potentially depend on external vendors, other factors could affect when specific transitions can take place. These additional factors could include:

• availability of PQC products and services
• service level agreement requirements
• availability of human and financial resources
• external integration points (for example, inter-office VPNs, cloud providers)

Additionally, it may be beneficial to focus on a simple PQC upgrade at the beginning of the transition to understand the new cryptographic parameters and develop expertise before attempting larger, more complex upgrades.

Once the appropriate factors have been decided upon, organizations will need to determine how to assign a quantum risk assessment. For simplicity, a qualitative scheme with 3 assessment levels such as low, medium and high should be sufficient for organizations to determine the order for the transition. In general, the higher the rating assigned, the higher the priority of migrating to PQC.

The following 2 examples highlight cases where a high quantum risk assessment should be applied:

• the protection of confidential data that needs to remain undisclosed for a long period of time
• the protection of software/firmware updates, for which migration could take a significant amount of time to complete

Note: Timeframes for protecting data may differ based on individual nations’ jurisdiction.

It is important for organizations to communicate with vendors to understand their plans. We recommend regular communication to ensure that, if their PQC product roadmaps have changed, you will be able to adjust your plans accordingly. You may discover that your current infrastructure will need to be replaced as either your vendor or the standardized protocols that your services use will not support PQC in the future. For example, PQC will only be available in TLS 1.3 and later. If your web services use TLS 1.2 for securing communications, you may have to:

• upgrade the software
• upgrade the operating system that runs the software
• replace the infrastructure the service runs on
• deal with any combination of the above

Transition

The transition phase is used to implement PQC on quantum-vulnerable systems. A plan for this phase will need to meet your organization’s requirements and consider items including, but not limited to, timelines, business operations and the priority of the data and systems that the cryptography protects.

While developing the transition plan, we recommend that you perform tabletop exercises that will help identify any issues that may prevent a smooth transition to PQC. Determining potential issues early on will generally reduce costs, errors and the time to perform the transition, and may result in fewer issues during the upgrade process. When performing the transition, make sure to follow your organization’s change-management processes.

Testing

In addition to the testing that your organization already performs on your IT environments, you should consider adding PQC tests to your test plans. This will ensure that your IT environment continues to meet organizational requirements and also validate that the PQC has been implemented correctly. At minimum, your plans should:

• Ensure that the cryptographic products meet system requirements
  Some devices use dedicated hardware or chip instruction extensions to improve the performance of traditional cryptography. Although initial testing shows some PQC processing is as fast as existing PKC, until dedicated hardware is available for PQC, it may perform more slowly than systems currently in use. Another consideration is that PQC key, ciphertexts and signatures are often larger than those produced with the existing PKC algorithms. Problems could arise from these larger sizes when using low bitrate or noisy network connections such as on radios. Due to these concerns, and possibly others, it is important to ensure that new or transitioned devices continue to meet the system’s prescribed requirements.
• Validate interoperability Although a product may have been tested by a vendor, interoperability can fail between vendors based on different implementation assumptions. In situations where 2 or more products must work together to form a solution, it is important to perform testing to ensure that they will interoperate together.
• Test configurations to enable PQC Configuring a system to support PQC will often involve more than pressing a button or checking a box on a graphical interface. It may involve obtaining new cryptographic certificates as well as turning off cryptographic ciphers that you no longer wish to use. Having a plan to test varying configurations and verify that PQC algorithms are being used correctly will alleviate any mistakes that could leave your data and systems unprotected.

Documentation

During the transition, it is important to ensure that each change to any system is well documented. Relevant documentation includes but is not limited to:

• Business continuity plans (BCPs) As your environment changes, it is important to ensure that your BCP is kept up to date to ensure that it captures all the information necessary to continue business operations in the case of a disruption.
• Configuration and use documentation The configuration, as well as any specific use instructions for each system, should be recorded. This includes any configurations made to support PQC and deprecate traditional cryptographic algorithms.
• Information technology asset management (ITAM) Update the organization ITAM to record any changes to hardware and software, including removing any items that will no longer be needed after the transition.
• Cryptographic information Cryptographic recommendations will continue to change as new technologies are developed. Ensuring that all cryptographic technologies used in your organization are properly recorded and secured is an important part of cryptographic agility and will aid in future cryptographic changes. More information on storing cryptographic information can be found in Cryptographic inventory and the Cryptographic Bill of Materials in the Appendix of this publication.

Network devices and applications

• Active network vulnerability scanners: to interrogate network services directly and list supported protocols, cipher suites, and key-exchange mechanisms, highlighting the use of weak or deprecated algorithms. For example, nmap, testssl.sh and openssl
• Passive monitoring and traffic analyzers: to capture and analyze live communications in order to observe which cryptographic protocols and algorithms are actually negotiated during sessions. For example, Wireshark and tcpdump
• Large-scale network scanning frameworks like Shodan or Censys.io can be employed to map cryptographic exposure of Internet-facing assets

Externally developed software and hardware

• Binary and library inspection utilities: to analyze executables and verify dynamically linked cryptographic components and symbols
• Firmware inspection and analysis methods: to examine firmware images of embedded devices or accelerators for implemented algorithms and potential hardcoded keys
• System and hardware inventory utilities: to detect the presence of cryptographic accelerators, secure co-processors or dedicated modules integrated into servers and network appliances

Internally developed and open-source software

• Source code analysis methods: to identify direct calls to cryptographic APIs, functions or hardcoded keys inside applications.
• Dependency and package inspection tools: to detect cryptographic libraries declared in project files or packages
• Static and dynamic analysis techniques: to examine compiled code for linked cryptographic components and functions