rss.livelink.threads-in-node

Threat Modeling and Post Quantum Cryptography

MichaelHoward-MSFT — Thu, 13 Aug 2026 20:02:59 GMT

By Michael Howard (Azure Security PQC) and Simone Curzi (Azure Data Platform Security)

The transition to post-quantum cryptography (PQC) introduces a new challenge: organizations must first understand where cryptography is used before they can assess its suitability in a post-quantum world. Cryptographic functionality may be implemented through operating system libraries such as CNG, SymCrypt, or OpenSSL, third-party dependencies, frameworks, or application code. As quantum-resistant algorithms become necessary, organizations need to identify these usages, determine the algorithms involved, and plan migrations where required.

Building a complete cryptographic inventory is difficult. Automated discovery and code scanning can identify many dependencies, but they often miss architectural assumptions, platform-provided capabilities, indirect dependencies, and design-level controls. This article shows how threat modeling can uncover those gaps and contribute findings to a PQC migration inventory.

What is Threat Modeling?

This article assumes a basic familiarity with threat modeling. Readers who are new to the topic should refer to the Threat Modeling Manifesto, the works of Adam Shostack, Brook S. E. Schoenfield, Izar Tarandach, and Matthew J. Coles, (and dare we say, the authors of this post!), as well as the extensive online training and documentation available. Our focus here is on a specific application of threat modeling: helping organizations build a more complete cryptographic inventory to support PQC migration.

Pulling out the Crypto

At first glance, threat modeling and cryptography seem to operate at different levels. Threat modeling focuses on system design, while cryptography is often viewed as an implementation detail. As a result, cryptographic controls typically appear in a threat model as mitigations: data is encrypted in transit, encrypted at rest, or signed to provide integrity and authenticity. The specific implementation details are often omitted.

For example, threat models rarely record which protocol versions and algorithms are used, whether they originate from operating system libraries such as CNG, SymCrypt, or OpenSSL, from third-party dependencies, or from custom code. Details such as cryptographic key sizes, cipher suites, block modes, or signature algorithms are also frequently absent.

At the same time, threat modeling often captures information that is highly valuable for PQC migration.

A good threat modeler asks where cryptography is used, which assets and trust boundaries it protects, how keys are managed, and which components provide the capability. Each answer should be followed by questions such as: How is it implemented? Which operating-system, library, cloud, hardware, or custom-code dependency provides it? What assumptions and external dependencies does the design rely on?

These questions often reveal information that would otherwise remain undocumented, helping organizations build a more complete understanding of their cryptographic dependencies and better prepare for PQC migration.

By asking a small number of additional, low-level questions during the threat-modeling process, organizations can close much of the gap between a threat model and a cryptographic inventory. Here are some examples:

Which cryptographic algorithms are used?
What key sizes or security parameters are configured?
Which protocols, protocol versions and cipher suites are in use?
Are cryptographic functions provided by the operating system, third-party libraries, cloud services, or custom code?
Are RSA or elliptic-curve algorithms used for key exchange, certificates, or digital signatures?
Can the cryptographic implementation be upgraded or replaced without significant architectural changes?
Are there external dependencies whose migration to PQC is controlled by another party?
How long must the protected data remain confidential or trustworthy, and is it exposed to harvest-now-decrypt-later risk?
Where are keys generated, provisioned, stored, distributed, backed up, recovered, rotated, revoked, and destroyed?
Which identities, authentication flows, authorization decisions, or trust anchors depend on public-key cryptography?
Are certificates, certificate chains, PKI services, code-signing systems, tokens, or firmware-update mechanisms quantum-vulnerable?
Are secrets or keys protected by TPMs, HSMs, secure enclaves, smart cards, or other hardware, and can that hardware support PQC?
Note: PQC migrations are often constrained by hardware platforms whose firmware, key formats, or cryptographic APIs may not yet support post-quantum algorithms.
Does the system use cryptography in file formats, databases, backups, logs, messages, APIs, queues, or inter-service protocols?
Are cryptographic algorithms, parameters, or protocol versions hard-coded, negotiated, configured, or controlled by policy?
Can algorithms and key formats be changed independently, or are they tightly coupled to schemas, APIs, storage formats, or hardware?
Could an attacker force use of a weaker algorithm, legacy protocol, non-PQC path, or insecure compatibility mode?
Who owns each cryptographic dependency?

The questions we have listed here are far from being exhaustive, but they represent a good starting point.

But is it PQC?

Ok, so now we have our list of cryptographic algorithms or protocols used in your solution, now you must look at each algorithm to determine if it is quantum resistant, and if not, determine the replacement.

Here is a quick cheat sheet summarizing Microsoft’s most recent migration recommendations.

Current Scenario	Current Algorithm/Protocol	PQ Algorithm/Protocol
Network traffic	TLS 1.2	TLS 1.3 (required foundation)
Network traffic	TLS 1.3 with classical key agreement (Elliptic Curve)	TLS 1.3 hybrid (Elliptic Curve + ML-KEM)
Key establishment	RSA/ECDH/DH	ML-KEM
Data at Rest Bulk Encryption	Anything that is not AES256	AES256
Asymmetric Key Wrapping	RSA/ECC	Use an ML-KEM-based key establishment mechanism or wrap with a symmetric key already established through a PQ-safe mechanism.
Symmetric Key Wrapping	AES128	AES256
Hashing	<= SHA256	SHA384
Digital Signature	RSA/ECC	ML-DSA or SLH-DSA or composite signatures

A note on TLS 1.3 – you must use TLS 1.3 to support post-quantum hybrid key establishment. Prior versions of TLS do not support PQC.

The biggest band-for-the-buck PQC improvement is to move TLS 1.2 to TLS 1.3 and support hybrid groups; you can learn more at a previous post here.

We must also add a note related to SHA256: this hash algorithm is still a suitable option at the time of writing and is still used by some PQC algorithms like SLH‑DSA. The recommendation to migrate to SHA384 is aligned with Microsoft’s most recent internal guidance for PQC and is based on the need to adopt stronger algorithms offering superior security for longer.

Short, Worked Example

Some people are more visual, so let’s look at a small section of a worked example.

The following diagram represents a system that accepts job requests and allows users to retrieve their status. The front-end validates each request and submits a job definition to an enterprise queue shared with other applications. The back-end retrieves and executes the job, updating a status repository that the front-end queries on behalf of the user. The job-execution logic is omitted because it is not relevant to this example.

A threat modeler should begin by clarifying the assets and required security properties. The job definition may require confidentiality, integrity, origin authentication, authorization, and protection against replay.

The status information may have similar requirements. Because the queue is shared, the threat modeler should also understand the isolation and authorization guarantees provided by the queue rather than assuming either that they are sufficient or that they are inadequate.

For the enqueue and dequeue flows, initial questions might include:

Which identities do the front-end and back-end use?
Which identities are authorized to enqueue, dequeue, or inspect messages?
What isolation guarantees does the enterprise queue provide?
What protocol and minimum version protect each connection?
Which cryptographic key-establishment and authentication algorithms are negotiated?
How does each client perform server certificate validation, including server identity, key usage, validity dates, issuer, certificate signature etc?
Which public-key and signature algorithms are used throughout the certificate chain?
Who owns the TLS endpoint, certificates, issuing PKI, and migration of those dependencies?

For the worked example, the threat model must record both the minimum protocol version and the negotiated key-establishment group.

A TLS 1.3 connection is post-quantum resilient only when it uses a supported PQ or hybrid group, such as x25519_MLKEM768; the corresponding cipher-suite configuration, such as TLS_AES_256_GCM_SHA384, should also be captured.

The threat modeler should then examine protection of the queued job definition. Infrastructure-level cryptography may protect the queue’s storage without necessarily providing application-specific confidentiality, integrity, origin authentication, or isolation from other authorized queue clients. Whether additional application-level protection is needed depends on the security requirements and the guarantees provided by the queue.

If the back end must verify job origin independently of the queue, the design needs an appropriate authenticity mechanism. This might be a digital signature or, where the trust model permits shared secrets, a message authentication code. If confidentiality from other queue clients or operators is required, application-level cryptography may also be necessary.

Once a cryptographic control is identified in the worked example, the threat modeler should record the details that are specific to that control: the algorithm and parameters, the exact content protected, the implementation provider, the message format, replay handling, separation of key purposes, algorithm and key-version metadata, quantum-vulnerability status, and required confidentiality or trust lifetime.

The resulting information should be added to the cryptographic inventory together with the protected asset, security objective, implementation provider, dependency owner, quantum-vulnerability status, and migration constraints. Contradictory or incomplete answers should be investigated because they may reveal either a security weakness or a dependency that has not yet been assigned a migration owner.

You might use a table like the following one to track your findings.

Asset	Job Definition
Objective	Integrity / Origin Authentication
Algorithm	ECDSA P-256
Implementation	OpenSSL
Owner	Team X
PQ Status	Vulnerable
Migration Target	ML-DSA

A Note on PaaS

If your solution uses PaaS components like Azure SQL DB, Azure Front Door, Azure Storage and you are relying on their security features, then the implementation and operation of PQC-capable cryptography is generally the responsibility of the provider under the Shared Responsibility Model, although customers remain responsible for understanding their dependencies and adopting platform capabilities where required. Your own client-side platforms should embrace crypto-agility so they can move to new crypto algorithms as needed in case algorithms show weakness over time. You can read more about crypto-agility here.

Summary

PQC readiness begins with knowing where cryptography is used, what it protects, who owns it, and which dependencies constrain its replacement with PQC algorithms. Threat modeling complements automated discovery and code analysis by exposing design-level controls, trust relationships, and assumptions that those techniques can miss. Feeding these findings into a maintained cryptographic inventory helps organizations identify migration risks earlier and adapt their systems with greater confidence.

Thanks

We’d like to thank the following for their review and comments on this post:

- Jack Richins – Microsoft PQC team

Azure Key Vault Premium and AES-KW Post Quantum Resistant Key Wrapping in Public Preview

MichaelHoward-MSFT — Wed, 05 Aug 2026 14:41:52 GMT

Introduction

Post-quantum cryptography, like any cryptographic system, depends on strong foundational components.

Key management is one of those critical foundations.

Azure Key Vault is Azure’s most popular key-management service, and Azure Key Vault Premium now supports quantum-resistant AES key wrapping (AES-KW) in Public Preview.

AES-KW lets services replace quantum-vulnerable RSA key wrapping with a quantum-resistant alternative.

For most readers, that is the key takeaway; you can read the announcement update here.

For people who want to learn more, keep going!

Key-wrapping

Ok, let’s back up a little now that we have the core message out of the way!

Azure Key Vault offers the following services:

Key/Secret/Certificate management
Encryption and decryption
Signing and signature verification
Key-wrapping and unwrapping

For the purposes of this post, we will focus only on the last bullet – Key-wrapping.

Key-wrapping is simply the process of protecting one cryptographic key by encrypting it with another key. The key doing the protecting is commonly called a key-encryption key (KEK), while the protected result is called a wrapped key, and is often used as a data-encryption-key (DEK) – it is that final DEK that performs the bulk data encryption.

Wrapping is encryption, but the term more precisely describes its purpose: protecting one key with another.

A good example of key wrapping is Transparent Data Encryption (TDE) in Azure SQL DB and SQL Server. TDE uses a KEK to protect (wrap) a DEK that is used to perform the low-level, high-speed encryption and decryption of data on disk, as noted in the image below.

Historically, and commonly, the KEK is an RSA key, and RSA is used to wrap and unwrap the DEK, which is usually AES today. The problem lies with the RSA KEK; RSA breaks in a post-quantum world because of Shor’s Algorithm, so RSA must be replaced by a quantum-resistant algorithm, and AES Key Wrap (AES-KW) is a solution.

Note, AES-KW is nothing more than a standardized way to use AES to wrap keys, it is defined in RFC 3394.

AES-KW can support quantum-resistant key management when used with appropriately sized AES keys and sound operational controls.

For this scenario, use AES-256 to provide an appropriate post-quantum security margin; AES-128 is not recommended.

Sidebar: Shor’s algorithm breaks today’s public-key cryptography (RSA, Elliptic Curve, Diffie-Hellman); Grover’s algorithm weakens symmetric cryptography (AES, SHA-2).

Applications use key-wrapping when they need to store or transport key material without exposing the plaintext key. During wrapping, the KEK transforms the key into protected key material. During unwrapping, the same KEK reverses that operation and returns the original key.

The change is to switch out the KEK from RSA to use AES-KW. The existing DEK can remain unchanged, so the encrypted data - such as TDE-protected data - does not need to be decrypted and re-encrypted. Only the DEK is unwrapped with the RSA KEK and then rewrapped with AES-KW.

You may rotate the DEK separately if desired, but this migration does not require it.

The process looks like this:

I have been a little more precise (to keep the cryptographers happy) in the diagram! When wrapping keys with RSA (or any other wrapping mechanism), you use a padding and encoding scheme; in this case we use RSA Optimal Asymmetric Encryption Padding (OAEP) which adds randomness to the plaintext before encryption, ensuring that the same plaintext produces different ciphertexts each time; the ‘256’ part in OAEP-256 is a SHA256 hash used to provide randomness.

Let’s get back on track.

Azure Key Vault and AES-KW

AKV now supports AES key wrapping (AES-KW) in Public Preview, providing a quantum-resistant alternative to the RSA-based key wrapping previously available. RSA could be broken by a Cryptographically Relevant Quantum Computer (CRQC).

This is a big deal, because AKV is used by just about every application running on Azure to protect secrets and keys, and will allow services to become more post-Quantum resilient when protecting data at rest.

For Post-Quantum protection of data on the wire, services must use TLS 1.3 with hybrid groups, see my previous post on this topic.

It’s not a good blog post without some code!

So, let’s look at some simple code that uses AKV and AES-KW to protect an AES-256 key.

async Task<WrapResult> GetWrappedKey() { AzureKeyVaultSettings settings = await LoadAzureKeyVaultSettingsAsync(); CryptoPolicy policy = CryptoPolicy.ResolveForEncryption(settings.KeyWrapAlgorithm); var credential = new DefaultAzureCredential(); var keyClient = new KeyClient(settings.Uri, credential); KeyVaultKey wrappingKey = await keyClient.GetKeyAsync(settings.WrappingKeyName); var cryptoClient = new CryptographyClient(wrappingKey.Id, credential); byte[] aesKey = RandomNumberGenerator.GetBytes(settings.KeySizeBytes); try { return await cryptoClient.WrapKeyAsync(policy.KeyWrapAlgorithm, aesKey); } finally { CryptographicOperations.ZeroMemory(aesKey); } }

This code requires a little explaining because there is no reference to any crypto settings! This is to support crypto-agility. All the config is resolved by LoadAzureKeyVaultSettingsAsync() and ResolveForEncryption() and the settings are pulled from an appsettings,json file:

{ "AzureKeyVault": { "Uri": "https://akv-<snip>-tst.vault.azure.net/", "WrappingKeyName": "key-wrapping-key", "KeySizeBytes": 32, "KeyWrapAlgorithm": "A256KW" } }

These settings can change if needed depending on your DEK key size and key wrap algorithm.

DefaultAzureCredential(), KeyClient(), GetKeyAsync() and CryptographyClient() are the standard ceremony to set up a connection to AKV to use keys. RandomNumberGenerator.GetBytes() creates a new random 32-byte AES key and WrapKeyAsync() wraps the newly minted AES key in AKV.

Note Be careful with DefaultAzureCredential() as it runs through multiple ways to gather your Azure logon credentials and this can be time consuming!

The function returns a wrapped AES key wrapped with AES256KW; you can now save that key safely with your application!

To unwrap the AES key, just pass the wrapped key to:

UnwrapResult unwrapResult = await cryptoClient.UnwrapKeyAsync( policy.KeyWrapAlgorithm, wrapResult.EncryptedKey);

Now you have the plaintext AES key, the DEK, and you can encrypt and decrypt your data.

The flow looks a little like this:

A note on RBAC

Like other Azure services, Azure Key Vault supports role-based access control (RBAC) for both control-plane and data-plane operations. Although key wrapping is conceptually similar to encrypting a DEK, the REST API exposes wrapKey and encrypt as separate operations. This distinction allows permissions to be granted independently - for example, an identity can be authorized to wrap keys without receiving broader cryptographic permissions.

Use least-privilege access policies and audit them regularly.

What is oct-HSM?

When working with AES keys in AKV and Managed HSM you will see the term oct-HSM. What is it?

If you dump key metadata using code like this:

using Azure.Identity; using Azure.Security.KeyVault.Keys; var keyVaultUrl = "https://akv-<snip>-tst.vault.azure.net/"; var client = new KeyClient(new Uri(keyVaultUrl), new DefaultAzureCredential()); await foreach (var keyProperties in client.GetPropertiesOfKeysAsync()) { var key = (await client.GetKeyAsync(keyProperties.Name)).Value; Console.WriteLine($"Name: {key.Name}"); Console.WriteLine($"Type: {key.KeyType}"); }

you will see output like this:

Name: key-wrapping-key Type: oct-HSM

And there it is – ‘oct-HSM’, it means:

oct for Octet string, or a series of 8-bit values.
HSM because it's an HSM key.

It is the object data type, oct-HSM simply means it's a symmetric key of a length (in bits) divisible by 8 because it is byte aligned. The term ‘octet’ is used extensively in standards documentation such as Distinguished Encoding Rules (DER) which is used by X.509 certificates.

Azure Portal UI

The UI updates that reflect AES-KW are in flight and you might not see the updates yet! Programmatic, JSON, ARM and Bicep config all work, however.

What about Managed HSM?

Azure Key Vault Managed HSM is Azure Key Vault’s significantly bigger brother and has supported AES key wrapping since inception.

The main difference between AKV and Managed HSM is tenancy and scope: AKV is a multitenant service that manages keys, secrets, and certificates, while Managed HSM provides a dedicated single-tenant HSM for cryptographic keys only, with stronger isolation and customer-controlled administration for high-value or compliance-sensitive workloads.

Client code to wrap and unwrap keys is the same across both services; you only need to update the URI to point to your AKV or Managed HSM instance.

Pieter Vanhove wrote about using Managed HSM for TDE key-wrapping in this blog post Transparent data encryption in Azure SQL Database now supports AES keys (Public Preview) | Microsoft Community Hub and he will need to update it to include AKV now!

But wait, there is more!

AKV now supports AES encryption and decryption in addition to AES key wrapping, capabilities that have long been available in Managed HSM. However, neither AKV nor Managed HSM is intended for encrypting or decrypting large volumes of data; use these operations only for small payloads. I may explore AES encryption and decryption in a future post-let me know if that would be useful.

Thanks

A big ‘Thank you’ to the following for their review, suggestions and comments.

Jack Richins – Azure Security
Pieter Vanhove – Azure Data
Dan Bullock – Azure Data
Raul Garcia – Microsoft Crypto Board

ASP.NET, Kestrel and Schannel GA with TLS 1.3 Post-Quantum Cryptography

MichaelHoward-MSFT — Tue, 14 Jul 2026 19:06:42 GMT

IMPORTANT

Before I get to the body of this post, there is an important update you must be aware of:

My colleague, Aabha Thipsay from Windows Security has published an update to her June post on PQC in Windows. Hybrid TLS using ML-KEM key exchange groups is now generally available (GA) in Windows 11 and Windows Server 2025. This allows TLS connections to combine classical and post-quantum key establishment mechanisms, providing cryptographic agility and protection against future quantum-enabled attacks.

Read more, including the update details here.

Introduction

All organizations must move to TLS 1.3 to support post-quantum cryptography (PQC) for network data.

Prior versions of TLS, such as 1.0, 1.1 and 1.2 DO NOT support and WILL NOT support PQC. TLS 1.0 and 1.1 are already deprecated, and 1.2 will eventually go the same fate, too.

Also note that TLS 1.0 and 1.1 are officially deprecated by the IETF via RFC 8996.

The security technology most used to protect (encryption and integrity checks) data on the wire is TLS, which is so pervasive that almost nothing else is used to authenticate servers (and optionally authenticate clients) and then provide encryption and integrity protection for network traffic.

To be honest, in a distant 2^nd lies SSH.

The beauty of TLS is that it supports crypto-agility (see my previous post here) by design by allowing a server and client to negotiate to a mutually agreed-upon ciphersuite.

Note that this blog post focuses on Windows, I will write a follow-up post about Linux, OpenSSL, and nginx.

If you are happy with that level of detail, and you don’t need to understand how TLS supports PQC and crypto-agility, then jump straight to the section below titled ‘ASP.NET and Kestrel’ where I explain using hybrid TLS 1.3 with ASP.NET and the Kestrel web server.

From here on, all references to TLS are TLS 1.3 and later.

TLS 1.3 and Crypto-Agility

The diagram and text below explain how TLS negotiates to a mutually agreed-upon ciphersuite and hence supports crypto-agility.

The client (such as a web browser) sends a list of its supported ciphersuites in a ClientHello message to the server which is the first message sent by the client during a TLS negotiation.

The server selects which ciphersuite to use and that is sent back in the ServerHello message.

Here both the client and server list contain TLS_AES_256_GCM_SHA384, and since it sits at the top of the server's list, the server selects it even though TLS_AES_128_GCM_SHA256 was first in the client list.

Note that RFC 8446 “The Transport Layer Security (TLS) Protocol Version 1.3” §4.1.1 leaves the selection algorithm to the server. The client's list order is a hint, but most production servers ignore it and walk their own preference list top-down - picking the first entry that also appears in the client's offering.

If there were zero overlap between the client and server ciphersuite lists, the server would usually send a handshake_failure alert (40) and tear down the connection.

Important sidenote about TLS 1.3 ciphersuite strings

TLS 1.3 cleaned up the ciphersuite strings substantially from prior versions. In TLS 1.2 and earlier, a single ciphersuite name bundled together multiple concerns: the key exchange algorithm, the authentication algorithm, the bulk encryption algorithm, and the hash or message authentication function. That made the names more difficult to reason about and more rigid.

TLS 1.3 simplified this model by reducing the ciphersuite to just the symmetric encryption and hash components, such as TLS_AES_256_GCM_SHA384.

TLS 1.3, ciphersuites, groups and PQC

TLS key exchange, establishment or agreement is negotiated separately through the supported_groups and key_share TLS extensions, and authentication is handled through the signature_algorithms TLS extension.

This separation is important because it makes the protocol easier to evolve, new key exchange mechanisms can be introduced, including post-quantum or hybrid key establishment methods, without having to redefine the entire ciphersuite structure.

Important

From a PQC perspective, the ciphersuites used by TLS 1.3 are largely unchanged, it's the supported groups we care about most.

In TLS 1.3, the ClientHello message uses supported_groups, key_share and signature_algorithms extensions to add PQC algorithms. I want to keep this simplified so the post doesn’t become a treatise on TLS 1.3, so I will elide many details!

When using hybrid (ie; PQC + classic crypto) the supported_groups and key_share data structures might look something like this:

The supported_groups order is a preference, highest first, and most commonly today, hybrids (PQC + classical) are at the top, then classic groups below as a fallback for servers that don't yet speak PQC. As an optimization, the client also sends a key_share for its top choice in the same ClientHello — the actual ephemeral public keys — so that if the server accepts that group, the handshake completes in one round trip rather than triggering a HelloRetryRequest and a second one.

In this example, the client is saying "I'd really like to use hybrid crypto, but I'll downgrade to plain X25519 or secp256r1 if you can't." And it doesn't just say it - and as an optimization, the client sends a key_share, pre-generating and attaching the ephemeral public keys for its top pick (X25519MLKEM768) so the handshake can finish in one round trip if the server agrees. The fallback groups are listed but not pre-computed, so falling back to one of them costs an extra round trip.

The key_share sizes in the diagram show the hybrid is just two key exchanges glued together: the client's 1216-byte share is a 32-byte X25519 public key plus a 1184-byte ML-KEM-768 key. The server's reply is a slightly different size because the ML-KEM half returns a ciphertext rather than a matching public key.

It is up to the server to determine what algorithms to use, however. We know what the client can support, because the client told us in the ClientHello message.

As a side note, the word "group" isn't arbitrary - it comes from the underlying algebra (elliptic-curve groups, finite-field multiplicative groups). It's mathematically precise; but it's just opaque to anyone who isn't thinking about group theory! However, ML-KEM isn't built on a group at all - its hardness comes, in part, from lattices, but let’s not go down that rabbit hole!

Now let’s switch to why we are here – ASP.NET, Kestrel and PQC.

ASP.NET and Kestrel

ASP.NET is Microsoft's open-source web framework for building web apps, APIs, and real-time services on .NET.

Kestrel is the cross-platform, high-performance HTTP[S] server built into .NET that handles raw TCP connections and HTTP protocol processing.

ASP.NET and Kestrel relate in that Kestrel is the default in-process web server that listens for and handles HTTP requests for an ASP.NET.

Below is some minimal C# Kestrel code that listens for HTTPS connections:

using System.Net; using Microsoft.AspNetCore.Connections.Features; var builder = WebApplication.CreateBuilder(args); builder.WebHost.ConfigureKestrel(o => o.ListenAnyIP(8443, l => l.UseHttps())); var app = builder.Build(); app.MapGet("/", (HttpContext ctx) => { var tls = ctx.Features.Get<ITlsHandshakeFeature>(); return Results.Json(new { Timestamp = DateTime.UtcNow, Protocol = tls?.Protocol.ToString() ?? "Unknown", CipherSuite = tls?.NegotiatedCipherSuite?.ToString() ?? "Unknown" }); }); app.Run();

This code is correctly written because it makes no assertions about TLS protocol version, nor ciphersuites, nor groups. Rather, these settings are made outside the application is some form of configuration.

The anti-pattern to the code above is this:

This code is NOT crypto-agile and should be considered an anti-pattern because it embeds cryptographic details like TLS protocol versions and ciphersuites in the code, and if any of these must change in the future then the code needs updating, too. This code will not necessarily negotiate to a PQC connection.

Note: CipherSuitesPolicy is Linux-only. On Windows/macOS the constructor throws PlatformNotSupportedException - ciphersuites on those platforms are governed by the OS (SChannel on Windows). The TLS protocol restriction works cross-platform, however.

And that is a nice segue to SChannel!

Schannel Configuration on Windows

Windows uses a component named schannel.dll to perform TLS communication. Today, July 14th, 2026, schannel is GA with PQC support, see the note about Aabha's update on the topic.

Even though this version supports TLS hybrid groups today, the PQC groups are not enabled by default, so you must set them up.

Setting up Schannel

There are three main ways to configure schannel:

Modify the Registry directly
Use Group Policy
Use PowerShell cmdlets

We will focus on (3), but ultimately, all methods directly or indirectly update the Registry.

Use the following site as a reference for the various PowerShell TLS cmdlets.

Get-TlsCipherSuite dumps all the supported ciphersuites irrespective of TLS protocol version. You can disable a ciphersuite using Disable-TlsCipherSuite.

What we’re interested in is setting up a group for PQC, and for that we use:

Enable-TlsEccCurve -Name "X25519_MLKEM768" -Position 0

The -position option is important as it places the hybrid group at the top of the preferred group list. If you do not do this, you might not negotiate to the hybrid PQC group.

You can use Get-TlsEccCurve to verify the setting, as noted below:

x25519_mlkem768 curve25519 NistP256 NistP384

Now that we have set the group, we can run the server code and connect with a browser such as Edge or Chrome. When you do this, you can see the connection details under Developer Tools à Security.

This shows the protocol version (TLS 1.3), the group (X25519MLKEM768) and the ciphersuite (AES_256_GCM).

Congratulations, you just connected to Kestrel or ASP.NET using a quantum resilient group! You are officially living in the future!

You can also use OpenSSL as a client to determine the group:

openssl s_client -connect 127.0.0.1:8443 -tls1_3 -brief Connecting to 127.0.0.1 depth=0 CN=localhost CONNECTION ESTABLISHED Protocol version: TLSv1.3 Ciphersuite: TLS_AES_256_GCM_SHA384 Peer certificate: CN=localhost Hash used: SHA256 Signature type: rsa_pss_rsae_sha256 Negotiated TLS1.3 group: X25519MLKEM768

A note about server authentication

It’s important I bring this up. The key negotiation process used post-quantum cryptography, but the server authentication used a classic certificate. That's by design for now: the immediate goal is encrypting data on the wire to defend against harvest-now, decrypt-later attacks, where an adversary records traffic today hoping to decrypt it once quantum computers mature. Authentication is a different threat model - an attacker would need a quantum computer during the live session to forge the certificate, not years later. So, protecting confidentiality first, with PQC key exchange, addresses the more urgent risk while the ecosystem catches up on PQC certificates and CA migration.

Wrap-up

Post-quantum TLS 1.3 is no longer theoretical — you can experiment with it on Windows today. By moving your services to TLS 1.3, avoiding hard-coded cryptographic choices in application code, and letting SChannel negotiate hybrid groups such as X25519MLKEM768, you can start validating how ASP.NET and Kestrel behave in a quantum-resilient configuration. If you build or operate services on Windows, now is the time to get the latest Windows Insider or preview build, enable the hybrid TLS group, run your Kestrel workloads, and inspect the negotiated connection. The best way to prepare for post-quantum cryptography is to start testing it now.

Thanks

As usual, a big thanks to all the people who reviewed the drafts of this post and provided valuable input and feedback.

Aabha Thipsay - Windows Security

Jessica Krynitsky - Windows Security

Andrei Popov - Window Security

Barry Dorrans - .NET Security

Jeremy Barton - .NET Security

Raul Garcia – Microsoft Crypto Board

Post-Quantum Cryptography and Crypto-Agility

MichaelHoward-MSFT — Thu, 06 Aug 2026 01:04:18 GMT

Introduction

This post focuses on a topic critical to help move to post-quantum cryptographic (PQC) algorithms and that topic is crypto-agility for applications that use cryptography.

This post does not discuss the implications of quantum computers on cryptography; you can read that elsewhere such as:

What is Crypto-Agility?

As NIST explains, crypto-agility is about changing cryptographic algorithms without interrupting the flow of a running system, which is exactly why it is foundational to long-term resilience in the PQC era.

However, crypto-agility is not simply the ability to swap one algorithm for another; it is the engineering discipline of designing protocols, applications, services, and infrastructure so cryptographic mechanisms can be updated repeatedly, safely, and with minimal disruption. In practical terms, that means avoiding hard-coded algorithm choices, understanding where cryptography is used, and building abstraction, configuration, and testing into systems so transitions—such as the move to post-quantum cryptography—do not become expensive, brittle, one-time rewrites.

Note: This post assumes you know how to build a correct cryptographic system, if you do not, you should not, rather you should seek help from cryptographic professionals.

The Need for Crypto-Agility NOW

The industry has known for at least 15 years that crypto-agility is a solid engineering practice, but sadly, few products support it for their own crypto. The looming threat from PQC makes crypto-agility not just a good idea, but an important forcing function – everyone designing and developing applications must move to use crypto-agility to help migrate to PQC and beyond.

The main threat posed by quantum computers is the potential to break asymmetric algorithms like RSA, Elliptic Curve and Diffie-Hellman, these algorithms are used extensively to:

Wrap, exchange, or agree-upon symmetric encryption keys that are then used to bulk encrypt data
Sign data and code
Authenticate principals

We will focus primarily on the first bullet as this is an endemic problem today and it is the core of the Harvest Now, Decrypt Later (HNDL) threat.

What Makes This Post Different

There are many articles about the importance of crypto-agility, but few focus on HOW to achieve crypto-agility, and that is where this article is different, we will focus on real-world designs and coding mechanics.

Step 0 – Don’t Do Your Own Crypto Agility!

Think about the shared responsibility model, if you use Infrastructure as a Service (IaaS) you need to do more work, but you have more control.

If you use Platform as a Service (PaaS) then PaaS pushes more of the responsibility to the provider, rather than you.

The same applies to cryptography.

Where possible, you should offload tasks like signing and encryption to a service or product you trust has a PQC plan to do the crypto work for you. For example, rather than writing your own code to encrypt backups, use a backup service that performs that task (or has plans to do so) and allows you to control the key wrapping keys.

However, if you must use your own crypto, then read on!

Crypto-Agile Designs

Many applications that protect data with encryption do so without regard for the cryptography used. For example, plaintext is passed to encryption code and is then encrypted with a key, or a key derived from some key material, and then the code writes out the ciphertext.

Something like this:

using System.Security.Cryptography; using var aes = Aes.Create(); aes.Key = SHA256.HashData(Encoding.UTF8.GetBytes(args[1])); byte[] ciphertext = aes.EncryptEcb( await File.ReadAllBytesAsync(args[0]), PaddingMode.Zeros); await File.WriteAllBytesAsync(args[0] + ".enc", ciphertext);

This code is problematic on many fronts, including:

Encryption algorithm details are hard-coded in the core code path. This makes crypto agility impossible.
The crypto is weak:
- Using Electronic Code Book (ECB) block cipher mode
- No data authentication
- Not using an appropriate Key Derivation Function (KDF).
- You might also say there is no Initialization Vector (IV) but an IV is not used by ECB.
The ciphertext is just a blob of bytes, there is no metadata to indicate how this blob was created and what cryptographic parameters are used.

Hard-coded algorithm assumptions are a strong anti-pattern for crypto-agility and usually make safe migration to newer algorithms harder or more expensive.

To be crypto-agile, a system must support new ciphersuite metadata and store that metadata with the ciphertext; there are several ways to do this.

Crypto-agility in Microsoft Products

To get a better understanding of how to create crypto-agile solutions, let’s look at how Microsoft has addressed this in some products, notably:

Microsoft Office
SQL Server and Azure SQL DB
Azure Blob Storage

There is no single crypto-agility pattern that fits every application’s needs for agility, but these should give you some ideas.

Microsoft Office

In its Open Office XML (OOXML) file structure, Microsoft Office embeds every aspect of the crypto used to protect a document as metadata in the XML payload. Microsoft Office refers to this structure as Agile Encryption. OOXML is primarily a symmetric key solution, so that is all we will cover here.

I have some C# code that dumps the main crypto metadata from an encrypted OOXML file, you can find it here and the output looks a little like this:

Key Data: saltSize : 16 blockSize : 16 keyBits : 256 hashSize : 64 cipherAlgorithm : AES cipherChaining : ChainingModeCBC hashAlgorithm : SHA512 saltValue (or IV) : ktwu3iMe57cJ0LTDJHwf7g== Password Encryptor: spinCount : 100000 saltSize : 16 blockSize : 16 keyBits : 256 hashSize : 64 cipherAlgorithm : AES cipherChaining : ChainingModeCBC hashAlgorithm : SHA512 saltValue (or IV) : p8MRLOBj/a5MOYG1tvfA/Q== encryptedVerifierHashInput : D8jQbWvjyPK8uWa1Z/0hiw== encryptedVerifierHashValue : ikHKt4eXn<snip>QsfCKVqQaawWe1celUw== encryptedKeyValue : p0lVCnKVd<snip>KrmggpYbeH69p8MBvahw=

This is enough data to create the various cryptographic objects needed to decrypt this document. Of course, this code needs to unwrap the data encryption key (DEK) using a user-provided password.

Depending on the language and crypto libraries you use, you could use code like this pseudo code to decrypt data given a block of crypto-metadata:

descriptor = parse(encryption_metadata) cipherName = descriptor.cipherAlgorithm chainMode = descriptor.cipherChaining paddingMode = descriptor.padding keyBits = descriptor.keyBits blockSize = descriptor.blockSize hashName = descriptor.hashAlgorithm hashSize = descriptor.hashSize spinCount = descriptor.spinCount IV = decodeBase64(descriptor.saltValue) cipher = GetAlgFromAlgName(cipherName) hash = GetAlgFromAlgName(hashName) ) if cipher is null: fail("unsupported cipher") if hash is null: fail("unsupported hash") cipher.build(keyBits, chainMode, blockSize, paddingMode) plaintext = cipher.decrypt(ciphertext, IV, key) function GetAlgFromAlgName (name): switch name: case "AES": return new Aes() case "TripleDES": return new TripleDes() case "SHA256": return new Sha256() case "SHA384": return new Sha384() case "SHA512": return new Sha512() default: return null

This pattern works well for documents because even though the metadata is large, it’s probably smaller than the document. But it does not work so well with rows of data, such as database platforms.

So, let’s look at that.

SQL Server and Azure SQL DB

SQL Server and Azure SQL DB offer a feature called Always Encrypted (AE) that also supports crypto agility, but rather than store metadata, it has a version number at the start of the ciphertext that maps to set of cryptographic primitives.

Currently, SQL Server only has one version of AE, version 1, but if the SQL team added a new set of cryptographic primitives, then the version number would be bumped to 2.

You can see this version number if you dump the hex-encoded ciphertext, below is an example.

Look at the first byte of each NationalIDNumber, it’s always 0x01, that’s the version number, and that maps to the following ciphersuite:

AEAD_AES_256_CBC_HMAC_SHA_256

Which, when translated to English means:

AEAD — Authenticated Encryption with Associated Data: Provides both encryption (confidentiality) + authentication (integrity + authenticity) in one step. It can also protect "associated data" (e.g., metadata) that isn't encrypted.
AES_256 — Advanced Encryption Standard with a 256-bit key (strong symmetric encryption).
CBC — Cipher Block Chaining mode (handles padding and chaining blocks; requires an Initialization Vector/IV).
HMAC_SHA_256 — Hash-based Message Authentication Code (MAC) using SHA-256 (provides the authentication tag/MAC).

This is an Encrypt-then-MAC construction: encrypt the data first, then compute a MAC over the ciphertext (plus associated plaintext data) to authenticate it.

If you look at the .NET SqlClient driver source code, you can see the version number is held in the AlgorithmVersion member variable, and the ciphersuite details are gated on that version number. When a new version is introduced, the code is updated to support it while continuing to read version 1 data and writing new data with the latest version, such as version 2.

Azure Blob Storage Client-side Encryption

The Azure Blob Storage client library for .NET supports encrypting data within client applications before uploading to Azure Storage, and decrypting data while downloading to the client. The library also supports integration with Azure Key Vault for key management.

At the time of writing this, there are two ciphersuite versions supported by the client library. Version 2 came into being because of a Padding Oracle vulnerability (read more here) in v1, rendering v1 obsolete.

Blob Storage client-side encryption supports various key wrapping mechanisms, you can learn more here.

You can see how this code is managed in a crypto-agile manner by looking at the Azure SDK source code.

Post Quantum Crypto and Version Numbering

Imagine over the years, you started with a version 1 ciphersuite, then in 2020 you added a newer version 2, and finally, today with Q-Day around the corner, you want to add a version 3 that is quantum safe.

This is the pattern you might use using version numbers:

public enum CryptoVersion : byte { V1 = 1, V2 = 2, V3 = 3, Latest = V3, } public static byte[] Encrypt( ReadOnlySpan<byte> plaintext, ReadOnlySpan<char> password, CryptoVersion version = CryptoVersion.Latest) { switch (version) { case CryptoVersion.V1: return EncryptV1(plaintext, password); case CryptoVersion.V2: case CryptoVersion.V3: return EncryptGcm(plaintext, password, version); default: throw new ArgumentOutOfRangeException( nameof(version), version, "Unknown crypto version."); } } public static byte[] Decrypt(ReadOnlySpan<byte> blob, ReadOnlySpan<char> password) { CryptoBlobHeader header = ParseHeader(blob); return header.Version switch { CryptoVersion.V1 => DecryptV1(blob, password, header), CryptoVersion.V2 => DecryptGcm(blob, password, header), CryptoVersion.V3 => DecryptGcm(blob, password, header), _ => throw new CryptographicException( $"Unsupported blob version {(byte)header.Version}."), }; }

This code is simple; when encrypting you pass in (or generate) appropriate cryptographic parameters and then an Encrypt method that then passes it off the correct encryption handler that varies by ciphersuite.

For decrypt, the only parameter you need is the password to derive the key encryption key (KEK) that decrypts the embedded wrapped data encryption key (DEK) and the rest is read from the header metadata that is written as part of the encryption operation.

Over time, if you add more ciphersuite versions, you just bump up the version number and call the Encrypt or Decrypt handler function. Easy! I have a version of this here.

In a future installment, I will add a v4 that also digitally signs the ciphertext blob using ML-DSA, but for the moment, V3 is quantum-safe because it uses quantum-safe symmetric algorithms and key sizes.

I have left out setting the block size, key size, IV, nonce, padding mode, block cipher mode and so on, to keep the code smaller. Store all IVs, salts, and nonces alongside the ciphertext as metadata, and ensure their integrity and authenticity by including them as associated data in an AEAD (Authenticated Encryption with Associated Data) scheme. They are not encrypted, but because they are authenticated by the AEAD construction, any tampering is detected

When your code reads encrypted data, it reads the version number and decrypts the data using the correct set of algorithms and configuration. When your code writes ciphertext it always uses the latest supported version. So, you could read a v1 blob, edit the data and then upon write, use v3 algorithms and settings.

The ciphertext blob has a 4-byte ‘magic’ header, in this case ‘CA42’ for Crypto Agility 42. The ‘42’ is there for no specific reason. Your ‘magic’ header, if you decide to use one, is totally up to you!

The ciphertext blob looks like this on disk across the various example versions:

Versions 2 and 3 are functionally identical; the only difference is the AES key size, visible in the wrapped DEK blocks; v3 increases the symmetric key from 128-bit to 256-bit, raising the effective security margin against Grover’s algorithm.

Sample code can be found here.

JOSE and Crypto Agility

Another option, especially for greenfield solutions, is to use JOSE.

JOSE (JSON Object Signing and Encryption) provides a strong foundation for crypto agility through its explicit separation of key wrapping (alg) and content encryption (enc) algorithm identifiers in the JWE protected header.

Because algorithm selection is declarative and self-describing, migrating between cipher suites requires no structural changes to the payload format, only a header update and corresponding key material rotation.

This makes JOSE well suited to versioned algorithm tiers, where each version maps cleanly to a distinct alg/enc pairing and older versions can be deprecated without breaking the envelope format.

Looking ahead, the IETF JOSE working group is actively developing algorithm registrations for post-quantum primitives - particularly ML-KEM for key encapsulation and ML-DSA for signatures - meaning the same JWE envelope structure will carry forward into a post-quantum world once those identifiers are standardized, with no changes required to parsing or storage infrastructure. Until then, implementations targeting PQC can use private x-prefixed header parameters as a forward-compatibility shim, accepting the loss of interoperability as a temporary trade-off.

Here's a highly abridged JOSE serialization example using the x- shim for ML-KEM and ML-DSA:

{ // Key wrapping: // ML-KEM-1024 (via x- private header) + HKDF-SHA-512 → AES-256-KW // Content encryption: AES-256-GCM // Signing: ML-DSA-87 (JWS wrapper — see outer envelope) "protected": { // Standard JOSE fields "enc": "A256GCM", // content encryption algorithm "alg": "A256KW", // key wrapping algorithm (KEK → DEK) "kid": "key-2024-v3", // key identifier "cty": "application/json", // content type // PQC shim — private parameters (x- prefix = non-registered, bespoke) "x-kem-alg": "ML-KEM-1024", // FIPS 203; encapsulate the KEK "x-kem-kid": "mlkem-pub-001", // recipient ML-KEM public key id "x-kdf": "HKDF-SHA-512", // derives AES-256-KW KEK from ML-KEM shared secret "x-kdf-info": "v3-kek-derive", // HKDF info string (context binding) "x-sig-alg": "ML-DSA-87", // FIPS 204; signs outer JWS envelope }

CMS and Crypto Agility

CMS is especially relevant for PQC migration because ML-KEM use in CMS is now standardized using _KEMRecipientInfo_, allowing post-quantum key establishment to be incorporated without changing the overall CMS envelope grammar. You can read more here.

CMS and JOSE solve similar problems, but they use different serialization models. CMS is defined with ASN.1 and is usually encoded as a compact binary structure (commonly DER, though BER is also used in some contexts), much like X.509-related formats. JOSE, by contrast, uses JSON-based serializations, often with base64url-encoded components in JWS/JWE, which usually makes it easier for developers to inspect and debug but can increase message size relative to a compact binary encoding.

DER (Distinguished Encoding Rules) and BER (Basic Encoding Rules) are simply encoding rules, DER is stricter than BER.

The Fly in the Ointment – Existing code

So far, we have spoken about creating new systems that use crypto agility. But what about systems we already have in place that simply create a blob of ciphertext data and nothing to describe its crypto settings?

You really have two options.

The first is to use one of the patterns above to wrap the ciphertext blob and call that version 1 or describe all the parameters

The second is to add a distinct header at the start of new ciphertext and include the metadata, and for old data (let’s call it v1) if that header is missing, then it’s old ciphertext with no metadata.

Think of the header as a magic number like that used in a JPEG (0xFF 0xD8 0xFF), GIF89a (GIF89a), PNG (0x89 PNG\r\n\1x1a\n) or PDF (%PDF-) file. You could use something like 0x00 0xC1 PH 3R 0x01, which is a null followed by ‘CIPHER’ and then the version number, 0x01. Of course, there is a small, but non-zero chance that some ciphertext could include this series of magic values, so make sure you code gracefully fails when it does not decrypt legacy data.

Summary

To be honest, this post is about 8 pages longer than I wanted, but I would rather err on the side of completeness. Besides, as JRR Tolkien said of The Lord of the Rings, “This tale grew in the telling.”

Crypto-agility is the engineering capability to change cryptographic primitives safely and repeatedly without redesigning systems, and it is now essential for post-quantum migration.

Crypto-agility requires either self-describing cryptographic metadata or versioned ciphertext formats so implementations can read legacy data while writing with the newest approved algorithms. A well-designed crypto-agile system should aim to read older ciphertext formats long enough to support migration, while writing new data with the newest approved configuration.

Practical patterns range from Office-style embedded metadata, to SQL-style and Azure Blob Storage version numbers, to JOSE/CMS headers and metadata that separate key wrapping from content encryption.

The design rule is simple: remove hard-coded algorithm assumptions, persist enough information to reconstruct the cryptographic context, and build systems so algorithm upgrades become routine engineering rather than emergency rewrites.

Thanks

I would like to thank the following people for their valuable input and review of this post:

Jack Richins – Azure Security, PQC
Jessica Krynitsky – Windows Security
Andrei Popov – Windows Security
Pieter Vanhove – Azure Data
Jeremy Barton – .NET Crypto
Raul Garcia – Microsoft Crypto Board

rss.livelink.threads-in-node

Threat Modeling and Post Quantum Cryptography

What is Threat Modeling?

Pulling out the Crypto

But is it PQC?

Current Scenario

Current Algorithm/Protocol

PQ Algorithm/Protocol

Short, Worked Example

A Note on PaaS

Summary

Thanks

Azure Key Vault Premium and AES-KW Post Quantum Resistant Key Wrapping in Public Preview

Introduction

Key-wrapping

Azure Key Vault and AES-KW

It’s not a good blog post without some code!

A note on RBAC

What is oct-HSM?

Azure Portal UI

What about Managed HSM?

But wait, there is more!

Thanks

ASP.NET, Kestrel and Schannel GA with TLS 1.3 Post-Quantum Cryptography

IMPORTANT

Introduction

TLS 1.3 and Crypto-Agility

Important sidenote about TLS 1.3 ciphersuite strings

TLS 1.3, ciphersuites, groups and PQC

Important

ASP.NET and Kestrel

Schannel Configuration on Windows

Setting up Schannel

Congratulations, you just connected to Kestrel or ASP.NET using a quantum resilient group! You are officially living in the future!

A note about server authentication

Wrap-up

Thanks

Post-Quantum Cryptography and Crypto-Agility

Introduction

What is Crypto-Agility?

The Need for Crypto-Agility NOW

What Makes This Post Different

Step 0 – Don’t Do Your Own Crypto Agility!

Crypto-Agile Designs

Crypto-agility in Microsoft Products

Microsoft Office

SQL Server and Azure SQL DB

AEAD_AES_256_CBC_HMAC_SHA_256

Azure Blob Storage Client-side Encryption

Post Quantum Crypto and Version Numbering

JOSE and Crypto Agility

CMS and Crypto Agility

The Fly in the Ointment – Existing code

Summary

Thanks