Unmanaged Devices with Microsoft Intune (1/3): Windows
Windows BYOD with Intune has three distinct paths. Most organizations configure the wrong one. MAM, MDM enrollment, Conditional Access, and the enrollment pitfalls clients hit in practice.
A personal laptop connects to your corporate tenant. It passes Conditional Access. The user downloads a SharePoint document. Your DLP policy never triggers. Six months later, that laptop is stolen. You have no wipe capability. You can’t tell which files were on it. You find out the device was never enrolled. Just registered.
I start with Windows because most organizations have more Windows devices than anything else. And because the misconceptions about what is actually configured are biggest here.
Key Takeaways
- Windows MAM is generally available but only protects data within Microsoft Edge. Outlook, Teams, and desktop Microsoft 365 apps are not covered. This is a fundamental difference from iOS and Android MAM.
- If you configure MAM user scope in automatic enrollment, MAM takes precedence over MDM and personal devices won’t enroll in MDM through the account-add flow. This is the simplest way to prevent accidental enrollment for MAM-only BYOD.
- Most BYOD incidents start with Entra Registered devices that IT assumes are enrolled in Intune. They’re not. The two states look the same in the Entra portal but behave completely differently.
- MAM-only, MDM Personal, and MDM Corporate are not interchangeable. Choosing the wrong one creates either a security gap or unnecessary friction that pushes users away from managed workflows.
- Conditional Access requires Entra ID P1 (included in Business Premium, E3, and E5). Without it, “Require app protection policy” cannot be enforced.
What is a BYOD or unmanaged device?
In most tenants I audit, IT teams treat “unmanaged” as a binary: either a device is in Intune or it isn’t. The reality Microsoft has built is more granular than that. A device can appear in Entra ID, pass authentication checks, and access corporate data while being completely invisible in Intune device management. That in-between state is where most BYOD incidents originate.
The term BYOD gets used for different things. A personal laptop someone brings from home. A contractor device that belongs to another company. A guest who needs temporary access. An employee in a region where the company doesn’t issue hardware.
What they share: the device is not owned or controlled by your organization. It isn’t in your MDM. It might or might not have security software. You don’t know its patch level. You don’t control what else is on it.
When a user adds a work account to a personal Windows device, the device registers with Entra ID. Registration is not enrollment. A registered device is invisible to Intune, does not pass compliance checks, and cannot be wiped. Only after MAM enrollment through Conditional Access can Intune perform a selective wipe of corporate app data. Most BYOD incidents start with IT treating registered devices as if they were enrolled.
This is the distinction that matters: registration happens automatically and silently. Enrollment requires a deliberate step. The two states look identical in the Entra device list, but they behave completely differently when Conditional Access runs its checks.
What options does Microsoft Intune offer for Windows?
Microsoft doesn’t offer a single BYOD mode for Windows. It offers three approaches that operate at fundamentally different levels. According to Microsoft’s own documentation, the enrollment path a device takes determines every management capability available to you afterward. Understanding the difference before you configure anything matters because the wrong choice creates security gaps that are difficult to close retroactively.
Option 1: MAM-only (no enrollment) - recommended for BYOD
Mobile Application Management without device enrollment. Intune manages Microsoft Edge on the device but has no visibility into or control over the device itself. On Windows, MAM is currently limited to Edge. This is fundamentally different from iOS and Android, where MAM also protects Outlook, Teams, and Microsoft 365 apps.
What you can do:
- Apply app protection policies to Microsoft Edge
- Block cut, copy, and paste of corporate data within Edge
- Block printing of organizational data from Edge
- Block saving corporate content to personal storage from Edge
- Health checks: minimum OS version, offline grace period, disabled account detection
What you cannot do:
- Apply MAM protection to Outlook, Teams, Word, Excel, or other desktop apps
- Enforce cross-app copy/paste restrictions (unlike iOS/Android, this stays within Edge)
- Enforce device compliance
- See the device in Intune
- Push device configuration
- Use “Require compliant device” in Conditional Access
Windows MAM is generally available. Requirements: Windows 10 version 20H2 with KB5031445 or later, or any version of Windows 11, plus Microsoft Edge for Business version 147 or later. The Windows Security Center (MTD) health connector requires Windows 11 23H2 or later.
The app scope limitation is significant. All corporate data protection on Windows MAM runs through Edge. If users open SharePoint in Chrome, Teams files in the desktop app, or Outlook in the desktop client, that data moves outside MAM protection entirely.
Option 2: MDM enrollment (personal) - not recommended for BYOD
The device is enrolled in Intune and marked as personally owned. Microsoft limits what you can control to reduce privacy concerns. This sounds like a reasonable middle ground. In practice, it creates more problems than it solves for BYOD scenarios.
What you can do:
- Apply compliance policies
- Push required apps
- Enforce device configuration (password, encryption)
- Use “Require compliant device” in Conditional Access
- Remote wipe (full, unless configured otherwise)
What goes wrong in practice:
- Corporate device configuration policies land on a personal device. Users notice unfamiliar restrictions and raise support tickets.
- Personal devices enrolled this way often fail compliance checks because they were never provisioned to your corporate baseline.
- You are managing a device you don’t own, didn’t provision, and can’t guarantee the security posture of from day one.
- Privacy friction is real: users reasonably object to their personal laptop being managed by their employer’s MDM.
- Workplace-joined personal devices that accidentally enroll via the account-add flow end up here and will never pass a properly configured compliance policy.
Recommendation
Block personal MDM enrollment entirely. For BYOD scenarios, use MAM-only instead. For contractors where even browser access is too risky, Windows 365 provides a fully managed Cloud PC without touching their physical device.
Option 3: MDM enrollment (corporate) - for corporate-owned devices only
Full management. The device is marked as corporate-owned. Intune has complete visibility and control.
This is not BYOD. It is the correct path for devices your organization owns, provisions, and issues to employees. I include it here because organizations regularly end up with personal devices in this state when they retroactively enroll devices that should have stayed MAM-only, or when contractors are given hardware that is treated as personal.
How do the three options compare?
| Capability | MAM-only | MDM Personal | MDM Corporate |
|---|---|---|---|
| Recommended for BYOD | ✅ Yes | ❌ No | ❌ No |
| No device enrollment required | ✅ | ❌ | ❌ |
| App protection policies | ✅ | ✅ | ✅ |
| Remote wipe (corporate data only) | ✅ | ✅ | ✅ |
| Remote wipe (full device) | ❌ | ✅ | ✅ |
| Require compliant device (CA) | ❌ | ✅ | ✅ |
| Device visible in Intune | ❌ | ✅ | ✅ |
| Hardware inventory | ❌ | Limited | ✅ |
| Push device configuration | ❌ | Limited | ✅ |
| Works on Windows 10 | ⚠️ Limited | ✅ | ✅ |
| Works without Company Portal | ✅ | ❌ | ❌ |
| Edge required as browser | ✅ | ❌ | ❌ |
What enrollment pitfall do most organizations hit?
This is the issue I find at almost every client. A user adds their work account to a personal Windows device. They go to Settings > Accounts > Access work or school. They click Connect. The device registers with Entra ID. IT pulls the device report, sees the device in the list, and assumes it’s enrolled. It isn’t. Registration and enrollment are different operations, and Microsoft’s portal doesn’t make the distinction obvious.
Registration happens automatically when a user adds a work account. The device appears in Entra ID. It does not appear in Intune device management. It is not subject to compliance policies. It does not need to pass “Require compliant device” in Conditional Access.
Enrollment requires a separate step: the user goes through the Company Portal, or auto-enrollment triggers correctly. Only then does the device appear in Intune.
The practical consequence: users on registered-only devices can appear to have access while bypassing every compliance check you’ve configured.
The accidental MDM enrollment problem
There is a second, less obvious issue. On Windows, when a user adds a work account via Settings, the device might silently enroll in MDM, depending on your auto-enrollment configuration. This happens silently through the “Add work or school account” flow in Windows Settings, without the user explicitly choosing to enroll.
Enrollment restrictions can block personal Windows devices from enrolling via the account-add flow using the “Block personally owned Windows devices” platform restriction. But this depends on how Intune determines device ownership at enrollment time. In environments where ownership is not pre-assigned, the restriction doesn’t reliably catch the enrollment before it completes. That’s the gap that exists in practice.
How to block personal MDM enrollment
Before configuring either option below, set the enrollment platform restriction first. In Intune > Devices > Device onboarding > Enrollment > Device platform restriction, block personally owned Windows devices. This prevents personal devices from enrolling via the Company Portal or Windows Settings enrollment flow.
That restriction alone doesn’t cover all paths. There are two additional mechanisms to close the remaining gaps:
Option A: Configure MAM scope to take precedence over MDM scope. In Intune > Devices > Enrollment > Windows enrollment > Automatic enrollment, configure the MAM user scope for your BYOD users. When both MDM and MAM user scopes are enabled for the same user, MAM takes precedence and the device will not be enrolled in MDM through the account-add flow. This is the simplest approach if your BYOD strategy is MAM-only from the start.
Option B: Use the account-add flow enrollment setting (public preview). In Intune > Devices > Device onboarding > Enrollment > Windows > Automatic enrollment, enable “Disable MDM enrollment when adding work or school account”. When enabled, this prevents MDM enrollment triggered through the first-time account-add flow in Edge or native apps such as Teams. Use this if you have a mixed population where some users need MDM and others need MAM-only, and you want per-user control over which path applies.
Two important limitations: this setting is currently in public preview, and it does not apply to the Windows Settings flow. Users can still enroll via Settings > Accounts > Access work or school if they are in scope for MDM automatic enrollment.
In most environments, the combination of unchecked auto-enrollment and no restriction on the account-add enrollment flow means personal devices are silently entering MDM management. The device is managed. The user doesn’t know it. IT didn’t intend it. Standard device configuration policies then apply to a personal device, and the support issues that follow are difficult to trace back to the root cause.
How do you manage Edge for Business on unmanaged devices?
Edge is the cornerstone of Windows BYOD. Every MAM-protected interaction on an unmanaged Windows device runs through it. But “managing Edge” means different things depending on which path you use. There are three distinct approaches, each with different requirements and capabilities.
Path 1: Intune app protection policies (MAM)
The path covered throughout this article. Edge is enrolled in Intune MAM via an app protection policy. Requires Windows 10 20H2 with KB5031445 or later, or any version of Windows 11, plus Microsoft Edge for Business version 147 or later, and an Intune Plan 1 license. Protects corporate data accessed through Edge: cut/copy/paste controls, print blocking, and save restrictions.
This is the right path for organizations that already have Intune and want to protect BYOD users without enrolling their devices.
Path 2: Edge Management Service
A cloud-native management path that doesn’t require Intune or device enrollment. Configured via Microsoft 365 admin center > Settings > Microsoft Edge. As of January 2026, this supports both Windows and macOS.
What it gives you:
- Work/personal profile separation in Edge
- Browser policy enforcement
- Basic configuration via the M365 admin portal
What it doesn’t give you:
- Cut/copy/paste controls on corporate data
- Print blocking
- File download restrictions
- Selective wipe of corporate data
The Edge Management Service is the right starting point if you need a lightweight option or if BYOD users don’t have Intune licenses.
Edge capabilities by management path
| Capability | MAM (App Protection) | Edge Management Service |
|---|---|---|
| Work/personal profile separation | ✅ | ✅ |
| Browser policy enforcement | ✅ | ✅ |
| Cut/copy/paste control | ✅ | ❌ |
| Print blocking | ✅ | ❌ |
| File download restrictions | ✅ | ❌ |
| PIN requirement | ✅ | ❌ |
| Selective wipe of corporate data | ✅ | ❌ |
| Device enrollment required | ❌ | ❌ |
| Intune license required | ✅ | ❌ |
Purview inline DLP in Edge
Microsoft is delivering Purview Data Loss Prevention controls directly into Edge browser sessions for unmanaged devices. This applies DLP policies at the browser layer and catches data exfiltration attempts in real time, even on a device you don’t manage.
This requires Microsoft 365 E5 Compliance, E5 Information Protection & Governance, or an E5 add-on. It is not available at Business Premium level. For organizations that need this level of control on unmanaged devices, it changes the calculus on whether Windows 365 is the better investment.
How do compliance policies and Conditional Access work together?
For unmanaged Windows devices, the Conditional Access grant that matters is Require app protection policy.
The CA policy uses a device filter to target unmanaged devices only: exclude compliant devices and Microsoft Entra hybrid joined devices. Within that scope, the grant requires an app protection policy. On Windows, only Microsoft Edge can satisfy this grant. Users on unmanaged devices are directed to Edge, which triggers MAM enrollment and applies the app protection policy. The CA policy must target Browser as the client app condition.
Registered-only devices and Conditional Access
A device that is only Entra Registered, not enrolled, can satisfy “Require app protection policy” through Edge when a MAM policy is applied via Conditional Access.
Which Conditional Access policies should you configure for BYOD?
Most BYOD deployments configure one or two Conditional Access policies and stop there. What I find at clients who have BYOD working well is a set of four policies that work together. Each covers a different gap.
Web-only access for unmanaged Windows devices
Allows unmanaged Windows devices to access Microsoft 365 only through a browser. Download and sync are blocked via session policy. Desktop app access is blocked entirely. No corporate files land on the local device.
This is the Conditional Access implementation of what SharePoint’s AllowLimitedAccess does at the SPO layer, but it applies to all cloud apps. BYOD access already exists by default. Anyone with valid credentials can sign into Microsoft 365 from any device right now. This policy controls what happens when they do. It doesn’t open a door that was closed.
Configure with: device filter excluding compliant and hybrid joined devices, session control set to app enforced restrictions or Microsoft Defender for Cloud Apps.
Two session control options exist here. App enforced restrictions uses SharePoint and Exchange to apply their own limited-access logic: read-only browser sessions, no downloads, no sync. No additional license is required beyond Entra ID P1. This is the right starting point for most organizations.
Microsoft Defender for Cloud Apps (MDCA) session controls go further. MDCA proxies the browser session and can enforce real-time policies: block specific file types from downloading, watermark documents in the browser, log user activity, block uploads to unmanaged locations, and alert on anomalous behavior. This requires a Defender for Cloud Apps license (included in E5 Security or M365 E5). For organizations that need audit trails or file-level controls on unmanaged devices, MDCA is the layer that makes those controls possible without device enrollment.
Session controls for BYOD users
On a managed corporate device, you have Intune compliance checks and Defender signals as compensating controls. On a personal device, you have neither. A shorter session window is the substitute.
Microsoft’s default sign-in frequency is a rolling window of 90 days — too long for a device you have no visibility into. Configure a shorter sign-in frequency for BYOD users based on your risk tolerance; many organizations land between 1 and 12 hours for unmanaged device scenarios. Combine this with a Persistent browser session policy set to “Never persistent” to prevent session cookies from surviving browser restart on unmanaged endpoints.
Require TAP for security info registration
Forces users to authenticate with a Temporary Access Pass when registering new MFA methods. Without this, an attacker who compromises credentials can register their own MFA device before the legitimate user notices. On a BYOD device this risk is higher because you can’t verify the device state at the moment of registration.
Configure with: user action set to “Register security information,” grant set to require authentication strength (Temporary Access Pass). For MSPs onboarding new clients, this also gives you control over the MFA registration process from day one.
App protection policy for mobile BYOD
Covered in Parts 2 and 3 of this series. Configure the policy alongside your Windows BYOD policies from the start — the structure is the same, only the platform filter changes.
How does SharePoint handle unmanaged devices?
SharePoint Online has its own access control layer, separate from Intune, and it enforces independently of any app protection policy you have in place. This separation surprises most IT teams the first time they encounter it.
You can restrict access for devices that are not compliant or not enrolled using the SharePoint conditional access settings. The PowerShell setting that applies limited access for unmanaged devices:
Set-SPOTenant -ConditionalAccessPolicy AllowLimitedAccessThis puts unmanaged devices in a browser-only, limited-access mode. Users can view files in the browser but cannot download them, sync them, or open them in desktop Office apps.
For higher-risk environments where even browser access is unacceptable, use BlockAccess instead:
Set-SPOTenant -ConditionalAccessPolicy BlockAccessThis blocks all access for unmanaged devices, including the browser. AllowLimitedAccess is the right starting point for most BYOD scenarios. BlockAccess is appropriate for sites that contain sensitive or regulated data where the access risk outweighs the productivity cost.
You configure this at tenant level or per site collection. It applies to devices that do not meet the “managed device” definition in Microsoft’s terms: hybrid joined or Intune-compliant.
Note: SharePoint’s unmanaged access control is separate from Intune’s app protection policies. You can have an app protection policy on Outlook and still have SharePoint applying limited access in the browser. The two systems enforce separately.
| Action | Unmanaged (Limited Access) | Managed Device |
|---|---|---|
| View files in browser | ✅ | ✅ |
| Download files | ❌ | ✅ |
| Sync with OneDrive client | ❌ | ✅ |
| Edit in desktop Office apps | ❌ | ✅ |
| Access via mobile apps | Depends on MAM policy | ✅ |
How do you handle guest and partner access?
External partners, contractors, and guests create a different challenge from employee BYOD. They use devices that belong to their own organization, which may or may not be managed. They need access to your tenant without you being able to enroll their device. Microsoft’s B2B collaboration framework supports this through Entra External ID and guest accounts.
The right approach depends on whether the partner’s organization uses Intune. You cannot manage or push compliance policies to a device enrolled in another organization’s Intune tenant — devices can only be managed by the user’s home tenant.
If the partner has Intune with active compliance policies: configure Cross-Tenant Access Settings in Entra ID (External identities > Cross-tenant access settings > Inbound trust > Trust compliant devices). This lets your Conditional Access policies honor the compliance claim from the partner’s tenant. The grant “Require compliant device” then works for B2B users without enrolling their device in your tenant.
If the partner has no MDM or doesn’t enroll devices: you cannot enforce device compliance from your side. Restrict access to browser-only through a Conditional Access session policy and use app enforced restrictions or Defender for Cloud Apps session controls for additional protection.
One important limitation that affects both scenarios: “Require app protection policy” as a Conditional Access grant does not work for B2B guest users. Microsoft explicitly documents this as not supported for external users.
Important: For external admins (partners with delegated admin access doing work in your tenant), don’t rely on MAM alone. Require time-bounded access through Privileged Identity Management (PIM), enforce phishing-resistant MFA, and never assign permanent privileged roles to guest accounts.
What I see at clients with external IT partners: the partner has Global Admin or Global Reader delegated access that was set up years ago and never reviewed. The partner connects from their personal device. There is no Conditional Access policy scoped to external admins. There is no PIM. The partner’s device accesses your tenant with the same level of trust as an enrolled corporate device. That trust is not based on anything you control.
What goes wrong at clients?
These are the five situations I encounter most consistently.
Registered devices treated as enrolled. Users add work accounts to personal devices. IT assumes the devices appear in Intune. They don’t. The device passes Conditional Access anyway because the policy only required Entra Registration, not enrollment.
MAM configured but no Conditional Access enforcing it. App protection policies are created in Intune but no Conditional Access policy requires them for resource access. Users access SharePoint through Chrome with no protection applied.
Personal devices accidentally enrolled through the Windows account-add flow. Users add a work account, the device silently enrolls in MDM. The device is managed, but the user didn’t know it was happening and IT didn’t intend it. Standard device configuration policies then apply to a personal device. Support issues follow that are hard to trace back to this cause.
“Require compliant device” blocking users without a MAM alternative. IT tightens Conditional Access to require compliance. Users on personal devices are blocked. Exceptions are added. Exceptions become permanent. The policy exists but enforces nothing.
Edge not adopted, MAM gap never closed. MAM-only BYOD requires Edge for web access to be protected. Users continue using Chrome. IT either blocks Chrome (support tickets) or adds it as an exception (no protection). Neither is sustainable.
The common thread across all five: a policy was created, a gap was discovered, and an exception was added to keep users productive. That exception never got closed. The gap remains open months or years later. It’s not a technical problem. It’s a governance problem that the technical controls can’t fix on their own.
Which licenses do you need?
| Feature | License Required |
|---|---|
| Intune (MDM + MAM) | Microsoft Intune Plan 1 (included in Business Premium, E3, E5) |
| App protection policies | Microsoft Intune Plan 1 |
| Conditional Access | Entra ID P1 (included in Business Premium, E3, E5) |
| Defender for Endpoint integration | Defender for Endpoint Plan 2 (E5 Security or add-on) |
| Windows 365 | Windows 365 Business or Enterprise (separate license) |
| Privileged Identity Management | Entra ID P2 (included in E5, or add-on) |
| Cross-Tenant Access Settings (B2B device trust) | Entra ID P1 (included in Business Premium, E3, E5) |
Frequently asked questions
If I enable MAM scope for my BYOD users, will it affect corporate devices that are already MDM-enrolled?
No. MAM scope takes precedence only during the account-add flow on personally-owned devices. Corporate devices that are already MDM-enrolled stay enrolled in MDM. The precedence rule applies specifically to personal devices adding a work account, not to devices that were enrolled through provisioning or Autopilot.
My BYOD users need Teams and Outlook on their personal Windows laptop. Does MAM block those apps or just leave them unprotected?
They are unprotected, not blocked. Windows MAM only covers Edge. Teams desktop and Outlook desktop on a personal device run entirely outside MAM. If you want to block desktop app access from unmanaged devices, you need a Conditional Access policy that targets the desktop client app type and enforces web-only access. Without that policy, users can access corporate data through desktop apps with no controls applied.
Do I need both a Conditional Access app protection policy AND SharePoint’s AllowLimitedAccess setting, or does one cover the other?
Both are needed and serve different purposes. Conditional Access controls whether and how a user gets access to Microsoft 365 services. AllowLimitedAccess controls what that user can do inside SharePoint: no downloads, no sync, no desktop app access. CA alone does not prevent downloads within SharePoint. AllowLimitedAccess alone does not block access from Chrome or other unprotected clients. Configure both for complete control.
A personal device accidentally enrolled in Intune through the account-add flow. How do I remove MDM management without wiping the user’s personal files?
In Intune, go to Devices > All devices, find the device, and select Retire, not Wipe. Retire removes corporate data and MDM management but leaves personal files intact. The user should also disconnect the work account via Settings > Accounts > Access work or school > Disconnect. To prevent it happening again, configure MAM scope precedence in automatic enrollment settings so the account-add flow routes personal devices to MAM instead of MDM.
We have guest users accessing our SharePoint. How do we apply device controls?
Microsoft does not support “Require app protection policy” as a Conditional Access grant for B2B guest users. For partners whose organization uses Intune with device compliance policies, configure Cross-Tenant Access Settings (Entra ID > External identities > Cross-tenant access settings > Inbound trust > Trust compliant devices) to honor their device compliance claims in your tenant. For partners without Intune, use Conditional Access session controls to restrict access to browser-only, combined with SharePoint’s AllowLimitedAccess setting.