Microsoft is preparing to make Windows volume activation more resistant to impersonation and infrastructure tampering by tying future Key Management Service deployments to TPM-based hardware attestation. The new KMS Hardware-Secured model is intended to confirm that a KMS host is running on a trusted, uncompromised platform before it is allowed to activate Windows systems across an organization.
For Windows Server administrators, this is not simply another licensing feature. It marks a meaningful change in how Microsoft defines a trusted activation server. KMS has traditionally depended on a combination of volume licensing credentials, server configuration, DNS discovery, network reachability, and the host’s activation state. Under the emerging model, those software and network controls will be supplemented by cryptographic proof rooted in the server’s hardware.
The transition will begin with readiness notifications in Windows Server 2025 beginning in August 2026. TPM attestation is then expected to become mandatory for KMS Hardware-Secured activation in a future Windows Server Long-Term Servicing Channel release. Microsoft has not publicly attached the final requirement to a named product version, so administrators should avoid assuming that every implementation detail is fixed today.
What is clear is that organizations with older KMS hosts, unmanaged virtual machines, aging server hardware, or loosely controlled DNS records should begin treating activation infrastructure as a security modernization priority.
Key Management Service, commonly known as KMS, is Microsoft’s on-premises volume activation technology. It allows organizations to activate Windows and eligible Microsoft products through a centrally managed service rather than requiring every machine to contact Microsoft individually for activation.
A KMS client normally discovers a host through a DNS service record, connects to it over TCP port
For large Windows estates, this is a practical and efficient model. A properly designed KMS deployment can activate a substantial number of Windows clients and servers while keeping licensing operations inside the organization’s network boundary.
KMS also has built-in thresholds intended to prevent it from being used in very small or accidental deployments:
A host name can be copied. A virtual machine can be cloned. Network details can be reproduced. DNS records can be modified. Even credentials and installation media can be mishandled or exposed if an organization’s operational controls fail.
Traditional KMS protections still matter enormously, but they are often centered on software identity and network placement. Microsoft’s new approach is designed to add a stronger question to the process:
A TPM is a hardware-based security component that can protect cryptographic material and participate in integrity measurement workflows. In practical Windows security terms, TPM technology is already associated with features such as:
The broad logic is straightforward:
In a conventional environment, an attacker who gains access to a KMS host’s software state may attempt to duplicate its configuration elsewhere. Even if such an effort is imperfect, it can create confusion, complicate licensing compliance, and expose organizations to activation infrastructure they do not control.
Hardware-backed attestation raises the bar. The attacker would need more than a cloned virtual disk, copied configuration, renamed machine, or exposed credentials. The replacement platform would also need to satisfy the required hardware trust conditions and complete the attestation process successfully.
This does not make attack scenarios impossible. It does make a significant class of software-only impersonation attempts more difficult and easier to distinguish from an approved host.
A hardware-attested KMS host gives organizations another way to limit implicit trust. Rather than treating server location and application configuration as sufficient proof, the activation system can incorporate evidence of platform identity and integrity.
This is especially relevant in environments where:
Hardware-secured KMS does not replace normal licensing governance. It does, however, create a more defensible model for identifying legitimate activation servers. That can improve internal auditing by connecting activation authority to known, managed hardware rather than only to a server name or installed key.
For organizations operating in regulated industries, this is likely to be a welcome direction. A verifiable chain of trust around activation infrastructure is easier to explain than an arrangement based on historical knowledge, informal server ownership, and old DNS entries.
That phased rollout is sensible. KMS often lives on infrastructure that administrators rarely revisit because it has been stable for years. In many organizations, the KMS host may be a low-resource virtual machine, an older utility server, or a platform that was deployed during an earlier server refresh cycle.
The readiness stage should give IT teams an opportunity to answer basic questions before they become urgent:
Existing KMS environments are not expected to stop functioning merely because a readiness notice appears. The purpose is to identify whether the host can move toward Microsoft’s hardware-secured activation model.
That said, a non-compliant readiness status should not be ignored. A KMS host is a relatively small service, but replacing or redesigning it can involve licensing teams, server teams, security staff, virtualization administrators, hardware vendors, and DNS owners. Delaying discovery until a future Windows Server LTSC release could turn a manageable refresh project into an unnecessary operational incident.
For TPM-based attestation, that is only the starting point.
A modern trust chain may involve the TPM version, TPM readiness, endorsement key certificate availability, UEFI configuration, Secure Boot status, measured boot data, firmware integrity, operating system support, and the verifier’s policy. A TPM that exists but is disabled, improperly provisioned, outdated, or operating alongside legacy boot settings may not provide the expected attestation result.
For Windows Server environments, a practical readiness review should cover the following baseline:
KMS hosts have long been suitable for virtual deployment. They generally have light resource requirements, do not need dedicated high-performance hardware, and are often placed on shared infrastructure alongside other management services.
However, hardware-backed attestation complicates that operational simplicity.
A physical KMS server can work directly with the TPM embedded in or attached to the physical system. A virtual KMS host introduces more layers:
Microsoft has not yet provided all public implementation details for virtualized KMS hosts. Organizations should therefore avoid making assumptions that every existing KMS virtual machine will qualify without changes.
The wiser approach is to classify KMS hosts into risk categories:
A KMS host can be hardware-attested and still be compromised through weak administrator passwords, stolen privileged tokens, unpatched Windows vulnerabilities, exposed remote management interfaces, insecure backup practices, malicious DNS changes, or poor segmentation.
The right way to view KMS Hardware-Secured is as an additional control in a layered defense model.
As organizations prepare for hardware-secured KMS, they should also validate that:
This should include:
Review whether the TPM is enabled, ready, provisioned, and trusted. Confirm that the server boot configuration is UEFI-based and that Secure Boot is functioning according to the desired security policy.
Changes to firmware configuration should be handled carefully. A TPM reset, Secure Boot modification, firmware upgrade, or boot configuration change can affect other security services, including BitLocker and measured boot-dependent controls.
A readiness result should be captured, reviewed, and assigned an owner. “Not ready” is not necessarily a crisis, but it should produce a remediation decision:
When replacing a KMS server, organizations should plan for DNS registration, network access, host activation, client discovery, and the KMS activation count. A newly deployed host needs sufficient valid activation requests before it can activate the appropriate classes of systems.
The transition should include:
That direction has been visible in TPM 2.0 adoption, Secure Boot, Secured-core server, Device Health Attestation, virtualization-based security, shielded virtual machines, and measured boot workflows. KMS Hardware-Secured extends the same principle into volume activation.
This is a logical evolution. Modern Windows environments are highly virtualized, heavily automated, and often spread across on-premises data centers, branch locations, cloud platforms, and managed hosting providers. In that world, a server name and a copied configuration are weak evidence of legitimacy.
Hardware-backed attestation will not eliminate the need for sound licensing management, DNS protection, patching, monitoring, and privileged-access controls. It will, however, make it more difficult to treat an unauthorized or cloned KMS host as equivalent to the approved activation authority.
The August 2026 Windows Server 2025 readiness phase gives organizations an opportunity to prepare without immediate enforcement pressure. The most effective response is to inventory KMS infrastructure now, validate TPM and firmware posture, scrutinize virtual deployments, secure DNS registration, and create a documented replacement plan for legacy hosts.
KMS may remain a quiet background service in day-to-day Windows administration, but Microsoft’s new hardware-secured model makes one point unmistakable: the systems responsible for activating Windows at scale must increasingly prove not only what they are configured to do, but also where that authority is actually running.
For Windows Server administrators, this is not simply another licensing feature. It marks a meaningful change in how Microsoft defines a trusted activation server. KMS has traditionally depended on a combination of volume licensing credentials, server configuration, DNS discovery, network reachability, and the host’s activation state. Under the emerging model, those software and network controls will be supplemented by cryptographic proof rooted in the server’s hardware.
The transition will begin with readiness notifications in Windows Server 2025 beginning in August 2026. TPM attestation is then expected to become mandatory for KMS Hardware-Secured activation in a future Windows Server Long-Term Servicing Channel release. Microsoft has not publicly attached the final requirement to a named product version, so administrators should avoid assuming that every implementation detail is fixed today.
What is clear is that organizations with older KMS hosts, unmanaged virtual machines, aging server hardware, or loosely controlled DNS records should begin treating activation infrastructure as a security modernization priority.
KMS Has Always Been More Important Than It Looks
Key Management Service, commonly known as KMS, is Microsoft’s on-premises volume activation technology. It allows organizations to activate Windows and eligible Microsoft products through a centrally managed service rather than requiring every machine to contact Microsoft individually for activation.A KMS client normally discovers a host through a DNS service record, connects to it over TCP port
1688, and requests activation. Activation is not permanent: clients generally renew their KMS activation periodically, and the KMS activation validity interval is 180 days.For large Windows estates, this is a practical and efficient model. A properly designed KMS deployment can activate a substantial number of Windows clients and servers while keeping licensing operations inside the organization’s network boundary.
KMS also has built-in thresholds intended to prevent it from being used in very small or accidental deployments:
- Windows client operating systems require a KMS count of at least 25 before activation begins.
- Windows Server editions and volume-licensed Office products generally require a count of at least 5.
- The host maintains a rolling count based on recent unique activation requests.
- A single KMS host can serve a large number of systems, although resilient organizations commonly maintain more than one host.
Why Microsoft Is Moving KMS Toward Hardware Trust
The central concern behind KMS Hardware-Secured is that software configuration alone is not always persuasive proof of server legitimacy.A host name can be copied. A virtual machine can be cloned. Network details can be reproduced. DNS records can be modified. Even credentials and installation media can be mishandled or exposed if an organization’s operational controls fail.
Traditional KMS protections still matter enormously, but they are often centered on software identity and network placement. Microsoft’s new approach is designed to add a stronger question to the process:
That is where the Trusted Platform Module, or TPM, becomes significant.
A TPM is a hardware-based security component that can protect cryptographic material and participate in integrity measurement workflows. In practical Windows security terms, TPM technology is already associated with features such as:
- BitLocker Drive Encryption
- Secure Boot
- Measured Boot
- Windows Hello for Business
- Device Health Attestation
- Credential Guard
- Virtualization-based Security
- Secured-core server capabilities
- Shielded virtual machine deployments
What TPM Attestation Brings to KMS
Under the KMS Hardware-Secured approach, the KMS host will use TPM-backed evidence to establish a hardware-rooted trust relationship. Microsoft can then validate that evidence before the host performs activation services under the new model.The broad logic is straightforward:
- The KMS host presents hardware-backed attestation information.
- The evidence is linked to the host’s TPM and platform integrity state.
- The attestation process verifies that the host meets the required trust conditions.
- A qualifying host can participate in hardware-secured activation.
- A host that cannot prove the required security posture is not eligible for that model.
A Stronger Defense Against Cloned Hosts
The most obvious benefit is better resistance to unauthorized KMS host cloning.In a conventional environment, an attacker who gains access to a KMS host’s software state may attempt to duplicate its configuration elsewhere. Even if such an effort is imperfect, it can create confusion, complicate licensing compliance, and expose organizations to activation infrastructure they do not control.
Hardware-backed attestation raises the bar. The attacker would need more than a cloned virtual disk, copied configuration, renamed machine, or exposed credentials. The replacement platform would also need to satisfy the required hardware trust conditions and complete the attestation process successfully.
This does not make attack scenarios impossible. It does make a significant class of software-only impersonation attempts more difficult and easier to distinguish from an approved host.
Better Alignment With Zero Trust Principles
The change also fits the broader direction of enterprise security: do not trust a system solely because it is inside the network, joined to a domain, or configured to look legitimate.A hardware-attested KMS host gives organizations another way to limit implicit trust. Rather than treating server location and application configuration as sufficient proof, the activation system can incorporate evidence of platform identity and integrity.
This is especially relevant in environments where:
- Virtual machines are frequently created, copied, migrated, or restored.
- Infrastructure administration is distributed across multiple teams.
- Legacy Windows Server systems remain in place beyond their intended lifecycle.
- Mergers, acquisitions, or cloud migrations have left behind duplicate infrastructure.
- Licensing operations are handled separately from server security operations.
- Privileged access is difficult to monitor consistently.
A More Defensible Compliance Position
KMS is fundamentally connected to software licensing. When an organization cannot clearly demonstrate which systems provide activation services, it creates both operational and compliance risk.Hardware-secured KMS does not replace normal licensing governance. It does, however, create a more defensible model for identifying legitimate activation servers. That can improve internal auditing by connecting activation authority to known, managed hardware rather than only to a server name or installed key.
For organizations operating in regulated industries, this is likely to be a welcome direction. A verifiable chain of trust around activation infrastructure is easier to explain than an arrangement based on historical knowledge, informal server ownership, and old DNS entries.
Windows Server 2025 Will Provide the First Readiness Signal
Microsoft’s transition plan begins with readiness notifications in Windows Server 2025 starting in August 2026. This is an important distinction: the first stage is designed to help administrators identify compatibility gaps before TPM attestation becomes a mandatory requirement for hardware-secured KMS activation.That phased rollout is sensible. KMS often lives on infrastructure that administrators rarely revisit because it has been stable for years. In many organizations, the KMS host may be a low-resource virtual machine, an older utility server, or a platform that was deployed during an earlier server refresh cycle.
The readiness stage should give IT teams an opportunity to answer basic questions before they become urgent:
- Does the KMS host have a compatible TPM?
- Is the TPM enabled and healthy?
- Is the system using modern UEFI firmware settings?
- Is Secure Boot enabled where required?
- Does the KMS host run on supported hardware?
- Is the server physical or virtual?
- If it is virtual, will the virtualized TPM and underlying platform meet the final requirements?
- Is the host’s firmware current and managed?
- Does the organization have documented recovery and replacement procedures?
Readiness Is Not the Same as Enforcement
Administrators should avoid overreacting to the August 2026 milestone. Readiness messaging is not equivalent to an immediate shutdown of conventional KMS infrastructure.Existing KMS environments are not expected to stop functioning merely because a readiness notice appears. The purpose is to identify whether the host can move toward Microsoft’s hardware-secured activation model.
That said, a non-compliant readiness status should not be ignored. A KMS host is a relatively small service, but replacing or redesigning it can involve licensing teams, server teams, security staff, virtualization administrators, hardware vendors, and DNS owners. Delaying discovery until a future Windows Server LTSC release could turn a manageable refresh project into an unnecessary operational incident.
TPM Requirements Are About More Than a Chip Being Present
A common mistake in hardware-security planning is to reduce the conversation to a simple yes-or-no question: Does the server have a TPM?For TPM-based attestation, that is only the starting point.
A modern trust chain may involve the TPM version, TPM readiness, endorsement key certificate availability, UEFI configuration, Secure Boot status, measured boot data, firmware integrity, operating system support, and the verifier’s policy. A TPM that exists but is disabled, improperly provisioned, outdated, or operating alongside legacy boot settings may not provide the expected attestation result.
For Windows Server environments, a practical readiness review should cover the following baseline:
- TPM 2.0 is present where required and enabled in firmware.
- The server uses UEFI, not a legacy BIOS compatibility configuration.
- Secure Boot is available and enabled according to the supported configuration.
- TPM health and provisioning status are reviewed within Windows.
- BIOS, UEFI, BMC, and TPM firmware are managed through an approved update process.
- The server remains within a supported hardware lifecycle.
- The machine is running a current, supported Windows Server build.
- Administrative access is restricted, logged, and protected with strong identity controls.
Virtual KMS Hosts Are the Major Planning Question
The most important unresolved area for many organizations is virtualization.KMS hosts have long been suitable for virtual deployment. They generally have light resource requirements, do not need dedicated high-performance hardware, and are often placed on shared infrastructure alongside other management services.
However, hardware-backed attestation complicates that operational simplicity.
A physical KMS server can work directly with the TPM embedded in or attached to the physical system. A virtual KMS host introduces more layers:
- The Windows Server guest operating system
- The guest’s virtual TPM implementation
- The hypervisor
- The physical host’s TPM and UEFI configuration
- The virtualization management plane
- The host security baseline
- The relationship between guest identity and underlying hardware identity
Microsoft has not yet provided all public implementation details for virtualized KMS hosts. Organizations should therefore avoid making assumptions that every existing KMS virtual machine will qualify without changes.
Planning for Virtualization Without Overcorrecting
There is no need to rush every KMS workload onto standalone physical hardware. Virtualization can support excellent security when it is deployed with modern controls, patching, secure management, host attestation, Secure Boot, and protected VM capabilities.The wiser approach is to classify KMS hosts into risk categories:
- Modern physical hosts with TPM 2.0, UEFI, Secure Boot, current firmware, and clear administrative ownership.
- Modern virtual hosts operating on managed, supported hypervisor platforms with virtual TPM support and strong underlying hardware security.
- Legacy virtual hosts running on older hypervisors, unclear host platforms, or poorly documented infrastructure.
- Legacy physical hosts that lack TPM capability, run in legacy boot mode, or are nearing hardware retirement.
Hardware Attestation Does Not Replace KMS Security Hygiene
TPM attestation is valuable, but it should not be treated as a security cure-all.A KMS host can be hardware-attested and still be compromised through weak administrator passwords, stolen privileged tokens, unpatched Windows vulnerabilities, exposed remote management interfaces, insecure backup practices, malicious DNS changes, or poor segmentation.
The right way to view KMS Hardware-Secured is as an additional control in a layered defense model.
The Controls That Still Matter
A well-protected KMS environment should continue to include:- Timely Windows Server security updates
- Firmware and TPM firmware maintenance
- Secure Boot and appropriate platform integrity protections
- Privileged access management
- Multifactor authentication for administration
- Least-privilege role assignments
- Endpoint security monitoring
- Centralized log collection and alerting
- Restricted inbound and outbound network access
- DNS change monitoring
- Documented recovery procedures
- Secure handling of the KMS host key
- Tested host replacement and migration processes
_vlmcs._tcp service records. A trusted KMS host can still be operationally undermined if clients are directed to the wrong address or if old records remain active after a migration.As organizations prepare for hardware-secured KMS, they should also validate that:
- Only authorized systems can publish or modify KMS DNS records.
- Unauthorized or obsolete
_vlmcs._tcprecords are removed. - DNS zones are monitored for suspicious changes.
- Clients are not manually configured with outdated KMS host names.
- Firewalls permit KMS traffic only where necessary.
- Event logs are reviewed for unusual activation patterns.
A Practical Preparation Plan for IT Administrators
The best preparation is not a one-time TPM check. It is an organized review of the entire activation service.1. Inventory Every KMS Host
Start by identifying all current and historical KMS servers.This should include:
- Active production KMS hosts
- Backup or secondary hosts
- Disaster recovery systems
- Branch-office hosts
- Lab and test environments
- Legacy systems still publishing DNS records
- Hosts created during mergers or acquisitions
- Hosts used for Windows activation and those used for Office activation
2. Document the Current Activation Path
For every host, document:- Server name and IP address
- Windows Server version and patch level
- Physical or virtual deployment type
- Hypervisor platform, if virtual
- TPM status
- Firmware and Secure Boot configuration
- DNS registration ownership
- Network and firewall rules
- KMS host key custody
- Administrative owners
- Monitoring coverage
- Backup and restoration method
3. Test TPM and Platform Health
Administrators should confirm that the host is not merely showing a TPM device in Device Manager. The system must be suitable for attestation in the supported KMS configuration.Review whether the TPM is enabled, ready, provisioned, and trusted. Confirm that the server boot configuration is UEFI-based and that Secure Boot is functioning according to the desired security policy.
Changes to firmware configuration should be handled carefully. A TPM reset, Secure Boot modification, firmware upgrade, or boot configuration change can affect other security services, including BitLocker and measured boot-dependent controls.
4. Update Windows Server 2025 and Review Readiness Output
Once the relevant Windows Server 2025 updates begin surfacing readiness information in August 2026, include that status in normal operational reporting.A readiness result should be captured, reviewed, and assigned an owner. “Not ready” is not necessarily a crisis, but it should produce a remediation decision:
- Upgrade the platform
- Enable and configure existing TPM capabilities
- Move the KMS role to a newer host
- Redesign a virtual deployment
- Retire an unnecessary KMS instance
- Wait for supported virtual-host guidance where appropriate
5. Build a Migration and Recovery Plan
A KMS host may be small, but it should not be treated as disposable.When replacing a KMS server, organizations should plan for DNS registration, network access, host activation, client discovery, and the KMS activation count. A newly deployed host needs sufficient valid activation requests before it can activate the appropriate classes of systems.
The transition should include:
- Deploy and secure the replacement host.
- Configure the KMS role and validate host activation.
- Confirm required DNS registration and TCP
1688access. - Monitor activation traffic and KMS counts.
- Verify Windows client and server activation behavior.
- Remove obsolete DNS entries only after the replacement is functioning reliably.
- Retire the old host securely, including removal of unnecessary activation configuration.
The Larger Meaning of KMS Hardware-Secured
Microsoft’s KMS attestation plans reflect a broader Windows security shift: critical infrastructure roles are increasingly expected to prove their platform integrity, not merely present correct software settings.That direction has been visible in TPM 2.0 adoption, Secure Boot, Secured-core server, Device Health Attestation, virtualization-based security, shielded virtual machines, and measured boot workflows. KMS Hardware-Secured extends the same principle into volume activation.
This is a logical evolution. Modern Windows environments are highly virtualized, heavily automated, and often spread across on-premises data centers, branch locations, cloud platforms, and managed hosting providers. In that world, a server name and a copied configuration are weak evidence of legitimacy.
Hardware-backed attestation will not eliminate the need for sound licensing management, DNS protection, patching, monitoring, and privileged-access controls. It will, however, make it more difficult to treat an unauthorized or cloned KMS host as equivalent to the approved activation authority.
The August 2026 Windows Server 2025 readiness phase gives organizations an opportunity to prepare without immediate enforcement pressure. The most effective response is to inventory KMS infrastructure now, validate TPM and firmware posture, scrutinize virtual deployments, secure DNS registration, and create a documented replacement plan for legacy hosts.
KMS may remain a quiet background service in day-to-day Windows administration, but Microsoft’s new hardware-secured model makes one point unmistakable: the systems responsible for activating Windows at scale must increasingly prove not only what they are configured to do, but also where that authority is actually running.
References
- Primary source: Petri IT Knowledgebase
Published: 2026-07-23T15:37:54+00:00
Loading…
petri.com - Official source: microsoft.com
Prepare your servers for Secure Boot certificate updates | Microsoft Windows Server Blog
The original Secure Boot certificates introduced in 2011 are approaching the end of their planned lifecycle, with expirations beginning in late June 2026.www.microsoft.com - Official source: learn.microsoft.com
Loading…
learn.microsoft.com - Related coverage: neowin.net
Microsoft making a new feature mandatory requirement for Windows KMS activation - Neowin
Microsoft is introducing a new feature as a mandatory requirement for Windows KMS activation soon. The company has shared the details.
www.neowin.net
- Official source: techcommunity.microsoft.com
- Official source: download.microsoft.com