Microsoft is warning in the Security Blog that preparing for post-quantum cryptography does not stop at encrypted data. Certificate-based authentication also has to be tested: certificate chains, trust anchors, PKI services, applications, devices, and hardware security modules can all be affected by new algorithms and larger certificates. For small and midsize companies, this is not a reason for rushed replacement projects, but it is a good reason to make certificate dependencies visible.
Why certificates belong on the review list now
Microsoft describes post-quantum authentication as a multi-year transition rather than a single update. The risk is not that every production certificate needs to be replaced immediately. The more practical issue is that many organizations do not fully know which systems issue, store, validate, or distribute certificates. That is where compatibility problems are likely to appear later when algorithms, certificate sizes, or chain lengths change.
For day-to-day IT operations, this means the first question is operational readiness rather than cryptography itself. A certificate can be technically valid and still cause trouble if an appliance cannot parse the chain, an older application rejects larger certificates, or a validation tool does not understand a new algorithm.
Where dependencies often hide in SMB environments
Even companies with 10 to 250 seats use more certificate logic than is obvious at first glance. Common places include:
- TLS certificates for websites, customer portals, VPNs, or remote access,
- internal certificates for Wi-Fi, device certificates, print services, or application servers,
- security and network appliances that inspect TLS connections or distribute their own certificates,
- business applications that use certificates for client authentication or API access.
A Microsoft Security Assessment should include these areas before a forced replacement date exists. Microsoft explicitly recommends inventorying certificate-dependent systems, documenting trust relationships, assessing vendor roadmaps, and creating safe test environments.
Which dates and limitations Microsoft names
The Microsoft article from 8 October 2026 refers to the PQC TLS Pilot Program in the Microsoft Trusted Root Program. According to Microsoft, this pilot launched on 27 August 2026 and continues with rolling admissions for eligible certificate authorities through the end of 2026. It is not meant for production websites: pilot certificates are not publicly trusted, not intended for production trust scenarios, and not intended to secure public-facing web connections.
Microsoft also names concrete Windows requirements for testing ML-DSA certificates. Supported test scenarios start with the Windows 11 updates from 28 July 2026: KB5101681 for version 26H1 and KB5101684 for version 25H2. On older or unsupported systems, Microsoft Certificate Trust List validation can fail with errors such as NTE_BAD_ALGID.
These dates are not a migration deadline for SMBs. They show when Microsoft first describes test paths in its own trust program and on specific Windows 11 builds. If dependencies are known early, vendors can be questioned deliberately instead of discovering under pressure which component blocks a certificate chain.
What should not be done yet
The boundary matters: Microsoft is not asking customers to migrate production certificates to post-quantum algorithms immediately. On the contrary, the pilot is explicitly limited to closed testing environments, custom applications, and enterprise testbeds. Companies should therefore not secure public websites, production VPNs, or Microsoft 365 access paths with pilot certificates. The useful step is a clean inventory, so that later requirements do not collide with unknown legacy dependencies.
Pilot updates should also not be read as a buying signal. Microsoft describes limited, experimental support, not a general production approval. Procurement, replacement, and rollout decisions should follow a technical review; they should not be the starting point.
Concrete next steps
For Microsoft 365 Consulting and technical security reviews, this creates a manageable work plan:
- List certificate sources: public CA, internal CA, devices, appliances, cloud and SaaS providers.
- Document trust chains: which systems accept which root or intermediate certificates?
- Flag long-lived assets: systems with slow update cycles, older Windows versions, embedded devices, and business applications.
- Ask vendors whether roadmaps, test options, and support statements for post-quantum certificates are available.
- Plan a non-production test window before certificate sizes, validation paths, or TLS inspection limits become daily operations issues.
Official Microsoft sources
- Microsoft Security Blog: Post-quantum authentication
- Microsoft Trusted Root Program: PQC TLS Pilot Program Requirements
- Microsoft Trusted Root Program: PQC pilot root announcements
If you want to know where certificates could become critical in your Microsoft 365 and Windows environment, we review inventory, trust chains, and realistic testing steps as part of a Microsoft Security Assessment – get in touch.
What does this mean for your environment?
Assess the topic in the context of your Microsoft 365 environment and define a practical next step.
You speak directly with Sebastian Kerssen – working in the Microsoft ecosystem since 2014, with personal consulting and a dedicated point of contact.
