Preparing OpenStack for the post-quantum era: A systematic approach to crypto-agility

OpenStack powers clouds used by some of the most security-sensitive organizations on the planet: government agencies, telecommunications providers, financial institutions, and healthcare systems. Behind every API call, every stored secret, and every tenant workload, cryptography quietly holds the trust model together.

That trust model is about to face its biggest challenge in decades. Shor's algorithm, running on a cryptographically relevant quantum computer (CRQC), will break RSA (Rivest-Shamir-Adleman), ECDSA (Elliptic Curve Digital Signature Algorithm), ECDH (Elliptic Curve Diffie-Hellman), and Ed25519—the very algorithms OpenStack relies on for token signing, key generation, TLS connections, and secret storage. The security community calls the future moment when a CRQC makes this possible Q-day, an event that is a matter of when, not if.

Rather than waiting for that moment, we set out to systematically catalog every quantum-vulnerable cryptographic usage across the entire OpenStack ecosystem. This blog post describes what we found, what we're changing, and how the work connects to the broader Red Hat post-quantum strategy already in production.

Why OpenStack needs specific PQC attention

Many findings in a typical cloud stack resolve automatically when the underlying platform upgrades to OpenSSL 3.5 and its post-quantum algorithms. Python services negotiate post-quantum cryptography (PQC)-hybrid TLS with no code changes—if the application code does not block it.

The problem is that OpenStack code does frequently block it. Across the ecosystem, we found hardcoded algorithm choices, forced TLS 1.2 protocol versions, and key generation routines that only produce RSA or ECDSA keys. These patterns act as barriers that prevent OpenStack from inheriting the PQC protections already available in the platform.

Consider the specific risks:

• Barbican stores long-lived secrets—encryption keys, certificates, passwords. These are prime targets for harvest now, decrypt later (HNDL) attacks, where adversaries collect encrypted data today to decrypt with future quantum computers.
• Keystone signs every authentication token with ECDSA P-256 (ES256), hardcoded with no configuration option. On Q-day, an adversary could forge tokens and impersonate any user.
• oslo.messaging manages RabbitMQ TLS for interservice communication across the entire control plane. Its legacy protocol map blocked TLS 1.3 negotiation, preventing PQC key exchange for all message traffic. 

These risks and more are illustrated in Figure 1.

Figure 1. Where cryptography is used in OpenStack

The analysis: 27 teams, 90+ repositories, 572 findings

We approached this as a structured engineering effort, not a one-off audit. The analysis combined 2 tracks working in parallel.

Upstream, the PQC Migration Pop-up Team, established at the April 2026 PTG (Project Teams Gathering), published an assessment guide and built a per-project cryptographic inventory covering 30 project areas across the OpenStack ecosystem.

Downstream, within Red Hat OpenStack Services on OpenShift, 27 engineering teams analyzed over 90 repositories using an internally-made, purpose-built scanner with dozens of rules organized in 10 categories: asymmetric crypto, TLS configuration, JWT/JWS signing, certificate handling, legacy algorithms, and more. Each team recorded their findings, classifying every hit by algorithm, quantum risk (Shor-vulnerable, Grover-weakened, or safe), severity, and whether the usage was hardcoded or configurable.

An independent security review validated every team's results. The Security Services team ran its own scans against each repository and compared results, identifying gaps where teams had missed findings or misclassified severity.

The result, illustrated in Figure 2: 572 documented findings across 23 teams, with 39 cross-cutting patterns that repeat across multiple components. Of those teams, Security Services (103 findings) leads with its cross-cutting analysis of shared components like Castellan, oslo.service, and keystonemiddleware. VANS (62) follows with Octavia and Designate's extensive certificate and key generation code. EDPM (55) and Cinder (48) reflect the breadth of cryptographic usage in operators and drivers.

Figure 2. Distribution of PQC-relevant findings across Red Hat OpenStack Services on OpenShift teams

What we found: Four critical patterns

Figure 3 illustrates the vulnerabilities discovered in different projects. Projects like Barbican, Octavia, and Nova have the highest concentration of quantum-vulnerable code that requires application-level fixes. Across all repositories, the findings concentrate into 4 systemic patterns.

• Hardcoded asymmetric key generation. Barbican's SimpleCrypto plugin only generates RSA and DSA keys. Keystone signs JWS tokens with a hardcoded ECDSA P-256 call—no configuration option, no way to switch to a post-quantum algorithm. Octavia builds amphora certificates with hardcoded RSA and ECDSA. Every one of these is broken by Shor's algorithm.
• TLS protocol barriers. oslo.messaging's RabbitMQ driver maintained a legacy ssl_version configuration option that mapped to specific protocol constants, including PROTOCOL_TLSv1_2. This map had no entry for TLS 1.3, effectively blocking PQC hybrid key exchange (which requires TLS 1.3) for all interservice messaging. Apache configurations across multiple operators similarly lacked TLS 1.3 in their SSLProtocol directives.
• Certificate validation bypass. We found InsecureSkipVerify (Go) and verify=False (Python) scattered across multiple components: lib-common, Cinder storage drivers (NetApp, Synology), Manila, and the VMware migration kit. While not a quantum-specific vulnerability, disabling certificate validation removes a critical defense layer during the transition period.
• Default crypto in Kubernetes operators. cert-manager Certificate resources without a privateKey specification default to RSA-2048. Go-based operators without an explicit tls.Config.MinVersion allow protocol downgrade. These patterns repeat across nearly every Red Hat OpenStack Services on OpenShift operator.

Figure 3. Upstream per-project inventory showing CRITICAL and HIGH findings 

The dependency chain: What resolves automatically

Not every finding requires a code change. Understanding the dependency chain, illustrated in Figure 4, is essential for prioritizing work.

Figure 4. The PQC dependency chain

OpenStack services sit on top of pyca/cryptography, which wraps OpenSSL. OpenSSL 3.5 ships ML-KEM (FIPS 203) and ML-DSA (FIPS 204) natively, and negotiates hybrid TLS key exchange (X25519MLKEM768) by default. Since May 2026, pyca/cryptography 48.0.0 exposes ML-KEM and ML-DSA primitives to Python applications running on OpenSSL 3.5. Version 49.0 (June 2026) adds X.509 certificate support for ML-DSA. Python services will automatically negotiate PQC-protected TLS connections—but only if the application code does not restrict protocol versions, cipher suites, or key exchange groups.

This means a significant portion of findings resolve with a platform upgrade alone:

• TLS hybrid key exchange for all Python services using ssl.SSLContext without protocol restrictions
• cert-manager certificates, once cert-manager supports ML-DSA issuance
• Go-based operators on Go 1.24+, which includes ML-KEM in its default TLS key exchange groups

Fixing some vulnerabilities will require code changes in OpenStack itself:

• Barbican key generation (add ML-DSA/ML-KEM key types)
• Keystone JWS token signing (make algorithm configurable)
• oslo.messaging TLS (remove legacy protocol map, enable TLS 1.3)
• openstacksdk and cursive (add ML-DSA signature support)

The upstream work is less about implementing crypto and more about removing barriers and ensuring crypto-agility.

Making OpenStack crypto-agile

We are not waiting for full PQC library support to start fixing things. The first phase focuses on crypto-agility: making algorithm choices configurable so that operators can adopt post-quantum algorithms as soon as the underlying libraries support them.

Barbican: Crypto-agile key generation. The SimpleCrypto plugin now supports elliptic curve (EC) key generation alongside RSA and DSA, with a new asymmetric_key_default_algorithm configuration option. Operators can set this to RSA, DSA, or EC in barbican.conf, and the chosen algorithm applies to all key generation requests that do not specify one via the API. The internal architecture has been refactored into a dispatch pattern that makes adding ML-KEM and ML-DSA straightforward—now that pyca/cryptography 49.0+ ships both algorithms, extending Barbican to generate post-quantum keys requires minimal code changes.

Keystone: Configurable JWS token signing. Token signing is no longer locked to ES256. Operators can now configure the JWS algorithm, choosing from ES256, ES384, ES512, or EdDSA. A separate jws_accepted_algorithms option enables a migration window where tokens signed with a previous algorithm remain valid until they expire. This prepares Keystone for ML-DSA adoption now that pyca/cryptography 49.0+ ships ML-DSA primitives and RFC 9964 (May 2026) registers ML-DSA as an official JOSE (JSON Object Signing and Encryption) algorithm.

Keystone: PBKDF2-SHA512 password hardening. Keystone now supports transparent password rehashing: When a user authenticates successfully and the stored hash uses fewer PBKDF2-SHA512 iterations than currently configured, the password is automatically rehashed with no user interaction. The default iteration count has been raised from 25,000 to 600,000, aligning with the OWASP 2023 recommendation. Grover's algorithm provides a quadratic speedup for brute-force search, making high iteration counts essential for long-term password security in a post-quantum context.

oslo.messaging: TLS 1.3 for RabbitMQ. The legacy ssl_version option and its protocol map have been deprecated and removed from the RabbitMQ driver. Without the legacy map, the driver defaults to modern SSLContext behavior, which negotiates TLS 1.2 or 1.3 automatically. This enables PQC hybrid key exchange (X25519MLKEM768) for all interservice messaging across the control plane, affecting every OpenStack service that communicates via RabbitMQ.

Operator TLS hardening. Rather than fixing each operator individually, we are implementing centralized solutions in openstack-operator and lib-common. A single change to the openstack-operator's certificate templates adds an explicit privateKey specification to every cert-manager Certificate resource across all Red Hat OpenStack Services on OpenShift operators, replacing the RSA-2048 default. Similarly, Apache SSL/TLS configurations will inherit secure defaults from the OpenShift TLS profile, enforcing TLS 1.2+ minimum and enabling TLS 1.3 across all operators with a single configuration point.

All of these changes are being submitted upstream under the pqc-migration Gerrit topic and are currently under review by core maintainers.

The phased approach: From analysis to migration

The remediation follows a 6-phase plan with clear dependency ordering, illustrated in Figure 5.

Figure 5. The PQC remediation roadmap for OpenStack, grouped by phases

• Phase 1 (patches submitted): Crypto-agility foundations—make Keystone JWS and Barbican key generation configurable.
• Phase 2 (patches submitted): Quick wins—PBKDF2 iterations, oslo.messaging TLS, osprofiler HMAC-SHA1 upgrade, python-keystoneclient CMS removal.
• Phase 3 (in progress): Operator TLS hardening—enforce TLS 1.2+ minimum and add privateKey spec to cert-manager certificates across all Red Hat OpenStack Services on OpenShift operators via centralized changes in openstack-operator and lib-common.
• Phase 4: Barbican ecosystem—validate Dogtag KRA, PKCS #11 lifecycle, and key format translations with PQC key types.
• Phase 5 (unblocked): Full PQC integration—add ML-DSA and ML-KEM as key types in Barbican, Keystone, openstacksdk, cursive, and python-openstackclient. The library dependency is now resolved: pyca/cryptography 49.0+ ships ML-KEM, ML-DSA, and X.509 ML-DSA certificate support.
• Phase 6 (currently blocked): Tempest validation—end-to-end API testing with PQC configurations, blocked on completion of earlier phases.

Community engagement

This work is happening in the open. The PQC Migration Pop-up Team, co-led by the Red Hatters Maurício Harley and Jean-Philippe Jung, was established at the April 2026 PTG. The Technical Committee approved the governance change, making PQC Migration an officially recognized upstream effort.

The team operates under 3 guiding principles:

• Opt-in and backward-compatible. PQC is added alongside classical algorithms. Operators adopt at their own pace. No existing deployments are broken.
• No custom cryptography. OpenStack relies on platform libraries (OpenSSL, pyca/cryptography). Our job is to remove barriers and expose configuration.
• Crypto-agility over crypto replacement. Algorithm choices should be configurable, not hardcoded. This future-proofs OpenStack against any algorithm transition.

Resources are available for any project team that wants to assess their own repositories:

• Wiki: wiki.openstack.org/wiki/Post_quantum_openstack
• Gerrit hashtag: pqc-migration
• Etherpad: etherpad.opendev.org/p/openstack-pqc-migration

Connecting the dots: Red Hat Enterprise Linux, Red Hat OpenShift, and Red Hat OpenStack Services on OpenShift

The OpenStack PQC work is not happening in isolation. It builds on—and benefits from—the PQC foundations already in production across the Red Hat ecosystem, as shown in Figure 6.

Figure 6. The Red Hat platform ecosystem and its engagement with PQC security

• Red Hat Enterprise Linux (RHEL) 10.x provides the cryptographic bedrock. OpenSSL 3.5 ships ML-KEM and ML-DSA natively. Since RHEL 10.1, the system-wide crypto policy prefers PQC by default for TLS and SSH connections, and RPM packages are signed with ML-DSA keys. RHEL 10.2 extends PQC to SSH key exchange in FIPS mode.
• Red Hat OpenShift 4.20+ brought PQC to the control plane, protecting internal TLS communication between cluster components. Service Mesh 3.3 added opt-in PQC support for in-mesh mTLS and gateways via X25519MLKEM768 hybrid key exchange.
• Red Hat OpenStack Services on OpenShift inherits all of this. When RHEL negotiates PQC-hybrid TLS by default and Red Hat OpenShift protects the control plane, OpenStack services running on that stack already benefit for every connection that does not hardcode a classical-only algorithm. The application-level work described in this post removes those remaining barriers, so the full stack is quantum-ready from the operating system to the cloud API.

What you can do today

If you operate an OpenStack cloud or contribute to an OpenStack project, here are concrete steps you can take right now:

1. Audit your code for hardcoded algorithm choices (RS256, ES256, SECP256R1, rsa.generate_private_key). The assessment guide on the OpenStack wiki provides search patterns and classification criteria.
2. Remove ssl.wrap_socket() calls. Replace them with ssl.SSLContext, which is required for PQC key exchange negotiation.
3. Don't force TLS 1.2. Allow TLS 1.3 negotiation. PQC hybrid key exchange requires TLS 1.3.
4. Make algorithm choices configurable. Expose configuration options instead of hardcoding algorithm constants.
5. Use PKCS #8 for key serialization. Unlike PKCS #1, PKCS #8 is algorithm-agnostic and will work with ML-DSA and ML-KEM keys without format changes.

For operators, the step you can take that would have the most impact is to plan an upgrade to RHEL 10.x and test hybrid TLS in a staging environment. When your platform negotiates PQC by default, every OpenStack service running on it benefits immediately—except where application code blocks it.

For developers, review the PQC cryptographic inventory on the upstream wiki for your project. The tracking sheet shows exactly which findings need attention. Join the openstack-discuss mailing list (tag [pqc-migration]) to coordinate.

The analysis is complete. The remediation is underway. And the foundation—RHEL, Red Hat OpenShift, and the upstream platform libraries—is already quantum-ready. What remains is removing the barriers in OpenStack's own code so the entire stack can benefit.

The quantum clock is ticking. The levee is being built. Now it's time to make sure OpenStack is on the right side of it.

Learn more about post-quantum cryptography in Red Hat products:

• “Building the levee: Why Red Hat's post-quantum strategy is already in production,” Emily Fox
• “Advancing post-quantum capabilities in SSH on Red Hat Enterprise Linux,” Pavol Žáčik
• OpenStack PQC Migration Wiki