Red Hat counted 572 quantum-vulnerable spots in OpenStack. The obstacle is OpenStack's own pins.

The mechanism that makes this an inventory exercise rather than a migration sits in one line of Red Hat's write-up: much of a cloud stack's quantum exposure closes by itself when the platform moves to OpenSSL 3.5, because Python services will negotiate PQC-hybrid TLS without a code change, as long as the application does not block it ^[8]. OpenStack blocks it, repeatedly, through hardcoded algorithm choices, forced TLS 1.2 versions and key generation routines that emit only RSA or ECDSA ^[2].

That reframes the deliverable. The unit of work is not a new algorithm but a location where somebody froze a choice years ago. oslo.messaging is the clean example: a legacy protocol map kept TLS 1.3 off the table, which quietly denied post-quantum key exchange to every message on the control plane bus ^[4]. Nobody decided that. It was inherited.

The counts are worth doing arithmetic on. 572 findings spread over more than 90 repositories averages fewer than 6.4 per repository ^[19], which reads as thin until you look at where they sit. Security Services alone recorded 103, from cross-cutting analysis of shared components including Castellan, oslo.service and keystonemiddleware ^[14]. That is 18 percent of the total in library code rather than in any service ^[18]. Add VANS at 62, EDPM at 55 and Cinder at 48, and four teams hold 47 percent of everything found ^[15][17]. With 39 patterns identified as repeating across components ^[13], the fix list is far shorter than the finding list, and the highest-leverage entries are in code no OpenStack project owns by itself.

Two details deserve more attention than the headline number. First, the self-reported pass was not trustworthy on its own: an independent scan by the Security Services team against each repository turned up findings teams had missed and severities they had misclassified ^[5]. Anyone planning the same exercise should budget for the second scanner and the reviewer, not just the first sweep.

Second, Keystone. Every authentication token is signed with ECDSA P-256, hardcoded, with no configuration option ^[3]. An operator running a sensitive OpenStack cloud cannot mitigate that, cannot stage it, and cannot test an alternative. It ships as code or it does not exist, which puts the schedule in Red Hat's hands and the consequence, forged tokens and user impersonation once a capable quantum computer exists ^[3], in the operator's.

The upstream half of the effort is structured differently: a PQC Migration Pop-up Team formed at the April 2026 PTG published an assessment guide and a per-project inventory covering 30 project areas ^[10], against the downstream scan's 90-plus repositories and 10 rule categories ^[11]. Two inventories at two granularities, and only one of them classifies each hit as Shor-vulnerable, Grover-weakened or safe with a hardcoded-or-configurable flag attached ^[12]. The flag is the part that tells an operator whether they have a knob or a wait.