Which Windows builds still carry a FIPS certificate
Tick what you run. Free, instant, nothing to install and nothing to send us.
The short version, before you tick anything
A Windows build’s FIPS posture rests on two modules — bcryptprimitives.dll and cng.sys. The newest releases with an active pair are Windows 11 22H2 and Windows Server 2022, which gained FIPS 140-3 certificates on 31 August 2026 — for the exact builds those certificates name. Windows 11 22H2 is past Microsoft’s end of servicing (Enterprise and Education ended 14 October 2025; Home and Pro 8 October 2024), so no Windows 11 release Microsoft still services is named on a certificate. Server 2022 is supported to 14 October 2031 (mainstream support ends 13 October 2026). Dates are Microsoft’s US dates (its lifecycle tables print the next morning in UTC), read 14 September 2026.
Windows 10 21H2 and 22H2, Windows 11 23H2, 24H2, 25H2 and 26H1, and Server 2025 have no active core certificate in this snapshot. (25H2 and 26H1 are not yet rows in the table below; no certificate in the record names their builds either.) That is not a reason to avoid them. It is a reason to know before somebody asks, because “latest” and “validated” are currently pulling in opposite directions.
What this page cannot tell you about those same machines — and none of it is fixable by upgrading:
- Which build revision you are actually on. This works at release level; certificates name exact revisions. Windows Server 2019 is the proof: its certificates cover 10.0.17763.10021 and 10.0.17763.10127, Server Core only. Same release, different revision, outside the certificate.
- The cryptography inside your applications. Run on an ordinary laptop whose software list showed 301 packages and nothing cryptographic beyond Windows, our tool found six different OpenSSL versions. A package list cannot see them; they are files on disk.
- Everything that is not Windows. Firewalls, HSMs, storage arrays and network devices carry their own certificates and never appear in a software inventory at all.
- What to write down. Knowing a build has no certificate does not help — you cannot downgrade a fleet. What an assessor wants is the gap documented: the certificate number, the vendor’s position, and a plan-of-action entry. That is the report.
| Run it? | Release | Build | Core pair | Other Microsoft modules |
|---|---|---|---|---|
Build 28000 (latest 28000.2954 on 8 September 2026) per Microsoft's Windows 11 release information page, read 14 September 2026. Offered on new devices only, not as an in-place update, and not supported for IoT Enterprise. Microsoft's Windows 11 validations page (ms.date 2026-09-02) lists no entry for it. | 10.0.28000 | none in the record | none | |
Build 26200 (latest 26200.9445 on 8 September 2026) per Microsoft's Windows 11 release information page, read 14 September 2026. Microsoft's Windows 11 validations page (ms.date 2026-09-02) lists no entry for it. | 10.0.26200 | none in the record | none | |
| 10.0.26100 | none in the record | none | ||
No certificate in the CMVP record names this build. The gap is present-tense and is not created by the 21 September transition. | 10.0.26100 | none in the record | none | |
| 10.0.22631 | none in the record | none | ||
FIPS 140-3 #5410 and #5408, validated 31 August 2026, sunset 30 August 2031 - issued the day after the 30 August refresh, so this entry read "no validation" until 14 September 2026. The vendor's two documents disagree on the build: Microsoft's Windows 11 page says "Build: 10.0.22621.1"; section 2.2 of both security policies says "Windows 11 version 22H2 10.0.22621.30001". The tool matches only the version the security policy names, so a 22H2 machine on any other revision is not reported as covered - and, because Microsoft did validate this release, it is no longer reported as "no validation published" either. It reads as not determined, which is the honest state of a revision neither document names. Both named builds are listed above. | 10.0.22621.1 | 2 active #5408 #5410 | 5 active | |
In the record, the only Windows 11 release a FIPS 140-2 primitives certificate names. Since 31 August 2026, 22H2 also holds a FIPS 140-3 pair (#5410, #5408); Microsoft's Windows 11 page (ms.date 2026-09-02) lists no entry for 23H2, 24H2, 25H2 or 26H1. | 10.0.22000 | 2 active #4766 #4825 | 1 active | |
FIPS 140-3 #5410 and #5408, validated 31 August 2026, sunset 30 August 2031, Standard and Datacenter only (not Datacenter: Azure). The vendor's two documents disagree on the build: Microsoft's page (ms.date 2026-09-02) says "Build: 10.0.20348.1668"; section 2.2 of both security policies says "Windows Server 2022 10.0.20348.30000 (including the March 2023 updates)". Both are listed. The tool matches only the version the security policy names (data/security-policy-versions.json), so a machine on any other revision is NOT reported as covered by this pair - our conservative reading of a conflict between the vendor's documents, not a determination that it is uncovered. | 10.0.20348.1668 | 2 active #5408 #5410 | 7 active | |
The FIPS 140-2 validation: the bare build 10.0.20348 (Standard, Datacenter, Datacenter: Azure), moving to Historical on 21 September 2026. Server 2022 also holds a FIPS 140-3 validation of narrower scope, kept as its own entry - one pair per entry, as for Server 2019. | 10.0.20348 | 2 active #4766 #4825 | 7 active | |
The terminal Windows 10 release, and the one most fleets run. No certificate in the record names this build for the primitives libraries. | 10.0.19045 | none in the record | none | |
| 10.0.19044 | none in the record | none | ||
| 10.0.19043 | 2 active #4766 #4825 | none | ||
| 10.0.19042 | 2 active #4766 #4825 | none | ||
| 10.0.19041 | 2 active #4515 #4536 | 8 active | ||
| 10.0.18363 | 2 active #4515 #4536 | 8 active | ||
| 10.0.18362 | 2 active #4515 #4536 | 7 active | ||
The narrowest scope in the index, on both axes: two exact revisions and Core only. A Server 2019 on any other revision, or with the desktop experience installed, is outside these certificates. | 10.0.17763.10021 | 2 active #4670 #4687 | 6 active | |
| 10.0.17763.107 | none in the record | none | ||
| 10.0.17763 | none in the record | 8 active | ||
| 10.0.17134 | none in the record | none | ||
| 10.0.16299 | none in the record | none | ||
| 10.0.15063 | none in the record | none | ||
| 10.0.14393 | none in the record | none | ||
| 10.0.14393 | none in the record | none | ||
| 10.0.10586 | none in the record | none | ||
| 10.0.10240 | none in the record | none | ||
Server 2008 R2 and Windows 7 share build numbers and hold separate certificates - 1336/1335 are the server pair, 1329/1328 the client pair. Conflating them cites the wrong certificate for the right build. | 6.1.7600.16385 | none in the record | none |
Two things this cannot tell you, and both matter
An active pair is not the end of the question — read the scope. Windows Server 2019 is the sharpest example: its certificates name two exact revisions and cover Server Core only. A Server 2019 on any other revision, or with the desktop experience installed, sits outside them. A certificate number on its own cannot tell you that.
Other Microsoft modules being validated is not the same as your build being covered. A release with boot manager and code integrity validated, and no core pair, is not a covered build — and the right-hand column is there so that distinction is visible rather than flattened.
Want this for your actual machines?
$100 runs it on one machine and gives you the report — immediately, on your own hardware, with nothing sent to us. It reads an inventory you already export, or the machine it is run on, and names every certificate your estate rests on with the date each one ends.
An estate of twenty machines needs the twelve-month license, not twenty trials — and we would say so rather than sell you the wrong thing. The $100 comes off it if you go on to buy.
What happens on 21 September
Every remaining FIPS 140-2 certificate moves to NIST’s Historical list. Nothing stops working. Deployed systems keep operating, and continued use is permitted on an assessment of where and how each module is used. What changes is new federal procurement — and what an assessor concludes when the module you rely on sits on the Historical list.
It is also not the last date. 53 more certificates lose standing between 22 September 2026 and the end of 2027.
Where this comes from. The NIST CMVP validated-module list, snapshot 2026.09-full, fetched 2026-09-14, joined to our Windows release index 2026.08, in which every build number and certificate is quoted from Microsoft’s own published validation pages rather than inferred from certificate text.
What it cannot tell you. A certificate issued after that date is not in here. “None in the record” means nothing was found in a snapshot taken on that date — it is not a finding about Microsoft, and we do not publish it as one. Every certificate number links to NIST so you check the current position rather than take ours.