QuantumReady 365: Post-Quantum Cryptography for .NET, Done Safely

Post-quantum cryptography (PQC) is no longer a research topic — it is a shipped, standardized, and increasingly mandated part of building secure software. .NET 10 puts the core algorithms directly in your hands. The hard part is no longer whether the algorithms exist; it is adopting them safely, consistently, and in a way you can govern across a real codebase.

QuantumReady 365 is the educational companion and design blueprint for doing exactly that on .NET. This page is the foundation: the threat, the standards, the .NET 10 reality, and the gap a library is meant to fill.

Scope note. This documentation is public and educational. It teaches concepts, shows runnable code against .NET's in-box APIs, and describes the design of the QuantumReady 365 approach. The production library itself ships separately under CipherShift365 on a controlled feed. Where a capability is part of that library rather than something you can run today against the base class library (BCL), it is labelled [library].

1. Why now: harvest-now, decrypt-later

The urgency does not depend on a quantum computer existing today. The threat model is harvest-now, decrypt-later: an adversary records encrypted traffic or exfiltrates encrypted data now and simply waits. The day a cryptographically-relevant quantum computer arrives, every RSA- or elliptic-curve-protected secret captured in the meantime becomes readable retroactively.

This reverses the usual security timeline. For anything with a long confidentiality lifetime — health records, financial data, state secrets, long-lived credentials — the migration deadline is not "when quantum computers arrive." It is now minus the data's required secrecy lifetime.

That is why standards bodies and regulators have moved. The U.S. NSA's CNSA 2.0 suite sets 2030 as the migration target for National Security Systems, and FIPS 140-3 validation (via the CMVP program) was updated alongside the new standards so vendors can certify PQC implementations. PQC is moving from "recommended" to "required" on a clock.

2. What NIST standardized (August 13, 2024)

After an eight-year, open competition, NIST published the first three finalized PQC standards. They divide cleanly by job — they are not competing alternatives for the same task.

A fourth standard, FN-DSA (FIPS 206), derived from FALCON, is still forthcoming. It produces smaller signatures at the cost of more delicate implementation and targets niche cases such as firmware signing. It is not yet part of .NET and is out of scope for everything in this guide that targets the in-box APIs.

Two mental models worth keeping:

• KEM, not "encryption." ML-KEM does not encrypt your message. It establishes a 32-byte shared secret between two parties; you then use that secret with a symmetric cipher (e.g. AES-256-GCM) to protect data. Every ML-KEM parameter set yields the same 32-byte secret — the parameter set changes key/ciphertext sizes and the security margin, not the secret length.
• Two signature families on purpose. ML-DSA is the workhorse. SLH-DSA exists so that if a weakness is ever found in lattice math, you have a signature scheme whose security depends only on hash functions — at a real cost in speed and signature size. Choosing between them is an engineering decision this guide will make explicit, not hide.

3. The .NET 10 reality — and its sharp edges

Starting with .NET 10 (November 2025), ML-KEM, ML-DSA, and SLH-DSA are available in-box in System.Security.Cryptography. No third-party NuGet package is required to call the algorithms; the runtime delegates to the operating system's cryptographic provider.

That is genuinely powerful — and it is also where the easy story ends. Adopting these APIs directly in a real codebase runs into four sharp edges:

1. Platform dependence. The algorithms only work where the OS provider supports them: Windows 11 24H2+ / Windows Server 2025 (via CNG) or Linux with OpenSSL 3.5+. On an unsupported platform the call throws PlatformNotSupportedException unless you check IsSupported first. macOS support is still pending.

2. Experimental surface. Much of this API is marked [Experimental("SYSLIB5006")], which the compiler reports as an error by default. The MLDsa and SlhDsa classes — and several MLKem methods — require you to explicitly acknowledge that the surface may shift in a future .NET release. Every team that calls these APIs directly inherits that churn.

3. No hybrid out of the box. The recommended transition pattern — running a classical exchange (e.g. X25519) and ML-KEM together so security holds if either is broken — is not specified by FIPS 203/204/205. It lives in NIST IR 8547 and IETF drafts. And .NET 10 has no first-class X25519 type (one arrives in .NET 11). Hybrid is something you assemble, not something you call.

4. Easy to misuse. The BCL will happily let you pick a weak parameter set by accident, skip the IsSupported check and crash in production, compare secrets with a non-constant-time == (a timing side-channel), or leave key material lingering in memory. None of that is prevented by the types themselves — only by discipline.

4. What QuantumReady 365 adds

.NET 10 gives you the algorithms. QuantumReady 365's job is everything around them that turns raw primitives into safe, governable adoption:

• Safe-by-default usage. The patterns in this guide make the secure path the easy path: recommended parameter sets (ML-KEM-768, ML-DSA-65) as the default, a mandatory capability check before any operation, constant-time secret comparison, and zeroization of key material after use.
• Crypto-agility envelope. [library] A self-describing, versioned wrapper so a stored ciphertext or signature carries the identity of the algorithm that produced it. Readers dispatch on that identity; writers always use the current policy default. Algorithm changes become configuration, not a code migration — and data encrypted today stays decryptable forever.
• Policy-as-code and posture. [library] A single declarative policy (allowed algorithms, minimum parameter sets, hybrid-required dates) enforced at build time and at runtime, with telemetry that turns "are we PQC-ready?" from a guess into a measured number.
• Migration tooling. [library] Build-time detection of quantum-vulnerable cryptography, a cryptographic bill of materials (CBOM), and dual-stack patterns that let you verify legacy and post-quantum signatures during a transition while only ever producing the new form.

The honest one-line framing: .NET already gives you PQC; QuantumReady 365 is about adopting it without becoming a cryptography team and without tracking the platform's experimental churn yourself.

5. A migration path, not a flag day

You do not flip an organization to PQC overnight. The widely-recommended sequence — reflected in NIST's migration guidance — is incremental:

1. Inventory. Find where quantum-vulnerable cryptography (RSA, ECDH, ECDSA) lives. You cannot migrate what you cannot see.
2. Prioritize key exchange. Key establishment is the harvest-now, decrypt-later front line — protect it first.
3. Go hybrid. Run classical + ML-KEM together during the transition, so a weakness in either one does not break you. (Note: transport-level hybrid depends on protocol and runtime support that is still maturing — this guide is explicit about what works today versus what is coming.)
4. Monitor. Measure the share of traffic and stored data that is post-quantum protected, and watch for downgrades.
5. Move to pure PQC once the ecosystem and your dependencies are ready.

6. Who this is for, and what's next

This guide is written for CISOs and security architects deciding what to adopt and when, and for senior .NET engineers implementing it. It assumes you know .NET well; it does not assume you are a cryptographer.

Everything here is grounded in the published standards (FIPS 203/204/205), the .NET 10 API as it actually ships, and NIST's migration guidance — with the gaps and uncertainties called out rather than smoothed over.

Next pages:

• Getting started — install check, platform probe, your first encapsulation in ten lines.
• ML-KEM — key establishment, parameter sets, sizes.
• ML-DSA — the default signature scheme.
• SLH-DSA — the conservative hash-based alternative, and exactly what it costs.
• Hybrid migration — combining classical and post-quantum safely.
• Serialization — exporting and importing keys across platforms.
• Platform support — the capability matrix and graceful degradation.
• ASP.NET Core integration — signing responses under dependency injection.