In modern endpoint security, what you block is often more important than what you allow. One commonly overlooked risk in Windows environments is anonymous (null session) access to system resources.
Historically, Windows allowed certain shared resources and named pipes to be accessed without authentication. While this behavior had valid use cases years ago, it no longer aligns with today’s security standards or threat landscape.
Anonymous access can be abused by attackers during reconnaissance to enumerate system information, discover network shares, identify services, and map environments without ever providing valid credentials. This makes it a powerful entry point for lateral movement and privilege escalation attempts.
With Microsoft Intune, organizations can enforce strict controls that limit anonymous access by design, ensuring only explicitly approved resources are accessible and everything else is denied.
This policy works silently at the system level, remaining enforced across reboots and user sessions. Since this behavior is already the default posture in modern Windows versions, enabling it does not disrupt user productivity or business applications.
Users continue working normally, while the operating system quietly blocks unnecessary and potentially dangerous anonymous connections.
Why This Policy Matters
Restricting anonymous access is a foundational control that supports least privilege, Zero Trust, and defense-in-depth strategies.
By enforcing this policy, organizations gain:
Reduced attack surface by blocking unauthenticated enumeration
Stronger network hygiene without impacting legitimate users
Better resistance to reconnaissance and lateral movement
Consistent security behavior across all managed devices
Improved alignment with security baselines and compliance frameworks
This is a simple yet highly effective control that removes a common attacker technique without adding operational complexity.
Why Restricting Anonymous Access Improves Security Governance
This policy isn’t about breaking legacy behavior it’s about modern security governance.
In a well-managed environment, system resources such as named pipes and administrative shares should never be exposed to unauthenticated access. These decisions must be intentional, centralized, and enforced by policy.
By enabling this setting:
Anonymous users are blocked from accessing sensitive system resources
Attackers lose a common reconnaissance vector
Security ownership remains clearly with IT and security teams
The risk of misconfiguration and information leakage is significantly reduced
This aligns directly with Zero Trust principles, where access is never assumed and exposure is minimized by default.
Windows CSP Overview
This policy is enforced at the device level, ensuring consistent behavior regardless of which user signs in. Once applied, it remains active across reboots and user sessions.
It applies to the following Windows editions:
Windows 10 Pro
Enterprise
Education
IoT Enterprise / IoT Enterprise LTSC
The setting is supported on Windows 10 version 1803 and later, including Windows 11, making it suitable for modern Intune-managed environments.
Using this CSP, administrators can centrally define how anonymous access behaves across all endpoints, without relying on user awareness or manual configuration.
Policy Properties
The configuration framework uses a simple and reliable structure:
Format: Integer (int)
Access Type: Add, Delete, Get, Replace
Default Value: 1 (Enabled)
This allows the policy to be deployed, updated, or replaced consistently using Intune configuration profiles.
Allowed Values Explained
The policy supports two values:
1 (Default – Enabled) Restricts anonymous access to named pipes and shares. Only explicitly allowed resources can be accessed anonymously.
0 (Disabled) Allows broader anonymous access, which is not recommended in secure or managed environments.
Keeping this setting enabled enforces a least-access-by-default model that significantly reduces risk with no user impact.
Group Policy Mapping (For Reference)
For environments that still use Group Policy or hybrid management models, this Intune CSP maps directly to:
Policy name: Network access: Restrict anonymous access to Named Pipes and Shares
Location: Windows Settings > Security Settings > Local Policies > Security Options
This makes the control easy to audit and align across both modern and legacy management approaches.
How to Configure Restrict Anonymous Access Using Intune (Settings Catalog)
You can enforce this policy centrally using the Intune Settings Catalog, ensuring consistent deployment across all Windows devices.
To begin, sign in to the Microsoft Intune admin center and follow the steps below, as illustrated in the screenshot.
Create the Configuration Profile
In the Microsoft Intune admin center, navigate to Devices
Select Windows
Click 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 point, you’ve created the foundation of a Settings Catalog policy. In the next steps, you will locate and configure the setting that controls anonymous access to named pipes and shares, ensuring it is enforced consistently across all managed devices.
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 security baselines and configuration profiles.
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:
Suggested Name and Description
Name Enforce Least Privilege – Restrict Anonymous Access
Description This policy restricts anonymous (null session) access to Windows system resources such as shared folders and named pipes. It enforces least privilege by preventing unauthenticated users from enumerating system information, reducing the attack surface and strengthening the security posture of managed Windows devices.
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 security setting to enforce.
Click Add settings to open the Settings picker panel.
By default, this setting is not configured and effectively behaves as Disabled, meaning anonymous (null session) access is not explicitly restricted by this policy unless you enable it.
As shown in the screenshot, use the search field at the top of the Settings picker and type:
Network access Restrict anonymous access to named pipes and shares
Then click Search to filter the results.
From the returned results:
Select the Local Policies Security Options category
Choose the setting Network access: Restrict anonymous access to named pipes and shares
Once selected, the setting is added to the configuration profile. Back on the configuration page, change the value from its default state to Enable.
When enabled, Windows restricts anonymous access to named pipes and shares, allowing only explicitly permitted resources. This enforces a least-privilege model and prevents unauthenticated enumeration of system resources.
This configuration aligns with modern security baselines and Zero Trust principles, ensuring the control is enforced consistently across all managed devices through Intune.
After configuring the setting, click Next to continue with the profile deployment steps.
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 – Restrict Anonymous Access Policy
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 security outcome.
Pay special attention to the following items:
Policy name and description Confirm the policy clearly reflects its purpose: enforcing least privilege by restricting anonymous access.
Configuration settings Verify that Network access: Restrict anonymous access to named pipes and shares is set to Enabled.
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.
This final review step helps prevent misconfigurations, unintended deployments, or scope issues especially in environments with multiple policies and delegated administration.
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 Enforce Least Privilege – Restrict Anonymous Access configuration profile, the next critical step is to monitor its deployment status. This verification ensures that the policy has been successfully applied and is actively enforcing anonymous access restrictions on the targeted devices.
Although Microsoft Intune can take up to 8 hours to automatically deliver configuration profiles, deployment can often occur much faster. If needed, you can accelerate the process by:
Manually triggering a device sync from the Company Portal
Forcing a sync directly from the Microsoft Intune admin center
How to Verify Policy Deployment Status
To review the deployment results:
In the Microsoft Intune admin center, navigate to: Devices ➝ Configuration profiles
Use the search bar to locate the profile: Enforce Least Privilege – Restrict Anonymous Access
Select the policy to open the Overview page.
Review Deployment Metrics
As shown in the screenshot, Intune provides clear deployment indicators:
Succeeded – Devices have successfully applied the policy
In progress – Devices are still processing or have not checked in yet
Error – The policy failed to apply and requires investigation
Not applicable – The device does not support this setting
In this example, all targeted devices report Succeeded, confirming that the restriction on anonymous access to named pipes and shares is now fully enforced.
Why This Validation Matters
Monitoring deployment status ensures that:
Least privilege controls are actively enforced
Anonymous access paths are closed as intended
There are no silent failures or unsupported devices
Your security baseline remains consistent across managed endpoints
This final validation step closes the loop on the policy lifecycle from design and deployment to enforcement and verification reinforcing a secure, predictable, and governed endpoint environment.
Client-Side Verification via Event Viewer
After the device has synced with Intune, you can perform a client-side verification to confirm that the Enforce Least Privilege – Restrict Anonymous Access policy was successfully applied. This validation is especially useful for troubleshooting and for ensuring the restriction is actively enforced at the operating system level.
Windows records Intune policy processing events locally, allowing administrators to verify enforcement without relying solely on portal reporting.
How to Verify
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 policy “Network access: Restrict anonymous access to named pipes and shares” was applied successfully
Pro Tip: Match the event timestamp with the device’s most recent Intune sync. Event IDs 813 and 814 are the most reliable indicators that the policy was evaluated and enforced by the MDM engine.
Why This Validation Matters
Restricting anonymous access is a foundational security control. Attackers frequently leverage null sessions to enumerate shares, named pipes, user accounts, and system information during reconnaissance and lateral movement phases.
By enforcing this restriction through Intune and validating it locally, organizations ensure that:
Anonymous enumeration paths are closed
System information exposure is minimized
Legacy attack techniques are neutralized
Least privilege is enforced at the OS level
Key Takeaway
Security hardening doesn’t always require complex tooling. Small, well-placed configurations can dramatically reduce risk.
By enforcing anonymous access restrictions via Intune, you remove a long-standing attack vector that is still actively abused in modern environments. Combined with centralized deployment and reliable verification, this policy strengthens your endpoint security posture with minimal operational impact.
More Information
For additional technical details, official documentation, and deeper insights into this policy and related Microsoft Intune concepts, refer to the Microsoft Learn resources below:
Policy CSP – Local Policies Security Options Official reference for Windows security options exposed through MDM, including anonymous access restrictions and their supported values. https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-localpoliciessecurityoptions
Create a Settings Catalog Policy in Microsoft Intune Step-by-step guidance on creating and managing Settings Catalog policies for Windows devices. https://learn.microsoft.com/en-us/mem/intune/configuration/settings-catalog
Device Configuration Profiles in Intune Overview of how configuration profiles work and how they are applied across managed devices. https://learn.microsoft.com/en-us/mem/intune/configuration/device-profiles
Monitor Intune Policy Deployment and Troubleshoot Profiles Learn how to monitor deployment status, interpret errors, and troubleshoot configuration issues. https://learn.microsoft.com/en-us/mem/intune/configuration/device-profile-troubleshoot
Event Viewer Logs for MDM and Intune Diagnostics Detailed explanation of client-side Event Viewer logs used to validate Intune policy processing and enforcement. https://learn.microsoft.com/en-us/mem/intune/configuration/device-profile-troubleshoot#event-viewer-logs
Thank you!
🖥️ Ricardo Barbosa
🎖️ Microsoft MVP | 📘 Microsoft Certified Trainer (MCT)
☁️ Intune & Cloud Architect |💼 Technology Director at Altelix.com