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.

 

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.

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