Imagine the scene; You’ve started to adopt Microsoft Intune for device management, moving fully to the cloud. ✅ Getting shot of Group Policy management and even Configuration Manager ✅, you’ve nailed single user affinity devices ✅ and even rolled out Windows Hello for Business ✅ to improve the user sign in experience and security. You then turn your hand to shared devices and its not going so well. It works ✅ — but it isn’t seamless ⚠️. Did you know your MFA configuration might be the culprit?

Shared Windows devices in teaching labs, libraries, and lecture theatres need to “just work.” But when Microsoft Intune and Conditional Access are combined with Windows Autopilot pre-provisioning, things can go wrong in unexpected ways.

A common issue we’ve seen is that MFA never prompts the user during login. On the surface, this might look like a smoother experience. In reality, it means no Primary Refresh Token (PRT) is established and without a PRT, seamless SSO fails. The knock-on effect is that students (or staff) can’t sync Company Portal policies, device configuration stalls, and Windows subscription activation doesn’t apply correctly.

Why It Happens

• Shared Windows devices (Azure AD joined, Intune managed, no primary user) don’t issue MFA at login.
• Conditional Access policies apply to all users and apps without exclusions.
• Non-interactive logins (Company Portal, Intune MDM, Windows licensing) then try to authenticate — but get blocked silently by Conditional Access because MFA is required but not triggered.
• Result: Company Portal only partially works, device policies sit as “Pending,” and subscription activation is delayed.

Interactive vs. Non-Interactive Sign-Ins in Entra ID

When a user signs in to a device or application, Entra ID records the sign-in as either interactive or non-interactive.

• Interactive sign-ins occur when the user is directly prompted to enter their credentials or complete an MFA challenge. This includes typing in a password, using Windows Hello, or approving a prompt on their phone. Interactive sign-ins always involve visible user interaction.
• Non-interactive sign-ins happen silently in the background, usually when a token is being refreshed or when applications/services request access on behalf of the user. For example, Microsoft Intune, Company Portal, or Office apps will often use non-interactive sign-ins to request tokens without interrupting the user.

The distinction matters in Conditional Access: if MFA is required on a non-interactive sign-in, the user won’t see a prompt right away. Instead, the process fails until something triggers an interactive sign-in, which can lead to confusion and policy mis-applications on shared devices.

The user experience

Instead of being prompted for MFA at sign-in, students only discover the problem when:

• Device configuration targeted at the user is delayed
• OneDrive sync client doesn’t automatically sign in and re-direct folders
• Edge automatic sign in and sync doesn’t automatically sign in and provide your user preferences
• Outlook prompts the user for their email address upon first launch
• Windows Enterprise/Education edition activation is delayed

In teaching environments, this disruption is magnified — students move rapidly between machines, and IT staff can’t troubleshoot MFA prompts that never appear.

Issue confirmation

So you’ve read this far and wonder if the user experience witnessed is caused by Conditional Access too? Let’s confirm before remediating.

You can first this in 2 way; one the affected device or via the entra sign in logs.

On the device

The simplest way to check is get the user to login and launch the start menu. Select their user account icon (either their picture or initials, if they don’t have a picture), if MFA is at fault here, they’ll get…

They can always verify account here and configuration will start to apply but by this point, the damage to SSO and the user experience is already disrupted. Not to mention that they might need to log off and on to get OneDrive, Edge and other configuration to automatically apply.

Entra Logs

You’ll need a role that allows access to user sign in logs and conditional access (to see the problematic policy report). Remember that sign in logs take around 10 minutes to populate so log into an affected device and wait before looking to the logs.

1. Navigate to entra.microsoft.com
2. Go to Entra ID > Users > Select test User > Sign In Logs
3. Select User sign-ins (non-interactive)
4. Now look for an interrupted sign in for Windows Search, Device Management…
5. Select the sign in log, it might be under aggregate, if so select that line and select the expanded record
6. You’ll see the basic authentication information with a message such as Failure Reason
7. Select Conditional Access
8. Here you’ll the policy causing the issue
9. You’ll see within the grant control required.

Intune Conditional Access Remediation Options for MFA on Shared Devices

Now that you’ve confirmed the issue, we need a solution! To balance security and usability, organisations need to exclude shared devices from strict MFA requirements, while still maintaining strong controls elsewhere.

Which Approach Should You Use?

• ✅ Exclude Intune / Windows Store for Business → if device sync and subscription activation are the main blockers.
• ✅ Filter by Enrollment Profile → if all shared devices use a dedicated Autopilot profile.
• ✅ Filter by Extension Attribute → if you need granular control across mixed Autopilot profiles or to tag only specific labs.
• ❌ Exclude by Network Location → only safe if you can guarantee shared devices are the only ones using those public IPs. Avoid if BYOD devices connect to the same network.
• ❌ Introduce Web Signin → only safe if you can guarantee shared devices will always have an internet connection.

Exclude Microsoft Intune

To prevent Company Portal and user initiated sync’s with Microsoft Intune being affected by your conditional access, the best advice would be to simply exclude the app entirely from the offending CA.

1. Navigate to entra.microsoft.com
2. Go to Entra ID > Conditional Access > Policies
3. Select the MFA policy (remember you might have more than one, so repeat steps 4-9)

• It might be a good idea here to review your other policies for grant controls and consider adding this exclude to those too. For example “Require Compliant devices”.

4. Select Target resources
5. Select Exclude
6. Select Select or the blue text below select
7. Search for and select “Microsoft Intune”. If this doesn’t appear, depending on your tenant look for “Microsoft.Intune” It’s the same App ID but some tenants have a dot in the middle. Good old Microsoft.
8. Select the blue Select button
   • Example screenshot of the policy filter in action:;

9. Save the policy.
10. The policy will be updated with the new exclusion and take around 20 minutes to apply.

Exclude Windows Store for Business

In the same way as Microsoft Intune. Subscription Activation of Windows is handled by Windows Store for Business. If devices are failing to uplift to Enterprise, exclude the Windows Store for Business Enterprise app entirely from the offending CA. Microsoft also include this in their documentation.

1. Navigate to entra.microsoft.com
2. Go to Entra ID > Conditional Access > Policies
3. Select the MFA policy (remember you might have more than one, so repeat steps 4-9)
   • It might be a good idea here to review you’re other policies for grant controls and consider adding this exclude to those too.
4. Select Target resources
5. Select Exclude
6. Select Select or the blue text below select
7. Search for and select “Windows Store for Business”. If this doesn’t appear, depending on your tenant look for “Universal Store Service APIs and Web Application” It’s the same App ID as the Windows Store.
8. Select the blue Select button
   • Example screenshot of the policy filter in action:;

9. Save the policy.
10. The policy will be updated with the new exclusion and take around 20 minutes to apply.

Filter for shared devices

Now comes the fun part! Depending on your environment will depend on the best approach here. I’ll cover off a general exclude and then a 2 tailored options for shared devices.

Network Approach

This option only works if you want to exclude all devices that reside on your internal network. If you have other device use cases or allow users to connect personal devices to the same network, even connected to different vlans, this isn’t the option for you. To clarify, if internet traffic for these devices is all route through the same public IP addresses to M365, I don’t recommend this approach. Be warned!

1. Obtain your public facing IP address(es)
2. Navigate to entra.microsoft.com
3. Go to Entra ID > Conditional Access > Named Locations
4. Review the IP ranges locations to ensure you don’t already have these setup. If you do, skip to step X
5. Select IP Ranges location
6. Provide a name such as the location or campus
7. Click on the + icon
8. Add the IPv4 range with /24 or/32 etc (I won’t explain these here)
9. Select Add
10. Navigate to Entra ID > Conditional Access > Policies
11. Select the MFA policy
12. Select Network
13. Select Yes on Configure
14. Select Exclude
15. Select Selected network and locations
16. Select None
17. Add the newly added or existing named location and select Save
    • Example screenshot of the policy filter in action:;

18. Remember to then Save the conditional access policy.

Now that you’ve excluded the MFA from the named location, the policy will take around 20 minutes to update and from then, MFA will not prompt users on this network. If you’ve selected the route, it would be a good idea to add an additional MFA policy that is targeted to this network. For example you could have a policy that includes this network but only targets the browser and Office 365.

Note- This will only work if devices are logging in, when on your network. If they take a shared device home and login for the first time, this solution doesn’t address the issue. Keep reading ;).

Filter for Devices Approach

You’re still with us. Good, this is where it gets interesting and becomes tailored to your device use case. If you only want to exclude the shared devices from the policies, this is where we’ll use Filter for Devices. It’s been around for quite some time but in my experience, it’s relatively less known.

You can use “Filter for Devices” within a Conditional Access policy to control if it should or shouldn’t apply via includes and excludes criteria. There are a number of filter options that can be selected. From Intune Compliance state, Device Name, EnrolmentProfileName and so on. Some of these are safer to use than others. I’d recommend not using a filter that a user could manipulate. For example a user could change their Device Name for exclude their device from a targeted CA policy.

We’ll run through 2 exclude options here, based on;

• Windows Autopilot enrolment profile - used by the shared devices onboarding via Windows Autopilot
• Extension Attributes (often used for Privileged Access Workstations - PAW) used when you want to target all or a subset of devices.

The mechanics behind Filter for devices is the same;

1. Navigate to entra.microsoft.com
2. Go to Entra ID > Conditional Access > Policies
3. Select the MFA policy
4. Select Conditions
5. Select Filter for Devices > Not Configured
6. Select Configure
7. Select the radial for Exclude filtered devices from policy
8. Select the property that you wish to exclude from the drop down
   • In our case it’ll be EnrollmentProfileName or ExtensionAttribute(1-15)
9. Operator should be “Equals”
10. Value should is a string with the value of
    • In our case it’ll be the EnrollmentProfileName from the Windows Autopilot Deployment Profiles blade within
      Microsoft Intune
    • Or a string value of our choice for the ExtensionAttribute, such as “Shared-MFAExcluded”
11. Select the blue Done once complete
    • Example screenshot of the policy filter in action:;

12. Remember to Save the policy to finish editing the CA policy
13. Again, wait around 20 minutes for the policy changes to take effect.

If you’ve used the EnrollmentProfileName property and devices are enrolled using that deployment profile, your work here is done and you can test with a new enrolment. If however you’ve opted for ExtensionAttribute, the device(s) still need to be tagged.

Add Extension Attributes to devices

This has been covered by many blog posts over the years so I’ll keep this part brief. I might even revise this in future and profile a Powershell script to call graph, watch this space. To understand adding this attributes, you have to understand that these attributes live within Entra, not Intune. The attributes gets added to the Autopilot Entra record. The bonus is that you only ever have to do this once. The downside is that it can’t be done via the Entra portal. It has to be done via Graph.

These blog posts cover how to add the extension attributes to devices

• ourcloudnetwork.com
• smbtothecloud.com

The concept is simple however; As an example, this script adds “Shared-MFAExcluded” to “extensionAttribute1” of a selected device, based on it’s name. I’ve kept it very simply without an if query to check the device exists etc but just so you get the concept and to allow for testing.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# Load the Microsoft Graph module
Import-Module Microsoft.Graph.Identity.DirectoryManagement
# Connect to Microsoft Graph with required permissions
Connect-MgGraph -Scopes "Directory.ReadWrite.All"

# Define the device name you want to update
$DeviceName = "DEVENV-34429856"

# Find the device by name
$Device = Get-MgDevice -Filter "displayName eq '$DeviceName'"

# Update extensionAttribute1
    Update-MgDevice -DeviceId $Device.Id -AdditionalProperties @{
        "extensionAttributes" = @{
            "extensionAttribute1" = "Shared-MFAExcluded"
        }
    }

To confirm that it’s worked, you should now see the extensionAttribute within Entra

1. Navigate to entra.microsoft.com
2. Go to Entra ID > Devices > All Devices
3. Search for your device
4. Select the device, in my case DEVENV-34429856
5. At the bottom of the record you should now see the extensionAttribute set.

6. Now to test your policy exclusion….
7. You should now see that the MFA policy now excludes this device from the policy

An Alternative Option: Web Sign-in

In addition to traditional sign-in methods, Web sign-in offers another possibility for shared devices. This option provides a streamlined experience by leveraging cloud-based authentication like MFA, Microsoft Authenticator, Temporary Access Pass (TAP), or FIDO2 security keys.

The primary drawback of Web sign-in is its complete dependence on a reliable internet connection. Unlike cached credentials from a traditional password login, the Web sign-in option requires an internet connection for every single login, even if the user has previously signed in to the device. This means if a device loses its network connection, users will be unable to sign in using this method.

More on Web Sign from Microsoft

What if a Login Fails?

You might be wondering if users will know how to switch options if their Web sign-in fails. The good news is that Windows is designed to handle this gracefully. The lock screen will always show multiple sign-in options if they are enabled on the device (e.g., password, PIN, Web sign-in).

If a Web sign-in attempt fails due to a network issue, the user can simply press Ctrl + Alt + Delete to return to the main login screen. From there, they can select an alternative sign-in method, such as a cached password or PIN, allowing them to complete their login without interruption.

Conclusion

Conditional Access and MFA are essential for securing identities in Microsoft 365, but shared devices introduce edge cases that can easily break the user experience. The challenge is that non-interactive logins silently fail when MFA is required but never prompted, leaving users confused and admins troubleshooting stalled configurations.

By carefully excluding the right enterprise applications, or by using targeted device filters such as Autopilot profiles or extension attributes, you can strike the balance between security and usability. The goal isn’t to weaken MFA, but to apply it intelligently so that shared devices remain functional while personal or high-risk scenarios stay protected.

As always, test exclusions thoroughly in a controlled environment before rolling them out broadly, and keep monitoring your Entra sign-in logs to validate that policies are working as intended.

Done right, Conditional Access doesn’t have to be a blocker — it becomes an enabler for seamless, secure, and scalable device management in Microsoft Intune environments.