The Open Standards Behind Post-Quantum Readiness

Post-quantum migration is a decade-long, industry-wide effort. It runs on shared, open, standards-aligned scaffolding, not on another proprietary score. Here is a field guide to the frameworks and standards worth adopting, and the case for keeping them open.

The post-quantum transition is unusual among security programs in that it is happening to everyone at once, on a published schedule, for the same underlying reason. That is a gift: it means the industry does not have to invent private answers to shared questions. There is a growing stack of open standards and frameworks that already describe what “quantum-ready” means, how to migrate, and how to prove it. The most useful thing most teams can do is not to build a bespoke readiness program, but to adopt the open pieces that already exist and align to the standards their auditors and customers already recognize.

This is a field guide to that stack: the standards layer, the framework layer, and the evidence layer, and why keeping all three open is not idealism but the reason any of it works.

The standards layer: NIST, and the deadlines that follow from it

Everything downstream anchors to a small set of public documents. Worth knowing by name, because your framework and your tooling should map back to them:

• The algorithms. In August 2024 NIST finalized its first post-quantum standards: ML-KEM (FIPS 203) for key establishment, and ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures. These are the replacements for RSA, Diffie-Hellman, and the elliptic-curve schemes.
• The timeline. NIST’s draft transition guidance (IR 8547) proposes deprecating the quantum-vulnerable algorithms after 2030 and disallowing them after 2035. NSA’s CNSA 2.0 sets a 2033 target for national-security systems.
• The migration guidance. NIST’s NCCoE runs a public “Migration to Post-Quantum Cryptography” project (SP 1800–38) that documents discovery, prioritization, and interoperability in the open, with industry participants.

The important property here is not the specific dates. It is that these are open, citable, versioned references that everyone shares. A readiness program that aligns to them is legible to any auditor; one built on a private rubric has to be re-explained every time.

The framework layer: maturity models as a shared language

Standards tell you what “correct” looks like for an algorithm. They do not tell you how ready an organization is, because readiness is not one property. It spans whether you can even see your cryptography, whether someone owns the migration, whether your data protection is quantum-safe, and whether your infrastructure can actually deploy the change. A single number cannot carry that, and every team that reduces it to one ends up hiding its weakest area behind an average.

This is what maturity models are for, and it is where an open framework earns its place. The Quantum Readiness Assurance Maturity Model (QRAMM) is one worth knowing: an open framework from CyberSecurity NonProfit (CSNP), released under the MIT License and developed in the open at github.com/csnp/qramm. It organizes readiness into four dimensions, each with practices scored across five maturity levels:

• Cryptographic Visibility & Inventory: knowing where cryptography lives and what depends on it.
• Strategic Governance & Risk Management: ownership, risk methodology, third-party exposure.
• Data Protection Engineering: quantum-safe encryption, key management, and data handling.
• Implementation & Technical Readiness: crypto-agility, capabilities, and testing.

A framework like this does two things a proprietary score cannot. It gives a customer, a vendor, and an auditor the same words for the same thing, so a readiness claim travels. And because it is open, its questions, weights, and control mappings can be read, challenged, and adopted by anyone, which is what turns a model into a shared standard rather than one company’s dashboard.

Get Leon Acosta’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Frameworks are also where readiness connects to the compliance programs you already run. A good one maps its practices to the control catalogs organizations report against, so a readiness gap reads as a compliance signal: NIST CSF 2.0, ISO/IEC 27001 (including A.8.24, the cryptography control), CMMC 2.0, SOC 2, FedRAMP, FISMA, and CIS Controls v8. Aligning to existing catalogs, rather than defining a new one, is the difference between a framework people can adopt tomorrow and one they have to be sold.

The evidence layer: open formats so results travel

The last layer is proof, and it has the same open-versus-proprietary fault line. If your inventory or your scan results are locked in a vendor format, they stop being evidence the moment you change tools. Two open formats matter here:

• CBOM (CycloneDX): a cryptographic bill of materials: a machine-readable, diffable inventory of every algorithm, key, and certificate, in an OWASP-governed format that any compliant tool can read.
• SARIF (OASIS): the static-analysis interchange format, so cryptographic findings show up as first-class alerts in the same code-scanning surface as everything else.

Open evidence formats are what make a readiness program portable: you can change scanners, hand results to an auditor, or feed them into a maturity assessment without re-keying anything. Proprietary output is a lock-in you pay for later.

Why open source, specifically

There is a reason this whole stack leans open, and it is not fashion. It is the oldest principle in cryptography, and it is how these standards came to exist in the first place.

Cryptography has known since Kerckhoffs in the 19th century that a system’s security must not depend on the secrecy of its design, only its keys. “Trust us, it is secure” is the one claim cryptographers do not accept. The NIST post-quantum standards themselves are the proof: they came out of an open, multi-year public competition (2016 to 2024) in which the entire community tried to break every candidate in the open. That is why we trust ML-KEM and ML-DSA. It would be strange to secure your migration to openly-vetted algorithms with closed, unauditable readiness tooling on top.

Open also travels. A proprietary readiness score is legible to one vendor; an open, cited framework is legible to your auditor, your customer, and your successor. And open lets the ecosystem improve the thing rather than each buyer re-deriving it: a fix to an open framework or an open scanner benefits everyone who adopts it.

The principle: adopt and contribute, do not reinvent

This is the approach we take at quantakrypto, and we think it is the right default for anyone building in this space. Where an open standard or framework already exists, adopt it and align to it rather than shipping a private substitute. Contribute back where you can add something, and keep your own tools open so results are auditable and portable.

Concretely, that has meant adopting QRAMM as the maturity framework rather than inventing a quantakrypto score, mapping it to the compliance catalogs teams already report against, and keeping the toolkit that produces the evidence, qScan, Sieve, and qProbe, open source with open output formats. The contribution we aim to add is not a new standard but a way to make the existing ones actionable: a five-minute readiness assessment built on the open model, and evidence that flows from scans and conformance runs into it. Full credit for the framework belongs to CSNP; the point of a shared model is precisely that no single company owns it.

Where this is going

The post-quantum migration will run for a decade or more, across every industry, and no single vendor or agency will carry it. Efforts at that scale succeed on shared, open scaffolding, the way the security of the web itself was built on open protocols and public review rather than proprietary boxes. The standards for the algorithms are set and open. The frameworks for organizational readiness are emerging and, increasingly, open. The evidence formats are open. The most durable thing a team can do is to build on those, align to them, and contribute back, instead of adding one more private rubric to a problem that is fundamentally shared.

If you are starting, start by adopting rather than inventing: read the NIST guidance, pick an open framework, use open evidence formats, and align to the compliance catalogs you already answer to. That is a posture that survives your tools, your vendors, and the next algorithm change, which is the only kind worth building.

Links and references

• Post-quantum standards: FIPS 203 (ML-KEM) · FIPS 204 (ML-DSA) · FIPS 205 (SLH-DSA)
• QRAMM, the open maturity model: qramm.org · github.com/csnp/qramm (MIT, by CSNP)
• Readiness standard and compliance mapping: quantakrypto.com/readiness · free assessment
• Open evidence formats: CycloneDX CBOM · SARIF (OASIS)
• Open toolkit: github.com/quantakrypto/pqc-tools
• quantakrypto: site · blog

quantakrypto, operated by Dandelion Labs JSC, works on open, standards-aligned post-quantum readiness. QRAMM is the open maturity model by CyberSecurity NonProfit (CSNP), released under the MIT License; we adopt and build on it with attribution.