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 attentionMany 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.