Exploring Microsoft Intune Tenant Lockdown policy

How do you ensure a reset device returns to your organization instead of becoming a personal device?

In enterprise environments, maintaining control over devices throughout their lifecycle is a critical concern. The TenantLockdown Configuration Service Provider (CSP) addresses this challenge by forcing Windows devices to connect to a network during OOBE (Out-of-Box Experience) after a reset - preventing users from skipping network connectivity.

What is Tenant Lockdown?

Tenant Lockdown is a feature (powered by the TenantLockdown Configuration Service Provider) that forces devices to connect to a network during the Out-of-Box Experience (OOBE) after a reset. By requiring network connectivity, it ensures devices cannot skip the network step during OOBE - but it does not by itself prevent users from selecting “Setup for personal use” or creating local accounts. For full protection, TenantLockdown should be combined with Windows Autopilot device registration.

The name “Tenant Lockdown” is somewhat misleading - it suggests the feature locks a device to a specific tenant, but in reality it only ensures network connectivity during OOBE. A more accurate name might be “RequireNetworkInOOBE” (which is actually the name of the underlying setting). The tenant binding only happens when combined with Windows Autopilot device registration.

Image viewer

Key characteristics of Tenant Lockdown:

• Network enforcement: Requires devices to connect to a network during OOBE before proceeding - removes the “Skip for now” option for network.
• Reset protection: Prevents devices from completing OOBE offline after a reset.
• Requires Windows Autopilot for full protection: TenantLockdown alone does not hide “Setup for personal use” or bind the device to your tenant. Combine with Windows Autopilot device registration for complete protection.
• Limited theft deterrent: Reduces the value of stolen devices when combined with Windows Autopilot, but can be bypassed by reinstalling Windows from external media. See Complementary protections for ways to address this limitation.

Why Tenant Lockdown matters

Without Tenant Lockdown, a user who resets a managed device could skip the network connection during OOBE entirely and complete device setup offline - no enrollment, no policies, no organizational control. I have seen this happen in practice: a user resets a managed laptop, skips the network step, creates a local account, and the device effectively disappears from management. If the device is also registered with Windows Autopilot, combining it with TenantLockdown closes this gap - the device connects to the network, recognizes the Windows Autopilot registration, and re-enrolls automatically.

Understanding RequireNetworkInOOBE

The TenantLockdown CSP has a single but powerful setting: RequireNetworkInOOBE.

./Vendor/MSFT/TenantLockdown/RequireNetworkInOOBE

Setting details

When RequireNetworkInOOBE is set to True:

• Users must connect to a network during OOBE before proceeding
• There is no “Skip for now” option for network connectivity

Supported Windows Editions

Tenant Lockdown is available on the following Windows editions:

Configuring Tenant Lockdown in Microsoft Intune

There are multiple ways to configure Tenant Lockdown in Microsoft Intune:

Option 1: Using Settings Catalog

1. Sign in to the Microsoft Intune admin center .
2. Navigate to Devices > Configuration profiles > Create profile.
3. Select Windows 10 and later as the platform.
4. Choose Settings catalog as the profile type.
5. Select Create.
6. Enter a descriptive name for the profile (e.g., “Windows - Tenant Lockdown Policy”).
7. Select Next and then Add settings.
8. Search for Tenant Lockdown in the settings picker.
9. Select the Tenant Lockdown category and add:
   • Require Network In OOBE: Set to True
10. Select Next and assign the profile to the appropriate device groups.
11. Review and create the profile.

Option 2: Using Custom OMA-URI Profile

1. Sign in to the Microsoft Intune admin center .
2. Navigate to Devices > Configuration profiles > Create profile.
3. Select Windows 10 and later as the platform.
4. Choose Templates > Custom as the profile type.
5. Select Create.
6. Enter a descriptive name (e.g., “Windows - Tenant Lockdown OMA-URI”).
7. Select Next and then Add to create a new OMA-URI setting.
8. Configure the following:
   • Name: Require Network In OOBE
   • Description: Requires network connectivity during OOBE after device reset
   • OMA-URI: ./Vendor/MSFT/TenantLockdown/RequireNetworkInOOBE
   • Data type: Boolean
   • Value: True
9. Select Save, then Next.
10. Assign the profile to appropriate device groups.
11. Review and create the profile.

Benefits of Tenant Lockdown

The value of Tenant Lockdown depends on whether you combine it with Windows Autopilot device registration. On its own, TenantLockdown enforces network connectivity during OOBE - useful, but limited. When paired with Windows Autopilot, the benefits multiply significantly:

• Automated re-enrollment: Devices that connect to the network during OOBE are recognized by the Windows Autopilot service and re-enroll with your organization automatically - no manual intervention required.
• Simplified device recovery: Returned or recovered devices reconnect to your tenant without IT involvement.
• Theft deterrent: The combination of forced network connectivity and Windows Autopilot registration makes stolen devices difficult to repurpose, reducing their value.
• Audit trail maintenance: Devices remain tracked within your management infrastructure, supporting compliance and governance requirements.
• Data protection: Prevents unauthorized access to potentially cached sensitive data by ensuring devices re-enroll and receive policies.

Limitations of Tenant Lockdown

It’s important to understand that Tenant Lockdown is a software-based protection, not a hardware-backed solution like Apple’s Activation Lock. This means there are scenarios where the protection can be bypassed.

Physical devices vs. virtual devices

Tenant Lockdown is designed for physical devices and may not be applicable or beneficial for virtual environments:

Software-based protection limitations

RequireNetworkInOOBE is stored in the MDM policy store, which lives inside the Windows installation itself. Think of it as “a setting stored inside Windows, not on the device.” When Windows is removed, the setting is removed with it. There is no firmware-level persistence for this setting.

Why TenantLockdown still provides value

Despite these limitations, TenantLockdown remains valuable because:

• Technical barrier: Most users lack the knowledge or tools to perform a clean Windows installation from external media.
• Data loss: A fresh installation completely wipes all data, which may deter some attackers.
• Deterrent effect: The effort required reduces the attractiveness of stealing devices.
• Casual bypass prevention: Prevents the most common bypass attempts (simple resets).

Complementary protections

For TenantLockdown to provide meaningful protection against determined attackers, you must combine it with firmware-level controls that prevent booting from external media:

• UEFI/BIOS password: Prevents changing boot order or booting from external media without authorization. This is essential - without it, TenantLockdown can be trivially bypassed.
• Disable external boot devices: Configure UEFI to prevent booting from USB, DVD, or network sources.
• Secure Boot: Helps ensure only trusted software runs during startup.
• BitLocker encryption: Protects data even if the device is stolen or reinstalled.
• Windows Autopilot device registration: Devices registered with Windows Autopilot will still be recognized by Microsoft and prompted to enroll even after a fresh install. The hardware hash is stored in the Windows Autopilot service, providing a hardware-level binding that persists across OS reinstalls.

Drawbacks and considerations

Tenant Lockdown is straightforward to deploy, but there are practical considerations to plan for:

How to release a device from Tenant Lockdown

There are situations where you need to release a device from TenantLockdown, such as device disposal, resale, or tenant migration. Here’s how to do it:

Method 1: Disable RequireNetworkInOOBE via policy

Before resetting or retiring a device, disable the TenantLockdown setting:

1. In the Microsoft Intune admin center , navigate to your TenantLockdown configuration profile.
2. Edit the profile and set Require Network In OOBE to False.
3. Deploy the updated policy to the target devices.
4. Wait for the policy to sync to the device.
5. The device can now be reset without enforcing network connection during OOBE.

Method 2: Using Custom OMA-URI

To disable TenantLockdown via OMA-URI:

1. Create or modify a custom configuration profile.
2. Configure the following OMA-URI setting:
   • OMA-URI: ./Vendor/MSFT/TenantLockdown/RequireNetworkInOOBE
   • Data type: Boolean
   • Value: False
3. Deploy to the target devices.
4. After sync, the device is released from tenant lockdown.

Method 3: Remove device from management

If the device needs to be completely released from your organization:

1. In the Intune admin center, navigate to Devices > All devices.
2. Select the target device.
3. Select Delete to remove the device from Intune management.
4. In Microsoft Entra admin center, navigate to Devices > All devices.
5. Select the device and choose Delete to remove it from Microsoft Entra ID.
6. Reset the device - it should now go through OOBE without tenant restrictions.

Troubleshooting Tenant Lockdown

If you encounter issues with Tenant Lockdown, consider these troubleshooting steps:

Verify policy deployment

Whether you configure Tenant Lockdown using the Settings Catalog or a custom OMA-URI profile, the RequireNetworkInOOBE setting is stored in the internal MDM policy database - not in a browsable registry key or file. The Settings Catalog provides a user-friendly interface, but under the hood it writes to the same MDM policy store as the TenantLockdown CSP.

To verify the TenantLockdown policy is applied:

1. In the Microsoft Intune admin center , navigate to Devices > All devices.
2. Select the target device and go to Device configuration.
3. Verify the TenantLockdown profile shows as Succeeded.

Alternatively, on the device itself:

1. Navigate to Settings > Accounts > Access work or school.
2. Select the connected account and choose Info.
3. Scroll down to view the applied policies and verify the TenantLockdown policy is listed.

Common issues

Final thoughts

Tenant Lockdown enforces network connectivity during OOBE after a reset, but it fits best with Windows Autopilot. Windows Autopilot registration stores your device’s hardware hash with Microsoft, which causes the device to be recognized and routed to your tenant when it connects to the network - hiding the “Setup for personal use” option entirely.

When implementing device lifecycle management, consider this layered approach:

1. TenantLockdown - Forces network connectivity during OOBE
2. Windows Autopilot device registration - Binds devices to your tenant via hardware hash
3. UEFI/BIOS password - Prevents booting from external media
4. BitLocker - Protects data at rest

Happy exploring!

–Jesper