Reading Microsoft’s Cryptographic Posture Framework as a Network Team

April 16, 2026

EN | DE

The Microsoft Security Division CTO’s office published a Cryptographic Posture Management framework this week. It organizes PQC work into four domains (code, network, runtime, storage), a six-stage lifecycle (discover, normalize, assess, prioritize, remediate, monitor), and a table mapping first-party Microsoft tools plus named partner products to each domain.

For a CISO sequencing a PQC program across a large estate, the framework is a useful shared structure. The domain split keeps code inventory, network posture, runtime telemetry, and storage-at-rest concerns from being conflated into a single “are we PQC-ready” question. The lifecycle stages give program managers something to check against. Microsoft publishing this out of the Security Division office also signals that enterprise procurement conversations about PQC can now point at a named framework rather than improvising from first principles.

This post reads the framework the way a network team would and suggests where a companion measurement layer fits alongside it.

The network column and what it covers

Microsoft’s table assigns two tools to the network domain. Defender for Endpoint is the primary one. The cell reads:

Identifies encrypted traffic sessions (TLS, SSH) via network detection and response.

Azure Network Watcher sits alongside, providing flow-level indication that traffic is encrypted and the protocol class it belongs to. The lifecycle instructions repeat the shape: the Network Domain starter steps are to enable MDE to identify encrypted sessions and configure Network Watcher to capture traffic metadata.

That is useful information. Session-presence inventory tells a program team where encrypted traffic exists at all, which is where any PQC migration plan starts. Without it, a team can skip endpoints entirely.

A network team typically also wants to know what those sessions are negotiating: which algorithms the client offered, which the server selected, whether the key exchange is classical, hybrid, or pure post-quantum, and whether the certificate chain is signed with RSA, ECDSA, or ML-DSA. Those are different questions from “is a session encrypted,” and they come from parsing handshake contents rather than from flow metadata.

How the named partners extend the coverage

Four partners appear in the framework. Keyfactor and Entrust operate in PKI and certificate lifecycle management, which matters because certificate authentication is one of the two places PQC lands (the other being key exchange). Isara focuses on discovery, inventory, and remediation workflow across a large estate. Forescout contributes network-layer posture where PQC classification is one dimension among many in an IT, IoT, and OT risk matrix.

Each of those partners is a strong fit for the layer it occupies. A handshake-contents parser that sits next to them, reading what’s actually negotiated on the wire at the endpoints that MDE flagged as encrypted, rounds out the picture. pqprobe is one option for that role; an in-house tool built on Zeek or tshark is another. The category matters more than the specific product.

Where trajectory fits in the lifecycle

The six lifecycle stages each produce point-in-time state. Monitor tracks inventory changes across snapshots, which answers “what did we have then vs now.” A complementary read is whether a specific endpoint is improving toward PQC, holding stable, oscillating, or drifting backward across consecutive scans. Trajectory as a measurable output is a natural fit for the monitor stage and gives program teams an early signal when a deployment regresses rather than waiting for the next full assessment cycle.

This isn’t a criticism of the framework. It’s the kind of measurement that fits on top of it.

What pqprobe adds, inside and outside the Microsoft estate

pqprobe parses TLS handshakes across thirteen protocols in passive mode. Each scan records cipher suites offered and selected, key exchange groups including hybrid constructions such as X25519MLKEM768, certificate signature algorithms across the full chain, and hybrid-PQC compliance against BSI TR-02102. Repeated scans produce a trajectory classification (IMPROVING, DEGRADING, STABLE, OSCILLATING) against a baseline.

For teams already running MDE, pqprobe ingests Advanced Hunting exports directly. A single pqprobe import mde run consumes the DeviceTvmSoftwareInventory and DeviceFileCertificateInfo tables from an MDE CSV or JSON export, maps each software entry against a PQC capability catalogue covering fifteen crypto libraries (OpenSSL, BoringSSL, rustls, Bouncy Castle, Go crypto, Windows SymCrypt, and others) with version-range matching, and produces per-device PQC scoring alongside certificate posture findings. Results flow into the same dashboard and grading as handshake scans, so the inventory baseline and the on-the-wire measurement live side by side in one view. This matches the Discover and Assess stages of the CPM lifecycle without deploying anything on endpoints.

The second piece matters more for most organizations. The CPM framework is organized around Microsoft tools, which is the right scope for the Microsoft-managed portion of an estate. The rest of the estate usually extends past it: Linux servers outside Defender’s coverage, network appliances and load balancers, SaaS endpoints the organization depends on but does not operate, vendor APIs, third-party payment processors, IoT and OT systems, legacy infrastructure inherited through acquisitions. Those endpoints carry TLS handshakes, and harvest-now-decrypt-later applies to them the same way it applies to Windows workloads. A CISO planning a PQC program needs a view of that surface, not only the part Microsoft can already see.

pqprobe scans any reachable endpoint by hostname or IP, so the MDE baseline and the external handshake data land in the same dashboard. Self-hosted deployments keep all scan data inside customer infrastructure.

Using the framework well

The CPM framework gives a PQC program real structure for the Microsoft-managed part of an estate. MDE and Network Watcher cover session inventory inside that estate. The partner list fills PKI, remediation workflow, and generalist posture. Handshake-contents measurement at the endpoints MDE identified, scanning of the non-Microsoft surface the framework does not cover, and trajectory tracking across all of it gives a network team the full picture needed to plan a migration sequence and verify it landed.

The takeaway for teams reading the Microsoft post this week: the framework is a solid planning tool for the part of the estate Microsoft can see, and most organizations need a complementary layer for everything else. Pairing the internal view with external handshake measurement is what gives a CISO a threat model that matches the actual attack surface.