Every authentication request a domain-joined device sends travels across the network, and an attacker positioned on that path does not need your password, just a weak enough cipher to ride along.
When a Windows device joins Active Directory, it establishes a secure channel with a domain controller to carry NETLOGON traffic such as pass-through authentication and SID lookups. This channel can be encrypted, but the strength of that encryption is negotiable unless an administrator locks it down.
Left to negotiate freely, a domain member can fall back to legacy 64-bit session keys, a cryptographic strength that predates modern attack tooling and offers little resistance to interception or replay.
The DomainMember_RequireStrongSessionKey setting removes that negotiation entirely. When enabled, Windows refuses to establish the secure channel unless 128-bit encryption is available, closing the door on weak fallback ciphers before the connection is even made.
Enforcing it through Microsoft Intune guarantees the same cryptographic floor on every managed endpoint, regardless of how the device was provisioned or which domain controller it happens to authenticate against.
The result is an environment where secure channel traffic between endpoints and domain controllers cannot be quietly downgraded, closing a persistent gap in the trust relationship that authentication depends on.
Why This Policy Matters
Attackers who compromise network position, whether through ARP spoofing, rogue DHCP, or a compromised switch, look for protocols that still support weak cryptography as an easy foothold. NETLOGON secure channel traffic has historically been one of those protocols.
Because the secure channel underpins how a device proves its identity to the domain, weakening it weakens the entire authentication chain that Active Directory and, by extension, conditional access and identity protection controls, rely on.
Without this policy:
- Domain members can silently negotiate down to 64-bit encryption, giving attackers a realistic path to decrypt or tamper with secure channel data
- Man-in-the-middle actors on the local network can intercept NETLOGON exchanges with far less computational effort
- Legacy domain controllers or misconfigured trusts go undetected until an actual compromise surfaces the weakness
- Security teams have no consistent baseline to point to when auditors ask how secure channel encryption is enforced
With this setting enforced through Intune:
- Every managed device requires 128-bit session key strength before establishing a secure channel, with no silent fallback
- The organization gains a measurable, auditable baseline for secure channel encryption across all endpoints
- Weak or outdated domain controllers are surfaced quickly because affected devices fail to authenticate, rather than silently downgrading
- The control reinforces the broader identity protection stack, including Microsoft Defender for Identity's ability to detect anomalous NETLOGON behavior
This configuration aligns with modern security principles such as defense in depth, endpoint hardening, proactive threat detection, and Zero Trust architecture.
Security Governance
Security governance ensures that hardening controls are consistently applied, monitored, and aligned with organizational standards.
Without centralized governance, settings such as this one can drift across devices, leaving blind spots that attackers can exploit.
Managing the Domain member: Require strong (Windows 2000 or later) session key setting through Microsoft Intune brings several governance benefits:
- Centralized enforcement of the control across all managed Windows endpoints
- Consistent configuration aligned with corporate security baselines
- Clear visibility into deployment status and configuration compliance
- Defined ownership and accountability through scope tags and role-based administration
- An auditable policy lifecycle from creation to enforcement and validation
This level of governance ensures that the control is handled in a controlled and transparent manner, reinforcing compliance with internal security policies and regulatory frameworks.
Windows CSP Overview
This section explains how the setting is exposed at the operating system level and how Microsoft Intune interacts with it. The configuration is powered by the Windows Policy Configuration Service Provider (CSP) framework, specifically the LocalPoliciesSecurityOptions area.
| Scope | Editions | Applicable OS |
|---|---|---|
| ✅ Device ❌ User | ✅ Pro ✅ Enterprise ✅ Education ✅ IoT Enterprise / IoT Enterprise LTSC | ✅ Windows 11, version 22H2 with KB5053657 [10.0.22621.5126] and later; Windows 11, version 24H2 [10.0.26100] and later |
Domain member: Require strong (Windows 2000 or later) session key This security setting determines whether 128-bit key strength is required for encrypted secure channel data. When a computer joins a domain, a computer account is created. After that, when the system starts, it uses the computer account password to create a secure channel with a domain controller within the domain. This secure channel is used to perform operations such as NTLM pass-through authentication, LSA SID/name Lookup, and so on. Depending on what version of Windows is running on the domain controller that the domain member is communicating with and the settings of the parameters: Domain member: Digitally encrypt or sign secure channel data (always) Domain member: Digitally encrypt secure channel data (when possible) Some or all of the information that's transmitted over the secure channel will be encrypted. This policy setting determines whether or not 128-bit key strength is required for the secure channel information that's encrypted.
If this setting is enabled, then the secure channel won't be established unless 128-bit encryption can be performed.
If this setting is disabled, then the key strength is negotiated with the domain controller. Important In order to take advantage of this policy on member workstations and servers, all domain controllers that constitute the member's domain must be running Windows 2000 or later. In order to take advantage of this policy on domain controllers, all domain controllers in the same domain as well as all trusted domains must run Windows 2000 or later.
In order to take advantage of this policy on member workstations and servers, all domain controllers that constitute the member's domain must be running Windows 2000 or later. In order to take advantage of this policy on domain controllers, all domain controllers in the same domain as well as all trusted domains must run Windows 2000 or later.
Description Framework Properties
This section defines how the configuration behaves at a technical level within the CSP framework.
| Property name | Property value |
|---|---|
| Format | int |
| Access Type | Add, Delete, Get, Replace |
| Allowed Values | Range: [0-1] |
| Default Value | 1 |
Group Policy Mapping
For organizations operating in hybrid environments, this CSP setting maps to a corresponding Group Policy configuration.
| Name | Value |
|---|---|
| Name | Domain member: Require strong (Windows 2000 or later) session key |
| Friendly Name | Domain member: Require strong (Windows 2000 or later) session key |
| Location | Windows Settings > Security Settings > Local Policies > Security Options |
| Path | Windows Settings > Security Settings > Local Policies > Security Options |
Security Considerations
Before enabling this policy, administrators should understand how it behaves and plan for its impact.
- All domain controllers servicing the affected devices, including those in trusted domains, must support 128-bit secure channel encryption or authentication attempts will fail outright
- Legacy or unpatched domain controllers still running very old operating systems can cause secure channel establishment failures once this setting is enforced
- The setting applies at the device level and requires the target device to be domain-joined; it has no effect on non-domain-joined or Microsoft Entra joined only devices
- Changes take effect after the device reprocesses its secure channel session, so a restart or the next scheduled netlogon cycle may be required to confirm enforcement
A phased, pilot-first deployment is recommended to validate the behavior in a controlled group and avoid unexpected impact before rolling the setting out across production devices.
How to Configure Domain Member: Require Strong Session Key Using Intune (Settings Catalog)
You can enforce this policy centrally using the Intune Settings Catalog, ensuring that only 128-bit encrypted secure channel connections are accepted is applied consistently across all managed Windows devices.
To begin, sign in to the Microsoft Intune admin center and follow the steps below, as illustrated in the screenshots.
Create the Configuration Profile
In the Microsoft Intune admin center:
- Navigate to Devices › Windows › Configuration
- Select + Create policy
In the Create a profile pane:
- Platform: Windows 10 and later
- Profile type: Settings catalog
Click Create to continue.
At this stage, you have created the foundation of a Settings Catalog policy. In the next steps, you will search for and configure the setting that enforces strong session key encryption on secure channel traffic.
Define Basic Profile Details
After clicking Create, the next step is to define the basic details of the configuration profile. This stage is essential for long-term management, clarity, and governance within Microsoft Intune, especially in environments with multiple endpoint hardening policies and security baselines.
Providing a clear Name and a concise but meaningful Description ensures that the purpose of the policy is immediately understood by administrators and security teams in the future. As shown in the screenshot, configure the fields as follows.
The Platform field is already pre-selected as Windows, so no changes are required. Once the name and description are defined, click Next to proceed to the configuration settings.
Configure the Setting Using the Settings Picker
With the profile basics defined, the next step is to configure the policy using the Settings picker, where you select the exact Windows setting you want to enforce. To open the Settings picker panel, click Add settings.
By default, this setting is enabled on modern Windows editions, but relying on the built-in default leaves the behavior unmanaged and unverifiable across the fleet, which is why explicit enforcement through Intune is recommended.
In the search field at the top of the Settings picker, type Session Key, and then click Search to filter the results.
From the returned results, select the category Local Policies Security Options, and then choose the setting Domain Member Require Strong Session Key. Once selected, the setting is automatically added to the configuration profile. Back on the configuration page, change the value from its default state to Enabled.
When enabled, Windows refuses to establish a secure channel with a domain controller unless 128-bit key strength can be negotiated. This ensures that:
- Secure channel data cannot be transmitted using legacy 64-bit encryption
- Weak or outdated domain controllers are surfaced through authentication failures rather than silent downgrades
- NETLOGON traffic retains a consistent, verifiable cryptographic floor across every managed device
This configuration aligns with modern endpoint hardening practices and supports Zero Trust security principles.
Configure Scope Tags (Optional)
Scope tags are used to control who can view and manage this policy within the Microsoft Intune admin center. They are particularly useful in environments with delegated administration, multiple IT teams, or regional management models.
As shown in the screenshot, the Default scope tag is selected. This is the standard and recommended configuration for most environments, as it ensures the policy is visible to all administrators who have access to Intune.
Optionally, custom scope tags can be assigned if you need to:
- Restrict policy visibility to specific IT roles or teams
- Enforce administrative separation of duties
- Support delegated or region-based Intune management
If no additional scope tags are required, keep the Default selection and click Next to continue.
Assignments – Secure Channel Encryption Baseline
After configuring the policy settings, the next step is to assign the policy to the appropriate target group. Assignments define which devices will receive and enforce this configuration, ensuring the policy is applied in a controlled and intentional manner.
In the Assignments tab, click Add groups under Included groups and search for the group you want to target. This approach allows you to deploy the policy gradually, starting with test devices before expanding to production.
As shown in the screenshot, the policy is assigned to the following group: GRP – MS365Education – Test Computers.
Once the group is selected, verify the following:
- The group appears under Included groups
- The group status is Active
- No assignment filters are applied (unless explicitly required)
At this stage, no Excluded groups are configured, which is appropriate for controlled test deployments.
After confirming the assignment, click Next to proceed to the Review + Create step.
Review + Create – Final Validation
The Review + Create step is the final checkpoint before deploying the policy. This is where you validate that all configurations are correct and aligned with your intended endpoint hardening objective.
Pay special attention to the following items:
- Policy name and description: confirm that the policy clearly reflects its purpose, enforcing 128-bit secure channel encryption on domain-joined devices
- Configuration settings: verify that Domain member: Require strong (Windows 2000 or later) session key is set to Enabled, under Local Policies Security Options
- Scope tags: ensure the correct scope tag is assigned. In this example, the Default scope tag is used
- Assignments: confirm the policy is assigned to the intended group, GRP – MS365Education – Test Computers, and that no unintended exclusions are configured
Once everything has been validated, click Create to finalize and deploy the policy to the assigned devices.
Monitor Policy Deployment Status
After creating and assigning the WIN – Endpoint Hardening – Secure Channel Encryption configuration profile, the next step is to verify its deployment status. This validation confirms that the policy has been successfully applied and that secure channel connections now require 128-bit encryption on the targeted devices.
Although Microsoft Intune can take up to 8 hours to automatically deliver configuration profiles, deployment often occurs much faster. If needed, you can accelerate the process by:
- Triggering a manual device sync from the Company Portal
- Initiating a sync directly from the Microsoft Intune admin center
Intune provides clear indicators to evaluate the policy deployment status: Succeeded (devices have applied the policy), In progress (devices are still processing), Error (the policy failed and requires investigation), and Not applicable (the device does not support the configuration).
When devices report Succeeded, it confirms that the strong session key requirement is active, ensuring that secure channel negotiation with domain controllers can no longer fall back to weak encryption.
Client-Side Verification via Event Viewer
After the device has synced with Intune, you can perform a client-side verification to confirm that the policy was successfully applied. Windows records Intune policy processing events locally, allowing administrators to confirm policy enforcement without relying only on the Intune portal.
- Open Event Viewer on the target device
- Navigate to Applications and Services Logs › Microsoft › Windows › DeviceManagement-Enterprise-Diagnostics-Provider › Admin
- Select Filter Current Log
- Look for Event ID 813 or Event ID 814, which indicate successful processing of Intune configuration policies
- Open the event details and confirm that the LocalPoliciesSecurityOptions setting was applied
For deeper validation, you can confirm the effective setting directly on the device. Open the Local Security Policy console (secpol.msc), navigate to Local Policies > Security Options, and confirm that "Domain member: Require strong (Windows 2000 or later) session key" is set to Enabled.
Keep in mind that all domain controllers servicing this device must support 128-bit secure channel encryption, otherwise authentication attempts will fail until the domain infrastructure is aligned with this requirement.
Why This Matters for Endpoint Security
The trust relationship between a device and its domain is one of the most privileged, and least visible, channels in an enterprise network, which makes it an attractive target for lateral movement and credential theft.
Without an explicit encryption floor, that trust relationship can quietly degrade to weaker ciphers, leaving a blind spot that neither users nor most monitoring tools notice until an incident forces the question.
By enforcing Domain member: Require strong (Windows 2000 or later) session key through Microsoft Intune and validating the configuration locally, organizations ensure that:
- Secure channel traffic between endpoints and domain controllers maintains a consistent, strong cryptographic baseline
- Legacy domain infrastructure gaps are surfaced proactively instead of being discovered during an incident
- The identity trust chain that Defender for Identity and conditional access policies rely on remains intact
- Compliance and audit teams have a verifiable, centrally enforced control to point to for NETLOGON encryption requirements
This configuration provides strong security value without disrupting standard user workflows when properly validated and deployed.
Key Takeaway
A domain trust relationship is only as strong as the weakest cipher it is allowed to negotiate.
Enforcing this setting through Microsoft Intune removes that negotiation entirely, applying the same 128-bit encryption floor to every managed endpoint the moment it authenticates.
Combined with centralized deployment and client-side validation, the organization gains a measurable, auditable control over one of its most privileged and least visible communication channels.
And in modern security architecture, strong secure channel encryption is not optional, it is essential.
More Information
For additional technical details, refer to the official Microsoft documentation below:
- https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-localpoliciessecurityoptions#domainmember-requirestrongsessionkey
- https://learn.microsoft.com/en-us/mem/intune/configuration/settings-catalog
- https://learn.microsoft.com/en-us/mem/intune/configuration/device-profiles
- https://learn.microsoft.com/en-us/mem/intune/configuration/device-profile-monitor
- https://learn.microsoft.com/en-us/mem/intune/configuration/device-profile-troubleshoot
Thank you for reading!
🖥️ Ricardo Barbosa
🏆️ Microsoft MVP | 📘 Microsoft Certified Trainer (MCT)
☁️ Intune & Cloud Architect | 💼 Technology Director at Altelix.com
💬 Follow me for more Windows endpoint hardening and Intune content.