SerpApi.Org
A researcher at the Federal Rural University of the Amazon published a framework Tuesday that may finally answer the most stubborn governance question in post-quantum cryptography migration: not what to migrate to, but how to measure how far along you actually are. The paper, approved July 21 on the IACR Cryptology ePrint Archive, proposes the Crypto-Agility Readiness Score (CARS) — a five-dimension weighted composite index that gives security teams a single, defensible number representing their migration readiness.
The timing is pointed. Today, July 22, 2026, marks exactly 30 days since President Trump signed Executive Order 14412, "Securing the Nation Against Advanced Cryptographic Attacks" — the deadline by which every federal agency must have designated a PQC migration lead responsible for cryptographic inventory management and agency-wide planning. The framework, which Skadden and other legal analysts have confirmed flows through the Federal Acquisition Regulation to government contractors, transforms what was once an aspirational timeline into a compliance obligation with real contractual consequences.
CARS does not just fill a governance gap. It fills the gap that cryptographers, standards bodies, and enterprise security teams have explicitly identified as the reason migration plans stall: without a shared, quantifiable metric, a CISO cannot report meaningful progress to a board, a migration engineer cannot prioritize remediation work, and auditors have no baseline against which to measure progress. CARS is to PQC readiness what CVSS scores are to vulnerability severity — an attempt to turn a sprawling, multi-dimensional problem into a number that can actually drive decisions.
Most Cryptographic Tooling Scores One-Quarter Ready
The paper's benchmark data is unsparing. Allan D.B. Costa evaluated 43 open-source cryptographic software repositories across three infrastructure categories and found that even specialized tooling remains far from full PQC readiness:
Legacy cryptographic libraries averaged a CARS of 24.9 out of 100, with a standard deviation of 9.5. PKI and certificate management tools averaged 25.8 ± 8.2. HSM and PKCS#11 middleware — the most purpose-built infrastructure category — averaged 39.7 ± 15.2, scoring higher in part because these projects specifically exist to address cryptographic boundary problems.
Put plainly: the category of software that most organizations will use to execute their PQC migration currently clears, on average, roughly one-quarter of the readiness bar the framework defines. The HSM/PKCS#11 result offers a partial exception — these tools have a narrower focus and more natural alignment with the interface-level changes PQC requires — but even a score of 39.7 leaves substantial ground to cover before the 2030 deadline.
Why Measurement Has Been So Hard
Post-quantum cryptography as a field now knows what to migrate to. NIST finalized three landmark standards in August 2024: FIPS 203 (ML-KEM, a module-lattice-based key encapsulation mechanism derived from CRYSTALS-Kyber), FIPS 204 (ML-DSA, a module-lattice-based digital signature algorithm derived from CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, a stateless hash-based signature algorithm derived from SPHINCS+ and designed as a conservative fallback independent of lattice cryptography's hardness assumptions).
What has been missing is a way to measure how far along an organization is in getting there. The existing landscape includes ETSI's three-stage migration model, the PKI Consortium's PQC Capabilities Matrix, and commercial assessment tools from vendors including SEALSQ — but these tend to be qualitative, stage-based, or checklist-driven, making direct comparison across organizations or time periods difficult.
CARS attempts to operationalize the concept of crypto-agility — the capacity to swap out cryptographic algorithms without overhauling entire systems — across five concrete dimensions, scored via a weighted composite index: Inventory Completeness (has the organization identified all cryptographic assets, including hard-coded primitives and third-party dependencies?), Algorithm Compliance (do deployed algorithms align with NIST FIPS standards, and have deprecated predecessors like Kyber been formally retired?), Architectural Decoupling (are cryptographic functions isolated from application logic to enable algorithm substitution without systemic refactoring?), Toolchain Readiness (does the build, test, and deployment pipeline support PQC algorithms end-to-end, including HSM/PKCS#11 middleware and TLS libraries?), and Governance & Compliance Alignment (are migration activities tracked against external mandates with documented responsibilities and audit trails?).
The weights for each dimension came not from theoretical estimation but from a two-round Delphi process involving 12 senior migration engineers — a methodology that gives the scoring system empirical grounding while keeping the index auditable.
The Harvest Now, Decrypt Later Clock Is Already Running
The urgency behind the CARS paper is not theoretical. Nation-state adversaries are widely believed to be conducting what security researchers call Harvest Now, Decrypt Later (HNDL) attacks: intercepting and archiving encrypted network traffic today, with the intent to decrypt it retroactively once a Cryptographically Relevant Quantum Computer (CRQC) becomes available. While direct evidence of HNDL programs remains classified or inferential, EO 14412 itself explicitly cites this threat model as a policy driver, stating that "adversaries may harvest highly sensitive but encrypted material" now, before the quantum technology to break it exists.
For data carrying confidentiality requirements extending into the mid-2030s or beyond — trade secrets, healthcare records, classified intelligence — the HNDL window has effectively already closed under classical cryptography. Organizations protecting such data are not migrating ahead of the threat; they are catching up to it.
Cloud Security Alliance estimated in early 2026 that Q-Day — the arrival of a CRQC capable of breaking standard RSA and ECC encryption — could occur by 2030. A 2025 paper by Craig Gidney of Google revised downward the estimated qubit count required to break RSA-2048 to under one million physical qubits, from a prior estimate of roughly 20 million, suggesting the timeline may be compressing faster than regulatory planning assumed.
How CARS Works in Practice
The paper's most compelling evidence comes from a longitudinal case study of oqs-provider — the Open Quantum Safe project's OpenSSL 3 provider plugin and the primary mechanism by which enterprises currently integrate NIST PQC algorithms into TLS 1.3 and PKI workflows for testing.
Costa tracked CARS scores across oqs-provider releases from version 0.3.0 (January 2022) to version 0.6.0 (April 2024), mapping the project's migration arc over more than two years. The analysis recorded a Delta CARS of plus 21 points across that span — a measurable, quantified improvement that aligns directly with real engineering milestones: the deprecation of Kyber (the pre-standardization Round 3 algorithm) in favor of ML-KEM (FIPS 203 final), the addition of ML-DSA (FIPS 204 final) support, fixes to PKCS#11 integration, and updates to IANA code points.
This is significant because it demonstrates that CARS is not merely a snapshot metric. It can function as a longitudinal tracking tool — one that shows migration velocity over time and correlates score changes with specific technical events. That means a security team can use it not just to tell a board "we are at 38," but "we gained 21 points over the past two years, and here are the specific engineering changes responsible."
The oqs-provider has continued evolving beyond the study window, reaching version 0.9.0 in May 2025 per the Open Quantum Safe TLS release history. The OpenSSL Corporation now ships native ML-KEM, ML-DSA, and SLH-DSA support, with TLS defaulting to the hybrid X25519MLKEM768 key exchange — meaning the ecosystem the CARS framework measures has itself continued advancing since the study closed.
The Technical Gap CARS Specifically Surfaces
The benchmark scores reveal something engineers already know but rarely quantify: the architectural decoupling and governance dimensions are where most projects fall short, not the algorithm implementation dimension.
This matters because the pattern of PQC software development tends to prioritize the cryptographic algorithm first — getting ML-KEM or ML-DSA implemented and correct — and treat the system-level questions later: How is the key stored? What HSM firmware needs updating? Does the TLS library honor the PKCS#11 interface or does it bypass it? Is there a documented owner for each cryptographic dependency? These are the questions CARS Dimensions 3, 4, and 5 probe, and they are the ones where the benchmark data shows scores clustering near the bottom of the range.
HSM/PKCS#11 middleware scores higher not because its underlying cryptography is more advanced, but because PKCS#11 is an explicit interface standard — software targeting it must, by definition, work at the abstraction layer that crypto-agility requires. The lesson the benchmark implies is that software designed around a stable interface contract is inherently more migratable than software where cryptographic calls are embedded directly in application logic.
An independent 2026 study across 32,011 internet domains found that while 49.3% now support hybrid post-quantum key exchange mechanisms such as ML-KEM-768 combined with X25519, exactly zero percent had deployed hybrid post-quantum certificates — leaving the authentication layer fully exposed to quantum-enabled certificate forgery even where key exchange has already been upgraded.
What EO 14412 Means for Contractors Who Cannot Answer These Questions
Federal contractors face a compounding obligation. EO 14412 requires the FAR Council to publish a proposed rule within 180 days — by approximately December 19, 2026 — requiring covered contractors to comply with NIST FIPS standards, including all those incorporating PQC-compliant algorithms, by December 31, 2030. A separate 270-day rule will require contractor vulnerability disclosure policies covering cryptographic vulnerabilities, and CISA guidance on minimum elements for a Cryptographic Bill of Materials will follow on the same timeline.
A CBOM requirement is what transforms CARS from a research tool into a potential compliance artifact. Once regulators publish CBOM guidance, contractors will need to document every cryptographic asset in their software and hardware — the precise input that CARS Dimension 1 (Inventory Completeness) formalizes. Organizations that have already built that inventory will have a CARS-compatible foundation; those starting from scratch will face a compressed timeline.
Sectigo's "State of Crypto Agility" report from August 2025 found that 97% of organizations report significant PQC-related skills gaps, and only 14% have completed a full assessment of their quantum-vulnerable systems. Separate analysis suggests that full PQC migration for a large enterprise typically takes five to ten years, which means an organization beginning its migration seriously in 2026 is at the outer edge of feasibility for the 2030 deadline.
The DoW PQC Strategy, released June 24, 2026, extends these timelines across the Defense Industrial Base and into the Cybersecurity Maturity Model Certification program, signaling that even companies without direct federal contracts may face PQC compliance requirements as they flow through the defense supply chain.
Does Your Toolchain Score Measure Up?
For organizations currently navigating PQC migration, the CARS framework raises several practical questions worth examining against their own infrastructure.
On inventory: Most enterprises have significant blind spots in their cryptographic asset inventory. Hard-coded algorithm references in firmware, legacy certificate management systems, cloud provider dependencies, and HSM configurations all represent places where classical cryptography can sit undetected outside an organization's update cycle. CARS Dimension 1 forces a reckoning with the full scope of that inventory before a migration plan can be meaningfully constructed.
On decoupling: The benchmark data's most actionable finding is that architectural decoupling scores poorly across all three infrastructure categories because most deployed software was never designed to be cryptographically agile. Abstraction layers, dependency injection patterns, and modular cryptographic interfaces all carry their own engineering cost. CARS provides a governance rationale for investing in that refactoring now rather than waiting until EO deadlines create forced-march timeline pressure.
On compliance: Federal contractors who cannot produce a quantified, auditable readiness score may find themselves at a disadvantage as FAR rulemaking converts FIPS compliance from a best practice into a contract condition. A standardized metric like CARS offers something that stage-based checklists cannot: a number that changes as engineering work gets done, making compliance progress traceable and defensible.
The paper, authored by Costa of the Federal Rural University of the Amazon, is available as IACR Cryptology ePrint Archive Paper 2026/1467. Whether CARS ultimately becomes the standard the field settles on or a starting point that peer review and adoption refine, the 43-repository benchmark dataset provides a calibration baseline that has not previously existed — and in a migration effort operating against a hard 2030 clock, a measurable starting point is not a minor contribution.
Frequently Asked Questions
How does the Crypto-Agility Readiness Score differ from existing post-quantum migration frameworks?
Prior frameworks from ETSI, the PKI Consortium, and commercial vendors are primarily qualitative: they assign organizations to stages or categories rather than producing a number that changes as engineering work progresses. CARS is a five-dimension weighted composite index calibrated against 43 real open-source repositories using scores derived from a Delphi process with 12 migration engineers. The result is a metric that can be tracked longitudinally — the oqs-provider case study recorded a plus-21-point gain across two years of releases, tied to specific engineering milestones. That auditability is what distinguishes it from checklist-based assessments.
What is a Harvest Now, Decrypt Later attack and why does it make PQC migration urgent today?
A HNDL attack involves intercepting encrypted network traffic now and storing it, with the intent to decrypt it once a sufficiently powerful quantum computer becomes available. Because the decryption happens in the future, the urgency is present-tense: data collected today under RSA or ECC encryption that must remain confidential for ten or more years is already exposed to this threat, regardless of when a CRQC actually arrives. Organizations protecting long-lived sensitive data — health records, trade secrets, classified material — are not migrating ahead of the threat; the HNDL window for much of that data has already opened.
Could CARS become the industry standard for measuring PQC readiness — and what would that mean for compliance?
CARS is the first publicly available quantitative metric for crypto-agility readiness in legacy systems, and its arrival coincides with EO 14412's requirement for Cryptographic Bills of Materials guidance from CISA. A CBOM requirement effectively mandates the kind of cryptographic inventory that CARS Dimension 1 formalizes. If CISA or NIST incorporates a readiness scoring methodology into CBOM guidance or FAR rulemaking, a framework like CARS could become a compliance artifact rather than a research proposal. The field has explicitly lacked a standard metric for years; CARS is the most structured candidate currently available.
Does EO 14412 apply to private companies that are not federal contractors?
Not directly — EO 14412 imposes migration obligations on federal agencies and, through anticipated FAR rulemaking, on covered government contractors. However, the DoW PQC Strategy released June 24, 2026 explicitly extends requirements to the Defense Industrial Base, including updates to the Cybersecurity Maturity Model Certification (CMMC) program. Beyond defense, the EO requires Sector Risk Management Agencies to assist critical infrastructure operators in developing PQC migration plans. For any organization in the federal supply chain, financial services, healthcare, or critical infrastructure, the practical compliance pressure extends beyond the literal text of the executive order, as Skadden's analysis of the EO and its contractor flowdown obligations explains.
Related Articles
