rss.livelink.threads-in-node

Advanced Microsoft Intune capabilities - Coming to Education A5?

MarkBerry — Fri, 31 Jul 2026 08:06:51 GMT

The Advanced Microsoft Intune capabilities (what was the Intune Suite has now arrived for E5 customers (and some of the features to E3 customers. Can anyone give any clarity as to if/when these features will be coming to A5 customers?

I can see we seem to have some of the features (Remote Help, Endpoint Privilege Management) but could really do with knowing if the rest of the features are coming. Can't seem to find any information online about it.

problem with Auto-Enrollment for windows devices in Hybrid enviroument

Amir Gh — Wed, 29 Jul 2026 12:06:51 GMT

Hi everyone,

I am in the process of setting up Intune for automatic enrollment on Windows devices within our hybrid environment. Here are the steps I have taken so far:

1. Configured Entra ID sync to synchronize a selected OU with Entra ID.

2. In the Intune Portal, set the Automatic enrollment MDM user scope to "All."

3. Created a GPO linked to that OU, which includes the settings to "register domain-joined computers as devices" and "Enabled automatic MDM enrollment using default Azure credentials" based on User Credential.

4. Prepared a clean computer, free of any software, and joined it to the Domain (on-prem server).

5. Moved the computer to the appropriate OU for syncing with Entra ID.

6. At this point, I can see the computer listed in the Entra ID portal under devices as Entra Hybrid joined

7. A regular domain user with a Business Premium license logged into the computer.( Only sign-in to windows, we don't have office app or add this account to windows.)

8. I ran GPupdate /force and rebooted the computer several times, but it still does not appear in the Intune portal.

9.Windows client is windows 11 Pro version 25H2 OS build 26200.8893

Dsregcmd output shows:

✅ Device is domain joined
✅ Device is synced to Entra ID
✅ Device authentication is working
✅ User has a valid PRT (Primary Refresh Token)
✅ Hybrid Join is successful

On second test computer2, I installed office desktop app, then sign-in with test user to activate it. After few minutes the computer appeared on Intune portal. but on test computer 1 without user's interaction, it doesn't show up.

would you be able to help me with this? Does it really need user to attach his/her account manually to "work or school account" or sing-in to any office desktop apps?

Registry Inventory in Microsoft Intune: Verifying What’s on Your Devices

Intune_Support_Team — Tue, 28 Jul 2026 20:59:27 GMT

By: Madison Cooks, Product Manager | Microsoft Intune

IT admins need a reliable way to confirm how Windows devices are configured, especially when troubleshooting, validating compliance, or investigating security posture. Policy assignment alone doesn’t always show what’s present on the device and getting registry visibility at scale has often required custom discovery or remediation scripts that take time to build, test, and maintain.

With Microsoft Intune’s July (2607) release, device inventory will include Windows registry data, helping IT admins verify a device’s actual configuration, not just the policy assigned. With a new Device inventory property for registry keys, you define the keys you care about in the properties catalog, and Intune collects them for you. There’s no collection logic to build or keep running.

This makes registry-based configuration checks easier to operationalize across managed Windows devices, so teams can spend less time maintaining scripts and more time acting on the data.

Figure 1: Microsoft Intune device inventory profile creation screen showing the Properties picker with the Registry category selected for inventory data collection.

What registry data you collect

Registry data collection is configured through the existing properties catalog. For each entry, provide a registry key path and, when needed, a value name. For every targeted device, the device agent attempts collection and reports:

Registry key path
Value name
Value type
Value data

Figure 2: Microsoft Intune device inventory profile configuration page showing registry key collection settings, including registry path, collection pattern options, and value name fields.

The initial release supports the following collection patterns designed for common admin scenarios that use HKEY_LOCAL_MACHINE (HKLM) paths.

Single value

Specify a registry path and value name to collect one value from that path. For example, collect Secure Boot certificate servicing status from HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot by using values such as UEFICA2023Status, UEFICA2023Error, or UEFICA2023ErrorEvent.

All values under a path, non-recursive

Specify a registry path to collect all values directly under that path. This pattern doesn't include subkeys. For example, collect values directly under a Windows Update configuration path to help validate expected settings.

Same value across subkeys

Specify a base registry key path and a value name to collect that value from each immediate subkey. For example, collect DHCP status across network interface subkeys under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces.

Where registry inventory data appears

After collection, registry inventory data will be available in Device inventory at initial release. We’ll expand access to registry data in the coming months, including support in additional reporting and exploration experiences.

Figure 3: Microsoft Intune Device Inventory page displaying collected Windows registry data for a device, including registry key paths, values, collection status, and timestamps.

This makes registry data available alongside other inventory signals, so admins can use familiar tools to investigate configuration, validate device state, and support troubleshooting without building separate collection scripts.

How admins use this

You can collect registry data and view it per device in Device inventory - a verified record of each endpoint’s actual configuration and a key source of settings data on each endpoint. This helps answer questions like: Is a setting actually enabled on the device? Which app, version, or configuration is installed? Did a policy apply correctly? Why is this device behaving differently from the rest?

Registry data collection in Device inventory is included with Microsoft Intune Plan 1.

Collection results and limits

If a registry value exists but doesn’t contain data, collection succeeds and the value appears as empty. If the registry path or value name doesn’t exist on a device, that device reports Not found for the collection result. Collection continues for all other devices, so one missing value won’t block results from devices where the value exists.

Registry inventory includes safeguards to keep collection focused and manageable. Each collected registry value is capped at 6 KB, and each device can collect up to 100 registry keys. If a value or device exceeds these limits, collection skips the excess data and reports the applicable result for that device. These limits help manage data volume, maintain service performance, and reduce the risk of over-collection.

Registry inventory is designed for configuration visibility and troubleshooting, not for collecting sensitive or confidential data. Built-in heuristic detection helps identify and prevent ingestion of values that may contain secrets, credentials, authentication tokens, certificates, private keys, connection strings, or other data that could grant access if exposed. If a value is flagged as potentially sensitive, it isn’t collected.

Collection is limited to HKEY_LOCAL_MACHINE (HKLM) paths. This keeps inventory focused on device-level configuration and avoids user-specific registry contexts.

Summary

Registry inventory in Microsoft Intune helps admins collect Windows registry data in a native, declarative way. Instead of maintaining custom scripts for common inventory scenarios, admins can configure registry collection in the properties catalog and query the results through familiar Intune reporting experiences.

Use registry inventory for configuration visibility and troubleshooting across managed Windows devices. As you plan your collection strategy, focus on device-level HKLM data, avoid sensitive values, and remember collection limits to keep inventory targeted and manageable.

If you have any feedback or questions, leave a comment below or reach out to us on X @IntuneSuppTeam.

Compliance Policies - Device Health Attestation failing (Syncml 404 / 0x87d10194)

Durrante — Tue, 28 Jul 2026 16:31:49 GMT

Windows 11 devices are non compliant in Intune against BitLocker, Secure Boot and Code Integrity, all three returning the Syncml 404 error. The settings are genuinely enabled. The real cause is the device can't retrieve a Device Health Attestation certificate, so the health cert status sits at 65535 and the retrieval task fails.

What I've found: the TPM is healthy (present, ready, attestation capable, firmware not vulnerable), and the endorsement key cert is valid, chaining to Nuvoton TPM Root CA 2111. But the EK chain check comes back invalid with zero intermediate certificates, because the Nuvoton key is signed straight off the root with no intermediate for the chain walk. A Hyper-V VM on the same build and tenant works fine, but only because it has no manufacturer EK cert, so it skips that chain check entirely.

What I've tried: patching TPM firmware (ruled out the older ADV190024 issue), refreshing the local trusted TPM certificate store, and rerunning the retrieval task. None fixed it. This matches Rudy Ooms' well known call4cloud writeup, where he concluded it's a service side trust problem that can't be fixed from the device.

It's now appearing on brand new Dell hardware too, so I can't just exclude the old kit and move on.

Is this a known issue with the Nuvoton root chain, and is there a supported fix or position from Microsoft? Screenshots below showing the compliance errors and the failure.

What’s new in Microsoft Intune – July

ScottSawyer — Tue, 28 Jul 2026 22:03:17 GMT

Ask an IT admin what a good day looks like, and it usually comes down to one word: control. Control means you push a change and know it landed. It means you have a clear view into your device fleet, from compliance status to sync health. That certainty is what helps IT stay ahead and deliver.

Still, endpoint management gets harder as fleets grow across locations and device types. More devices and policies rarely mean fewer admin hours. This month's updates focus on giving IT clearer visibility and more confident action.

Demystify Windows device sync status

When admins troubleshoot a device, they need visibility into what’s happening. The updated per-device sync experience in the Intune admin center now shows progress, making it easier for admins to confirm actions are running and understand where they are in the process.

The updated sync action also triggers both the mobile device management check-in and the Intune Management Extension (Windows only) check-in. One sync can now pull-down policy, app, and script changes in a single pass. For admins working through a single-device issue, this makes sync more transparent, more complete, and easier to trust as a troubleshooting step. Learn more about sync actions for Windows and how to use them to troubleshoot and validate device state.

Figure 1: The Sync status pane tracks each step live, from notifying the device to calculating compliance.

Want a deeper story about how we delivered this change? Read the blog about how Intune helps IT prioritize time-sensitive actions or catch the recent Microsoft Technical Takeoff video on Intune timing demystified.

Help ensure compliance for macOS

This month, custom compliance settings for macOS became generally available. Admins can use these settings to apply organization-specific requirements that built-in compliance settings don’t cover. This extended coverage helps reduce risk and unblock macOS deployments by aligning compliance and Conditional Access requirements with the Intune security policies organizations need to manage them. To learn more about compliance policies and what they do, see "Use compliance policies to set rules for devices you manage with Intune."

Additionally, using discovery scripts and JSON rules, admins can inspect many macOS device attributes and conditions. Think about installed software, running processes, app versions, or security posture that no Apple built-in setting captures. Now macOS devices report compliance the same way Windows and Linux devices do, giving you one consistent view instead of three different ones. Read more about how to set up the custom compliance settings documentation for Microsoft Intune.

More control over Samsung firmware updates

Keeping firmware current becomes harder as your mobile device fleet grows. For example, a new version may need testing against line-of-business apps before reaching production devices. In a Zero Trust environment, every unpatched device can become a compliance gap waiting to happen.

The Samsung Knox Enterprise Firmware-Over-The-Air (E-FOTA) integration brings precise control over firmware and OS updates across their Galaxy devices into the Microsoft Intune console. Existing Intune device groups determine which devices receive each version. If group membership changes, the firmware assignment follows.

Admins can keep production devices on their current version while testing an update. After validation, they can roll it out gradually during planned maintenance windows. Battery requirements and postponement limits provide more control over installation timing. This helps maintain consistent firmware and compliance across the fleet.

Intune: Myth vs. reality

Myth: Windows Autopilot requires device registration for new PCs.

Reality: Device registration is not required in all Windows Autopilot scenarios. Many IT admins associate Windows Autopilot with device registration because the original Windows Autopilot solution uses registration to identify devices. Today, organizations can choose from multiple Autopilot approaches depending on their deployment needs.

Windows Autopilot helps IT remotely provision devices at scale across a range of deployment scenarios, including existing devices, pre-provisioning, self-deploying deployments, and remote users.

Windows Autopilot device preparation helps streamline Windows 11 provisioning without requiring Windows Autopilot registration. It uses enrollment-time grouping to deliver selected apps and scripts during setup, with near real-time deployment reporting.

How to choose the right Autopilot approach: If you need registration-based deployment scenarios, such as pre-provisioning, self-deploying deployments, or existing device provisioning, use the original Windows Autopilot solution. Use Windows Autopilot device preparation when you want to streamline Windows 11 onboarding without Windows Autopilot registration and deliver selected apps and scripts during setup before users reach the desktop.

Windows Autopilot in action: Watch Microsoft MVP Jonathan Edwards walk through remote, at-scale onboarding with Intune. You will get a step-by-step look at both Windows Autopilot and Autopilot device preparation in action, along with guidance on choosing the right approach for your environment.

Keep the conversation going

Control rarely arrives as one big feature or capability. It shows up in the smaller updates admins lean on daily. A sync they can watch, a compliance rule they can shape, or a firmware update they can run with confidence. Together, these capabilities add more certainty and give time back. That is how modern endpoint management should work.

In that same spirit, staying in control means staying current as threat response speeds up. Read our recent post by Jason Roszak for practical guidance on building a patch strategy with Microsoft. Let us know in the comments what you think of these new capabilities and stay tuned for more next month.

Stay up to date! Bookmark the Microsoft Intune Blog and follow us on LinkedIn or @MSIntune and @IntuneSuppTeam on X to continue the conversation.

IOS Enrollment Policys - User affinity with modern auth, does not work with Company Portal VPP

GT3 — Tue, 28 Jul 2026 02:55:58 GMT

IOS Enrollment Policys - User affinity with modern auth, does not work with Company Portal VPP

I am trying to test the newer iOS Enrollment Policies using User Affinity with Modern Authentication instead of the older Enrollment Profiles.

One thing I've noticed is that the "Install Company Portal with VPP" setting exists in Enrollment Profiles, but I don't see an equivalent setting in the new Enrollment Policies.

My test Policy configuration is using:

User Affinity with Modern Authentication
Company Portal deployed as a VPP app

I tested deploying Company Portal as a required VPP app, and it installs successfully. However, when I launch Company Portal and sign in with my Entra ID credentials, it immediately prompts me to set up company access and download a management profile.

This doesn't seem correct because the device was already enrolled through ADE. If I select Postpone, Company Portal reports that I can't access company resources, and when I check further, it states that the device must be managed before apps can be installed.

this has to be a bug or something right? the microsoft docs on this are very confusing or missing details.

I also noticed that the device initially appears in Intune/entra as "iPad". After some time, the name eventually updates in entra and intune, However, within the Company Portal app, I end up seeing two devices:

"iPad" (This is the Ipad that you're currently using)
"ipad123-testing" ( this is the proper name and matches intune / entra)

Under Settings > General > VPN & Device Management, I can see the correct Intune management profile installed. Sync and restart actions from Company Portal also work successfully.

It appears that Company Portal is not associating itself with the existing ADE enrollment record. Instead, it seems to be attempting a user-driven enrollment workflow on a device that is already enrolled and managed through ADE.

Has anyone else seen this behavior when using the new iOS Enrollment Policies with User Affinity and Modern Authentication? its unusable in this state.

i saw a random blog about using an app config to set xml for the company portal app but that cant be right for such a vanilla use case? didnt need to do that with the old profiles.I am trying to test the newer iOS Enrollment Policies using User Affinity with Modern Authentication instead of the older Enrollment Profiles.

One thing I've noticed is that the "Install Company Portal with VPP" setting exists in Enrollment Profiles, but I don't see an equivalent setting in the new Enrollment Policies.

My test Policy configuration is using:

User Affinity with Modern Authentication
Company Portal deployed as a VPP app

this has to be a bug or something right? the microsoft docs on this are very confusing or missing details.

"iPad" (This is the Ipad that you're currently using)
"ipad123-testing" ( this is the proper name and matches intune / entra)

Under Settings > General > VPN & Device Management, I can see the correct Intune management profile installed. Sync and restart actions from Company Portal also work successfully.

Has anyone else seen this behavior when using the new iOS Enrollment Policies with User Affinity and Modern Authentication? its unusable in this state.

i saw a random blog about using an app config to set xml for the company portal app but that cant be right for such a vanilla use case? didnt need to do that with the old profiles.

iOS Enrollment and Conditional Access

GuilhermeSoares — Mon, 27 Jul 2026 19:37:50 GMT

Hello everyone,

I need some help!

We are configuring Intune to allow BYOD on iOS devices using the Account Driven User Enrollment method. In this scenario, the user enrolls the device by following the path:

Settings > General > VPN & Device Management > Sign in to your Work or School Account

The enrollment process was working correctly until we configured a Conditional Access policy to ensure that only BYOD-managed devices can access company resources. In other words, only devices that have successfully completed enrollment and are marked as Compliant in Intune should be allowed to use corporate applications.

However, after applying the policy, we are no longer able to complete the enrollment process. During one of the enrollment steps, the device displays the following message:

Translate English

"Setting Up iPhone
iPhone setup may take a few minutes.
Sign-In Failed
Enrollment failed. Please try again.
OK"

1. Target resources (Include)

2. Target resources (Exclude)

3. Device Platform: iOS

4. Filter for devices: device.mdmAppId -notIn ["0000000a-0000-0000-c000-000000000000"]

5. Grant: Require device to be marked as compliant

This is our current Conditional Access policy configuration. Has anyone encountered this behavior before, or can identify whether there is any setting that might be blocking the enrollment process during the compliance validation stage?

From hours to minutes: Rethinking Microsoft Intune compliance reporting with the Export API

Intune_Support_Team — Fri, 24 Jul 2026 19:07:28 GMT

By: Daniel Gerrity – Principal Product Manager | Microsoft Intune

If you manage a large device fleet with Microsoft Intune, you’ve almost certainly needed to get reporting data out of the service at scale — compliance state, device inventory, app status, endpoint analytics, or one of the many other reports admins rely on for operations and audit evidence. Intune supports this pattern through the export API, which generates supported reports as asynchronous export jobs instead of requiring you to retrieve the same data through thousands of operational Graph calls.

You can see the full list of reports available through the export API in Intune reports and properties available using Graph API documentation. In the illustrative scenario below, moving one nightly job from operational Graph reporting endpoints to the Intune export API (exportJobs) cuts the work from roughly 100,000 API calls to about 15 while producing the same report data. The runtime drops from ~2.5 hours to ~15 minutes. Here’s how, and why the pattern holds up as your fleet grows.

Note on the numbers

The figures below are a representative example for a hypothetical 50,000-device enterprise, “Contoso,” and are rounded for clarity. Your results may vary based on fleet size, policy count, and how many compliance settings you evaluate.

The scenario

Contoso runs a nightly job that answers a deceptively simple question:

For each device, across every compliance policy assigned to it, what is the state of each individual setting?

This is a classic per-device, per-compliance-policy, per-setting state export. It’s the raw material behind compliance dashboards, audit evidence, remediation targeting, and “why is this device noncompliant” investigations. In Intune’s reporting catalog, this is the DeviceStatusSummaryByCompliancePolicySettingsReportV3 report.

Contoso has ~50,000 managed devices, and the job runs once a day.

The old way: Operational Graph APIs

The intuitive approach treats compliance data as something you fetch, per device, right now. The script:

Enumerates the fleet (managedDevices).
Loops over every device, and for each one calls the operational reporting or setting-state endpoints (such as managedDevices detail and settingStates) to pull that device’s per-policy, per-setting results.
Pages through the results in small JSON pages (often 50 rows at a time), reassembling everything client-side.

It works. It just doesn’t scale because the number of calls is a function of the number of devices.

At roughly two operational calls per device, 50,000 devices is on the order of ~100,000 Graph calls per run. That volume brings its own tax:

Throttling. You hit service protection limits and have to implement retry/back-off logic.
Threading. To finish inside the window at all, you parallelize which means concurrency bugs, partial failures, and harder debugging.
Fragility. A run that makes 100,000 calls has 100,000 chances to fail, and a mid-run failure often means starting over.
Time. End=to-end, the job lands around ~2.5 hours.

Every time Contoso onboards more devices, this job gets slower and more expensive - the worst possible scaling direction for something that runs every night.

The new way: Export API (exportJobs)

The export API flips the model. Instead of asking Graph to compute results device-by-device in real time, you ask Intune to generate the entire report once, server-side, and hand you back a single file.

The flow is a short, asynchronous handshake:

1. POST /deviceManagement/reports/exportJobs { "reportName": "DeviceStatusSummaryByCompliancePolicySettingsReportV3", "format": "csv", ...optional filter/select... } → returns a jobId, status: "notStarted" 2. GET /deviceManagement/reports/exportJobs('{jobId}') → poll until status: "completed" (a handful of polls while it builds) → response includes a short-lived download URL 3. GET {download URL} → one zipped CSV containing every device × policy × setting row

That’s the whole pattern: request → poll → download → unzip → load. One report, one file, the entire fleet inside it.

Count the calls: one POST to start the job, a handful of GET polls while Intune builds the file, and one GET to download it - call it ~15 calls total. Not ~15 per device. ~15 for the whole 50,000-device run. And that number barely moves whether Contoso has 50,000 devices or 150,000.

Runtime drops to about ~15 minutes, most of which is simply waiting for the export to finish - cheap poll calls, not active compute.

Most importantly, the output schema is identical. The CSV columns match what the old per-device loop assembled, so nothing downstream; dashboards, warehouse tables, alerting, has to change. You swap the acquisition layer and leave everything else alone.

Side by side

Comparison	Operational Graph APIs	Recommended Export API (`exportJobs`)
Pattern	Per-device loop plus paging	Async export → download one file
API calls per run	~100,000	~15
Calls scale with	Number of devices	Nothing. The handshake remains fixed.
Runtime	~2.5 hours	~15 minutes
Concurrency	Threading required	None needed
Output schema	—	Unchanged and drop-in compatible
Net result	—	~6,000× fewer API calls ~10× faster runtime

Why it scales: Roundtrips, not bytes

Here’s the subtlety worth internalizing, because it’s easy to get wrong. There are two different costs in this job, and they scale on different axes:

The number of API calls - round-trips across the wire.
The volume of data - the actual compliance rows you move.

The data volume is the same either way. 50,000 devices × N settings is 50,000 × N rows, whether you assemble them from 100,000 little paged responses or receive them in one CSV. The export doesn’t move less data - it moves the same data. And yes, that file grows with both device count and setting count. More devices, bigger file; more settings, bigger file.

So the win isn’t fewer bytes. The win is fewer round-trips.

Every one of those 100,000 operational calls relies on authentication, TLS setup, network latency, and service-protection (throttling) accounting regardless of how much data it returns. Multiply that fixed overhead by 100,000 and it dominates everything. The export only pays that tax twice: once to start the job, once to download the file. Intune does the assembly server-side and streams you the result in a single bulk transfer.

That reframes the scaling story:

Call count is essentially constant - it doesn’t grow with devices or settings. It’s one job and one download.
Data volume grows with devices and settings but a bigger CSV is a bigger single download, not more calls. Bulk transfer is exactly what HTTP is good at.
Runtime has a mild data dependency: a larger fleet takes Intune a little longer to build the file. But you absorb that as a few extra seconds of poll-waiting, not as thousands of extra calls you have to orchestrate, retry, and throttle-manage.

What the IT admin actually gets

Beyond the raw speed, here’s the value that shows up in day-to-day operations:

Your maintenance window comes back. A 15-minute job leaves room for everything else.
Fewer moving parts to maintain. No custom throttling handler, no thread pool, no resumability logic. Less code is less to break at 2 a.m.
Reliability by design. Two roundtrips means two failure points, and the server does the heavy lifting of assembling a consistent snapshot.
Lower cost and lower service impact. Eliminating ~100,000 calls is easier on your tenant’s throttling limits and a better citizen for the Intune service overall.
Room to grow. Because call count is decoupled from device count, doubling the fleet doesn’t double the job, you just download a somewhat larger file.
No downstream disruption. Same schema for the output means the migration is contained to the ingestion step which is a low-risk swap, not a re-platforming.

When to use which

The export API isn’t a universal replacement, it’s best used for bulk, point-in-time snapshots:

Reach for exportJobs when you need the whole fleet’s state (or a large, filtered slice) on a schedule such as nightly compliance loads, audit exports, warehouse hydration.
Stick with the operational endpoints when you need a single device right now, an interactive “check this one device” lookup, or a real-time remediation trigger where waiting on an async job doesn’t make sense.

The two are complementary. The mistake isn’t using the operational APIs, it’s using them in a loop to reconstruct something the export API will hand you in one file.

The takeaway

The per-device loop feels natural because it mirrors how we think about devices, one at a time. But at fleet scale, the question isn’t “what’s the state of this device?” a hundred thousand times over. It’s “give me the state of everything,” once. The export API is built for exactly that question, and answering it the right way turned a multi-hour nightly grind into a coffee break - from ~100,000 calls to about 15, ~10× faster, with zero downstream changes.

If you have any questions, leave a comment below or reach out to us on X: @IntuneSuppTeam!

Designing Intune enrollment for frontline workers: Choosing the right path for real-world devices

Intune_Support_Team — Thu, 23 Jul 2026 16:59:40 GMT

By: Shawn Catlin – Senior Product Manager | Microsoft Intune and Sucheta Gawade, Microsoft MVP (Azure & Security / Intune)

Practitioner perspective from Sucheta Gawade, Microsoft MVP (Azure & Security / Intune), with deep experience in secure frontline mobility, including regulated healthcare environments.

Enrollment methodology is one of the most consequential design decisions teams make for frontline environments. It shapes how devices are used, how identity is handled, how failures are recovered from, and how much friction workers experience before they can do their jobs.

Frontline use cases aren’t limited to shared devices. They can span nearly every enrollment type available in Microsoft Intune, including user-assigned, shared, dedicated, kiosk, corporate-owned, BYOD, and zero-touch deployment models. The right choice is often influenced by business need, operational workflow, budget, support model, and security requirements. But it must also account for platform and operating system design. Android, iOS, and iPadOS may offer similar enrollment concepts, but they don’t always behave the same way or support the same management patterns.

That distinction matters. A kiosk or dedicated-device model, for example, is intentionally designed for a locked-down, task-focused experience. It manages the device around a specific function, not around a personalized user workspace. In that model, broad app availability, persistent personalization, and user-driven app installation are not the primary management paradigm. Similarly, a shared-device model should not be selected simply because an organization cannot provide a dedicated device to every worker. If identity, app access, compliance, or user context are required, those needs must be part of the enrollment decision from the beginning.

There is no copy-and-paste frontline enrollment strategy that works across every industry, business unit, or device scenario. Some frontline devices are shared across shifts and must remain reliable where connectivity, identity, and support are not guaranteed. Others are assigned to supervisors, clinicians, field workers, or shift leads who need persistent access to apps, settings, and data. When enrollment choices are made without accounting for these realities, especially platform differences and OS-level limitations, friction surfaces quickly during pilots and scales painfully during rollout.

This article explains how to approach Intune enrollment for frontline devices through a practical, reality-first lens: start with how the device is used, align the management model to the workflow, and then plan how the device will be enrolled, replaced, and reprovisioned at scale.

In a hospital environment, frontline does not mean one type of device or one type of worker. A shared clinical workstation, a nurse’s mobile device, a patient check-in kiosk, a barcode scanner, and a supervisor’s assigned device may all be considered frontline, but they each have very different identity, security, app, and recovery requirements. That is why enrollment decisions have to start with the workflow.

Sucheta Gawade
Practitioner

Enrollment Is a Design Decision, not a Checkbox

Enrollment does more than bring a device under management. It defines how the device is expected to work, where the security boundary sits, how identity is applied, and what recovery looks like when something fails in the field.

There is no single “best” enrollment model for frontline. There is only the model that best fits how the device is actually used. The right choice depends on whether the device follows a person, a shift, a task, or a business process. It also depends on how much identity matters to the experience, whether apps need to be personalized, whether Conditional Access or compliance is required, and how quickly the device must be replaced or recovered.

This is why many problems that look like policy, app, or configuration failures are actually enrollment design problems in disguise. A device can be successfully enrolled and still be poorly designed for the job it needs to do.

A device can be successfully enrolled and still fail the workflow. If a shift worker cannot access the right app quickly, if a shared device retains the wrong user context, or if a replacement device cannot be brought online during a shift, the issue may look like an app or support problem. In reality, it often traces back to an enrollment model that did not match the workflow.

Sucheta Gawade
Practitioner

Separate Two Decisions: Management Model and Provisioning Method

Frontline enrollment planning becomes easier when teams separate two related but different decisions.

The first decision is the management model. This is the architectural choice. It answers questions such as:

Does the device need to represent a specific person?
Is the device shared across multiple workers?
Is it dedicated to a narrow task or workflow?
Does the device require personal apps, persistent settings, or user-specific data?
Does the workflow require Conditional Access, compliance, auditability, or individual identity?

This decision determines whether the device should be user-associated, shared, dedicated, kiosk-style, personally owned, or corporate-owned with a work profile.

The second decision is the provisioning and reprovisioning method. This is the lifecycle choice. It answers questions such as:

How will the device get into management the first time?
Will it be staged by IT, a depot, a partner, or the site?
What happens after a wipe, repair, refresh, or reassignment?
Can the device recover without a specific user’s credentials?
Will Wi-Fi, certificates, tokens, apps, and policies be available at first boot?

Zero-touch, pre-staging, depot workflows, and reprovisioning plans support the selected management model. They should not replace the decision about which model is right for the scenario.

Start With How the Device Is Used

In the previous article, Migrating Frontline Mobile Devices: Understanding the Reality of Your Estate, we discussed why successful frontline migrations begin with understanding how devices are actually used in the field. That discovery work should now feed directly into enrollment design.

The most reliable starting point is not the department, license, or ownership model. It is the device’s behavior in the field.

Ask:

Does this device follow a person?
Does it follow a shift?
Does it follow a task?
Does it need to know who the user is?
Does it need persistent user context?
Does it need to be quickly replaced with minimal IT involvement?
Does the platform support the experience you expect?

The answers help map real-world requirements to the right Intune enrollment approach. Before selecting an enrollment model, organizations should also understand how identity is expected to function on the device. If you have not yet reviewed assigned versus shared identity patterns, see our previous article, Migrating frontline mobile devices: Identity considerations for assigned and shared devices, which explores how user identity, authentication, auditability, and device ownership assumptions can influence frontline management decisions.

Decision indicator	Usually points toward	Validate before choosing
One person regularly uses the device and needs persistent apps, settings, approvals, or data	User-driven or user-associated enrollment	Whether identity and personalization are truly required for the workflow
Multiple workers use the same device across shifts and need individual sign-in	Shared or device-first enrollment with identity support	How sign-in, sign-out, session cleanup, and auditability will work
The device performs a narrow, repeatable task	Dedicated or kiosk-style enrollment	Whether the workflow can operate with a locked-down app set and minimal user choice
The device needs corporate control but may allow limited personal use	Corporate-owned work profile where supported	Whether the OS supports the expected separation between work and personal data
The device is personally owned and only work data needs to be protected	BYOD / personally owned work profile / user enrollment	Whether the workflow can tolerate limited organizational control
The device must be replaced quickly with minimal IT involvement	Pre-staged, zero-touch, or easily reprovisioned device-first model	Reset behavior, network readiness, certificate delivery, and replacement speed
The environment has inconsistent connectivity or limited support	Simpler enrollment paths with fewer live dependencies	What the device needs at first boot, during sign-in, and after wipe or reset

Map Frontline Scenarios to Enrollment Models

A practical Intune strategy starts by accepting that frontline is not one scenario. It is a collection of scenarios. Standardization is important, but standardizing on one enrollment method for every frontline use case is rarely the right goal. Mature organizations standardize the decision framework, not necessarily the deployment model.

Device usage pattern	Typical characteristics	iOS/iPadOS enrollment	Android enrollment
User-assigned device	One person regularly uses the device and needs personalized apps, settings, and data	Automated Device Enrollment with user affinity	Android Enterprise Fully Managed or Corporate-Owned Work Profile if personal use is permitted
Shared device with individual sign-in	Multiple workers share the device and sign in with their own identities	Automated Device Enrollment with Microsoft Entra Shared Device Mode; Shared iPad when multi-user iPad support is required	Android Enterprise Dedicated Device with Microsoft Entra Shared Device Mode
Dedicated or task-based device	Device performs a specific function and does not require a personalized user experience	Automated Device Enrollment without user affinity, with supervised device and app restrictions	Android Enterprise Dedicated Device
Android device without Google Mobile Services	Corporate-owned specialty device, often shared or task-focused	Not applicable	Android AOSP userless or AOSP user-associated enrollment
Personally owned device	Employee-owned device used for work	BYOD User Enrollment	Android Enterprise Personally Owned Work Profile
Zero-touch or pre-staged deployment	Corporate-owned device that needs scalable provisioning or replacement	Automated Device Enrollment through Apple Business Manager or Apple School Manager	Android Zero-touch Enrollment, Samsung Knox Mobile Enrollment, or equivalent supported provisioning path

If the device follows a person, choose a model optimized for identity and personalized access. If the device follows a shift, workflow, or task, choose a model optimized for simplicity, consistency, and easy replacement.

If you’re looking for more platform-specific guidance please see frontline enrollment resources for both Android and iOS/iPadOS:

These resources provide detailed implementation guidance, recommended enrollment approaches, and platform-specific considerations for frontline deployments.

Platform and OS Differences Matter

Teams often assume that similar enrollment concepts behave the same way across platforms. They do not.

On Android, a shared frontline device that needs a locked-down experience and individual worker sign-in often maps to Android Enterprise Dedicated Device with Microsoft Entra Shared Device Mode. Android Enterprise Dedicated Device provides the task-focused management model. Entra Shared Device Mode adds the identity layer so workers can sign in as themselves. Intune Managed Home Screen then helps present a consistent launcher experience and enforce the sign-in flow between shifts.

On iPadOS, a shared device with individual sign-in may be designed using Shared iPad for Business or Automated Device Enrollment with Microsoft Entra Shared Device Mode. The distinction becomes important when security requirements are involved. Shared iPad can support multi-user scenarios, but organizations should review its limitations carefully, especially if Conditional Access or device compliance enforcement is required. Where Conditional Access, compliance, and security-driven access controls are mandatory, ADE with Entra Shared Device Mode may be the better fit, although it introduces additional configuration considerations and dependency on compatible apps. See Shared iOS and iPadOS devices for more information.

Platform differences also matter for corporate-owned devices that allow personal use. Android Corporate-Owned Work Profile provides a native work profile boundary between corporate and personal data. iOS and iPadOS do not provide that same OS-level separation for corporate-owned personally enabled devices, so organizations often rely more heavily on app-level controls and MAM policies.

The practical point is simple: choose the enrollment model that fits the workflow, but confirm that the platform supports the management pattern you expect.

One of the most common mistakes I have seen is designing for the cleanest administrative model instead of the messiest operational reality. In FLW cases, the real test is not whether the device enrolls successfully on day one. It is whether the device can keep supporting the workflow after shift changes, network changes, app issues, wipes, repairs, and urgent replacements.

Sucheta Gawade
Practitioner

When User-Driven Enrollment Makes Sense

User-driven enrollment still has a place in frontline, but the use cases are narrower than many teams expect. It makes sense when the device needs to reflect a specific person, not just a task.

This can work well for shift managers, supervisors, clinicians, field workers, or frontline leads who need persistent access to apps, approvals, notifications, data, and settings. In these cases, user-driven or user-associated enrollment can provide cleaner app targeting, stronger identity context, and a more familiar experience for the person carrying the device.

Common indicators include:

The worker keeps the device for most of its working life.
The user needs email, Teams, approvals, or real-time app badges.
The workflow depends on user-specific apps, settings, or data.
The device may support some personal enablement where the platform supports separation.
The worker is responsible for keeping the device available, charged, and ready for use.

But personalization comes with operational cost. User-driven enrollment increases dependency on credentials, adds friction when sign-in steps fail, and makes recovery more complex when a device must be replaced quickly. It is usually a poor fit for shared workflows, high-turnover roles, or task-based devices where speed and predictability matter more than personalization.

Designing for Shared and Shift-Based Devices

Shared and shift-based devices are passed from one worker to the next. They are expected to stay productive across handoffs and often operate in environments where there is little time for sign-in friction or troubleshooting.

For these scenarios, device-first enrollment usually aligns better with reality because the device is treated as a managed tool for a shared workflow, not as a personal endpoint tied to one individual. The goal is consistency: the next worker should be able to pick up the device, authenticate if required, and get to work without recovering from leftover state or complex setup steps.

If shared devices require individual sign-in, identity must be designed into the enrollment model. Microsoft Entra Shared Device Mode and QR code authentication can help preserve individual identity without forcing workers through a full username and password flow at every handoff. This is especially relevant in environments such as retail, healthcare, warehousing, and field operations where shared devices still need auditability, Conditional Access, app access, or user-specific sessions.

Shared-device success does not come from default settings alone. Teams should define:

How sign-in and sign-out should work.
What user context should persist.
What should be cleared between sessions.
Which apps need to support shared-device behavior.
How quickly a device can be swapped or reprovisioned.
Whether access depends on the user, the device, the app session, or a combination.

Especially in healthcare and clinical settings, shared devices have to be absolutely ready for the next worker, the next patient, and the next task. There is rarely time for complex recovery steps, unclear ownership, or leftover user state from the previous shift. A good shared-device design should support quick handoff, clean session behavior, and predictable recovery under pressure.

Sucheta Gawade
Practitioner

Dedicated and Kiosk Devices: Avoid Personalization Drift

Dedicated and kiosk-style enrollment is ideal when the device performs a narrow, repeatable function and individual identity is secondary or unnecessary. Examples include scanners, point-of-sale systems, check-in kiosks, digital signage, inventory devices, and task-specific handhelds.

The strength of kiosk-style design is that it limits choice. That is also the boundary teams must respect. A kiosk is not intended to behave like a general-purpose device where users browse a catalog of available apps, personalize settings, or install what their business unit needs on demand.

A common friction point occurs when organizations try to simplify IT support with one shared kiosk configuration for multiple businesses or personas, and then expect users to install the apps they need. That creates a mismatch. User-installed available apps are not the kiosk paradigm. If each business unit needs a different set of apps, the better design is usually to do the work upfront: segment the device scenarios, define the required app sets, and deploy the right configuration to the right devices.

This is also important for identity and certificates. User certificates, persistent user sessions, and shared secrets can conflict with the assumptions of a device-first or kiosk model. If the workflow requires user identity, auditability, or user-specific access, that requirement should be addressed through the right shared-device identity pattern, not bolted onto a kiosk design after the fact.

Enrollment at Scale: Plan for Provisioning and Replacement

Once the right management model is selected, teams should plan how devices will be enrolled and reprovisioned at scale.

At scale, enrollment becomes a lifecycle capability. The question is not only how a device gets into management the first time. Instead, it is how quickly that same device can be staged, replaced, wiped, repaired, reassigned, or reintroduced into service.

Some organizations ship devices directly to frontline locations and complete setup during out-of-box experience. Others rely on depot, partner, or white-glove processes to front-load setup before the device reaches the site. Neither model is automatically better. The right choice depends on network readiness, site support, variability at first boot, app dependencies, certificate delivery, and replacement expectations.

Replacement velocity is a real design constraint. In many frontline settings, a broken device cannot wait for a full troubleshooting cycle. A worker may need to drop one device at a charging bay and pick up another with minimal disruption. The more the enrollment and reprovisioning model supports a known-good state, the less productivity depends on one specific device surviving the shift.

Common Friction Points in Frontline Enrollment

Frontline enrollment problems are rarely caused by one dramatic failure. More often, they come from reasonable decisions made in the wrong order or optimized for the wrong thing.

Friction point	Why it happens	Better design approach
Treating frontline as only shared	The organization assumes all frontline workers use devices the same way	Segment by workflow: person, shift, task, or business process
Choosing shared because dedicated devices are too expensive	Budget drives the model before identity and workflow are understood	Validate identity, app, compliance, and recovery needs before choosing shared
Using kiosk for personalized workflows	Kiosk seems simple and locked down	Use kiosk only when the workflow is task-focused and does not require broad personalization
Wanting available apps on kiosk devices	One configuration is used for too many personas	Build scenario-specific app sets and configurations instead of relying on user installation
Using shared credentials	Enrollment was not designed for individual identity	Use Entra Shared Device Mode, QR code authentication, or another supported identity pattern
Requiring user certificates on device-first or kiosk scenarios	Security assumptions are copied from knowledge-worker designs	Validate whether access can be controlled through device, app, or session design
Over-securing setup at the expense of recovery	Controls are designed for ideal conditions, not shift pressure	Design security that holds up during replacement, poor connectivity, and limited support
Treating enrollment as a one-time event	Success is measured by initial provisioning only	Design for wipe, repair, reassignment, refresh, and reprovisioning

A deployment path that saves time on day one can create years of friction if it does not match how the device is used. In frontline scenarios, the best enrollment model is not always the fastest one to provision. It is the one that is easiest to sustain.

One of the most common mistakes I have seen is designing for the cleanest administrative model instead of the messiest operational reality. In FLW cases, the real test is not whether the device enrolls successfully on day one. It is whether the device can keep supporting the workflow after shift changes, network changes, app issues, wipes, repairs, and urgent replacements.

Sucheta Gawade
Practitioner

Closing

Successful frontline deployments are rarely defined by the sophistication of their policies alone. They are defined by how well design choices hold up under real-world pressure. Enrollment is one of the earliest and most visible signals to frontline teams about whether the technology is there to support their work or get in the way.

By treating enrollment as a deliberate design decision and grounding it in how devices are actually used, organizations can reduce friction, improve resilience, and create a foundation that scales as frontline operations evolve. Getting enrollment right does not guarantee success, but getting it wrong sets a ceiling that no amount of policy refinement can overcome.

For more frontline examples and implementation guidance, see related Microsoft frontline worker management resources, including the blog, From the frontlines: Frontline worker management with Microsoft Intune, and the earlier article, Migrating Frontline Mobile Devices: Understanding the Reality of Your Estate.

When enrollment, identity, security, and recovery are designed well, frontline teams can stay focused on the people they serve - customers, patients, guests, employees, students, and communities - instead of the device in their hands. That is the standard a frontline enrollment strategy should be measured against.

Sucheta Gawade
Practitioner

As always, we welcome your feedback and experience. If you’ve navigated identity decisions for shared or frontline devices, share your advice and lessons learned in the comments, or reach out to us on X @IntuneSuppTeam.

Dell Firmware Very Slow to Appear in Intune Driver Updates

SenõrEngineer — Wed, 22 Jul 2026 08:56:43 GMT

Have an instance where the Dell 5520 latest firmware release (1.51.0 released 09/06/26) has still not appeared in the Intune Driver Updates which means we have vulnerable laptops in the field.

We do not utilise Dell Command update on the laptop to reduce the attack surface so do rely on Intune to deliver these updates in a timely manner.

I'm aware that it can take a little while for Dell releases to appear on the Microsoft side, but this is over 6 weeks now.

We have spoken to Dell Support, but they have deemed this a Microsoft problem. We then spoke to Microsoft Support, and it was deemed that we would have to pay for support on this given it fell outside of the scope of our service level. So essentially no-one wanted to take responsibility or assist with this!

Does the forum have any insights into what may be going on here and how we can move this forward?

Bitlocker key requested on the boot, but I don’t have any key

Yann1 — Mon, 20 Jul 2026 10:22:27 GMT

My laptop (Windows 10, version 22H2, build 19045), that I have been using more than 6 years already, suddenly started asking for the BitLocker recovery key at startup, which is blocking access to the system entirely.

What I've already checked/tried:

- Checked account.microsoft.com/devices/recoverykey while signed in with my Microsoft account, no key appears for this device.

- Contacted Microsoft Support directly, they said they can no longer assist with Windows 10 issues and suggested posting here instead.

Is there any way to recover access to this drive?

Microsoft EPM – Random CMD / PowerShell / OpenConsole popups

silasst — Mon, 20 Jul 2026 08:35:45 GMT

Hello everyone,

we are currently testing Microsoft Endpoint Privilege Management (EPM) and are seeing some unexpected behavior on several devices.

Symptoms

Users occasionally see random:

CMD windows
PowerShell windows
OpenConsole windows

The windows usually appear shortly after logon and disappear automatically after a short time.

Some developers also reported issues related to:

VS Code terminal integration
Copilot terminal actions
Windows Terminal
WSL / Debian

Additional observations

However, we have also seen PowerShell popups on a user who is not currently part of the EPM pilot group
Some affected devices still have Admin By Request installed

Current EPM Configuration

At the moment we only have an Elevation Settings Policy assigned with User Confirmed enabled.

We currently do not have any custom elevation rules, file hash rules, publisher rules or automatic elevations configured.

The issue appears in a configuration that is essentially limited to:

EPM client installed
Elevation Settings Policy assigned
User Confirmed elevation workflow enabled

This is one of the reasons why we are unsure whether the behavior is directly related to an EPM policy configuration or to an interaction between:

EPM agent
Windows Terminal / OpenConsole
VS Code
WSL
Admin By Request

Questions

Has anyone experienced random CMD / PowerShell / OpenConsole windows after introducing EPM?
Has anyone seen issues between EPM and:
- Windows Terminal
- OpenConsole.exe
- VS Code terminal
- WSL
Has anyone run Admin By Request and Microsoft EPM on the same device and observed unexpected console windows?
Are there any EPM-specific logs that provide detailed parent/child process relationships for these launches?

Any ideas or similar experiences would be greatly appreciated.

Thanks!

Is it possible to automate Minimum Windows OS version compliance policy?

Modechristo_13 — Fri, 17 Jul 2026 06:17:56 GMT

Is it possible to set a Windows compliance policy for Minimum OS Version that automatically updates each month and marks the device noncompliant after 14 days?

This would work if we normally allow users 2 weeks after Patch Tuesday to get their device updated. We would like to avoid having to have someone remember to manually edit the compliance policy every month to update the minimum build number in the policy.

Android Fully Managed devices treated as personal after AD password change

dammas — Sun, 12 Jul 2026 17:39:36 GMT

Hello!

We have a huge problem...

We have recently observed an issue in our organization affecting Android Fully Managed devices.

After users change their domain password, within 1–3 days Conditional Access starts blocking access to Outlook and Teams. The system appears to treat the device as non-corporate, even though in Intune the device is still present, marked as corporate, and fully functional. It synchronizes both manually and automatically, and remote actions can be executed without any issues.

However, when users open Outlook or Teams, they receive messages such as “We need to secure your device” and “Install the Intune app from Google Play,” which does not make sense because Intune is already installed on the device.

When opening the Intune app, users see a “Update your password” prompt. After selecting it, they are redirected to a device registration screen.

Previously, it was sometimes possible to complete this process (although we did not understand why it was required), but recently re-registration consistently fails. The user clicks “Register,” and the process spins indefinitely without completing.

This issue is very difficult to troubleshoot. Device logs are not particularly helpful, and all users have Microsoft Authenticator configured. The problem appears randomly across users with no clear pattern—some devices were enrolled over a year ago, others just a month ago.

The only clue we have found so far points to a potential issue with the broker authentication token, but we do not know how to verify or resolve this, nor why it is happening in the first place.

We have been experiencing this issue since around January this year, but we noticed a significant increase in cases this month. In addition, there are more and more devices that can no longer be re‑registered from within the Intune app.

Has anyone encountered a similar issue or can provide guidance on how to investigate or fix this?

Configuration Manager manifest synchronization failing since 8 July 2026

rajha1750 — Fri, 10 Jul 2026 12:28:01 GMT

Has anyone else experienced Configuration Manager Updates and Servicing synchronization failures since 8 July 2026?

We have three independent Microsoft Configuration Manager hierarchies:

Test environment

Production T0 environment

Production T1 environment

All three started showing the same SMS_DMP_DOWNLOADER error during the last three days.

The affected request is sent to:

https://sccm.manage.microsoft.com/SCCMConnectedService.svc/Manifest

Configuration Manager builds a hierarchy-specific request containing the Tenant, Version, Ring, and Branch parameters. However, the endpoint now returns only:

The resulting file is:

ConfigMgr.Update.Manifest.cab Size: 2 bytes Hex: 4F 4B Content: OK

Because this is not a valid signed CAB file, dmpdownloader.log records:

manifest.cab (http response) size is 2 Error in verifying the trust of file ConfigMgr.Update.Manifest.cab' WARNING: Failed to call IsFileTrusted WARNING: Failed to download and verify the manifest.cab. We cant get info in Updates and Servicing mode.

Build a patch strategy for today’s threat pace with Microsoft

Intune_Support_Team — Fri, 10 Jul 2026 17:18:27 GMT

AI-accelerated vulnerability discovery and remediation are changing how organizations manage risk. As discussed in Pavan Davuluri’s recent blog, Microsoft is investing across the vulnerability lifecycle to help organizations identify, validate, and respond faster.

For IT and security teams, one challenge lies downstream: deploying fixes quickly across endpoints to reduce exposure. Each update needs to be evaluated, piloted, monitored, and enforced across a mixed fleet of devices and apps. Some parts of the estate can move quickly; others cannot because of compliance requirements, approved change windows, and business-critical dependencies.

As organizations adopt AI tools and agents across their environment, maintaining a current and hardened endpoint estate becomes increasingly important. In this context, patching becomes an ongoing operational discipline that combines OS, app, and driver updates with compliance enforcement, access control, and security baseline hardening.

To keep pace, organizations need a patch strategy that helps in 3 stages:

Mitigate: automate updates that can move quickly
Assess: prioritize risk based on exposure and severity
Contain: enforce compliance and limit exposure

Operationalizing a patch strategy requires coordinated capabilities across endpoint management and security tools. Microsoft Intune brings these capabilities together in a single admin center, alongside the broader Microsoft security ecosystem, and is available with qualifying Microsoft 365 subscriptions¹.

In this post, we show how organizations can use these capabilities to build a patch strategy that helps reduce the time between update release and deployment across their endpoint estate.

1. Mitigate: automate updates that can move quickly

A patch strategy is not about pushing every update everywhere at once. It’s about identifying the parts of your estate that can move quickly, then using automation, rings, monitoring, and enforcement to help those updates move with confidence. Regulations, approved change windows, validation needs, and business dependencies will shape what’s possible, but the strategy starts by separating repeatable update work from the exceptions that need deeper review.

For OS, app, and driver updates that can move quickly, modern tools can help shorten the time between update release and deployment; without manual rollouts, ticket-driven packaging, or reboot disruption.

Operationalize in Intune

Windows Autopatch orchestrates ring-based update rollouts to reduce manual effort and keep Windows devices current. To help monitor risk, the Autopatch report visualizes how quickly devices apply updates based on the configured deployment cadence. In this report, devices are categorized as current within three days of update release, at risk between three and seven days, and at critical risk beyond seven days, based on the reporting model used by Windows Autopatch. Learn more about ring-based rollout updates or how to reassess Windows OS updates using this report.
Hotpatch (enabled by default for 24H2+ in Intune) applies critical updates without requiring a reboot, helping reduce security gaps while keeping users productive.

Figure 1: Watch the latest Microsoft Mechanics episode to see how Windows Autopatch and Hotpatch help organizations accelerate update deployment, reduce operational overhead, and keep devices secure.
Intune Enterprise App Management (EAM) supports keeping Windows apps current through auto-updates, including the guided upgrade supersedence reporting, which surfaces outdated versions or version changes. EAM auto-updates are now generally available; details are included in the June Intune What’s new blog.

Figure 2: Watch how Intune helps you move from update release to deployment to accelerate responses to vulnerabilities with Windows app management.
The enhanced application inventory in the All apps page shows the app version installed on each managed Windows device, refreshed multiple times per day on most active devices, helping teams target app-specific vulnerabilities and confirming when fixes have been applied.
The Vulnerability Remediation Agent in Security Copilot uses data from Defender Vulnerability Management to prioritize Common Vulnerabilities and Exposures (CVEs) across Intune-managed Windows devices and apps, and provides recommended remediation actions within Intune. The Vulnerability Remediation Agent is currently in public preview, read the blog to learn more.

Figure 3: Watch this video to see how the Vulnerability Remediation Agent in Security Copilot, within Microsoft Intune, helps make agentic security easier to adopt and use.

Extend across your endpoint estate

Apple devices can be configured for automatic OS updates on managed devices, including enforcing updates to the latest version and deploying Background Security Improvement patches through the settings catalog. App updates can be managed by configuring volume-purchased App Store apps to update automatically and deploy updated app packages to keep apps current across macOS, iPhone, and iPad devices.
Android devices can be managed using built-in update policies in Intune, including configuring install windows and freeze periods. For corporate Android fleets, Intune also integrates with OEM firmware management solutions - including Zebra LifeGuard Over-the-Air and Samsung E-FOTA - to enable more granular update control. Managed Google Play also supports configurable app auto-update modes, allowing admins to define whether updates install automatically, on Wi-Fi only, or manually.

2. Assess: prioritize risk based on exposure and severity

The first step is reducing exposure across the parts of your estate that can move quickly. But not every system, application, or vulnerability can be addressed through broad update deployment. Teams also need a way to determine which risks require immediate action and which ones can be addressed over time.

A calendar-based approach can treat every CVE equally. However, it doesn’t account for severity, exposure, or business impact. As AI accelerates vulnerability discovery, this can lead to effort being spent on lower-risk updates while higher-risk updates remain unaddressed.

Risk-based service level objectives (SLOs) help bring prioritization to address this challenge. Instead of patching on a fixed schedule, IT and security teams can align response timeframes by severity, moving quickly on actively exploited or critical vulnerabilities, and applying a more measured approach where risk or impact is lower.

This stage creates a clearer prioritization of remediation and helps bridge the view between the security teams that identify threats and the IT teams that act on them.

Operationalize in Intune and Microsoft Defender

The security update status dashboard in Intune provides an aggregated view of update compliance across Windows clients, Windows servers, and Microsoft 365 Apps. It shows overall counts of devices in different states across Intune-endpoints and helps teams identify where remediation should be focused. These status categories reflect how quickly devices apply updates based on a configured deployment cadence and internal SLOs.

Figure 4: Security update dashboard showing patch status for Windows clients, servers, and Microsoft 365 apps.
Microsoft Defender Vulnerability Management surfaces CVEs, affected devices, vulnerable software, and recommended remediation actions, offering a shared view of risk and progress across IT and security teams.
Translate Defender recommendations into targeted Intune actions described in the mitigate section, such as updating software or moving devices through expedited remediation workflows so teams can focus on vulnerabilities that are actively exploited or most likely to affect an organization.

Extend across your endpoint estate

For Apple devices, use the Apple software update report in Intune to monitor update status across macOS, iOS, and iPadOS.
For Android, compliance reporting surfaces devices that fall behind on OS version or security patch level.

3. Contain: enforce patch compliance and limit exposure

Even with automated deployments and prioritized triage, gaps can remain. Some devices are unsupported, fall behind, operate on slower deployment rings, and others can’t be patched quickly. A patch strategy needs to focus on including containment for those surfaces.

Compliance controls, conditional access, and device hardening act as an always-on safety net that limits risks that can fall through gaps. Compliance policies and Conditional Access can use a patch state as a signal for resource access, preventing non-compliant devices from accessing corporate resources. Security baselines reduce the attack surface by limiting risky defaults and common attack patterns. Together, these controls shift enforcement from a periodic activity to a continuous condition across a fleet.

Operationalize in Intune and Defender

Use compliance policies in Intune to define what "current" means, including minimum OS build, required update levels, risk status, and encryption state.
Use Conditional Access (managed in Microsoft Entra, accessible from the Intune admin center) to control access to company resources based on user and device health. Combined with threat signals from Microsoft Defender, these policies help prevent non-compliant devices from accessing corporate resources.
Use Microsoft Defender Vulnerability Management and Microsoft Security Exposure Management insights to identify exposed assets, prioritize remediation, and apply recommended protections where patching must move more slowly.
Apply Intune security baselines to establish Microsoft-recommended configurations on Windows devices, such as disabling risky defaults, blocking common attack techniques, and reducing configuration drift. Watch this demo on security baselines being applied in the Zero Trust workshop.
Use attack surface reduction policies in Intune to deploy Microsoft Defender for Endpoint protections, such as ASR rules and network protection, that help block common attack techniques on devices that can't be patched right away.

Figure 5: Watch this Demo on how you can manage devices and implement Conditional Access with Intune.

Extend across your endpoint estate

Compliance policies and Conditional Access controls apply across Windows, macOS, iOS/iPadOS, and Android.
Intune app protection policies extend compliance requirements and data protections to managed apps used for work on personal devices and add an additional layer of data protection on corporate devices.
Use the settings catalog and configuration profiles to apply the same hardening intent on macOS, iOS/iPadOS, and Android, reducing configuration drift across platforms.

Stay ahead with a patch strategy

As vulnerability discovery and response continue to accelerate, organizations need an operational strategy that balances speed, risk, and resilience. By automating updates where possible, prioritizing remediation based on exposure, and limiting exposure through compliance and security controls, teams can reduce risk across their endpoint estate.

Intune helps simplify this approach by bringing these capabilities together alongside the rest of your Microsoft security tools and ecosystem.

Get started with Microsoft Secure Now to assess risk across your digital estate.
Explore the new security update status dashboard in Intune.
Harden the admin plane and review the best practices for securing Microsoft Intune.

¹ Licensing and requirements

Feature availability and included capabilities vary by Microsoft 365 subscription plan and feature. Some Microsoft capabilities referenced in this post may require specific licenses or additional enablement.

Advanced Microsoft Intune capabilities are now included in Microsoft 365 E5, with select capabilities available in Microsoft 365 E3 as part of updates effective July 1, 2026. Existing customers will receive a 30-day notice in the Microsoft Admin Center prior to availability, with access beginning by August 2026.

Microsoft Security Copilot and related AI capabilities may require separate licensing, learn more here.

Stay up to date! Bookmark the Microsoft Intune Blog and follow us on LinkedIn or @MSIntune and @IntuneSuppTeam on X to continue the conversation.

Autopatch for quality updates and WUFB for feature updates

demion — Thu, 09 Jul 2026 09:00:56 GMT

We have switched to Autopatch for quality updates in our environment, but now is the time for feature update deployments. In the past we had used Windows Updates for Business for feature update without any problem. We would like to deploy the feature updates and retain the control of the target groups through the process, which are different ones from the quality updates. As the content is much bigger, we would like to test to specific users, after communicating to them for the procedure, and also be sure that the availability and the bandwidth will be adequate specially now during summer holidays. Could we still use WUfB only for the feature deployment along with Autopatch, without intervening to the normal monthly update cycle?

Cannot delete a website shortcut by Intune managed iphone

rredford — Wed, 08 Jul 2026 12:16:14 GMT

We manually created a shortcut to a website from Safari browser and the shortcut is on the Intune managed iPhone. We don't need the shortcut now.

However we cannot delete it. Press and hold apps on this phone does not start wiggle mode and we cannot drag the shortcut onto a new home screen. We also cannot see it in the Apps list in Intune to delete either because it was manually added on that specific iPhone. Can you tell me if there is a away to delete the shortcuts please?

Kind regards

Rob

Automatically Sync SharePoint Document Libraries on macOS

ynarvil — Mon, 06 Jul 2026 13:01:11 GMT

Hi everyone,

We manage macOS devices with Microsoft Intune and need to automatically sync one or more SharePoint document libraries to users' OneDrive, similar to how it's done on Windows using the Intune auto-sync policy.

Has anyone successfully implemented this on macOS using Intune, Jamf Pro, configuration profiles, or a supported script?

We're looking for a Microsoft-supported solution that minimizes or eliminates user interaction.

Any guidance or recommendations would be greatly appreciated. Thanks!

Migrating frontline mobile devices: Identity considerations for assigned and shared devices

Intune_Support_Team — Wed, 01 Jul 2026 18:00:50 GMT

By: Carol Burns - Principal Product Manager | Microsoft Intune and Sucheta Gawade, Microsoft MVP (Azure & Security / Intune)

Practitioner perspective from Sucheta Gawade, Microsoft MVP (Azure & Security / Intune), with deep experience in secure frontline mobility, including regulated healthcare environments.

In previous articles in this series, we focused on understanding the reality of your frontline device estate and preparing for real-world testing through stakeholder alignment. One of the most critical areas to get right during the testing phase is identity and security, particularly given the often fast-paced, shift-based nature of frontline work, where organizations must account for the distinct requirements and challenges of devices assigned to a single individual versus devices shared across multiple users or shifts.

Identity decisions directly affect security posture, sign‑in experience, operational support overhead, and worker productivity. Getting them wrong is one of the most common reasons pilots stall or fail.

This article explores how to think about identity on frontline devices by distinguishing between assigned and shared usage models, clarifying when individual sign-in is required, and highlighting patterns to avoid such as shared accounts and passwords.

Start by distinguishing device usage models

Frontline mobile devices generally fall into one of two broad categories.

Assigned devices

Assigned devices are issued to a specific individual, often for the duration of their role. These devices:

Typically require persistent access to user‑specific data
Align with user‑based identity, Microsoft Entra ID Conditional Access, and audit controls.
Enable greater accountability and traceability by associating activity with an individual user rather than a shared credential.

Common examples include:

A doctor using an individually assigned clinical tablet, where uninterrupted access to patient data and clinical systems is essential and actions must always be attributable to a named identity
A field engineer assigned a single device that retains configuration, credentials, and offline content across jobs and locations
An inspector or supervisor using an assigned device for approvals, reporting, and decision‑making that requires traceability

Shared devices

Shared devices are used by multiple people across shifts or tasks. These scenarios introduce additional identity complexity and generally fall into two distinct models.

Shared devices without user sign-in (task or kiosk-based)

Some frontline devices exist to perform a narrow, often repetitive task and don’t require sign in with a user account.

Typical examples include:

Retail price-check devices used on the shop floor to scan an item and display its current price or stock availability, with no need for access to personal or user-specific information
Environmental monitoring devices used to read and record temperature or humidity in a storage area, ward, or vehicle, where the task is simple, repetitive, and not tied to an individual user identity
Warehouse or facility scanning devices used for a narrow operational task such as scanning an asset, bin, or location code to confirm status, location, or completion of a step in a process

In these cases:

Devices are locked down to a specific task
No user-specific data is stored, and access is limited to the minimum required for the task

“When a device is truly task-only, removing sign-in friction is a huge win, but only if we’re aware what data the device can access. When things like patient context or personalized tasks enter the picture, identity becomes required” - Sucheta Gawade, Microsoft MVP

Shared devices with individual user sign-in

Organizations are increasingly digitizing and modernizing frontline workflows end-to-end. Paper processes and simple apps give way to connected systems, manual handovers are replaced with digital task lists, and workers begin to rely on mobile devices as their primary interface from completing tasks.

As roles evolve, workers are expected to:

Receive tasks, schedules, and updates digitally
Communicate with supervisors and peers using collaboration tools such as Microsoft Teams
Capture information at the point of work rather than transcribing later
Interact with workflows that are increasingly automated or assisted by AI, such as guided steps, data validation, or suggested actions

This shift delivers clear productivity and quality benefits, but it also means access must now be tied to individual identity to protect sensitive data, support auditability, and prevent information from being carried over between users.

Common scenarios include:

Retail store associates rotating across shifts, moving from paper schedules and verbal handovers to digital task lists, real-time communications, and collaboration tools such as Microsoft Teams
Nurses sharing mobile devices in a hospital ward, where paper notes and whiteboards are replaced with secure access to patient-linked applications, care coordination tools, and role-based alerts
Logistics workers signing in to shared devices to complete role-based tasks, capture data at the point of work, and interact with AI-assisted workflows.

Don’t use shared credentials, always prefer individual sign-in

Shared credentials may seem like a shortcut in frontline environments, but they undermine accountability and make policy enforcement and incident response significantly harder.

“Shared credentials feel ‘efficient’ until your first incident. You lose auditability, Conditional Access becomes meaningless, and investigations turn into guesswork. Individual identity is the only scalable model.” -Sucheta Gawade, Microsoft MVP

If access involves corporate systems or sensitive data, each worker should use their individual credentials to sign in, even on a shared device.

Identity decision checklist for frontline devices

Use the checklist to validate identity choices and confirm that the overall security posture matches the way the device is used.

Decision area	Indicators
Use individual sign-in	Users access personal or role-specific data. Auditability or compliance is required. Conditional Access or multifactor authentication (MFA) must be enforced. Applications rely on user identity.
Use kiosk-style or device-only identity	Devices perform a single task. No user-specific or sensitive organizational data is accessed. Workflows are entirely device-centric. Speed and simplicity outweigh personalization.
Avoid entirely	Shared usernames or passwords. Reused local accounts across shifts. MFA exclusions that weaken security without compensating controls.

Choosing the right sign‑in experience

The challenge in frontline environments is balancing:

Security requirements
Speed of access
Ease of use across shifts

“Frontline setups may fail because the sign-in flow doesn’t match reality. If authentication takes 60 seconds and the worker has to do it 30 times a shift, they’ll find a workaround.” -Sucheta Gawade, Microsoft MVP

Typing complex usernames and passwords repeatedly during a shift is often impractical on mobile devices. QR code authentication is one effective option for shared frontline devices, but it’s not the only supported approach. For other supported methods, see Microsoft Entra authentication methods overview.

QR code authentication

Microsoft Entra QR code authentication is designed for frontline workers to sign-in efficiently on shared Android and iOS/iPadOS devices without repeatedly entering usernames and passwords.

Note:

QR code authentication enables workers to sign in using a unique QR code and a personal numeric PIN.

This approach:

Eliminates typed usernames and passwords
Preserves individual identity
Works well for shared devices with frequent user turnover
Integration with Microsoft Intune, Managed Home Screen and Conditional Access

QR code authentication should always be:

Scoped to specific users and devices
Combined with Conditional Access policies
Evaluated during real‑world testing to ensure the right balance of usability and security

Security posture and Conditional Access for frontline devices

Individual identity is a critical foundation for stronger security posture, but it’s not enough on its own. Frontline device security also depends on management, data and app protection, session handling, and access policies that reflect the actual usage model.

Conditional Access is an important part of securing frontline environments, but its effectiveness depends on aligning policies to the actual device and identity model in use.

To ensure that the QR code authentication method can only be used by the frontline workers it’s intended for, create a custom authentication methods policy, which you can use in a dedicated Conditional Access policy. That Conditional Access policy should then be scoped to the group of users (frontline workers) who should log on using the QR code authentication method, and have the Require authentication strength control configured, which targets the custom authentication strength for "QR Code" which was previously created.

During real‑world testing:

Validate that design and controls support the intended usage model
Ensure policies don’t block legitimate workflows
Confirm sessions, access, and user targeting behave as expected

These decisions should also be validated in practice: can users sign in and out reliably across shifts, is personal data cleared between sessions, and does the chosen experience match the pace of frontline work?

Summary

This article walks through how identity choices shape security, usability, and day-to-day success for frontline mobile devices. It explains the difference between assigned and shared devices, when individual sign-in is needed, and why shared credentials can create risk. It also highlights QR code authentication and Conditional Access as practical ways to keep each worker’s identity protected while making sign-in simple enough for fast-paced frontline workflows.

What’s next in the series

In the next article, we’ll focus on Microsoft Intune enrollment models, exploring how different enrollment approaches support—or constrain—the identity and usage patterns discussed here, including their role in protecting session identity, enforcing the intended sign-in model, and preventing one user’s access or data from carrying over to the next.

For more guidance across frontline scenarios, explore our broader From the Frontlines series on frontline worker management with Microsoft Intune.

Join our community! Discuss real-world scenarios, get expert guidance, connect with peers, and influence the future of Microsoft Security products. Learn more at aka.ms/JoinIntuneCommunity.