Microsoft Says PKI, HSMs and Security Appliances Must Prepare for Post-Quantum Authentication

Microsoft is urging organizations to prepare their certificate systems for post-quantum authentication, warning that public key infrastructure (PKI), hardware security modules (HSMs), and security appliances need testing before deployment.

Its October 8 guidance says the shift will affect applications, devices, certificate chains, and the processes that keep digital trust working. The message goes beyond protecting encrypted traffic.

While many quantum security plans focus on attackers collecting data now to decrypt later, authentication depends on certificates and private keys being issued, stored, checked, renewed, and managed across different vendors. Changing the underlying algorithms can expose gaps across that entire chain.

Microsoft Security Researchs noted that organizations often know where TLS protects communications but lack a complete view of certificate dependencies. Their report concerns infrastructure readiness, not a newly discovered malware campaign.

Post-Quantum Authentication

The main challenge is not simply finding a quantum-resistant algorithm. Businesses must establish whether their existing systems can use new certificates reliably.

Older PKI deployments, embedded devices, operational technology, custom applications, and third-party services may contain fixed assumptions that only become visible during testing.

Larger post-quantum certificates and certificate chains can affect connection setup, storage, transmission, and network inspection limits.

Related work on Cloudflare’s post-quantum certificate authority shows why certificate size and connection speed matter as providers explore different designs for quantum-safe authentication.

Those efforts do not remove the need to test enterprise systems individually. HSM providers and security appliance vendors therefore belong in the migration discussion from the start.

Teams need to check whether hardware-backed systems support future certificate requirements and whether monitoring, inspection, and certificate-management tools can process the resulting traffic. Support in one application does not establish readiness across the full environment.

Microsoft’s PQC TLS Pilot

Microsoft launched its Post-Quantum Cryptography TLS Pilot Program on August 27, 2026. It allows approved certificate authorities in good standing with the Microsoft Trusted Root Program to test certificate roots and issuance using ML-DSA-87, a quantum-resistant digital signature algorithm.

The focus is compatibility, performance, and day-to-day operations. The August release added seven pilot roots operated by ComSign, DigiCert, HARICA, IdenTrust Services, Sectigo, Shanghai Electronic Certification Authority, and SSL.com.

Admissions continue through the end of 2026. Microsoft’s published authentication readiness guidance directs eligible providers to the Trusted Root Program portal for requirements and applications.

These certificates are not publicly trusted. Microsoft limits their use to closed environments, custom applications, and enterprise testbeds, explicitly excluding production trust and public-facing websites.

Elsewhere, Let’s Encrypt’s certificate roadmap explores Merkle Tree Certificates for public-web authentication, highlighting that separate efforts are addressing different parts of the transition.

On supported, correctly configured Windows 11 systems, pilot testing begins with the July 28, 2026 updates. Microsoft names KB5101681, OS Build 28000.2608, for 26H1, and KB5101684, OS Builds 26200.8973 and 26100.8973, for 25H2.

ML-DSA certificates can also work with Secure Channel, or Schannel, in supported scenarios. Administrators must confirm platform requirements before testing.

Software and hardware readiness should be checked separately. Earlier coverage of Google’s quantum-safe digital signatures described software-based Cloud KMS support with hardware-backed support planned separately.

Microsoft similarly urges organizations to ask certificate providers, HSM vendors, software suppliers, and platform vendors about their roadmaps and testing capabilities rather than assume universal support.

Security teams should inventory certificate-dependent systems, map public and private trust relationships, and identify equipment with long upgrade cycles.

Non-production tests should cover compatibility, performance, and operational workflows. Developments such as OpenSSL’s post-quantum performance improvements offer useful testing context, but preview software and Microsoft’s pilot certificates should not be treated as production-ready replacements.

That work should include the full certificate lifecycle, not just a successful connection. Issuance, distribution, validation, renewal, and management all depend on linked systems.

Testing those steps together helps teams find process gaps that a standalone algorithm test could miss before they reach live business services.

Microsoft recommends a multi-year program with named owners, clear dependencies, and modernization priorities based on test results.

Organizations can ask their certificate provider whether it participates in the pilot and offers suitable testing. The practical goal is to uncover failures before quantum-resistant authentication becomes a large-scale deployment requirement.

Indicators of compromise (IoCs):-

Indicator category	Source finding
SHA-256, SHA-1, MD5 hashes	Not reported
Malicious domains	Not reported
Malicious IP addresses	Not reported
Attack URLs	Not reported

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Stops threats before impact with 21 min faster MTTR. Integrate ANYRUN’s Sandbox in your SOC