2026 Windows Server 2025 KMS Hardware Security Not Ready: Replace the Host?

A KMS host shows a hardware security readiness warning, but activation still appears to work.

Decision: Do not replace the host just because of this warning. Microsoft describes it as informational; check the host’s actual status and hardware eligibility, then decide whether to remediate or align replacement with your planned refresh.

This guide is for administrators maintaining an enterprise KMS host who need to distinguish a readiness notice from an activation failure.
It is also for IT leads assessing TPM and certification requirements before renewing Windows Server hardware.
If you are comparing server rental or purchase options, use the hardware checks below before treating a product description as proof of eligibility.

Last updated October 30, 2026. Checked against Microsoft’s KMS hardware-secured activation guidance, KMS planning documentation, and the Windows Server Catalog.

Warning status versus activation failure

The August 2026 cumulative update for Windows Server 2025 added a KMS host hardware security readiness status. Microsoft characterizes that status as informational: it helps you assess an environment against hardware conditions, but does not, by itself, change or stop current standard KMS activation. Microsoft’s explanation of KMS hardware-secured activation is the primary reference for interpreting the notice.

Keep these two questions separate:

• Is standard KMS activation working now? Check the host’s actual licensing and activation state, and investigate any activation errors.
• Does the host meet the stated hardware conditions? Check TPM status and whether the server hardware is listed in the Windows Server Catalog.

A readiness warning is not evidence that activation has already failed. It is also not a published enforcement date for a future Windows Server release. Microsoft says hardware-trust-based activation changes apply to future Windows Server versions, but the cited guidance does not establish a specific effective date or version number. Do not turn that uncertainty into an emergency deadline.

Microsoft’s KMS activation planning documentation is useful for reviewing the role of KMS in your environment. It does not replace checking the actual host and its current activation status.

Hardware eligibility checks

The readiness question is not answered by the CPU brand, the server’s age, or the fact that Windows Server 2025 is installed. Microsoft identifies two hardware conditions: TPM 2.0 must be present and enabled, and the server hardware must be certified through the Windows Server Catalog. Check the specific machine, not a similar model or a general product family.

For the graphical check, open the Run dialog and enter tpm.msc. Review whether the management console detects the TPM and reports its status. If the TPM is absent or disabled, check the server’s UEFI or firmware configuration with the hardware administrator. Do not change firmware settings on a production KMS host without following your change-control process.

For the documented command-line checks, use an elevated PowerShell session:

Get-TpmSupportedFeature -FeatureType KeyAttestation

Microsoft documents this cmdlet and its feature parameter in the Get-TpmSupportedFeature reference. Record the actual result from your system; do not infer eligibility from a command completing successfully. For a separate licensing snapshot, run:

slmgr.vbs /dlv

Microsoft’s Slmgr.vbs options reference explains the command’s licensing details. Treat it as an activation-state check, not as a hardware certification check.

For a virtual KMS host, verify the guest’s TPM and Key Attestation support with the virtualization platform or service provider. A physical server’s TPM status does not prove that a virtual machine has the required capability. Likewise, a virtual TPM being visible does not establish that the underlying server model meets the catalog condition. Record both sides separately and confirm how Microsoft’s documented conditions apply to your deployment.

Current activation versus future requirements

The immediate operational question is whether your KMS service is currently functioning. Confirm which system is acting as the KMS host, check its activation details, and review the warning’s source and exact wording. If client systems report activation errors, investigate those errors using Microsoft’s general KMS troubleshooting guidance. Do not use the hardware readiness notice as a substitute diagnosis.

The longer-term question is whether a future Windows Server version will require hardware-trust conditions that your current host cannot meet. Microsoft’s current statement points to future versions, but does not give a specific release or enforcement date in the cited material. That leaves room to plan, not a basis for inventing a cutoff.

This distinction matters in several ways:

• No confirmed activation outage: An informational readiness status alone does not establish that current standard KMS activation has stopped.
• No automatic device replacement requirement: The notice does not, by itself, mean every client device or every server in the organization must be replaced.
• No guaranteed future compatibility: A host that works for current KMS activation may still fail to meet a later hardware requirement.
• No proof from partial checks: A successful licensing check does not verify TPM or catalog status; a TPM check does not prove catalog certification.

If the host is operating normally, document that fact and open a planned eligibility review. If activation errors are present, handle those as a separate service issue while recording the hardware readiness result. Microsoft’s documentation for creating a KMS activation host can help you confirm the host’s intended role and configuration, but it should not be read as proof that a particular machine satisfies hardware-security conditions.

Three update paths

Choose a path based on documented eligibility, service dependency, change risk, and your existing renewal schedule. Do not estimate remediation cost, outage duration, or performance gain without a site-specific assessment.

Use this decision tree:

• If current activation is failing, follow the activation troubleshooting path first; do not treat replacement as the default fix for a readiness message.
• If activation works and the host is confirmed eligible, keep the evidence and monitor Microsoft’s guidance; proceed with normal lifecycle planning.
• If activation works but eligibility is unknown, preserve the current state, check TPM and catalog evidence, and assign an owner to close the gap before the next hardware decision.
• If the host cannot meet or verify the required conditions, compare remediation with a planned replacement. If neither can be completed now, document the risk and review it against your change calendar rather than inventing a deadline.
• If the host is virtual, repeat the eligibility review for the guest and underlying platform instead of copying results from a physical host.

Operational verification sequence

Use this sequence to make the decision reproducible. It is designed for administrators who prefer graphical management but can also run PowerShell commands.

1. Identify the host and its role. Record the machine name, Windows Server version, whether it is physical or virtual, and which systems depend on it for KMS. In Server Manager, check the local server and installed roles; then compare that inventory with your KMS planning records. Microsoft’s KMS planning guide provides context for reviewing the deployment.

2. Capture the current activation evidence. Run slmgr.vbs /dlv in an elevated command prompt and save the output in your change record. Note any relevant activation errors and the time you observed them. The output helps establish the licensing state; it does not determine TPM or catalog eligibility.

3. Check the TPM without changing configuration. Open tpm.msc and record whether a TPM is detected and enabled. If the console does not show the expected state, ask the hardware or virtualization administrator to check the server’s firmware or platform configuration. Do not enable or clear a TPM as a diagnostic shortcut.

4. Check Key Attestation capability. Run Get-TpmSupportedFeature -FeatureType KeyAttestation in PowerShell and save the result. Interpret it against Microsoft’s command documentation and the KMS hardware-secured activation guidance. Do not treat an empty, unexpected, or unclear result as proof of either compliance or failure; investigate the host configuration.

5. Verify the exact hardware model. Search the model identifier in the Windows Server Catalog and retain the relevant listing or record that no matching listing was found. Avoid relying only on a server family name or a vendor’s broad statement about compatibility.

6. Separate physical and virtual evidence. For a virtual machine, obtain confirmation of the guest TPM and Key Attestation configuration from the platform owner. Then verify the underlying hardware separately. A physical machine’s result cannot be transferred to a guest without evidence.

7. Test any planned change away from production first. If you intend to change firmware, move the KMS role, or replace the host, document dependencies and validate the proposed change in a test environment where possible. Define a rollback route, identify who will verify activation afterward, and set a review date within your organization’s change process.

8. Keep a decision record. Store the warning text, command outputs, catalog lookup, activation observations, chosen path, owner, and next review date together. This prevents a later hardware purchase from being based on an old assumption that TPM support or certification was already confirmed.

KMS readiness questions

Could this warning mean that client activation has stopped?

Not on its own. The warning describes hardware readiness for the KMS host; Microsoft says the status is informational and does not itself alter current standard KMS activation. Confirm client and host activation separately. If you find actual activation errors, follow the relevant troubleshooting process rather than assuming that the readiness notice explains them.

Which checks show readiness rather than licensing status?

Use Microsoft’s KMS hardware-secured activation guidance for the readiness conditions, inspect TPM state through the management console or firmware, and check the exact server model in the Windows Server Catalog. slmgr.vbs /dlv records licensing details; it does not prove TPM support or catalog certification. The Key Attestation cmdlet is another capability check, not a complete compliance verdict.

Does every KMS host need a physical TPM?

Microsoft’s stated condition includes an enabled TPM 2.0, but a virtual deployment needs its own careful review. Verify the TPM and Key Attestation capabilities presented to the guest, and confirm the underlying server’s catalog status. Do not assume that a virtual TPM automatically satisfies all hardware requirements or that a physical host check proves the guest is eligible.

What should I do if the host cannot meet the conditions?

First determine whether the gap can be resolved on the existing server and whether the exact model has the required catalog listing. If it cannot be verified or corrected, compare a planned replacement with the organization’s renewal schedule and KMS dependency. Preserve current activation evidence and define a rollback plan before migrating the role. The cited Microsoft guidance does not specify a future enforcement date.

Server procurement checks

Before renting or buying a server for a KMS role, ask for verifiable information rather than inferring capability from the processor, operating system, or “dedicated” label:

• Which Windows Server versions are available, and which version will be installed?
• Does the specific physical server provide an enabled TPM 2.0?
• Can the service provider confirm Key Attestation capability for the planned host configuration?
• Is the exact server model listed in the Windows Server Catalog for the intended Windows Server use?
• If the system is virtual, what TPM and attestation capabilities are exposed to the guest, and what evidence supports that answer?
• What records will be available to you before deployment so you can validate the configuration?

The product information available for OSFP Cloud lists Windows Server 2019, 2022, and 2025 options, with English, Traditional Chinese, and Simplified Chinese language choices. It does not confirm TPM 2.0, Key Attestation, or Windows Server Catalog certification for a particular server. Those capabilities remain unconfirmed unless the relevant product page or written specification says otherwise. Check the current OSFP Cloud server information and its service scope and limitations; if the required evidence is not published, ask before placing an order rather than treating the server type or processor as proof.

A shared cloud instance can also leave physical hardware details and guest-level TPM capabilities dependent on the provider’s configuration. That may be suitable when the provider can document the exact conditions you need. If it cannot, compare the verification process—not assumed performance—against a dedicated physical server, and ask for model-specific evidence before deployment.

A dedicated AMD physical server is worth considering when you need a stable, directly identified host and can verify its hardware eligibility before migrating KMS. It is not a shortcut around TPM or certification checks: OSFP Cloud’s available information does not confirm those capabilities. Review the published Windows Server and hardware details, then contact OSFP Cloud to confirm any missing KMS requirement in writing before you choose the host.

Questions

Does the Windows Server 2025 KMS readiness warning mean activation has stopped?

No. Microsoft describes the readiness message introduced with the August 2026 cumulative update as informational. It reports whether a KMS host meets the stated hardware security conditions; it does not, by itself, disable current standard KMS activation. Check the host’s actual activation state and the source of the warning before treating it as an outage or planning an emergency replacement.

Where can I check the KMS hardware security readiness status?

Start with Microsoft’s KMS hardware-secured activation guidance, then record the host’s activation details with an elevated `slmgr.vbs /dlv` command. For Key Attestation capability, Microsoft documents `Get-TpmSupportedFeature -FeatureType KeyAttestation`. These checks serve different purposes: activation status does not prove hardware eligibility, so also inspect TPM state and the server’s catalog listing.

What hardware does a KMS host need for hardware-secured activation?

Microsoft’s stated conditions include an enabled TPM 2.0 and server hardware certified through the Windows Server Catalog. Confirm both for the actual host model and operating environment. If the KMS host is virtual, verify its TPM and Key Attestation support separately with the platform provider; a physical host’s results do not establish that a guest meets the requirements.

Should I replace a server that is marked as not ready?

Not solely because of the informational status. First confirm whether the host is eligible for remediation, how much your activation environment depends on it, and whether a change fits your approved maintenance plan. If hardware cannot meet the conditions or the server is already due for renewal, include replacement in that planned cycle. Microsoft has not specified a future enforcement date in the cited guidance.