After installing the February 2026 Windows update, the Defender setting IntelTDTEnabled suddenly stops working. Intune reports the familiar 65000 error, while the device logs reveal the real cause: 0x86000002 (specific node does NOT exist), meaning the CSP node is no longer supported. What looks like a normal policy failure turns out to be a configuration endpoint that quietly disappeared from Windows.
Introduction
For a long time, Intel Threat Detection Technology (Intel TDT) was one of those interesting features sitting quietly in the background of Microsoft Defender. It promised hardware-assisted threat detection using CPU telemetry, something that sounded both powerful and slightly mysterious.
In practice, it mostly stayed invisible unless you went looking for it. Recently that changed…. Just a bit…While investigating Defender configuration behavior, something unexpected surfaced: the Intune Policy used to control Intel TDT suddenly stopped working after the February 2026 Windows update. At first glance, it looked like a normal Intune policy failure. After digging deeper, it became clear that something more fundamental had changed. Before looking at the 0x86000002 failure, it helps to understand what Intel TDT actually is.
What Intel Threat Detection (Intel TDT) Technology Does
Intel TDT is a hardware-assisted detection capability built into certain Intel CPUs. Instead of relying purely on software signals, Defender can use CPU performance telemetry to detect suspicious behavior patterns. Typical examples include cryptomining workloads or encryption patterns associated with ransomware.
The idea is simple: malicious activity often produces very specific CPU instruction patterns. Intel exposes those patterns through hardware telemetry, and Defender can analyze them with machine learning models. When supported hardware is present, Defender can use this signal alongside its normal protection layers, such as behavioral monitoring, cloud intelligence, and attack surface reduction. In most environments, this feature does not require manual configuration. When supported hardware is present and Defender is running, the Intel TDT integration activates automatically.
However, Windows also exposed a configuration switch that allows administrators to explicitly enable or disable the feature.
The Intune Policy That Used to Control Intel TDT
Administrators had two main ways to control the feature. The first was a local PowerShell configuration through Defender preferences: Set-MpPreference -IntelTDTEnabled 1
The second was through the Defender MDM configuration CSP (Settings Catalog) used by Intune: ./Device/Vendor/MSFT/Defender/Configuration/IntelTDTEnabled

When configured through Intune, the policy was successfully applied via SyncML through the Defender CSP provider.
The node mapped to the Defender preference model behind the scenes and enabled the hardware telemetry integration.

Which we could also spot in the registry as well

For a long time, this Defender Intel TDT policy worked exactly as expected.
The Policy Works… Until the February 2026 Update (0x86000002)
On systems running Windows 11 24H2 before the February cumulative update, the configuration behaves normally. The policy applies successfully, and Defender accepts the configuration. The PowerShell command works as expected, and the CSP node is visible and writable. After installing the 2026-02 Windows update, something has changed. Running the same PowerShell command now produces a warning:
IntelTDTEnabled has been deprecated; this operation will perform no action. At the same time, Intune deployments start failing with the well-known error 65000.
Normally, that error could be associated with licensing issues (or any other error that Microsoft didn’t map to a proper error code). In this case, it is not. The real error becomes visible when looking at the DeviceManagement event logs.
The Actual 0x86000002 Error Behind Intune’s 65000
Inside the DeviceManagement-Enterprise-Diagnostics-Provider log, the event shows the real failure.
Command failure status:
CSP Name: Defender
Command Type: Add
CSP URI: ./Device/Vendor/MSFT/Defender/Configuration/IntelTDTEnabled
Result: Unknown Win32 Error code: 0x86000002
This code originates from the Windows MDM stack and means that the requested node is doesn’t exist and is not supported anymore. In other words, Windows is rejecting the request before it ever reaches the Defender engine.
Testing the CSP Directly
To remove Intune from the equation, the next step was to test the configuration directly through SyncML. Using the local SyncML testing tool, we queried the configuration CSP defender node to find out if the IntelTDT was indeed gone
As shown above, the whole IntelTDT node was gone with the wind. When performing the same steps on a pre 2026-02 build, the Intel TDT node was still there:
At this point, it was clear that Intune was not the problem. The Intel TDT node itself was being rejected by the Windows MDM stack.
Recreating the Node Manually also got 0x8600002
Just to be certain, the next attempt was to manually add the IntelTDT node and apply the configuration again per the Defender CSP policy.
The result was identical to that of Intune. The request failed immediately with the same 0x86000002 error code. If the issue had been caused by missing configuration data or corrupted policy state, recreating the node should have restored the functionality. Instead, the result remained unchanged. Even when manually creating the node, Windows still rejects the request. The node simply no longer exists as a valid configuration endpoint.
Missing Documentation and No Warning in Intune
One thing that makes this change particularly confusing is that there is currently no documentation describing this behavior. (Please Note: I reached out to MSFT: They are aware of the issue)
The Microsoft Defender CSP documentation still lists the following configuration node: ./Device/Vendor/MSFT/Defender/Configuration/IntelTDTEnabled. Nothing in the documentation indicates that the setting has been deprecated or removed. From the documentation alone, administrators would assume the policy is still valid and supported.
However, systems updated with the February 2026 Windows update reject the node completely. Any attempt to configure it through Intune results in the well-known 65000 error. Looking at the device logs reveals the real failure: 0x86000002. This error originates from the Windows MDM stack and means the node is no longer supported by the operating system. At the same time, the Intune portal itself also provides no indication that the feature has been deprecated. So, Microsoft, maybe adding this to start with?

Because the policy can still be configured and assigned. The only visible symptom is the device’s deployment failure. From an administrator’s perspective, this creates an awkward situation:
| What the documentation says | What Windows actually does |
| IntelTDTEnabled is a supported Defender CSP node | Windows rejects the node |
| Policy appears configurable in Intune | Deployment fails |
| No deprecation notice | Error 65000 and 0x86000002 |
Without checking the device logs or testing the CSP directly, it is easy to assume something is wrong with the configuration or the device. In reality, the configuration endpoint itself appears to have been removed or deprecated, while the documentation and management tools have not yet been updated to reflect that change.
Is Intel TDT Deprecated or Just the Policy?
One interesting detail is that the default value for IntelTDTEnabled now appears to be False.

Attempts to enable it through PowerShell return a deprecation warning while the Defender CSP fails with error 0x86000002. At first glance, that could suggest the Intel TDT integration itself has been removed. However, there is currently no public documentation from Microsoft or Intel confirming that Intel Threat Detection Technology has been deprecated. What the evidence shows is that the administrator-controlled setting for Intel TDT is no longer functional. In other words, the configuration interface seems to be deprecated, while the underlying hardware capability may still exist and could be managed internally by Microsoft Defender rather than through an exposed policy setting.
0x86000002 Summary
After the February 2026 Windows update, the Defender CSP node IntelTDTEnabled stops working. Intune deployments start failing with error 65000, while the device logs reveal the real cause: 0x86000002, indicating the node is no longer supported. The setting also shows as deprecated when using Set-MpPreference.
The confusing part is that the documentation still lists the node as supported, and Intune still allows the policy to be configured. The result is a policy that appears valid but can no longer be applied because the CSP node has quietly disappeared from Windows.