← Knowledge base

Check PQC from Windows

Choose the application before choosing the test. A browser, IIS, RDP, PowerShell, and an application with bundled OpenSSL can use different cryptography on the same Windows device. This walkthrough tests a specific endpoint with an approved local tool, then explains how to assess the native application separately.

1. Inventory the OS and application

Get-CimInstance Win32_OperatingSystem |
  Select-Object Caption, Version, BuildNumber
$PSVersionTable.PSVersion
Get-Command curl.exe, ssh.exe, openssl.exe -ErrorAction SilentlyContinue |
  Select-Object Name, Source

These are read-only inventory commands for Windows PowerShell 5.1 or PowerShell 7 on Windows. Missing executables are simply absent tools. Record the product version of the application you care about as well as its actual TLS provider. Schannel is Windows' security provider; not every Windows application uses it.

2. Obtain a trusted diagnostic tool

The endpoint check requires an approved OpenSSL 3.5-series or newer build with X25519MLKEM768, plus its correct trusted CA bundle. These are prerequisites, not a statement that OpenSSL is preinstalled or that your Windows application's TLS supports PQC.

  1. Use your organization's signed software catalog or an already approved vendor distribution. For source builds, begin with OpenSSL's official releases and signature-verification instructions. Check support status and architecture.
  2. Verify the package publisher/signature and compare its checksum with your trusted distribution record before running it. A checksum downloaded beside a tampered binary is not independent publisher authentication.
  3. Install or stage it in an approved directory, preserving its required libraries/providers. Record the full executable path; do not silently use another copy from PATH.
  4. Obtain the CA bundle from your approved package/PKI process. Do not trust a server's own certificate merely to make its test pass.
# Replace both examples with pre-approved, existing local files.
$PqcOpenSsl = 'C:\ApprovedTools\OpenSSL\bin\openssl.exe'
$PqcCaBundle = 'C:\ApprovedTools\OpenSSL\certs\trusted-ca-bundle.pem'
if (-not (Test-Path -LiteralPath $PqcOpenSsl -PathType Leaf)) {
  throw 'Approved OpenSSL executable was not found.'
}
if (-not (Test-Path -LiteralPath $PqcCaBundle -PathType Leaf)) {
  throw 'Approved CA bundle was not found.'
}
Get-FileHash -LiteralPath $PqcOpenSsl -Algorithm SHA256
Get-AuthenticodeSignature -LiteralPath $PqcOpenSsl |
  Select-Object Status, SignerCertificate

The signature result needs to match your approved package's expected publisher and status. A missing Authenticode signature requires your organization's alternative verified-package process; NotSigned is not an approval. See Microsoft's signature inspection reference.

For disconnected systems, verify and stage the package through the same offline software-distribution process. No downloaded PowerShell module, CheckPQC package, execution-policy change, or administrator elevation is required by this diagnostic.

3. Run the read-only endpoint check

# Run these only after checking the package's provenance.
& $PqcOpenSsl version -a
& $PqcOpenSsl list -tls-groups -tls1_3

# Change this to the hostname you intend to test.
$PqcTarget = 'example.com'
$PqcTlsArguments = @(
  '-connect', ($PqcTarget + ':443'),
  '-servername', $PqcTarget,
  '-verify_hostname', $PqcTarget,
  '-verify_return_error', '-CAfile', $PqcCaBundle,
  '-tls1_3', '-groups', 'X25519MLKEM768',
  '-brief', '-no_ign_eof'
)
'' | & $PqcOpenSsl s_client @PqcTlsArguments
"OpenSSL exit code: $LASTEXITCODE"

First confirm the local group list contains X25519MLKEM768. Then require successful certificate verification and an actual selected hybrid group. The OpenSSL client reference documents the verification and group options. Stop with Ctrl+C if a network attempt hangs, or use the bounded reference script with the same approved tool.

Illustrative successful excerpt: formatting differs between builds.

Protocol version: TLSv1.3
Verification: OK
Negotiated TLS1.3 group: X25519MLKEM768
OpenSSL exit code: 0

That is evidence for this OpenSSL connection from this machine to the target. A nonzero exit, verification error, missing group, or timeout is inconclusive for PQC. For a classical comparison, rerun with X25519 in the arguments and record both results. See the troubleshooting table.

4. Assess Schannel and the actual application

A successful Invoke-WebRequest, TLS 1.3 result, or cipher-suite inventory does not expose enough evidence to name the negotiated key exchange group. Leave that application's PQC status unknown unless its documented diagnostics or the server receiving that exact connection report the selected group.

Use an approved test request from the actual application to an endpoint you operate, correlate it with server-side handshake telemetry, and record any terminating proxy. For an IIS/RDP/Schannel service, consult Microsoft's TLS management documentation and the specific supported Windows build/product guidance. OpenSSL or browser success cannot fill that evidence gap.

5. Update, retest, and retain recovery

Apply supported Windows and application updates using normal management channels. For bundled libraries, update the application; for managed policies, ask the administrator to review the product's supported configuration. Avoid speculative registry edits or preview crypto providers to force a green result.

Before changing policy, export its approved baseline and preserve the previous deployment package. Pilot the change, repeat the same application request and evidence capture, and test ordinary functionality. Roll back through your management system if it regresses, then record an owner and retest date in the worksheet.

Documentation reviewed 25 September 2026. PowerShell syntax and vendor references are reviewed; no Windows/Schannel execution matrix is claimed. Examples are illustrative.