# .NET 9 and .NET 10: Post-Quantum Cryptography APIs

**Source**: https://quantumsequrity.com/blog/dotnet-pqc
**Category**: Implementations

---

[← Back to Blog](../../blog.html) Implementations

# .NET 9 and .NET 10: Post-Quantum Cryptography APIs

10 min read

The .NET runtime ships its own cryptographic implementation across Windows, Linux, and macOS. On Windows, .NET cryptography routes through CNG (Cryptography Next Generation) and BCrypt, the operating system's crypto stack. On Linux and macOS, .NET cryptography routes through OpenSSL by default. This three-platform reality shapes how Microsoft adopts post-quantum cryptography in .NET. New algorithms have to land in CNG, in OpenSSL, and in the cross-platform .NET surface that abstracts them.

Microsoft has made this work explicit. .NET 9 (released November 2024) and .NET 10 (released November 2025) are the release vehicles for the bulk of post-quantum cryptography support in the System.Security.Cryptography namespace. The pace is faster than most managed frameworks because Microsoft controls both the .NET runtime and (on Windows) the underlying SymCrypt implementation that CNG calls into.

This article explains what .NET supports today, what is coming next, and how to write .NET code that is ready for the migration.

## How .NET Cryptography Is Layered

.NET cryptography lives across a few layers:

- The public managed API in `System.Security.Cryptography.*` namespaces
- Internal interop code that calls platform-specific implementations
- On Windows: BCrypt and CNG, eventually backed by SymCrypt
- On Linux and macOS: OpenSSL, called via P/Invoke

Microsoft has been slowly converging these on a unified backend. The SymCrypt library, originally built for Windows, has been open-sourced and is now usable across platforms. Newer .NET releases use SymCrypt directly on Linux for some operations, reducing the dependency on OpenSSL for those cases.

For broader context, see [openssl PQC status 2026](../openssl-pqc-status-2026.html).

## Where .NET Stands on Post-Quantum

Microsoft's roadmap and shipped surface for 2026 looks like this.

| Algorithm | Status in .NET |
|-----------|----------------|
| ML-KEM (FIPS 203) | Shipped in .NET 10 (System.Security.Cryptography.MLKem) |
| ML-DSA (FIPS 204) | Shipped in .NET 10 (System.Security.Cryptography.MLDsa) |
| SLH-DSA (FIPS 205) | Shipped in .NET 10 (System.Security.Cryptography.SlhDsa) |
| X.509 PQ certificates | Initial parsing/validation support in .NET 10 |
| Hybrid TLS groups | Through SslStream as Windows/OpenSSL gain support |
| FN-DSA | Not landed |
| HQC | Not landed |
| LMS / HSS | Available; framework-level support stabilizing |

This is one of the most complete coverage maps among managed frameworks. .NET 10 in particular brings ML-KEM, ML-DSA, and SLH-DSA into the standard library with first-class APIs.

## Using ML-KEM in .NET

A typical .NET 10 code snippet for ML-KEM is roughly:

- `MLKem.GenerateKey(MLKemAlgorithm.MLKem768)` returns an MLKem instance with a private key
- `mlkem.Encapsulate(out var ciphertext, out var sharedSecret)` performs encapsulation against a peer's public key
- `mlkem.Decapsulate(ciphertext)` returns the shared secret on the receiver side
- `MLKem.ImportFromPkcs8` and `Export` support standard PKCS#8 encoding for storage

The API follows the same pattern as ECDsa, RSA, and other asymmetric algorithms in System.Security.Cryptography. This means existing .NET code that handles asymmetric keys can integrate ML-KEM with minimal restructuring.

For algorithm-level details, see [ML-KEM explained](../ml-kem-explained.html).

## Using ML-DSA in .NET

ML-DSA support follows the same pattern:

- `MLDsa.GenerateKey(MLDsaAlgorithm.MLDsa65)` for keypair generation
- `mlDsa.SignData(data)` for signing
- `mlDsa.VerifyData(data, signature)` for verification
- PKCS#8 import/export and X.509 certificate integration

The MLDsa class implements the same interfaces other signing algorithms implement, so existing code paths that use generic signing work with ML-DSA.

For comparison with hash-based signatures, see [ML-DSA vs SLH-DSA](../mldsa-vs-slhdsa.html).

## SLH-DSA in .NET

SLH-DSA support exists for use cases that need stateless hash-based signatures. The class structure mirrors MLDsa:

- `SlhDsa.GenerateKey(SlhDsaAlgorithm.SlhDsaShake128f)` and similar parameter sets
- Sign and verify methods following the standard pattern

The trade-offs of SLH-DSA (large signatures, conservative cryptographic assumptions) are documented; .NET does not editorialize about which algorithm to choose, but exposes them all.

## Hybrid TLS Through SslStream

.NET TLS goes through `System.Net.Security.SslStream`, which delegates to the platform TLS stack. On Windows, that is Schannel. On Linux, OpenSSL. On macOS, Network.framework or OpenSSL depending on configuration.

Hybrid PQ TLS groups (X25519MLKEM768) become available in .NET applications when the underlying platform TLS stack supports them. On Windows, this depends on Schannel updates that Microsoft has been adding through Windows 11 24H2 and Windows Server 2025. On Linux, it depends on the OpenSSL version that .NET is built against.

For applications that want explicit PQ TLS without waiting for platform stacks, options include:

- Using a third-party TLS library that .NET can call into
- Routing TLS through a sidecar (envoy, nginx) configured for PQC
- Using Microsoft's CryptoSwift project or QuicConnection where applicable

## SymCrypt and Microsoft's Crypto Strategy

SymCrypt is Microsoft's cryptographic library, originally Windows-internal. It now lives at github.com/microsoft/SymCrypt and is open source. SymCrypt is the implementation behind CNG/BCrypt on Windows and is being adopted as the cross-platform default for .NET.

For post-quantum, SymCrypt has implementations of ML-KEM, ML-DSA, and SLH-DSA. These implementations:

- Are written in C with platform-specific assembly optimizations
- Pass NIST CAVP test vectors
- Are designed for FIPS 140-3 validation

When .NET 10 ships ML-KEM via System.Security.Cryptography.MLKem, the implementation underneath is SymCrypt on Windows and (increasingly) on Linux. On Linux, OpenSSL fallback paths exist where SymCrypt is not yet integrated.

For more on Microsoft's wider strategy, see [Azure Key Vault post-quantum](../azure-key-vault-post-quantum.html).

## X.509 Certificate Support

.NET's X509Certificate2 class is being extended to handle ML-DSA certificates. The work involves:

- Recognizing ML-DSA SubjectPublicKeyInfo OIDs
- Validating certificate chains containing ML-DSA signatures
- Exporting ML-DSA private keys via PKCS#8 and certificates via X.509

Hybrid certificates carrying both classical and PQ signatures are awaiting IETF stabilization; .NET parses the standardized formats once they are settled.

## FIPS Validation

Microsoft maintains FIPS-validated cryptographic modules across multiple Windows releases. These validations cover the SymCrypt library and extend to the higher-level CNG and .NET layers when used in FIPS mode.

PQ algorithm support in FIPS-validated form follows CMVP timelines. Expect FIPS-validated ML-KEM and ML-DSA modules to ship through 2026 and 2027 as Microsoft completes formal validation cycles. Until then, the implementations are correct per FIPS specifications but not formally CMVP-validated.

For broader migration considerations, see [AWS KMS quantum migration](../aws-kms-quantum-migration.html).

## Performance in .NET

.NET cryptography performance is generally within 10-20 percent of equivalent native libraries because most hot paths are managed wrappers over native code. ML-KEM-768 keypair generation and encapsulation in .NET 10 take roughly the same time as in BoringSSL or OpenSSL. The managed/native boundary cost is small relative to the algorithm work.

For TLS termination, .NET's SslStream uses Schannel or OpenSSL directly; the .NET overhead is per-handshake and small.

## What's Not in .NET Yet

Items not yet shipped:

- FN-DSA / Falcon: Not in .NET roadmap due to floating-point concerns and adoption timing
- HQC: Not in .NET roadmap
- BIKE: Not in .NET roadmap
- Hybrid certificates: Awaiting IETF
- PQC support in older .NET versions (.NET 6, .NET 8): Not backported

For .NET Framework (the legacy Windows-only stack, still supported for line-of-business apps), PQC support comes through Windows updates to Schannel and CNG, not through .NET Framework runtime updates.

## Concrete .NET 10 Code Patterns

A simple ML-KEM-768 encapsulation/decapsulation flow in .NET 10 looks like:

- Create a receiver-side keypair with `MLKem.GenerateKey(MLKemAlgorithm.MLKem768)`
- Export the public key with the appropriate Export method to share with the sender
- On the sender side, import the public key into an MLKem instance
- Call `Encapsulate` to produce a ciphertext and a shared secret
- Send the ciphertext to the receiver
- The receiver calls `Decapsulate(ciphertext)` to recover the shared secret

Both sides now have the same shared secret, which can feed into HKDF or directly into AEAD as a key.

For ML-DSA signing:

- Create a signing keypair with `MLDsa.GenerateKey(MLDsaAlgorithm.MLDsa65)`
- Export the public key for verifiers
- Sign data with `mlDsa.SignData(data)` returning a byte array signature
- Verifiers call `mlDsa.VerifyData(data, signature)` and check the boolean result

These APIs follow the same pattern as ECDsa and RSA in .NET, so existing code familiarity carries over.

## Integration with ASP.NET Core

ASP.NET Core's TLS handling delegates to .NET's underlying SslStream. Hybrid PQ groups in TLS work through Kestrel (ASP.NET Core's HTTP server) when:

- The server is running on a platform that supports hybrid TLS in its TLS stack
- The client supports hybrid groups (modern browsers, modern .NET clients, Go clients, etc.)

For ASP.NET Core developers, PQC TLS adoption is largely a matter of platform updates rather than application code changes.

## Pause-and-Resume Patterns for PQC

A pattern that's worth noting: many .NET applications use `IDisposable` patterns for asymmetric keys. The PQC types (MLKem, MLDsa, SlhDsa) follow the same pattern, ensuring private key material is zeroized on Dispose. Long-lived keys can be held in `using` blocks or in static fields with manual disposal at application shutdown.

For library authors building PQC abstractions on top of .NET, expose `IDisposable` consistently and document zeroization behavior. Cryptographic hygiene is a major concern for FIPS-aligned deployments.

For broader migration patterns, see [Azure Key Vault post-quantum](../azure-key-vault-post-quantum.html).

## Best Practices for .NET Developers

For .NET applications adopting post-quantum cryptography:

1. Plan your .NET 10 upgrade. ML-KEM and ML-DSA are first-class in .NET 10; backporting to older versions requires third-party libraries.
2. Use the standard System.Security.Cryptography APIs. Avoid algorithm-specific dependencies that lock you into one library.
3. For storage at rest, hybrid encryption (ML-KEM + AES) using .NET 10's MLKem and AES classes is the standard pattern.
4. For TLS, plan for platform updates. SslStream inherits PQC from the underlying TLS stack.
5. For X.509, plan for certificate size growth. Server chains will get larger when ML-DSA certificates roll out.

For broader infrastructure integration, see [Google Cloud KMS PQC](google-cloud-kms-pqc.html).

## Code Migration Path from Classical to PQC

A typical .NET application migrating to post-quantum signatures has a few phases:

Phase 1, abstraction. Refactor signing code to use the AsymmetricAlgorithm or crypto.Signer interfaces. Avoid hard-coded RSA or ECDsa types in business logic.

Phase 2, hybrid signing. Sign with both classical and PQ algorithms during the transition. Verify with classical first; once PQ verification is universal, drop classical.

Phase 3, full PQ. Use only ML-DSA-65 (or larger) for new signatures. Maintain classical verification for old signatures during a grace period.

This phased approach works for X.509 certificate signing, code signing, document signing, and JWT-style token signing. The pattern is well-understood in .NET's cryptographic agility playbook.

## .NET MAUI and Mobile Apps

.NET MAUI applications run on Android, iOS, macOS, and Windows. For mobile platforms, the cryptographic stack is platform-provided. Android uses Conscrypt (BoringSSL-based); iOS uses Network.framework and CommonCrypto. PQC support arrives through these platform stacks rather than through .NET runtime updates.

.NET MAUI applications that need direct PQC primitives can use System.Security.Cryptography in .NET 10 for cross-platform consistency. The MLKem, MLDsa, and SlhDsa classes work identically across MAUI's target platforms (subject to platform-specific cryptographic provider availability).

For broader mobile context, see [Mbed TLS PQC status](mbedtls-pqc-status.html).

## Frequently Asked Questions

### Can I use ML-KEM in .NET 8?

.NET 8 does not have native ML-KEM. You can use third-party libraries like BouncyCastle's .NET port or call into native libraries via P/Invoke. Native support arrives in .NET 10.

### Is .NET's MLKem class FIPS validated?

The implementations follow FIPS 203 and pass NIST test vectors. Formal CMVP validation of .NET cryptographic modules including PQC is ongoing through 2026.

### Does .NET support hybrid TLS groups today?

Through SslStream's underlying platform stack. Windows (Schannel) and Linux (OpenSSL) updates progressively add hybrid TLS group support, and .NET inherits it.

### Can I sign X.509 certificates with ML-DSA in .NET 10?

Yes. The X509Certificate2 class and the certificate generation utilities in .NET 10 support ML-DSA signing and verification.

### Where can I read the .NET source?

The repository is github.com/dotnet/runtime. The cryptography code lives in `src/libraries/System.Security.Cryptography`. SymCrypt is at github.com/microsoft/SymCrypt.

### Are there .NET API stability promises for PQC types?

.NET's standard library promises API stability across major versions for types in System.Security.Cryptography. Once MLKem, MLDsa, and SlhDsa ship in .NET 10 as stable APIs, they remain available with backward compatibility in .NET 11, 12, and beyond.

### Can I use PQC in Xamarin or MAUI applications?

MAUI applications running on .NET 10 inherit the System.Security.Cryptography surface including PQC types. Xamarin (the predecessor to MAUI) does not get backported PQC support. Migration to MAUI is the path forward for cross-platform mobile .NET applications that need PQC.

### Does ASP.NET Core support hybrid TLS for incoming connections?

Yes, when running on a platform with hybrid TLS support (Windows 11 24H2+, Windows Server 2025+, recent Linux distributions with updated OpenSSL). The Kestrel server uses the platform TLS stack and benefits from PQC support automatically.

## Sources

1. .NET runtime repository, github.com/dotnet/runtime
2. .NET 9 and .NET 10 release notes, learn.microsoft.com/dotnet
3. NIST FIPS 203, 204, 205 (post-quantum standards), 2024
4. SymCrypt repository, github.com/microsoft/SymCrypt
5. Microsoft Security Blog and Microsoft Research, learn.microsoft.com
6. CMVP (Cryptographic Module Validation Program), csrc.nist.gov

## Related Articles

- [What is post-quantum cryptography](../what-is-post-quantum-cryptography.html)
- [ML-KEM explained](../ml-kem-explained.html)
- [ML-DSA vs SLH-DSA](../mldsa-vs-slhdsa.html)
- [Azure Key Vault post-quantum](../azure-key-vault-post-quantum.html)
- [Hybrid encryption](../hybrid-encryption.html)

---

### Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

[Try QNSQY](../../pricing.html)