On July 22, 2026, Microsoft announced "KMS Hardware-Secured," a feature that ties the trust of Key Management Service (KMS)—used to activate Windows in bulk within organizations—to TPM. Starting in August, Windows Server 2025 will gain a feature that reports readiness status, and TPM-based attestation will become mandatory in the next Windows Server Long-Term Servicing Channel (LTSC). The goal is to narrow the room for forged or cloned KMS servers to impersonate legitimate hosts.
However, this doesn't mean unlicensed Windows installations will suddenly stop working across the board in August. The target here isn't individual PCs, but the KMS hosts within organizations that handle activation requests. What Microsoft is changing isn't how Windows legitimacy is checked on each device, but the premise of how the server issuing activations is trusted.
August 2026 Begins with a "Compliance Status" Indicator
Starting in August 2026, Windows Server 2025 will notify administrators whether their KMS hosts support hardware-based protection. Compliant or non-compliant messages will appear in slmgr /dlv, and warnings will also be logged in the event log. This isn't mandatory enforcement—it's a feature intended to help organizations prepare for the transition to the next LTSC.
For organizations using physical KMS hosts, Microsoft is asking them to verify whether their server is certified on the Windows Server Catalog and to ensure it has a TPM installed and enabled. Whether the TPM supports the key attestation capability required by KMS can be checked by running the following command in PowerShell with administrator privileges:
Get-TpmSupportedFeature -FeatureList "Key Attestation"
If Key Attestation appears in the response, the TPM supports the authentication capability that KMS Hardware-Secured uses. Meanwhile, regarding the timing of mandatory enforcement, all Microsoft has disclosed is that it will happen "by the next Windows Server LTSC release." The product name, release date, grace period before enforcement, and treatment of non-compliant hosts are not included in the announcement.
Why KMS Has Trusted Software Responses
KMS is a mechanism that lets large organizations activate Windows in bulk through an internal server, rather than having every device connect individually to Microsoft. Administrators install a Customer-Specific Volume License Key (CSVLK) on the KMS host, and Microsoft verifies that host key. From then on, clients discover the KMS host via DNS and request activation corresponding to a Generic Volume License Key (GVLK).
| Element of Current KMS | Mechanism |
|---|---|
| Host preparation | Install CSVLK; Microsoft verifies the host key |
| Client discovery | Devices with GVLK find the KMS host via DNS |
| Activation threshold | 25 devices for Windows clients, 5 for Windows Server |
| Renewal cycle | Re-activation attempted every 7 days by default; must connect within 180 days |
The KMS host counts the requesting client IDs and includes that count in its response. Clients are activated once the count meets the threshold. According to Microsoft's current documentation, these IDs are not permanently stored and are not sent to Microsoft. Precisely because KMS is designed to operate self-contained within an organization, if the destination a client connects to can be spoofed, it can be made to look like a legitimate internal activation infrastructure. The forged and cloned KMS servers that Microsoft is concerned about target exactly this point of trust.
KMS Hardware-Secured adds verification of the identity of the machine handling the key, in addition to verifying the correctness of the host key itself. In other words, it's no longer sufficient to return a correctly formatted software response—the KMS must also demonstrate that it's running on hardware Microsoft recognizes as legitimate.
TPM Ties Together the Identity and State of the Authenticating Host
A TPM keeps private keys from ever leaving the chip, and can bind keys to specific hardware or to boot-time measurements. Standard TPM key attestation cryptographically proves that a trusted TPM is protecting the private key. This kind of proof is difficult to carry over to another machine simply by copying software configuration files.
The KMS Hardware-Secured flow that Microsoft has outlined consists of three stages. First, the KMS host presents a TPM-backed hardware identity, and Microsoft verifies the attestation. Next, the TPM is used to confirm the platform integrity of the host. Once a host passes verification, it processes activation requests arriving from Windows devices within the organization.
This change raises the cost of running a forged KMS server. By tying the secrets required for activation to the TPM, it becomes harder to clone software configurations or impersonate a legitimate host. Organizations running legitimate licenses also benefit from a reduced risk of activation credentials being stolen from a compromised KMS host and used in a different environment.
That said, Microsoft has not yet disclosed the specific attestation protocol used for KMS. It remains unclear which platform measurements will be evaluated, how a host that fails attestation would be recovered, and what data would be sent to Microsoft. TPM-based identity verification is a defense aimed specifically at forged hosts—it is not a guarantee that it will stop every method of unauthorized activation.
Different from Windows 11's TPM 2.0 Requirement
Windows 11 requires TPM 2.0 as a minimum hardware requirement. But this is a condition on the client side for installing Windows 11. The KMS Hardware-Secured announcement adds TPM-based attestation to the KMS host that receives activation requests—it does not state that individual clients will face any new TPM checks.
The scope of affected activation methods is also limited to KMS. Windows volume activation also includes Multiple Activation Key (MAK), where devices connect directly to Microsoft's service, and Active Directory-based activation, which uses activation objects within a domain. Retail and OEM activation follow different paths entirely. Interpreting the KMS change as a blanket TPM requirement across all Windows activation would misjudge the actual scope of the transition.
Active Directory-based activation can, in some environments consisting only of domain-joined devices running supported OS versions, eliminate the need for a KMS host altogether. On the other hand, organizations with workgroup devices or older volume licensing products still in use will continue to require KMS. Administrators will need to not only update to TPM-compliant servers, but also reassess how many devices actually still need to rely on KMS in the first place.
The Remaining Gap in Requirements for Virtual KMS Hosts
Microsoft's current guidance states that a KMS host can be placed on either a physical or virtual machine running a supported version of Windows. There is no upper limit on the number of KMS clients a single host can handle, and Microsoft recommends at least two hosts for availability. In configurations where a small number of KMS hosts handle activation for an entire organization, the number of hosts requiring migration may be limited, but the impact of downtime is significant.
However, the preparation steps outlined in the KMS Hardware-Secured announcement are geared toward physical hosts. Guidance for virtualized environments is said to be coming in a future blog post, and it remains unclear whether a virtual TPM alone would satisfy the requirement, whether attestation of the underlying physical host would also be needed, or how Windows Server running in the cloud would be treated. Organizations running virtualized environments may find that the compliance indicator appearing in August alone isn't enough to finalize their migration design.
This change is less about a new feature for detecting pirated Windows at the device level, and more a measure to narrow, through hardware, which KMS hosts are permitted to issue activations. What administrators need to check next, beyond the warning messages in Windows Server 2025, is the attestation requirements Microsoft outlines for virtual hosts and the enforcement date for the next LTSC. Only once both of those are known can organizations determine whether simply enabling TPM will suffice, or whether they'll need to update KMS hosts and restructure their activation methods.