Executive Summary

Quantum computing is evolving at a pace that will redefine the boundaries of problem solving, but it also threatens the foundations of classical cryptography. The ability to break widely used algorithms makes the need for PQC urgent. It is important to note that quantum computing poses the greatest threat to asymmetric (public-key) cryptography, such as RSA and elliptic curve cryptography (ECC); symmetric algorithms (e.g., AES-256) and hash functions (e.g., SHA-256) are affected to a lesser degree and can remain viable with modest key-size increases [3]. Organizations must prepare now to safeguard encrypted data, digital trust systems, and regulatory compliance against “store now, decrypt later” risks.

A critical dimension of this transition is the impact on cloud key management. Larger key sizes, Post-Quantum Traditional (PQ/T) hybrid schemes or protocols, and certificates [20], and cross‑cloud interoperability introduce operational complexity that cannot be ignored. Enterprises must modernize governance, embed crypto agility, and strengthen lifecycle controls to ensure keys remain secure, interoperable (able to be migrated or operated seamlessly across cloud providers, hardware security modules (HSMs), and hybrid infrastructures, without vendor lock-in), and compliant in a quantum-capable world.

This paper provides a focused analysis of PQC and its impact on key management in cloud and hybrid environments. It highlights the technical and operational challenges that organizations must address, along with best practices to guide the transition. This paper covers the following topics: PQC industry developments, including National Institute of Standards and Technology (NIST) standardization, technical and operational challenges in PQC integrations, transition and remediation strategies, PQC transition roadmap, and best practices.

The governance structure for PQC transition should be consistent (e.g., inventory, risk assessment, prioritization, ownership, remediation planning testing , deployment, monitoring, and fallback). Risk profile and implementation priorities will vary by organizations based on asset criticality, data sensitivity, regulatory exposure, architecture, and operational readiness as these remain the responsibility of each organization.

Objective

This paper provides a practical framework for modernizing cloud key management in the post-quantum era. It highlights the impact of new cryptographic standards on key management systems (KMSs) and HSM platforms, outlines transition strategies such as hybrid crypto models and migration planning, and emphasizes crypto agility across multi-cloud environments. By aligning technical best practices with governance and compliance imperatives, it delivers a roadmap for secure, agile, and future-proof cryptographic operations.

This paper builds on the Cloud Security Alliance’s ongoing research in cloud key management and quantum-safe security, which has produced several related whitepapers and guides[^1] [^2] [^3]

Key Findings

PQC demands stronger key management practices. Organizations must adapt lifecycle controls, ensure interoperability, mitigate risks of hybrid downgrades, validate continuously, and enforce governance with trusted vendors. Embedding these measures into compliance frameworks provides a practical path to quantum-safe key management without disruption.

Table 1: Key Findings for PQC Key Management

Post-Quantum Cryptography Industry Development

As quantum threats become increasingly imminent, enterprises are accelerating the adoption of post-quantum cryptographic (PQC) protocols to safeguard data against future quantum decryption capabilities. Several emerging algorithms—such as CRYSTALS-Kyber, a post-quantum key encapsulation mechanism, and CRYSTALS-Dilithium, a post-quantum digital signature algorithm—have been standardized by NIST’s Post-Quantum Cryptography Standardization Project and are being integrated into enterprise systems and products.

However, the broader ecosystem remains in transition. Many critical communication protocols, including Transport Layer Security (TLS), Secure Shell (SSH), and Internet Key Exchange (IKEv2), are still undergoing updates within the Internet Engineering Task Force (IETF) to incorporate PQC mechanisms through hybrid- and migration-ready draft specifications. Until these updates are fully deployed, the protocols are vulnerable to feasible attack scenarios. For example:

• Store Now, Decrypt Later (SNDL): Adversaries can capture encrypted TLS traffic today and hold it until quantum computers (e.g., Cryptographically Relevant Quantum Computer (CRQC)) [2] are capable of breaking RSA or ECC keys, exposing sensitive data retroactively

• Trust Now, Forge Later (TNFL): A certificate-focused variant of SNDL in which adversaries harvest digitally signed artifacts today, including certificates, code signatures, or long-lived documents, with the intent to retroactively forge or repudiate them once a CRQC can break the underlying signature algorithm. TNFL is particularly relevant to public key infrastructure (PKI) migration planning and non-repudiation lifecycle management

• Downgrade Attacks in Hybrid Protocols: During migration, hybrid TLS handshakes that combine classical and PQC algorithms may be forced back to classical-only negotiation by a malicious actor, leaving sessions quantum vulnerable

• Man in the Middle Exploitation: In SSH or IKEv2, incomplete PQC integration can allow attackers to intercept and manipulate key exchange messages, exploiting gaps between classical and PQC negotiation paths

• Certificate and PKI Weaknesses: Legacy certificate parsing and validation routines may fail when encountering PQC artifacts, enabling attackers to bypass validation or inject fraudulent certificates

These scenarios illustrate that the risk is not theoretical: protocols in transition are actively exposed to exploitation until PQC mechanisms are fully standardized, tested, and deployed. Parallel standardization efforts are therefore essential to ensure interoperability, backward compatibility, and secure deployment across heterogeneous infrastructures.

NIST Standardization

To address emerging quantum threats, the National Institute of Standards and Technology (NIST) initiated the Post-Quantum Cryptography Standardization Project in 2016 to identify algorithms resistant to quantum attacks. In 2022, NIST announced its initial selections, CRYSTALS-Kyber for key establishment and CRYSTALS-Dilithium for digital signatures. In August 2024, NIST published its first finalized PQC standards: FIPS 203 (ML-KEM, based on CRYSTALS-Kyber), FIPS 204 (ML-DSA, based on CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, based on SPHINCS+). Additional post-quantum cryptographic standards and updates are anticipated as NIST continues to expand and mature its PQC standardization efforts.

These selections define the foundation for post-quantum transition planning across government and industry, serving as the primary reference point in the United States for enterprise cryptographic modernization and cloud key management system (KMS) integration strategies.

Leading Algorithms in PQC

Post-quantum cryptography refers to new mathematical techniques designed to protect data against future quantum computers. Today’s widely used methods, like RSA and ECC, rely on mathematical problems that quantum machines could solve quickly, making them vulnerable. To prepare, researchers have developed new families of algorithms that are resistant to quantum attacks.
ML-KEM (Kyber, FIPS-203) is one of the leading algorithms for secure key exchange. Think of key exchange as the process of safely handing someone a secret code over the internet. It uses lattice mathematics to make this exchange secure, efficient, and practical. Lattice-based algorithms rely on hard mathematical problems in high-dimensional lattices to secure data against both classical and quantum computer attacks. It is already being tested in real-world protocols like TLS, which secures most web traffic [15].
ML-DSA (Dilithium, FIPS-204) is another lattice based algorithm, but instead of exchanging keys, it focuses on digital signatures. A digital signature is like a secure stamp that proves a message or file really came from its sender. Dilithium balances strong security with reasonable performance and key sizes, making it suitable for both powerful cloud servers and smaller devices [16].
Other algorithms are also in the mix. FN-DSA (Falcon) offers very compact signatures, which are useful when bandwidth or storage is limited. SLH-DSA (SPHINCS+, FIPS-205) takes a hash-based approach, appealing to those who prefer conservative, well understood assumptions. Still, Kyber and Dilithium are leading the adoption curve because they combine strong security with practicality across diverse environments [18, 19].

Regulatory and Compliance

Regulators are paying attention, too. In the U.S., the National Security Agency (NSA) has already issued timelines for transitioning to quantum-safe algorithms in national security systems [3]. Europe is moving in a similar direction with the European Commission issuing a roadmap and timeline for PQC transition [14]. What is likely to emerge, as well, are cryptographic inventories, lifecycle tracking, and a shift toward architectures that can swap out legacy algorithms for PQC algorithms without requiring the entire system to be rewritten.

Organizations that wait until standards are finalized may find themselves scrambling to mitigate quantum risk and meet compliance requirements once formal timelines are established. Organizations should begin testing algorithms, assessing compatibility, and planning migration strategies early to enable a smoother transition.

Technical Challenges in PQC Integration

The integration of PQC into existing key management infrastructures presents a significant technical challenge. It goes beyond just algorithm selection. PQC has structural changes in key size, cryptographic artifact sizes, and performance. It introduces interoperability issues across protocols and hardware. Organizations must carefully consider these challenges to ensure secure, efficient, and practical deployment of PQC within enterprise systems, cloud platforms, IoT environments, and critical infrastructures. At the same time, delaying the adoption of PQC may result in weakening the security posture and “store now, decrypt later” attacks.

Implementation Challenges

The integration of PQC schemes into existing key management infrastructures (e.g., KMS, HSM), as well as existing IT systems (e.g., databases, cloud storage accounts, IoT devices) presents multi-dimensional challenges. It is primarily due to their distinct mathematical foundations, key characteristics, hardware, and software dependencies. PQC implementation in real-world systems (from pre-quantum to post-quantum) is hindered by algorithmic diversity and high computational and memory overheads. These issues result in longer key generation, signature verification, and ciphertext decryption times, which significantly impact performance-sensitive applications such as real-time communication or embedded IoT systems.

A practical example is a high-traffic TLS server, such as a cloud service endpoint or API gateway, handling thousands of concurrent connections per second. When PQC algorithms, such as ML-KEM or ML-DSA, replace classical RSA or ECDSA¹, the larger key, ciphertext, and signature sizes increase handshake latency, CPU load, and may also lead to broader system-level impacts. Additionally, larger handshake messages can exceed the typical Maximum Transmission Unit (MTU) limit, leading to fragmentation and retransmissions. These effects cascade through dependent services such as load balancers, caching proxies, and hardware accelerators, making end-to-end performance optimization and interoperability validation essential during early adoption phases.

Existing cryptomechanisms and systems must be extended or re-engineered to accommodate PQC primitives [3]. Vendors and IT owners must be prepared to transition from traditional to quantum-safe algorithms. They have to ensure their systems are backward compatible, resilient, and secure. In certain situations, this may require updates to software cryptographic libraries and hardware cryptographic modules or a holistic system redesign. Moreover, PQC algorithms and implementations are relatively new and lack the extensive field testing that is typically associated with cryptographic systems. As a result, they are more susceptible to implementation flaws, which pose reliability and security risks during the early stages of adoption.

Algorithmic Compatibility

PQC algorithms feature significantly larger key sizes, different operational semantics, and novel failure modes that challenge existing protocols and storage systems originally designed for algorithms like RSA and ECC [2].

Furthermore, the vast heterogeneity in algorithm classes (e.g., lattice-based, code-based, hash-based) may create incompatibilities across platforms that were not designed with PQC in mind. New PQC primitives, such as lattice-based schemes, would demand extensive randomness and larger computational blocks that traditional protocols were not designed to handle.

However, quantum computing poses minimal threat to symmetric encryption and hash functions. Under Grover’s algorithm, the effective security of symmetric keys is reduced by approximately half, meaning AES-256 or higher remains secure for most practical purposes. Similarly, hash functions such as SHA-256 retain their robustness and can continue to be used for typical applications [3]. As a post-quantum migration best practice, organizations should transition from AES-128 to AES-256 for symmetric encryption at rest and in transit, and from SHA-256 to SHA-384 or SHA-512 for collision-resistant hashing, to maintain adequate security margins against quantum-accelerated search attacks.

Key Size and Performance Constraints

Large key sizes from PQC algorithms, such as the 1,568-byte public key of Kyber1024, can pose significant challenges for existing security protocols [6]. Many protocols, for example, those used in identity and access management, such as OAuth and SAML, were designed for smaller, low-latency operations.

The table below compares public, private key sizes, and signature sizes of traditional and PQC signature schemes [7]:

Table 2: Traditional and PQC Signature Schemes

The large PQC keys can exceed the standard MTU of 1,500 bytes. This forces network packets to be fragmented. Packet fragmentation may increase latency and can lead to dropped packets, especially over unreliable or older networks. Application-layer impacts may also arise from increased PQC-related message and token sizes, which can interact with protocol header limits, buffering constraints, and timeout settings in distributed systems. Furthermore, security best practices include dropping fragmented packets by network devices and firewalls. The oversized payloads also disrupt the expected data alignment within these protocols, potentially causing errors or inefficient processing [8].

Storage and Transmission Overhead

The transition to PQC introduces significant increases in key, ciphertext, and signature sizes, which create measurable challenges in both storage and transmission. Traditional cryptographic systems, such as RSA and ECC, rely on compact keys and certificates that typically fit within one or two kilobytes. In contrast, PQC algorithms like Kyber and Dilithium produce substantially larger artifacts. These larger sizes strain devices with constrained memory, such as IoT nodes, smartcards, and embedded systems, which were initially provisioned with a few kilobytes of storage.

The adoption of PQC in TLS 1.3 highlights these issues in practice. A PQC or hybrid handshake, compared to legacy algorithms, could be multiple times larger in size. Hybrid key exchange mechanisms in TLS can produce key artifacts that exceed the MTU, potentially fragmenting the ClientHello message across multiple packets. It increases the likelihood of packet loss and retransmissions, introducing latency during the handshake. Similarly, the ServerHello message, which includes the server’s classical public key and the PQ KEM ciphertext (encapsulation), may also exceed the MTU, compounding these risks [9]. Even without fragmentation, larger messages increase round-trip time (RTT) exposure and amplify the cost of retransmissions in lossy environments.

Network devices processing these packets, which are not designed to handle fragmented ClientHello messages, may drop them entirely. Additionally, hybrid key exchange imposes greater computational demands on the client and increases handshake bandwidth, which can strain performance in constrained environments [10].

Limited HSM/KMS Support

HSMs and KMSs are crucial for managing the lifecycle of cryptographic keys, ensuring secure generation, storage, and access controls. However, many current HSM and KMS implementations and solutions are primarily designed to support RSA, ECC, and AES cryptographic primitives, with limited options for post-quantum algorithms. This limitation could pose challenges for organizations aiming to integrate PQC into their production environments.

In response, HSM and cryptographic service providers are transitioning toward post-quantum readiness by integrating NIST-standardized algorithms into production-grade firmware. While many leading platforms are now “early-adopter ready” with built-in PQC support, a critical distinction remains between functional availability and formal certification and validation. While the technology is accessible for integration, the availability of supported PQC algorithms and fully validated modules remains limited [11, 12, 13, 22, 25].

Interoperability Issues

The integration of PQC into enterprise and cloud environments faces significant interoperability challenges. Unlike classical cryptography, where algorithms and standards have matured over decades, the adoption of PQC is uneven across protocols, platforms, and PKI infrastructures. This fragmented landscape means systems may be individually secure but fail when asked to communicate, exchange keys, or validate certificates. Each layer of the technology stack evolves at different speeds due to varying levels of vendor commitment and standards maturity. This uneven progress can lead to operational failures such as handshake errors, certificate parsing problems, or service disruptions [1, 2, 3]. These challenges are compounded by the relative immaturity of PQC implementations, which lack the field testing that classical cryptographic systems undergo. Interoperability is therefore one of the most practical barriers to PQC migration, demanding a careful balance between innovation, compatibility, and resilience.

Table 3: Interoperability Challenges and Mitigations Across Four Layers of the Technology Stack—Protocols, Platforms, PKI, and Trust-Boundary Enforcement [1, 2, 4]

Protocol-Level Interoperability

Communication protocols such as TLS, SSH, VPN, and email standards face uneven adoption of PQC. Some are experimenting with hybrid cryptographic approaches, while others lack stable specifications, creating gaps that disrupt secure communications [1, 2, 3].

Issues:

• Protocols are adopting PQC at varying speeds, resulting in inconsistent security
• Existing networks may drop larger PQC or hybrid handshake messages when they exceed network MTU limits and trigger fragmentation or segmentation that some middleboxes or network devices do not handle correctly [2]
• Legacy email systems often cannot parse PQC-enabled certificates

Mitigations:

• Use hybrid modes during transition
• Maintain parallel classical and PQC/hybrid certificate chains during transition
• Pilot PQC-enabled handshakes in controlled environments
• Configure network and protocol settings to accommodate larger PQC handshakes, including Path MTU Discovery (PMTUD), TLS record size limits, and Maximum Segment Size (MSS)/MTU tuning to reduce fragmentation-related drops

Platform and Ecosystem Interoperability

Cloud providers and technology vendors are progressing at different speeds and exposing PQC through inconsistent interfaces [7, 8]. This creates complexity in multi-cloud environments where cryptographic operations must remain aligned.

Issues:

• PQC support varies across providers
• APIs expose PQC capabilities using inconsistent or proprietary interfaces
• Many enterprise products remain limited to RSA/ECC

Mitigations:

• Track provider readiness and prioritize early adopters to ensure seamless integration
• Use abstraction layers with feature detection to normalize cryptographic operations and dynamically select supported algorithms and key sizes across providers
• Require vendor documentation and verification of cryptographic implementations, including secure parameter selection and resistance to side-channel attacks
• Establish monitoring and operational metrics for PQC compatibility across platforms
• Automate alerts for incompatible or downgraded PQC operations

PKI and Certificate Interoperability

Certificates and PKI infrastructures were designed for classical public-key algorithms, such as RSA and ECC. As PQC extensions emerge, hybrid certificates often fail in legacy systems, while some implementations silently downgrade to weaker cryptography [2, 4, 5].

Issues:

• Legacy systems often reject hybrid certificates
• Standards such as X.509 and PKCS#11 are being extended inconsistently across implementations [4]
• TLS stacks may silently fall back to classical RSA/ECC algorithms when PQC or hybrid cipher suites are not recognized or implemented

Mitigations:

• Establish interoperability testing labs
• Evaluate certificate transparency (CT) log compatibility and browser ecosystem readiness for PQC or hybrid certificates, as larger signature sizes and new object identifiers (OIDs) may affect certificate logging and validation workflows
• Adopt PQC-ready PKI tooling
• Enable downgrade detection and logging
• Make downgrade behavior configurable to allow or prevent fallback to classical algorithms during PQC transitions

Interoperability is more than a technical nuisance; it is a systemic barrier to the coordinated adoption of PQC. While algorithms themselves may be standardized, uneven progress across protocols, platforms, and PKI threatens to undermine security during the transition. The way forward requires organizations to elevate interoperability into their PQC migration strategies by insisting on vendor alignment, conducting rigorous interoperability testing, and designing systems with flexibility at their core. This shift ensures that quantum-safe protections are not isolated pockets of resilience, but consistent safeguards applied across the entire technology stack [1, 3, 6].

Trust Boundaries and Enforcement

In distributed and multi-cloud architectures, cryptographic operations frequently cross multiple infrastructure domains that form security trust boundaries, meaning points where cryptographic policies may be enforced independently. Examples include boundaries between client devices, edge gateways, service meshes, and centralized cryptographic services such as KMS or HSM. If PQC support or enforcement policies differ across these boundaries, secure communications may succeed while silently reverting to classical cryptography, undermining quantum-resistant protections [1, 2].

Issues:

• Inconsistent PQC enforcement across client, edge, service mesh, KMS, and HSM boundaries
• Undetected fallback to classical cryptography between security domains
• Lack of visibility into negotiated algorithms across multi-cloud paths

Mitigations:

• Define PQC enforcement per trust boundary (fail-closed where quantum resistance is required)
• Implement downgrade detection and algorithm telemetry at each boundary
• Maintain end-to-end interoperability validation matrix across environments

Operational Challenges

Beyond the technical complexities of algorithm integration, the transition to post-quantum cryptography presents significant operational challenges that organizations must address to achieve a secure and sustainable migration. These challenges span key lifecycle management, cryptographic agility, vendor dependencies, infrastructure readiness, and workforce capability. Without deliberate operational planning, even technically sound PQC implementations may fail to deliver their intended security benefits.

Lifecycle and Policy Complexity

As organizations transition toward PQC, managing the lifecycle and policies of cryptographic keys introduces significant operational complexity. Unlike classical cryptographic systems, PQC algorithms often require larger key sizes and different handling semantics, demanding robust changes in how keys are generated, distributed, rotated, and destroyed.

Lifecycle management of PQC keys and certificates becomes particularly challenging in hybrid environments where legacy and quantum-resistant algorithms must coexist. Key rotation strategies must not only align with compliance standards but also accommodate performance constraints introduced by PQC’s computational demands. For instance, traditional time-based key rotation models may become inadequate, necessitating event-driven or context-aware key refresh strategies to mitigate risks without disrupting system performance. Similarly, PQC and hybrid certificate artifacts introduce larger certificate artifacts and added complexity into PKI policies governing issuance, certificate authority (CA) hierarchy design, and revocation, necessitating more adaptive strategies [25].

Enforcing cryptographic policies becomes more complex. Policies now need to factor in algorithm agility, key type transitions, and multi-cloud consistency, all while remaining auditable and aligned with compliance frameworks.

To illustrate, the following table outlines core lifecycle and policy challenges in PQC operations.

Table 4: Core Lifecycle and Policy Challenges in PQC Operations
Effective key lifecycle and policy governance in the PQC era demands a flexible, algorithm-agnostic infrastructure backed by unified orchestration, auditability, and forward-compatible standards alignment. Organizations must build cryptographic agility and compliance resilience into their operational fabric to sustain secure and scalable operations in the quantum future.

Crypto-Agility Requirements

No CRQC is currently operational. Does crypto agility mean that we only need to hasten our migration to PQC on the verge of CRQC becoming a reality? No, your data might already be at risk now. Adversaries may have already tapped your confidential data and plan to decrypt it later when CRQCs arrive. This is the so-called Store Now, Decrypt Later (SNDL) attack. Despite the name, the attack is not limited to data confidentiality and also affects data integrity.

Unlike other attacks, SNDL exploitation may start today but will not be complete until the appearance of CRQCs, the so-called Q day. Time plays a critical role in the attacks. Three moments in time are critical: 1) when CRQCs appear, 2) when one’s data asset loses value and no longer requires cryptographic protection, and 3) when mitigation technologies become available at low cost or effort.

Foundational PQC modules have become available, especially after the publication of NIST FIPS 203, 204, and 205. However, well-packaged and integrated enterprise applications are rare. One may need to compile or build applications oneself to replace the vulnerable cryptographic modules with ones supporting PQC. Therefore, mitigation cost and effort are fairly high at this point. Crypto agility requires one to assess the three conditions frequently and either migrate to PQC technologies (if they become available at low cost and effort) or compile and build one’s applications (if the value of one’s data lasts beyond the Q date).

Vendor Lock-In Risks

As organizations transition to PQC, vendor lock-in has become a significant operational and strategic risk. PQC standards and algorithms continue to evolve, and many KMSs, cloud encryption services, and HSMs offer only limited or proprietary support for emerging PQC algorithms [16, 17, 18]. Heavy dependence on a single vendor can restrict cryptographic agility, reduce transparency into key operations, and limit key portability, undermining long-term security and compliance. Fortunately, vendor-specific guidance does exist [27].

Vendor lock-in also impedes interoperability across hybrid and multi-cloud environments. The absence of standardized APIs and migration-friendly architectures complicates key rotation, policy replication, and algorithm updates, delaying adaptation to evolving NIST guidance or regulatory requirements.

These challenges are compounded by dependencies on FIPS 140 validation. Cryptographic modules validated under NIST’s CAVP and CMVP may be difficult to modify or replace without recertification, constraining the integration of PQC algorithms into compliant environments. As PQC standards mature, such dependencies can slow migration timelines and increase the risk of misalignment with emerging cryptographic mandates.
The table below summarizes vendor lock-in risks in the PQC context.

Table 5: Vendor Lock-In Risks in the PQC Context

To mitigate these risks, organizations should prioritize solutions that adhere to open standards (e.g., KMIP, PKCS#11 v3.2(draft), NIST PQC candidates) and support cryptographic agility. They should also ensure that vendors maintain forward-compatible FIPS-validated modules capable of integrating future PQC algorithms. It is important to note that algorithm changes affecting the security boundary will typically require a new CMVP validation submission (FIPS 140-3), though NIST SP 800-140 series guidance provides transition procedures for specific scenarios [19, 20]. Additionally, building abstraction layers or adopting vendor-agnostic key orchestration platforms can help decouple PQC operations from the underlying infrastructure.

Other Operational Challenges

Beyond lifecycle complexity, vendor lock-in, and skills gaps, several additional operational challenges arise as organizations prepare for the adoption of PQC. These challenges encompass performance overhead, backward compatibility issues, and a lack of standardization, all of which can hinder the secure and seamless implementation of these systems.

• Performance Overhead: PQC algorithms typically require larger key sizes and more computational resources than classical algorithms. This can introduce latency in encryption/decryption operations, straining resource-constrained environments such as edge devices, mobile platforms, or IoT sensors. Existing cloud-native applications may require architectural rework to absorb this overhead without compromising user experience or system throughput

• Backward Compatibility and Dual-Stack Complexity: Organizations cannot abandon classical cryptography overnight. A hybrid (dual-stack) approach, where both legacy and PQC algorithms coexist, becomes necessary during transition phases [24]. However, managing these hybrid cryptographic environments increases operational complexity, primarily when policies, audit mechanisms, and compliance controls must support both types simultaneously

• Toolchain and Infrastructure Readiness: Many commercial tools, such as API gateways, CI/CD pipelines, load balancers, and container orchestrators, do not yet support PQC primitives. This lack of integration can delay adoption and increase technical debt as teams create workarounds or custom wrappers to support basic functionality

• Standards Fragmentation: While bodies like NIST are standardizing PQC algorithms, not all vendors or regions align consistently. This fragmentation leads to uncertainty about which algorithms to trust, when to adopt, and how to prepare systems for long-term interoperability

Skills and Training Gaps

One of the most pressing operational challenges in the transition to PQC is the existing skills and training gap across cybersecurity, IT, and DevSecOps teams. While the theoretical foundations of PQC are advancing rapidly, the practical knowledge required to implement, manage, and maintain these systems remains scarce in most enterprise environments.

Traditional key management and cryptographic operations rely on widely understood algorithms, such as RSA and ECC, which have been taught and implemented for decades. In contrast, PQC introduces new mathematical structures, such as lattices, multivariate polynomials, and hash-based schemes, that are unfamiliar to most practitioners. Understanding these algorithms is critical not only for implementation but also for validating security configurations, assessing risk, and ensuring interoperability with legacy systems.

Furthermore, cloud service providers, KMS vendors, and HSM manufacturers are still evolving their documentation and support for PQC-enabled tools. This leads to operational friction, where security teams struggle to integrate PQC technologies due to a lack of clear best practices, performance benchmarks, or migration guides.

Addressing these gaps requires a concerted investment in cross-functional training, updated certification programs, tabletop exercises and industry-wide knowledge sharing. Organizations should collaborate with academia, standard bodies, and vendors to ensure workforce readiness as quantum-resilient infrastructures move from research to reality.

Transition and Remediation Strategies

PQC transition extends beyond technical algorithm replacement. It requires coordinated governance decisions like risk prioritization, ownership assignment, policy updates, and compliance alignment, alongside technical remediation.

The Mosca theorem, proposed by Professor Michele Mosca of the University of Waterloo in 2015 [23], suggests considering the time required for technical remediation, as well as the data “shelf life,” during which the data must be protected. However, the shelf life needs to be compared with the Q day. If it is short and does not extend beyond the Q day, no risk exists and no remediation is needed. The time required for technical remediation, on the other hand, affects the risk exposure and needs to be compared with the cost of remediation.

Section 3.2 on crypto agility suggests two possible strategic possibilities:

• Migrate to PQC technologies if they become available at low costs and effort
• Compile and build one’s applications if the value of one’s data lasts beyond the Q date

The first may be of low cost but may increase one’s risk exposure. The second is costly but may reduce one’s risk exposure. Considering all the factors, remediation is not a trivial task. One needs to assess their risks against the cost of migration frequently. To assess the cost of migration, one needs to start with an accurate inventory of the vulnerable cryptographic components and identify which ones should be remediated soon and which ones can take a lengthy transition period or even require no remediation.

Cryptographic Asset Inventory

Many advocate organizations to purchase a new type of tool called a cryptography bill of materials (CBOM) for the purpose of discovering or establishing cryptographic asset inventory. However, CBOMs go against the trend of offloading lower layer technical responsibilities to cloud service providers and distract organizations’ focus on their data. We advocate organizations take advantage of their existing asset management tools and what their service providers offer. Cryptographic components are typically parts of information technology systems and are not tracked in any asset management systems. However, the following widely used information systems may help:

• A configuration management database (CMDB)
• Cloud management portals, which manage cloud resource configurations
• Cloud resource configuration backups, which are usually in JSON format

Hybrid Cryptographic Models

Most encryption-in-transit protocols use algorithms such as RSA for key exchange. Securing these protocols against quantum attacks would require replacing certificates using the RSA algorithm. Before these certificates can be replaced by certificates using PQC, hybrid modes of the protocols may be used as a transition strategy. Using a hybrid mode, the key exchange is further encapsulated or protected by a PQC key encapsulation mechanism such as ML-KEM (based on CRYSTALS-Kyber), standardized as FIPS 203. In addition, asynchronous protocols such as S/MIME and OpenPGP also benefit from hybrid models; unlike TLS, they lack forward secrecy, so messages stored today can later be decrypted by a quantum-capable adversary, making them a candidate for PQC hybrid adoption.

Migration Planning and Phases

Migration planning should be preceded by a risk assessment of one’s data assets, starting with the identification of cryptographic assets at risk and followed by mapping out replacements. These activities should not be a one-time act but rather be carried out periodically. The Cloud Security Alliance (CSA) Cloud Control Matrix (CCM) contains control CEK-09, which requires, “Audit encryption and key management systems, policies, and processes with a frequency that is proportional to the risk exposure of the system, with audit occurring preferably continuously but at least annually and after any security event(s).” Included in CCM are mappings to the controls specified by other relevant frameworks such as CIS, ISO 27001, NIST 800-53 and CSF, and PCI DSS.

Identifying Cryptographic Assets at Risk

Cryptography is used in three security function areas: encryption in transit, encryption at rest, and non-repudiation.

• Encryption at Rest: Data at rest is typically protected by symmetric encryption. However, encryption keys are stored in KMSs or HSMs and are ultimately protected by public key encryption using providers’ certificates. Mitigation requires the providers’ certificates to be quantum-safe and the KMS and HSMs to use PQC algorithms. In envelope encryption architectures, PQC migration should prioritize the root of the key hierarchy, the master key (e.g., Customer Master Key (CMK) and Key Encryption Key (KEK)), before downstream keys and protected data can be considered quantum resistant. Applying PQC protections at lower layers while retaining a classical root key leaves the hierarchy vulnerable through the unprotected trust anchor. This sequencing risk is particularly significant for long-term archival data whose confidentiality requirements extend beyond the projected quantum threat horizon [23]

• Encryption in Transit Protocols: The most used end-to-end encryption protocols are TLS and SSH. The key exchange function is part of both protocols. The most used network-to-network encryption is a virtual private network (VPN) using IP security (IPsec) protocols. The key exchange function is performed using the IKE protocol

• Non-Repudiation: Unlike encryption in transit or at rest, non-repudiation has long-term security implications, as signed data may need to remain verifiable for many years. Non-repudiation can be regarded as a form of authentication with long-term value. The critical components are the public key algorithms used by the signing certificates. Long-term non-repudiation also requires quantum-safe timestamping. Both the signing certificate and the Timestamp Authority (TSA) certificate should migrate to PQC-based algorithms, as a classical TSA can weaken the long-term integrity of the non-repudiation chain against a quantum-capable adversary, regardless of the document signature algorithm used. Long-term archival formats support periodic timestamp renewal and algorithm migration, enabling the use of PQC-safe timestamps to preserve signature validity beyond the original certificate lifetime

Map out replacement cryptographic components. Most PQC modules and components are in the experimental stage. Hybrid post-quantum key exchange for TLS is being deployed at Internet scale and is supported by major CDN and browser infrastructure. In contrast, PQC digital signatures and full PKI integration remain under active standardization and are not yet widely deployed across mainstream products and enterprise certificate ecosystems. Organizations migrating PKI to PQC must also evaluate certificate approaches, including composite certificates, which combine classical and PQC keys within a single X.509 certificate, and parallel certificate chains, which maintain separate classical and PQC trust paths. Even interim solutions enabled by FIPS 203 (ML-KEM) or hybrid mode for encryption-in-transit protocols are not yet supported by out-of-the-box products. For example, OpenSSH version 10 may have its cryptographic library replaced to support PQC out of the box, but for versions 9 and below, one needs to compile and build with PQC module replacement oneself. Table 7 in Section 5.2 lists the popular modules supporting PQC and the cryptographic libraries that have incorporated them.

Cloud Service Provider Solutions

Following CSA CCM control STA-06 on supply-chain management, one should periodically review their cloud providers’ progress on PQC migration. If their data is at risk, they need to engage the cloud providers for timely migration.

Table 6: Cloud Providers’ Progress on PQC Migration

Best Practice Recommendations

Design for Agility

Unlike other attacks, SNDL exploitation takes time. Achieving cryptographic agility requires organizations to assess risks proactively, identify data whose confidentiality must extend beyond the projected quantum threat horizon, and implement continuous remediation strategies as technologies evolve, prioritizing based on confidentiality lifetime rather than current exploitability.

PQC Adoptions Incorporating NIST Standards

Several open-source PQC modules have implemented PQC algorithms. Among the algorithms, some are NIST standards, while others are still being studied by the cryptographer community, led by NIST’s Computer Security Resource Center (CSRC). A few closed-source PQC modules are branch-outs of the open-source ones and are developed by private industries. Most of the cryptography libraries and software development kits (SDKs) incorporate some PQC modules. But the majority of applications have not incorporated PQC capabilities.

The adoption of NIST-standardized PQC algorithms within these open- and closed-source libraries is not only relevant to cryptographic agility but also directly impacts key management technologies. Integrating PQC support in foundational cryptographic toolkits (e.g., OpenSSL, AWS-LC, CIRCL) determines whether enterprise KMSs, HSMs, and TLS clients can securely generate, store, and exchange post-quantum keys. Without compatible libraries, KMSs cannot perform key wrapping, hybrid key exchange, or certificate issuance using PQC primitives. Therefore, awareness of which libraries and vendor SDKs have incorporated NIST-approved PQC standards is essential for planning PQC-ready key management architectures.

Importantly, these PQC frameworks are implemented and executed on today’s conventional hardware and software infrastructures but are mathematically resistant to quantum-computer-based attacks, enabling organizations to begin secure adoption ahead of future quantum threats.

The following table summarizes representative open-source and commercial modules that have incorporated NIST-standardized post-quantum algorithms. These implementations, spanning cryptographic libraries, SDKs, and vendor platforms, illustrate the growing ecosystem readiness for post-quantum key generation, exchange, and lifecycle management. The listed algorithms (ML-KEM, ML-DSA, SLH-DSA) correspond to NIST FIPS 203–205 standards and are already supported in today’s classical hardware and software environments. Understanding where PQC capabilities are embedded at the library level helps organizations plan for the integration of quantum-resistant key management practices across cloud, endpoint, and communication infrastructures.

Table 7: PQC Module Adoption and Key Management Relevance

Continuous Validation

In the context of PQC, continuous validation is not just a best practice but an operational necessity. The rapid evolution of quantum-resistant algorithms, combined with uncertain timelines for quantum threats, necessitates that organizations adopt ongoing assurance mechanisms to validate both the effectiveness and compliance of their cryptographic environments.

Traditional “point-in-time” validations, such as annual audits or one-off penetration tests are insufficient for the adoption of PQC. Keys, policies, and cryptographic controls must be continuously monitored, tested, and validated to ensure they remain aligned with emerging standards (e.g., NIST PQC selections), regulatory requirements, and organizational risk thresholds.

Key aspects of continuous validation in PQC key management include:

• Policy Definition and Standards Alignment: This phase defines organizational PQC policies and approved PQC algorithms in alignment with industry standards

• Algorithm and Key Validation: Regular verification that deployed algorithms, key sizes, and rotation schedules match evolving PQC guidance and organizational policies

• Hybrid Environment Testing: Ongoing validation of dual-stack deployments (classical + PQC) to detect misconfigurations, interoperability failures, or degraded performance

• Automated Monitoring and Response: Leveraging orchestration and monitoring tools to detect and respond to anomalies in key usage, unexpected cryptographic calls, or policy drift across cloud and hybrid infrastructures. It should include measuring Mean Time To Detect (MTTD) and response rate.

• Compliance Alignment: Ensuring continuous evidence collection for regulatory and industry frameworks that are adapting to quantum-resilient requirements.

• Feedback and Improvement Loop: The feedback loop uses monitoring data to iteratively harden and mature cryptographic infrastructure. Validation findings regarding policy drift or security issues trigger direct remediations in key lifecycles and architectural planning. This creates a cycle of constant refinement that optimizes both interoperability and security performance.

Moreover, continuous validation must extend beyond active cryptographic operations to cover long-lived data assets. Organizations should identify sensitive data with extended confidentiality or integrity requirements and implement quantum-resilient archival strategies. This includes periodically re-encrypting or re-signing stored data, backups, and immutable logs to mitigate “store now, decrypt later” risks and ensure cryptographic validity persists through the PQC transition.

The ultimate goal of continuous validation is to build cryptographic resilience, aligned with principles of crypto agility and lifecycle management, ensuring that PQC deployments remain secure, performant, and adaptable while minimizing exposure to algorithm obsolescence, misconfiguration risks, and policy drift in the face of shifting threats and evolving standards. Without this ongoing assurance, organizations risk deploying algorithms or key management practices that may quickly become obsolete, non-compliant, or insufficient to protect long lived data assets.

Figure 1: Continuous Validation Lifecycle for PQC Key Management

PQC Transition Roadmap with Key Management Focus

The move toward PQC requires a phased approach that balances technical feasibility, vendor readiness, and organizational alignment. Success depends not only on technology but also on leadership, governance, and a culture of crypto agility.

Immediate Priorities (0–12 Months)

Enterprises must first gain visibility through a comprehensive cryptographic asset inventory, cataloging algorithms, protected data, and sensitivity levels across applications, databases, communication channels, and hardware. Parallel data classification ensures clarity on which assets are most critical. Pilot programs with NIST-standardized algorithms such as ML-KEM (key encapsulation) and ML-DSA (digital signatures) should begin, providing insight into integration challenges and performance impacts. Early engagement with vendors and cloud providers is essential to align roadmaps and reduce future friction.

Key management guidelines (immediate):

• Establish a centralized key inventory mapping all encryption keys to their associated data and algorithms

• Data with long confidentiality requirements (e.g., health records, intellectual property, state secrets) should be accelerated in the transition timeline

• Begin lifecycle tracking (e.g., generation, rotation, archival, destruction) for all keys

• Require dual control and separation of duties for key generation and rotation to reduce insider risk

• Engage vendors to confirm PQC-ready HSM/KMS support and roadmap alignment

• Organizations should also deploy cryptographic discovery and scanning tools capable of identifying embedded cryptographic algorithms in source code, binaries, network protocols, and infrastructure configurations. This capability is essential to build a reliable cryptographic inventory and prioritize migration efforts

• Consider incorporating high-level cost modeling factors (e.g., infrastructure scaling due to larger key sizes, increased CPU overhead, HSM upgrade costs, FIPS re-certification expenses). Adding an executive-level decision framework would enhance strategic planning value

• Organizations should identify long-lived ciphertext in databases, backups, and archives protected by classical key-wrapping mechanisms and initiate a proactive remediation program to mitigate SNDL risks. Where feasible, this includes re-wrapping data encryption keys (DEKs) using quantum-resistant mechanisms such as ML-KEM-derived KEKs, prioritizing actions based on data sensitivity and confidentiality horizon

Mid-Term Priorities (12–36 Months)

Organizations should deploy hybrid cryptography, combining classical and PQC algorithms in TLS, PKI, and other critical workloads to ensure compatibility while strengthening resilience. Interoperability testing across multi-cloud and hybrid environments will uncover gaps and ensure seamless communication. Workforce enablement is equally critical. Structured training programs will build confidence, foster crypto agility, and prepare teams for broader adoption.

Key management guidelines (mid-term):

• Implement hybrid key management, supporting dual algorithm keys (classical + PQC) in PKI and TLS

• Standardize rotation policies for hybrid keys to ensure smooth migration

• Conduct cross-cloud KMS interoperability testing to avoid lock-in and ensure portability

• Introduce crypto agility APIs that allow applications to switch key types without redesign

• Deploy monitoring and telemetry capabilities to track algorithm usage, handshake negotiation outcomes, and fallback events, enabling security teams to detect misconfigurations or downgrade attempts

Long-Term Priorities (36+ Months)

Validated systems should transition to PQC-only modes where feasible, supported by robust governance and continuous validation processes to monitor cryptographic health and compliance. PQC readiness must be embedded into enterprise risk management and compliance frameworks, ensuring resilience evolves alongside regulatory expectations and industry benchmarks.

Key management guidelines (long-term):

• Transition to PQC native key hierarchies in HSM/KMS platforms

• Transitioning master keys (or KEKs) and root-of-trust anchors requires careful sequencing. When done out of order, this can lead to outages

• Hybrid root hierarchies may require dual trust anchors temporarily. Again, this is a matter of correct sequencing

• Disaster recovery processes must support hybrid and PQC keys

• Enforce continuous validation of key strength, usage, and compliance with evolving standards

• Integrate key management metrics (e.g., coverage, rotation frequency, algorithm adoption) into enterprise risk dashboards

• Establish global governance policies for cross-border key residency, ensuring compliance with GDPR, HIPAA, and regional data laws

• Establish enterprise crypto agility frameworks, ensuring that cryptographic algorithms can be upgraded or replaced rapidly as standards evolve or vulnerabilities emerge

Conclusion

Post-quantum cryptography is no longer a distant concern; it is an operational and governance imperative. The risk of “store now, decrypt later” attacks and the accelerating pace of quantum research demand immediate action. Organizations that delay preparation risk both future data exposure and near-term compliance disruption as PQC standards become mandatory.

The transition is challenging larger key sizes, hybrid protocol complexity, and immature tooling, but it is also a unique opportunity to modernize cryptographic governance, strengthen crypto agility, and embed visibility into key management processes. Achieving a successful transition requires a phased roadmap encompassing comprehensive asset inventory and classification, piloting of NIST-standardized algorithms, early vendor engagement, deployment of hybrid architectures, and continuous validation practices.

Leadership must elevate PQC to the board level, treat it as a resilience strategy, and invest in people, processes, and governance. Key management is central; organizations must establish centralized inventories, enforce lifecycle tracking, adopt hybrid key rotation policies, and embed global governance for cross-border compliance.

The PQC shift is one of the most significant security transformations since the advent of public key cryptography. Those who act now will gain operational confidence, vendor leverage, and regulatory resilience. Those who wait may find quantum disruption arrives faster than their governance can adapt. The roadmap begins not with algorithms but with awareness, and the time to act is now.

References

[1] Walton, A. (2025, June). The Impact of Quantum Decryption. Cyber Defense Magazine. https://www.cyberdefensemagazine.com/the-impact-of-quantum-decryption/
[1a] Thomas, J. (2025, January 8). CISA: How Post-Quantum Cryptography Safeguards Against Quantum Threats. Innovation News Network. https://www.innovationnewsnetwork.com/cisa-how-post-quantum-cryptography-safeguards-against-quantum-threats/54045/
[1b] Swayne, M. (2025, May 15). U.S. Presses Federal Agencies to Adopt Post-Quantum Cryptography in Government Acquisitions. The Quantum Insider. https://thequantuminsider.com/2025/05/15/u-s-presses-federal-agencies-to-adopt-post-quantum-cryptography-in-government-acquisitions/
[2] National Cyber Security Centre (NCSC). (2024, August). Next Steps in Preparing for Post-Quantum Cryptography. Government of the United Kingdom. https://www.ncsc.gov.uk/whitepaper/next-steps-preparing-for-post-quantum-cryptography
[3] Moody, D., Perlner, R., Regenscheid, A., Robinson, A., & Cooper, D. (2024). Transition to Post-Quantum Cryptography Standards (NIST Internal Report 8547, Initial Public Draft). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.IR.8547.ipd
[4] Reddy, T., & Tschofenig, H. (2024, July 15). Post-Quantum Cryptography Recommendations for TLS-Based Applications (Internet-Draft, Version 04). Internet Engineering Task Force. https://datatracker.ietf.org/doc/draft-ietf-uta-pqc-app
[5] Ahmad, S. S. (2025, January 16). Lessons Learned from Testing Millions of Servers for PQ Compatibility [Conference presentation]. PKI Consortium Post-Quantum Cryptography Conference, Austin, TX. https://pkic.org/events/2025/pqc-conference-austin-us/THU_BREAKOUT_1100_Syed-Suleman-Ahmad_Lessons-Learned-from-Testing-Millions-of-Servers-for-PQ-Compatibility.pdf
[6] Vredendaal, C. V., Dragone, S., Hess, B., Visegrady, T., Osborne, M., Bong, D., & Bos, J. (2022, October 23). Quantum Safe Cryptography Key Information for CRYSTALS-Kyber (Internet-Draft, draft-uni-qsckeys-kyber-00). Internet Engineering Task Force. https://www.ietf.org/archive/id/draft-uni-qsckeys-kyber-00.html
[7] Banerjee, A., Reddy, T., Schoinianakis, D., Hollebeek, T., & Ounsworth, M. (2026). Post-Quantum Cryptography for Engineers (RFC 9958). Internet Engineering Task Force (IETF). https://datatracker.ietf.org/doc/rfc9958/
[8] Gill, G. (2025, April 9). Navigating the Quantum Shift with PQC. Cisco Blogs. https://blogs.cisco.com/security/navigating-the-quantum-shift-with-pqc
[9] Stebila, D., Fluhrer, S., & Gueron, S. (2025, September 7). Hybrid Key Exchange in TLS 1.3 (Internet-Draft, Version 16). Internet Engineering Task Force. https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design
[10] Reddy, T., & Tschofenig, H. (2025, July 3). Post-Quantum Cryptography Recommendations for TLS-Based Applications (Internet-Draft, Version 08). Internet Engineering Task Force. https://www.ietf.org/archive/id/draft-reddy-uta-pqc-app-08.html
[11] Amazon Web Services. (n.d.). Post-Quantum Cryptography. https://aws.amazon.com/security/post-quantum-cryptography
[12] Canavan, B. (2025, July 29). How to Become Quantum-Ready Today: Luna HSM v7.9 Delivers Real-World PQC, Validated by Thales PKI Technology Partners. Thales CPL. https://cpl.thalesgroup.com/blog/encryption/luna-hsm-pqc-quantum-safe-encryption
[13] Google Cloud. (n.d.). Post-Quantum Cryptography. https://cloud.google.com/security/resources/post-quantum-cryptography
[14] European Commission. (2025, June 23). A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography. Shaping Europe’s Digital Future. https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography
[15] National Institute of Standards and Technology. (2022). Post-Quantum Cryptography: Selected Algorithms — CRYSTALS-KYBER [Project page]. CSRC. https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization/selected-algorithms#kyber
[16] National Institute of Standards and Technology. (2022). Post-Quantum Cryptography: Selected Algorithms — CRYSTALS-Dilithium [Project page]. CSRC. https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization/selected-algorithms#dilithium
[17] National Institute of Standards and Technology. (2022). Post-Quantum Cryptography: Selected Algorithms — SPHINCS+ [Project page]. CSRC. https://csrc.nist.gov/projects/post-quantum-cryptography/selected-algorithms-2022#sphincs
[18] National Institute of Standards and Technology. (n.d.). Cryptographic Algorithm Validation Program [Project page]. CSRC. https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program
[19] National Institute of Standards and Technology. (n.d.). Cryptographic Module Validation Program [Project page]. CSRC. https://csrc.nist.gov/projects/cryptographic-module-validation-program
[20] Driscoll, F., Parsons, M., & Hale, B. (2025, June). Terminology for Post-Quantum Traditional Hybrid Schemes (RFC 9794). Internet Engineering Task Force. https://datatracker.ietf.org/doc/html/rfc9794
[21] Cybersecurity and Infrastructure Security Agency (CISA). (n.d.). Product Categories for Technologies That Use Post-Quantum Cryptography Standards. https://www.cisa.gov/resources-tools/resources/product-categories-technologies-use-post-quantum-cryptography-standards
[22] Davies, S. (2025, June 27). Luna HSM Firmware v7.9 Release: NIST-Approved PQC Algorithms Now Built-In. Thales Data Protection Updates. https://data-protection-updates.gemalto.com/2025/06/27/luna-hsm-firmware-v7-9-release-nist-approved-pqc-algorithms-now-built-in
[23] Mosca, M. (2018). Cybersecurity in an Era with Quantum Computers: Will We Be Ready? IEEE Security & Privacy, 16(5), 38–41. https://doi.org/10.1109/MSP.2018.3761723
[24] Tjhai, C. J., Tomlinson, M., Bartlett, G., Fluhrer, S., Van Geest, D., Garcia-Morchon, O., & Smyslov, V. (2023, May). Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) (RFC 9370). Internet Engineering Task Force. https://datatracker.ietf.org/doc/rfc9370/
[25] Truskovsky, A., Ounsworth, M., Kampanakis, P., et al. (2023). Multiple Public-Key Algorithm X.509 Certificates (Internet-Draft). Internet Engineering Task Force. https://datatracker.ietf.org/doc/draft-truskovsky-lamps-pq-hybrid-x509/
[26] National Institute of Standards and Technology. (2022). Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process (NIST Internal Report 8413). https://doi.org/10.6028/NIST.IR.8413
[27] Amazon Web Services. (n.d.). Key Spec Reference. AWS Key Management Service Developer Guide. https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-choose-key-spec.html

Glossary and Abbreviations

Review the CSA Glossary and CSA Quantum-Safe Security Glossary for terms and definitions related to this paper.

AWS: Amazon Web Services
BYOK: Bring Your Own Key
CAVP: Cryptographic Algorithm Validation Program
CCM2: Cloud Controls Matrix version 2
CIRCL: Cloudflare Interoperable Reusable Cryptographic Library
CMDB: Configuration Management Database
CMVP: Cryptographic Module Validation Program
CRQC: Crypto-Relevant Quantum Computer
CSA: Cloud Security Alliance
DevSecOps: Development, Security, and Operations
ECC: Elliptic Curve Cryptography
ECDSA: Elliptic Curve Digital Signature Algorithm.
ENISA: European Union Agency for Cybersecurity (originally European Network and Information Security Agency)
ETSI: European Telecommunications Standards Institute
FIPS: Federal Information Processing Standards
HSM: Hardware Security Module
IBM: International Business Machines
IETF: Internet Engineering Task Force
IKE: Internet Key Exchange
IoT: Internet of Things
KB: Kilobyte
KSM: Key Security Module (sometimes also Key Management System)
MTU: Maximum Transmission Unit
NIST: National Institute of Standards and Technology
OpenSSH: Open Secure Shell
PKCS: Public Key Cryptography Standards
PQ3: Post-Quantum 3
PQC: Post-Quantum Cryptography
Q-Day: Quantum Day (the point when CRQCs become available)
QKD: Quantum Key Distribution
RSA: Rivest-Shamir-Adleman
SNDL: Store Now, Decrypt Later
SLH-DSA: Stateless Hash-based Digital Signature Algorithm
ML-DSA: Module-Lattice-based Digital Signature Algorithm
ML-KEM: Module-Lattice-based Key Encapsulation Mechanism
SSH: Secure Shell
TLS: Transport Layer Security
VPN: Virtual Private Network