Intune Customer Success articles

Microsoft Intune and Apple OS 27: New settings, support, and platform changes

Intune_Support_Team — Thu, 24 Sep 2026 22:48:40 GMT

With Apple's release of OS 27, we’ve been working hard to ensure that Microsoft Intune provides support for Apple’s latest operating systems (OS) so that existing features work as expected, and adding support for new features that were introduced at WWDC.

We’ll continue to upgrade our service and release new capabilities that integrate elements of the new OS versions.

New DDM configurations and settings

With continued investments in the Intune data-driven infrastructure that powers the settings catalog, we’re able to provide day zero support for new OS settings as they’re released by Apple. We’ve updated the settings catalog to support newly released iOS/iPadOS and macOS settings for both declarative device management (DDM) and mobile device management (MDM) to empower your IT teams to have devices ready for the latest OS release. Configurations that have been updated include:

App settings (DDM)

Control which apps can launch on supervised iPhone, iPad, Apple TV, and Apple Vision Pro devices and which binaries can run on supervised Macs using allow and deny rules. Define organization-suggested privacy permission defaults for apps - including camera, microphone, Bluetooth, location, local network, dictation, and accessibility - to present users with a single consolidated consent prompt.

Intelligence settings (DDM)

Control Apple Intelligence capabilities, including Visual Intelligence, Writing Tools, Genmoji, Image Playground, app-specific features in Mail, Notes, and Safari, and requirements for on-device dictation and translation.

Accessibility settings (DDM)

Configure organization-defined accessibility preferences - such as display, text, motion, audio, and interaction options - so supported settings can be applied consistently on managed devices.

Safari settings (DDM)

Manage Safari behavior and privacy, including cookies, fraud warnings, history clearing, JavaScript, pop-ups, private browsing, summaries, new-tab start pages, and website camera or microphone permission defaults.

Siri settings (DDM)

Control Siri availability and behavior, including Siri AI features, user-generated content, access while the device is locked, profanity filtering, and reduction of sensitive content.

Content caching (DDM)

Configure the macOS Content Caching service to store Apple-distributed software and iCloud content locally, define the clients and networks it serves, and optimize parent, peer, storage, and network behavior to reduce internet bandwidth use.

DNS Proxy (DDM)

Configure a DNS proxy network extension to handle device DNS traffic, including the provider app and its vendor-defined settings, so name-resolution requests can be routed through an organization-approved service.

Web content filter (DDM)

Configure a plug-in-based web content filter to inspect and control network traffic using an approved filtering app, with provider, authentication, and filtering settings appropriate to the organization.

Login window (MDM)

Customize the macOS login window and sign-in experience, including the information shown to users and the login options and controls available on managed Macs. Located under the Login Window category.

More information on configuring these new settings using the settings catalog is available at create a policy using settings catalog in Microsoft Intune.

New keys to skip Setup Assistant panes

We recently added our new enrollment policies experience based on data-driven infrastructure that powers the settings catalog. This enables Intune to quickly and easily add new Skip Keys such as Liquid Glass and Accessibility Appearance. A list of Setup Assistant panes that can be managed is available in our Setup Assistant screen reference.

Streamline AppleCare cases with enhanced logging support

Microsoft Intune now supports Apple's Enhanced Logging device action on supported supervised devices running a compatible OS release. Administrators can start an AppleCare diagnostic-log collection session using an AppleCare-provided token and monitor device-reported status through DDM, reducing the need to coordinate manual log collection with the device user. More information is available in our device actions documentation for Enhanced logging.

Support updates for legacy MDM workloads

As more workloads are shifting to DDM, Apple is ending support for the following legacy MDM commands and payloads, which means they’ll no longer be updated or supported. You should instead manage these workloads using DDM through the settings catalog, which contains the latest settings.

MDM payloads that are now deprecated with OS 27 include:

Content caching service
DNS settings
DNS proxy
Parental controls application restrictions
Privacy preferences policy control
Passcode

Multiple settings have been deprecated in the MDM Restrictions payload, and we recommend using the equivalent DDM configuration to manage these features. The table below provides the new DDM location for these deprecated settings.

DDM Configuration	Deprecated MDM Settings
App Settings	Allow Listed App Bundle IDs Blocked App Bundle IDs
External Intelligence Settings	Allowed External Intelligence Workspace IDs Allow External Intelligence Integrations Allow External Intelligence Integrations Sign In
Intelligence Settings	Allow Apple Intelligence Report Allow Genmoji Allow Image Playground Allow Image Wand Allow Personalized Handwriting Results Allow Visual Intelligence Summary Allow Writing Tools Force On Device Only Dictation Force On Device Only Translation Allow Mail Smart Replies Allow Mail Summary Allow Notes Transcription Allow Notes Transcription Summary Allow Safari Summary
Keyboard Settings	Allow Auto Correction Allow Continuous Path Keyboard Allow Definition Lookup Allow Dictation Allow Keyboard Shortcuts Allow Predictive Keyboard Allow Spell Check
Siri Settings	Allow Assistant Allow Assistant User Generated Content Allow Assistant While Lock Force Assistant Profanity Filter

Apple previously ended support for MDM device configuration templates, and software update commands and settings. These have been removed from OS 27, and you should use DDM for these instead. To align with this change, starting with the October (2610) release, Intune will remove the following legacy workloads from the Microsoft Intune admin center:

iOS/iPadOS update policies
macOS update policies
macOS software updates report (per-device)
iOS update installation failures
macOS update installation failures

More information on this change is available in the support tip: Move to declarative device management for Apple software updates.

Support statement for “supported” versus “allowed” versions for user-less Apple devices

As new operating system updates are released throughout the year by Apple, Intune plans to support critical functionality that comes with each new OS version. With the release of iOS/iPadOS and macOS 26, we’ll continue with our existing model for enrolling user-less devices for supported and allowed OS versions to keep enrolled devices secure and efficient.

This includes devices enrolling without user affinity (user-less devices), such as shared iPads and devices enrolling through Automated Device Enrollment (ADE) without user affinity. We highly recommend updating your organization’s devices to the most recent Apple OS version publicly available to keep your devices secure and up to date.

Supported OS versions means that user-less devices running the three most recent iOS/iPadOS versions are fully supported by Intune. Devices running iOS/iPadOS 26.x, 18.x, and 17.x can enroll and take advantage of all Intune MDM functionality that is applicable to user-less devices, and all new eligible features will work on these devices. Allowed OS versions let you enroll user-less devices running an unsupported iOS/iPadOS version within the three versions of the supported range. These devices can use eligible Intune features supported by the MDM protocol, but OS changes, bugs, or other issues might affect functionality. Devices enrolled with user affinity or apps that rely on user sign-in will continue to not be supported.

User-less enrollment and feature support

Capability	Supported	Allowed
Applicable Versions	Three most recent versions (N-2): iOS/iPadOS 18.x and later macOS 15.x and later	Up to three versions below the supported version (N-5): iOS/iPadOS 16.x and later macOS 13.x and later
Can Enroll	Yes	Yes
User-less Eligible Intune MDM Features	Yes	Yes. May be impacted by breaking OS features, bugs, or issues.
User Affinity Enrollment	Yes	No
Apps That Require User Sign-In	Yes	No

For more details, review our blog Support statement for supported versus allowed versions for user-less Apple devices to learn more.

Intune MAM controls and updates

As you plan for the new features and changes with the latest OS release, we wanted to highlight additions with the latest Intune App SDK. With Intune App SDK for iOS v21.8.0 or later, organizations can take advantage of the following Intune MAM updates. Apps must be integrated with SDK v21.8.0 or later to support the experiences described below. As always, we recommend keeping apps updated with the latest SDK.

Refreshed app protection user experience

We’ve modernized the Intune app protection experience on iOS to make policy interactions clearer and more intuitive. The refreshed experience includes updated prompts and full-screen messaging, clearer account context on conditional launch screens such as the MAM PIN screen, and a Remove Account option that lets users remove a blocked managed account and its organizational data from the app. This is a user experience update only, with no changes to app functionality or app protection policies.

Control Siri onscreen awareness for organizational data

The Screen capture app protection policy setting now controls whether Siri onscreen awareness can access work or school data.

Set Screen capture to Block to prevent the Ask Siri option from appearing in the context menu for organizational data. If the setting remains Allow, which is the default value, users can share organizational data through Siri onscreen awareness.

The updates require apps to use the Intune App SDK for iOS version 21.8.0 or later.

Bookmark the Microsoft Intune Blog and follow us on LinkedIn  or @MSIntune and @IntuneSuppTeam on X to continue the conversation. Stay tuned to What’s new in Intune for additional settings and capabilities that will soon be available.

Moving from Windows Autopilot to Windows Autopilot device preparation

Intune_Support_Team — Wed, 16 Sep 2026 23:03:15 GMT

By: Maggie Dakeva, Senior Product Manager - Microsoft Intune

Organizations have spent years refining Windows Autopilot deployments. Profiles, Enrollment Status Page settings, group tags, dynamic groups, application assignments, and support processes all work together to deliver a familiar provisioning experience.

Windows Autopilot device preparation is a re-architecture of Windows Autopilot designed around the customer asks we hear most often: simpler configuration, faster and more reliable setup, clearer progress for users, and near real-time deployment reporting for administrators. A single device preparation policy brings deployment and the out-of-box experience (OOBE) settings together, enrollment time grouping (ETG) places devices into the right security group during enrollment, and granular application and PowerShell script status makes troubleshooting easier.

Autopilot device preparation is now the recommended solution for user-driven scenarios. Future engineering investments will focus on Windows Autopilot device preparation, enabling organizations to benefit from ongoing improvements to provisioning, reliability, reporting, and support. Moving eligible deployments positions your organization to benefit from those ongoing improvements while reducing the complexity of provisioning and support.

So how do you move without disrupting devices that are already working - or forcing every deployment scenario to transition at once?

The answer is a phased approach.

Windows Autopilot and Windows Autopilot device preparation can coexist in the same organization. You can move eligible user-driven Microsoft Entra join populations in controlled waves, validate the full experience, and keep scenarios that still require Windows Autopilot on their existing path.

The result is a practical way to adopt a simpler provisioning model while protecting the investments and workflows your organization still depends on.

Start with the outcome, not a one-for-one migration

Windows Autopilot device preparation brings enrollment settings, OOBE, device naming, required applications, PowerShell scripts, and enrollment-time targeting into a more coherent policy flow. The device preparation page, which replaces the Enrollment status page, gives users clearer progress and gives administrators more detailed deployment status for troubleshooting.

Windows Autopilot device preparation includes two complementary capabilities:

Device preparation policy defines the deployment experience, including OOBE settings, applications, scripts, naming, and ETG.
Device association optionally binds a physical device to your organization before enrollment. It can establish corporate ownership and tenant affinity, enable associated-device OOBE settings, and support direct per-device policy assignment.

Based on organizational needs, customers can choose to use device preparation policy, device association, or both. Device preparation policy provides the deployment configuration and experience, while device association adds pre-enrollment device affinity and device-based capabilities. Organizations can adopt each capability where it adds value to their provisioning model.

But moving to that model shouldn't mean recreating every Windows Autopilot object exactly as it exists today.

Instead, begin with the outcome each device population needs. Identify the required OOBE behavior, applications, scripts, naming, assignments, and support experience. Then design the device preparation policy and ETG model that delivers that outcome.

This approach reduces inherited complexity and helps ensure that the new deployment is designed for Windows Autopilot device preparation and not constrained by the architecture it replaces.

Choose what moves - and what stays

Windows Autopilot device preparation is the recommended path for eligible user-driven provisioning scenarios, including:

Corporate-owned Windows 11 devices
User-driven Microsoft Entra join
Windows 365

Continue using Windows Autopilot for scenarios that aren't supported or recommended for transition, including:

This isn't an all-or-nothing decision. The right transition plan deliberately separates eligible populations from valid exceptions.

Translate the provisioning model

Several familiar Windows Autopilot concepts have a corresponding role in Windows Autopilot device preparation:

Windows Autopilot Concept	Windows Autopilot Device Preparation Model
Deployment profile	Device preparation policy
Enrollment Status Page profile	Device preparation policy
Enrollment Status Page in OOBE	Device preparation page in OOBE
Windows Autopilot registration	Optional device association
Profile and dynamic group-based targeting based on group tags	Granular device preparation policy assignment with enrollment time grouping (ETG) using Microsoft Entra static security groups
Device name template defined in the Autopilot deployment profile	Device name template defined in the device preparation policy
Windows Autopilot deployments report	Windows Autopilot device preparation deployments report

The goal is to preserve the required customer and administrator experience - not every historical configuration object.

How the transition flow works

A controlled transition can follow eight steps:

Define the eligible population: Start with corporate-owned Windows 11 devices using user-driven Microsoft Entra join. Exclude scenarios that should remain on Windows Autopilot.
Design enrollment time grouping (ETG): Create assigned, static Microsoft Entra security groups for populations that genuinely differ by location, role, device type, or required configuration. Don't build the new design around a group tag or a device object that must exist before enrollment.
Create device preparation policy equivalents: Inventory each deployment profile and Enrollment Status Page pairing. Map the required OOBE settings, naming, applications, PowerShell scripts, blocking requirements, and dependencies into the new device preparation policy.
Evaluate whether device association is required for all scenarios. For user-targeted deployments that don't need pre-enrollment tenant affinity or per-device policy selection, the organization can use the device preparation policy without device association and simplify the setup and management of device onboarding. For devices that need automatic corporate ownership, OOBE customization settings, or stronger pre-enrollment trust, continue with step 5.
Pre-associate eligible devices. For existing registered or enrolled devices, collect the pre-association information by collecting the diagnostics logs, then exporting the DeviceLink CSV file found in the logs. Upload the CSV in the Associated devices blade in Intune and assign a device preparation policy to the device. Assignment can be done during the CSV upload process or after. Confirm that the device reaches the Pre-associated state before its planned reset or refresh.

Note: Device pre-association is only available for devices that meet the minimum OS and hardware requirements , including TPM 2.0.

Pilot the complete OOBE experience. Start with new devices or reset a small, representative set of devices. Validate policy selection, ETG placement, applications, scripts, naming, progress reporting.
Expand and pre-associate remaining devices. Pre-associate additional populations in controlled waves. You do not need to force resets to all existing enrolled devices but simply pre-associate to prepare them so they enroll via the Windows Autopilot device preparation flow whenever each device next undergoes a natural or required reset.
Retire registered flows. Retire deployment profiles, Enrollment Status Page profiles, groups, registrations, and processes only after reporting confirms that no active or planned population still depends on them.

Pre-association doesn’t reset the device or disrupt its current use. The device remains enrolled and productive until its next natural or required reset, when Windows Autopilot device preparation takes effect.

Don't remove the Windows Autopilot registration early. Doing so can remove Autopilot properties and affect dynamic-group membership that supports the device's current configuration.

The next time the device enters OOBE, Windows recognizes the association and follows the Windows Autopilot device preparation path. If a device is both registered and associated, association takes precedence. Plan the pilot around this behavior rather than expecting an automatic fallback to Windows Autopilot.

OEM and partner note: Device association uploads are currently only supported through Intune. OEM and partner pre-association scenarios aren't supported yet, but they’re on the roadmap.

What this means for your organization

You can prepare existing devices for transition while they remain enrolled and in use.
You can move one eligible population at a time instead of committing to an organization-wide cutover.
You can preserve Windows Autopilot for scenarios that still require it.
You can use the transition to simplify assignment and provisioning logic rather than carry every legacy object forward.
You can retire the old configuration gradually - after validation and dependency checks confirm that nothing still relies on it.

A sample customer pilot setup scenario

Consider a multinational organization, Contoso, that uses group tags to distinguish devices in the United Kingdom and Germany and to identify different device use cases. Dynamic groups use those tags to determine which deployment profile, Enrollment Status Page configuration, applications, policies, scope tags, and naming rules apply. The organization wants to move its eligible user-driven Windows 11 populations to Windows Autopilot device preparation without reproducing the same pre-created record and dynamic-group dependencies.

The Contoso deployment team transitions to Autopilot device preparation with the following steps:

Create static security groups for each required configuration. The team creates assigned Microsoft Entra security groups such as User Devices UK and User Devices Germany. It creates separate groups only when location, role, device type, scope, or required configuration differs.
Create a device preparation policy for each population. The team creates a policy such as User Devices UK DPP and User Devices Germany DPP. Each policy contains the required OOBE settings, applications, PowerShell scripts, blocking behavior, and device name template, and identifies the corresponding enrollment time grouping (ETG) security group.
Assign the device preparation policies to each population. The team assigns each device preparation policy to the respective sets of devices at time of pre-association or later. During enrollment, the device joins the group selected by the device preparation policy. For example, devices assigned the User Devices UK DPP join the User Devices UK group and receive the apps and policies assigned to that group.
Configure scope through the static groups. The team assigns the appropriate regional scope tag to each ETG security group. The device receives the associated scope tag when it joins the group during enrollment.
Set a naming template for each device preparation policy. The organization uses a naming convention where devices start with a prefix indicating their location. The team sets UK-%SERIAL% in User Devices UK DPP and DE-%SERIAL% in User Devices Germany DPP.
Pre-associate pilot devices without disruption. Selected devices can be pre-associated while they remain enrolled and in use. The team collects diagnostics logs via script, extracts the DeviceLink CSV files, imports them in Intune, confirms the devices reach the Pre-associated state, and keeps the Windows Autopilot registration in place until the approved reset or refresh window.
Validate the end-to-end experience with representative devices. The admin team uses test devices representing each target population to verify policy assignment, static group membership, scope tags, naming, applications, scripts, reporting, and successful completion of the device preparation flow. Existing devices can remain in service until their next natural or required reset.

Figure 1: Seven-step regional Windows Autopilot device preparation rollout workflow, from creating security groups and device preparation policies through regional configuration, pilot association, and device validation.

This scenario is illustrative, not a completed deployment or a measured customer outcome. It shows the transition pattern: define the supported scope, replace group-tag dependencies with ETG, move Enrollment Status Page and deployment profile settings to the device preparation policy, decide where device association adds value, validate end to end, and expand in controlled waves.

Get started

Begin with one eligible user-driven Microsoft Entra join population. Map its current Windows Autopilot outcomes to enrollment time grouping (ETG) and a device preparation policy. Pre-associate a representative pilot, validate the complete reset-to-desktop experience, and expand only when the results meet your deployment and support criteria.

Moving to Windows Autopilot device preparation doesn't require a forced cutover. It requires a clear boundary, a deliberately redesigned assignment model, and evidence from each wave.

That gives IT a controlled path toward simpler provisioning while keeping every device population on the experience that supports it best.

Learn more

We’d love to hear your feedback! Share your thoughts in the comments below, follow us on LinkedIn or reach out to us on X @IntuneSuppTeam or @MSIntune.

From GPO to Microsoft Intune: A practical guide to cloud-first policy management

Intune_Support_Team — Mon, 31 Aug 2026 16:44:53 GMT

By: Per Larsen - Senior Product Manager | Microsoft Intune

For many organizations, Group Policy Objects (GPOs) remain an important part of Windows configuration. As device strategies expand to include cloud-native management, Microsoft Intune provides the policy platform for devices that are Microsoft Entra joined and managed from the cloud. The goal isn’t to force every organization through the same migration, it’s to choose the right management path for each device population and each setting.

This guide explains three common paths: starting fresh for new cloud-native devices, selectively transitioning required settings to Intune, and coordinating GPO with Intune for hybrid Microsoft Entra joined or co-managed devices. Across all three paths, the recommended principle is the same: assess and rationalize existing policy before deciding what to retain, re-create, redesign, or retire.

1. Choose the right path for each device population

GPO was designed primarily for domain-joined, on-premises devices. Intune, in contrast, is designed for cloud-based management of devices whether they are on or off prem. The right path will depend on the scenario in which the devices are joined and managed.

Scenario 1: Start fresh for new cloud-native devices

This is the recommended approach for new Microsoft Entra joined devices. Invest in the cloud-first configuration you need today rather than reproducing every historical GPO. Begin with mandatory security requirements, Microsoft-recommended security baselines, and essential settings for services such as OneDrive and Microsoft Edge. Add other settings only when there’s business, security, or operational requirement.

Scenario 2: Selectively transition required settings

Organizations that need to preserve specific behavior can assess and rationalize existing GPOs, then re-create only the settings that are supported and necessary in Intune. Treat this as a deliberate replatforming effort, not a one-to-one copy. Test each new profile with a pilot group before broad deployment.

Scenario 3: Coordinate GPO and Intune for hybrid devices

Hybrid Microsoft Entra joined devices may receive settings from both GPO and Intune, including common scenarios where Intune-managed workloads or Windows Autopatch are used for existing hybrid domain-joined devices. Use of both group policy and Intune policy enforcement can continue for an extended period, but you should plan carefully to avoid conflicting settings. Organizations can either leave existing GPOs in place until devices are rebuilt as cloud-native, or actively shift selected policy areas to Intune while the devices remain hybrid joined.

Figure 1. A cloud-first policy workflow begins with assessment and rationalization, then applies the appropriate path for each device population.

2. Assess and rationalize before you transition

Before changing policy source, understand what’s actually in use. Many environments contain GPOs that are old, undocumented, duplicated, or applied more broadly than intended. A direct lift-and-shift carries that technical debt into Intune.

Key assessment actions

Export all GPOs from Group Policy Management Console (GPMC).
Use Gpresult and operational knowledge to identify which GPOs are still applied and functional.
Remove or archive unused, legacy, or duplicated policies instead of transitioning them.
Categorize required settings by security, update management, device restrictions, application control, and legacy or unsupported scenarios.
Record the device populations and business requirements associated with each policy.

3. Use Group Policy Analytics as an assessment input

Microsoft Intune includes Group Policy Analytics, a built-in tool that imports on-premises GPOs and reports their mapped support in mobile device management. It can help identify settings with Intune equivalents, deprecated settings, and configurations that may require another implementation approach.

Use the report as one source of evidence rather than as a complete transition engine. Its mappings may not reflect every setting currently available in the Settings Catalog, especially settings added after the analytics mapping was last updated. Validate important settings directly in Intune and against current Microsoft documentation.

Useful outcomes

Highlights settings with documented Intune mappings.
Surfaces GPO settings that no longer make sense for cloud-native devices.
Helps identify GPOs that should be retired rather than re-created.
Supports, but does not replace, business validation and pilot testing.

4. Don't lift and shift: Re-design for cloud-first management

A direct copy of GPOs into Intune can reproduce policy sprawl and create new conflicts. Instead, use the assessment to determine the intended outcome of each setting. Some settings will be unnecessary, some will have a direct Intune settings catalog equivalent, and others will need a cloud-appropriate redesign.

Retire settings that are no longer required.
Re-create settings that are supported and necessary.
Rethink and redesign legacy dependencies such as drive mappings, printers, or vendor-specific prioritizing or considering cloud-first solutions and configurations.
Document the owner, target population, and validation method for each resulting Intune profile.

Figure 2. Decide whether to retain, re-create, redesign, or retire each GPO based on device type and current business need.

5. Start with security baselines

Security baselines in Intune are curated collections of Microsoft-recommended settings for Windows, Microsoft Edge, and Microsoft Defender. They provide a controlled foundation that can reduce policy sprawl and align devices with current security guidance.

Review baseline settings with security stakeholders rather than applying them without evaluation.
Identify overlaps with existing policies before deployment.
Pilot the baseline with representative devices and users.
Layer additional configuration policies only for documented requirements.

6. Create equivalent Intune configuration profiles where needed

After assessment and baseline planning:

Configure supported and necessary settings in the settings catalog.
Use Administrative Templates or imported ADMX policies for applicable settings.
Use custom configuration, scripts, or remediations only when a built-in option doesn’t meet the requirement.
Use standard or organizational safe rollout practices to assign policies before broad rollout, and monitor deployment and conflict reports.

7. Coordinate GPO and Intune during a hybrid period

Customers often expect GPOWinsOverMDM to act as a universal precedence switch: whenever Group Policy and Intune configure the same setting, GPO should win. In reality, conflict control applies only to the subset of settings exposed through the Windows Policy CSP with corresponding Group Policy mappings.

Additionally, it doesn’t govern settings delivered through other CSPs, such as Defender or Windows Update. Those policy areas can have different precedence, merging, or conflict behavior. Consequently, using GPOWinsOverMDM as a coexistence strategy can produce inconsistent and difficult-to-predict results.

The safer approach is to avoid configuring the same setting through both management planes. Use targeted groups, assignment filters, GPO security filtering, and Organizational Units (OU) scoping to establish one authoritative source for each setting and device population.

Use selective targeting to move policy areas in controlled stages:

In Group Policy, use appropriate OU link placement, security group filtering, and carefully validated Windows Management Instrumentation (WMI) filters to stop selected GPOs from applying to devices that will receive the Intune equivalent.
In Intune, use Microsoft Entra groups, dynamic membership rules, assignment filters, and exclusions to target the intended device population.
For each policy area, document the authoritative management plane and the date or condition for changing ownership.
Validate effective configuration with Gpresult, Intune reports, Event Viewer, and representative pilot devices.

For example, an organization might leave most existing GPOs in place for hybrid joined devices while excluding a pilot group from the Windows Update GPO. The same group can then receive the corresponding Intune update policy. After validation, you can expand the targeting changes in stages in alignment with your organizational safe-rollout standards.

8. Common Pitfalls

Enforcing GPO and Intune side by side without coordinated targeting

Uncoordinated configuration can create conflicts, inconsistent results, and difficult troubleshooting. Define an authoritative management plane for each setting and device population.

Transitioning everything as is

You should rationalize old, unused, or duplicated settings rather than reproducing or recreating them in Intune. Supporting legacy or non-cloud-first settings. Some requirements don’t have a direct built-in Intune equivalent. Evaluate whether the requirement is still necessary, then use a supported alternative, redesign the process, or retain the setting in GPO for the applicable hybrid devices.

Skipping the pilot phase

Pilot groups reveal assignment, compatibility, and user-impact issues before a broad deployment.

10. Retire old GPOs gradually

Retire a GPO only after its replacement or removal has been validated for the affected device population.

Exclude a pilot population from the original GPO and assign the intended Intune configuration.
Validate effective settings, Intune deployment status, device events, and user impact.
Expand the targeting change in controlled stages.
Disable and archive the GPO after dependencies are removed and rollback is no longer required.
Keep GPOs that remain necessary for hybrid joined devices, with clear ownership and targeting.

Conclusion

Moving to Intune policy management isn’t a one-size-fits-all migration or a copy-and-paste exercise. For new cloud-native devices, start with a clean, cloud-first configuration. When existing behavior must be preserved, assess and rationalize the requirement before re-creating it in Intune. During a period of parallel Group Policy and Intune management, coordinate targeting so GPO and Intune do not compete for the same settings.

The key principles are:

Choose the management path by device population.
Assess and rationalize before making changes.
Start with security requirements and validated baselines.
Use Group Policy Analytics as an input, not as the sole source of truth.
Transition only supported and necessary settings.
Coordinate GPO and Intune targeting throughout any transition period.

Introducing device association for Windows Autopilot device preparation

Intune_Support_Team — Thu, 27 Aug 2026 15:00:00 GMT

By: Maggie Dakeva, Senior Product Manager - Microsoft Intune

We’ve heard organizations want Windows deployment to be simple for employees and predictable for IT admins. But before a device enrolls, how does the organization know that the device is really one of its own - and how can IT make sure the right experience and policy reach that device regardless of who signs in?

Today, we're announcing device association for Windows Autopilot device preparation, a new way to bind a physical Windows 11 device to your organization before enrollment begins.

Device association uses hardware-backed attestation to create a trusted relationship between the device and your tenant at the start of the provisioning journey. That relationship helps Windows Autopilot device preparation recognize the device during the out-of-box experience (OOBE), automatically treat it as corporate-owned, and apply the experience and policy intended for that specific device.

The result is a more secure, more consistent, and more device-centric onboarding flow.

Start with the device, not just the user

Windows Autopilot device preparation already gives IT teams a straightforward way to configure new Windows devices with the apps, scripts, and policies employees need. Device association extends that experience by allowing IT to target a device preparation policy directly to a device before it enrolls.

This is especially valuable when the deployment experience needs to follow the hardware rather than the person signing in. For example, one employee can enroll multiple devices that serve different purposes, and each device can receive its own device preparation policy. When both device-based and user-based assignments are available, the device-based assignment takes precedence.

That gives administrators greater confidence that the correct configuration reaches the correct device from the beginning of its lifecycle.

Create a simpler out-of-box experience

Because an associated device is recognized before enrollment, IT can configure more of the Windows setup experience in advance.

Device association enables organizations to:

Configure Language and region.
Automatically configure the keyboard and skip the keyboard selection page. When the device uses a Wi-Fi network connection during OOBE, the language and keyboard selection screens aren't hidden.
Hide the Microsoft Software License Terms page.
Hide privacy settings during OOBE.
Apply a device name template that uses the serial number or a randomized value.
Hide account-change options on company sign-in and domain error pages.

These controls reduce the number of decisions an employee must make while setting up a device and help create a consistent, organization-ready experience from the first screen.

Strengthen trust before enrollment

Device association isn't only an experience improvement. It establishes device trust earlier in the deployment process.

The association uses hardware-based attestation and TPM-backed cryptographic validation to verify the device's identity. Tenant affinity is stored in the device's UEFI firmware, where it persists across a Windows reset, operating system reinstallation, or removal of enrollment.

This durable, hardware-backed relationship helps ensure that the device presenting itself for preparation is the device the organization intended to onboard.

Associated devices are also automatically marked as corporate-owned. If your organization blocks personally owned Windows devices with Intune enrollment restrictions, device association can be used instead of uploading a separate corporate identifier. You can continue to use corporate identifiers where they fit your process, but an associated device doesn't need both.

How the device association flow works

Device association is designed as a clear workflow that starts with IT and finishes automatically during OOBE:

Create the device preparation policy. Configure the apps, scripts, deployment settings, OOBE experience, and optional device name template that should apply.
Export the device information. During OOBE, a technician opens the Autopilot menu and exports the DeviceLink CSV with the device information required for pre-association to a USB. For an existing device, the same information can be collected from Autopilot diagnostic logs.

Figure 1. The Windows Autopilot menu with Assign device association selected.

Figure 2. The Assign device association screen confirms that device link information was exported to a removable drive.

Pre-associate the device in Intune. In the Microsoft Intune admin center, go to Devices > Enrollment > Device association > Devices, upload the CSV, and optionally assign a device preparation policy directly to the device.
Figure 3. The Associated devices page in the Microsoft Intune admin center shows a successfully uploaded pre-associated device.
Complete association. When the device connects to a network in OOBE, it finds the pre-association record and completes association automatically. A technician can also trigger this step manually from the Autopilot menu.
Enroll and prepare the device. The device receives the applicable device-targeted policy, is marked as corporate-owned, and presents the configured OOBE experience.
Monitor the deployment. Administrators can review association state and assigned policy in the Device association blade and filter devices by state, policy, manufacturer, or model.

The device association lifecycle consists of the following states:

Pre-associated: The device was added on the service side and is waiting to complete association in OOBE.
Associated: The device completed association by writing the tenant affinity to UEFI and is ready for enrollment. This happens automatically when a pre-associated device syncs with an MDM provider.
Pending removal: A request to remove the pre-association is being processed.

A device's association can be removed by an administrator or partner with physical access to the device who manually runs a local script that clears the tenant affinity information stored in the device's UEFI. This action should be performed only when the device should no longer be associated with the organization, such as when it is sold, recycled, or transferred.

Manage the full device lifecycle

The association remains with the device through reset and reinstallation, helping preserve the organization's intended provisioning path when a device is redeployed internally.

When a device permanently leaves the organization - for example, when it's sold, recycled, or transferred—the association should be removed as part of decommissioning. Because the tenant affinity is stored on the device, clearing a completed association can be performed via script locally on the physical device, without access to the service.

This lifecycle model is intentional: association is durable during normal reuse inside the organization, while permanent removal can be completed by an admin or partner who has control of the physical device.

Designed to work alongside your existing Windows Autopilot strategy

Device association is part of Windows Autopilot device preparation and can coexist with traditional Windows Autopilot deployments in the same organization.

For a device already registered with Windows Autopilot, the association state determines which deployment runs. If the device isn't associated, its Windows Autopilot registration takes precedence. If it is associated, the Windows Autopilot device preparation deployment takes precedence.

This gives organizations a practical path to introduce device association while continuing to support existing Windows Autopilot investments.

Get started

To use device association, you'll need a supported physical Windows 11 device with TPM 2.0 enabled and in a healthy state. Virtual machines aren't supported because device association relies on hardware-backed identity verification.

Start by reviewing the Windows Autopilot device association requirements, then create or update your Windows Autopilot device preparation policy. From there, export the device information, pre-associate the device in Intune, and let Windows complete the trusted association during OOBE.

With device association, Windows Autopilot device preparation moves device trust, targeting, and customization earlier in the deployment journey - before enrollment and before the employee reaches the desktop.

That means fewer setup decisions for users, more predictable deployments for IT, and stronger confidence that the right device is joining the right organization with the right configuration.

Learn more

Remote Help on Windows: Unattended Support with Remote Sign-In Is Here

Intune_Support_Team — Tue, 25 Aug 2026 16:39:03 GMT

By: Rodolfo Bermudez | Sr. Product Manager & Kara Wang | Product Manager 2 - Microsoft Intune

Helpdesk teams have long asked for a way to remotely troubleshoot Windows devices without needing the user to be present. Whether it’s after-hours maintenance on a shared device in a call center, or a device sitting idle at a remote office, waiting for a user to be available shouldn’t be the blocker to getting work done.

With Intune’s August release, we’re excited to announce Remote Help Windows Unattended Support with Remote Sign-In a new capability that lets helpdesk staff remotely access physical Windows devices by signing in with credentials they have access to, without requiring the user to grant access or even be logged in.

Why this matters

Previously, every Remote Help session on Windows required the user to be present at the device to accept the connection. Now Remote Help Windows Unattended Support enables:

After-hours support - Devices that need maintenance outside business hours can be serviced without scheduling time with users.
Improved Helpdesk efficiency - Tier 2 support staff don't spend extra time coordinating schedules that often take only minutes to fix.
Remote locations get the help they need - Branch offices without on-site IT have path to immediate remediation.

With unattended capabilities your helpdesk connects directly to the Windows login screen, authenticates with their own credentials, and works in a separate Windows session, all while the user’s session remains safely locked and preserved.

What the feature enables

Capability	Details
Remote Access Without User Presence	Helpers can sign in with their own credentials and establish a new Windows session on the target device, even when no user is actively connected.
Session Isolation	The user's existing session remains locked and preserved, preventing disruption while support activities are performed in a separate session.
Security-First Design	Uses least-privilege access, a dedicated RBAC permission, and a complete audit trail to help maintain security and compliance requirements.
User Awareness	If a user is currently signed in, they receive a notification and can choose to accept or reject the remote access request.
Rich Session Features	Supports file transfer, clipboard passthrough, Remote Desktop Virtual Printer, multi-monitor support, and other productivity-enhancing capabilities.

Prerequisites

Licensing

Remote Help is included with Microsoft Intune Suite, Remote Help standalone add-on, or Microsoft 365 E3/E5.
Remote Help must be enabled in the tenant. You can find step-by-step instructions in the following article: Deploy Remote Help with Microsoft Intune.

Device requirements

Requirement	Details
Ownership	Supports corporate-owned enrolled devices that are Microsoft Entra joined or Hybrid Microsoft Entra joined. Personal and BYOD devices aren't supported.
Platform	Requires physical Windows devices running x64-based operating systems. Virtual machines aren't currently supported.
Device State	The device must be powered on, connected to the internet, able to reach the required Microsoft service endpoints, and have the Intune Management Extension installed.

Role-based access control (RBAC) permission

This feature uses a dedicated permission: Remote Help app > Windows unattended control remote sign-in. It must be explicitly assigned to helpdesk roles targeting specific device groups. To maintain a higher security boundary, this permission isn’t included in any Intune built-in role, including existing roles such as Help Desk Operator or School Administrator, and must be granted through a custom role assignment.

Tip: Limit Access to Unattended Support

Consider creating a dedicated custom role for unattended support rather than including it in your standard Remote Help roles. Because unattended access enables support sessions without an end user present, it's a best practice to restrict this capability to Tier 2 and Tier 3 support staff or senior administrators, and scope access only to the devices they are responsible for managing.

Figure 1: Remote Help app settings in the Microsoft Intune admin center showing enabled and disabled permissions, including elevation, screen viewing, full control, and Windows unattended control at remote sign-in.

How to set it up

Step 1: Configure RBAC

In the Intune admin center, go to Tenant administration > Roles
Create or edit a custom role
Under Permissions > Remote Help app, enable Windows unattended control remote sign-in
Assign to your helpdesk groups, scoping to the device groups that should receive unattended support

Step 2: Deploy Azure Virtual Desktop agents

Required agents

Package both the AVD Agent MSI and AVD Agent Bootloader MSI as Win32 apps in Intune. Deploy to the same target device groups that are intended to receive unattended support from Step 1. No ongoing maintenance is required - the components auto-update.

Step 3: Enable Remote Desktop

Go to Devices > Windows > Configuration profiles > Create profile
Platform: Windows 10 and later | Profile type: Settings catalog
Add setting: Search for Remote Desktop > Enable "Allow users to connect remotely using Remote Desktop"
Assign to your target device groups
Verify: Devices > Configuration profiles > Device status

The helper experience: A walkthrough

Starting the session

From the Intune admin center, navigate to the target device and select "..." > New remote assistance session. A side panel appears with two options:

Initiate attended control: sessions in which a signed-in end user is present and grants access to the helper
Initiate unattended control: sessions in which an authorized helper can access and control an Intune managed device without a signed in end user present

Select Initiate unattended control and click Select.

Figure 2: Microsoft Intune admin center device overview with the Remote Help panel open, showing the option to initiate an unattended control session on a corporate Windows device.

Built-in safety checks

Before connecting, the Intune portal validates several conditions:

Condition	What You'll See
Missing RBAC Permission	The unattended control option is disabled and displays the message: "You can only select session types for which you have permission."
Personal Device	The unattended control option is disabled and displays: "Unattended control is not available on personal devices."
Device Noncompliant	A warning appears indicating the device doesn't meet your organization's security or compliance requirements.
Device Offline	The connection attempt fails and displays: "Make sure the user's device is on and connected to the internet."
Missing Prerequisites	The Remote Help pane in the Intune admin center indicates that required agents, policies, permissions, or device settings haven't been configured.

Figure 3: Microsoft Intune Remote Help panel displaying a notice that unattended control is unavailable for a personally owned device, with session options disabled.

Connection progress and success

A progress panel shows real-time status: "Starting unattended session on user’s device" followed by green checkmarks when successful, with an "Open Remote Help" link.

If the connection fails, for example because the device is offline or there is a network connectivity related issue, you’ll see a clear error with a Retry option.

Figure 4: Microsoft Intune Remote Help panel confirming that an unattended remote session has started on a managed Windows device, with a link to open Remote Help.

This will launch a new browser tab opening the Windows App (web client). The helper may need to authenticate again using the same username and credentials used to authenticate to Intune Admin portal.

Signing in to the remote device

Once connected, the helper then needs to authenticate to the device within the remote session. You can sign in using a local Windows account (ComputerName\UserName), an Active Directory domain account (Domain\UserName or UPN), or a Microsoft Entra ID account (UPN), whichever is appropriate based on the join state of the device and the scenario. Least privilege is enforced - a standard user account does not gain Administrator permissions.

When a user is currently signed in

If someone is actively using the device, the helper sees: "Another user is signed in. If you continue, they’ll be disconnected. Do you want to sign in anyway?"

Figure 5: Windows sign-in screen displaying a prompt warning that another user is signed in and asking whether to continue with a remote sign-in session.

Choosing "Yes" locks the user’s session (preserving their work) and connects the helper to a separate Windows session.

The device-side experience

User notification (when someone is present)

If a user is signed in, they see a notification: "Do you want to allow the helper to connect to this machine? Click OK to disconnect your session immediately or click Cancel to stay connected. No action will disconnect your session in 30 seconds."

Figure 6: Windows 11 desktop showing a Remote Desktop Connection dialog requesting approval for a remote user to connect, with options to allow or cancel the session.

If they don’t respond in 30 seconds, the unattended session starts automatically.

During the session

The end user’s console shows their lock screen. They cannot see what the helper is doing. The helper works in a separate Windows session.

Taking back control

The end user can regain control at any time by signing back into their session from the lock screen. The helper is notified and can choose to disconnect.

Monitoring and audit

Unattended sessions are fully auditable using the same reporting infrastructure as existing Remote Help:

Session monitoring: Tenant administration > Remote Help > Monitor tab (active sessions, average time, total sessions)
Session history: Remote Help sessions tab with Provider, Recipient, Device, OS, session type (Unattended/Attended), and export capability
Audit logs: Tenant administration > Audit logs - filter by category "RemoteHelp" for complete session lifecycle events

For detailed step-by-step instructions on monitoring, reporting, and auditing Remote Help sessions, see: Troubleshoot and monitor Remote Help for Microsoft Intune.

Security at a glance

Control	How It Works
Corporate-Only Access	Only Intune-enrolled, corporate-owned physical devices that are Microsoft Entra joined or Hybrid Microsoft Entra joined are eligible for unattended support.
Explicit RBAC Permission	Uses a dedicated permission separate from traditional Remote Help scenarios that require user presence. This permission is included in the built-in Intune Help Desk Operator role.
Least Privilege	The helper's actions are limited to the permissions associated with the Windows account used to sign in to the target device.
User Awareness	If a user is actively signed in, they receive a notification and a 30-second window to accept or reject the unattended access request.
Session Isolation	Support occurs in a separate Windows session, keeping the user's active session locked and preventing access to in-use applications or data.
Full Audit Trail	All unattended support sessions are logged to support auditing, compliance reviews, and operational accountability.
12-Hour Maximum Session Duration	Unattended sessions automatically terminate after 12 hours to help reduce security risk and prevent abandoned connections.

Key things to remember

Things to Keep in Mind

✅ Three setup steps: RBAC role + AVD agents + Remote Desktop config profile, all targeting the same device groups.

✅ Corporate-owned physical devices only: Personal and virtual devices are not supported at GA.

✅ Dedicated RBAC permission: Use Windows unattended control remote sign-in.

✅ Devices must be online: Sleep, hibernate, and powered-off devices cannot receive unattended sessions.

✅ User sessions are preserved: If a user is signed in, their session is locked, not terminated.

✅ Auto-updating agents: The AVD agent updates automatically, so no ongoing deployment maintenance is required.

Frequently asked questions

Can I start an unattended session from the Remote Help app?

No. Unattended sessions can only be initiated from the device page in the Intune admin center.

What if a user rejects the connection?

If they click Cancel, nothing happens and the session doesn't start.

What happens if no one responds to the notification?

After 30 seconds with no response, the unattended session starts automatically.

Does this work on Windows 365 or AVD?

We are working towards providing support for Windows 365 and Azure Virtual Desktop in the future.

What's the maximum session length?

Sessions can last up to 12 hours. After 12 hours, the session automatically disconnects. This limit isn't configurable.

What credentials can I use to sign in?

Users can sign in using a local Windows account (ComputerName\UserName), an Active Directory domain account (Domain\UserName or UPN), or a Microsoft Entra ID account (UPN), whichever is appropriate based on the join state of the device and the scenario.

Resources to learn more

Remote Help overview
Microsoft 365 Roadmap
Role-based access control (RBAC) with Microsoft Intune
Remote Help Documentation: aka.ms/remotehelpdocs

We’d love to hear your feedback! Share your thoughts in the comments below, follow us on LinkedIn or reach out to us on X @IntuneSuppTeam or @MSIntune.

Support tip: Restore the Managed Home Screen Exit PIN

Intune_Support_Team — Fri, 21 Aug 2026 21:53:41 GMT

We identified and resolved a recent issue (IT1450132) that could cause the configured Managed Home Screen exit PIN to be removed from some existing Android Enterprise when updating older device configuration policies. While a fix has been deployed to address this, if a policy was already affected, you will need update the affected policy or policies and ensure the Exit Kiosk Mode PIN is set before saving.

What you might see

On an affected device, selecting Exit kiosk can display a message that a PIN to exit kiosk mode has not been set by the IT administrator, even though the policy was previously configured with one. See an example screenshot below. Note that this screen will also show on devices where you’ve intentionally disabled the Exit kiosk feature.

Figure 1: Android device in kiosk mode displaying a message that no PIN has been configured to exit kiosk mode and advising the user to contact an administrator.

Update the affected policy

In the Microsoft Intune admin center, open the device restrictions policy assigned to the affected Android Enterprise dedicated devices.
Under Device experience, confirm that Leave kiosk mode is set to Enable.
Enter a new 4-6 digit value for Leave kiosk mode code.
Save the policy and allow it to deploy to the affected devices.
Verify that the new PIN can be used to exit kiosk mode.

The previous PIN cannot be recovered after it has been removed, so a new PIN is required. For more information, see Android template device settings list to restrict features using Intune.

If you need temporary access before the updated policy reaches a device, use the Suspend Managed Home Screen device action, provided the documented prerequisites are met.

Figure 2: Microsoft Intune admin center showing Android Enterprise device restriction settings, with the “Leave kiosk mode” option enabled and a kiosk exit code configured.

Summary

The service-side issue has been resolved. Administrators with previously affected policies should configure and deploy a new Managed Home Screen exit PIN, then verify the behavior on their devices.

We’ll continue to update this post as new information becomes available. If you have questions or comments for the Intune team, reply to this post or reach out to @IntuneSuppTeam on X.

Configure Delivery Optimization for Windows to save bandwidth and speed up deployments

Intune_Support_Team — Tue, 18 Aug 2026 22:01:39 GMT

By: Carlos Diaz - Sr. Product Manager and Jason Sandys - Principal Product Manager | Microsoft Intune

Delivery Optimization is built into Windows and can help reduce bandwidth usage during app and update deployments. Instead of downloading content from the internet every time, devices can download it from nearby devices or a local cache when available.

Many organizations leave Delivery Optimization at its default settings or disable it entirely. As a result, they may miss opportunities to reduce network traffic, improve deployment performance, and make better use of existing network resources.

This article focuses on the Delivery Optimization scenarios and the common configurations that Intune admins use most often: large-scale patching, Windows Autopilot provisioning, branch office bandwidth management, and Microsoft Connected Cache for scenarios where peer-to-peer sharing alone isn't enough.

How Delivery Optimization works

Delivery Optimization is an HTTP downloader with built-in peer-to-peer capabilities available in supported versions of Windows. It helps distribute Windows updates, Microsoft 365 Apps updates, Microsoft Defender definition updates, Microsoft Store apps, Intune Win32 apps package and other supported content. Delivery Optimization checks local sources before falling back to internet content caches.

The most important Delivery Optimization policy setting is Download Mode, which determines how devices discover peers.

Mode	Description
Mode 1 (LAN)	Devices share content with peers behind the same IP/NAT boundary.
Mode 2 (Group)	Devices share content within a defined group, such as an Active Directory site, domain, or custom group ID. Recommended for environments with multiple VLANs or segmented networks.
Mode 3 (Internet)	Devices can share content with internet peers outside the organization. This mode is rarely used in enterprise environments.

Delivery Optimization checks sources in this order:

LAN or group peers and, if configured, Microsoft Connected Cache in parallel.
Internet peers, if allowed in the Download Mode setting
Internet content caches, which are always available as the final fallback

Regardless of the mode you choose, the goal is to keep content download traffic local whenever possible.

Common misconceptions

Before configuring Delivery Optimization, it's worth addressing a few common misunderstandings we’ve heard from customers.

"Does Delivery Optimization use my bandwidth to upload content to the internet?"

In Mode 1 (LAN), peer sharing is restricted to your local subnet. Content is only shared with other devices on the same network segment, and no content leaves your LAN. Additionally, you have full control over upload usage through the Monthly upload data cap setting.

"Is Delivery Optimization the same as BranchCache?"

While both technologies help reduce bandwidth usage, they are built on different architectures and support different scenarios. BranchCache relies on BranchCache-enabled content servers to cache and distribute content, whereas Delivery Optimization is built directly into Windows and is designed to work natively with cloud-delivered content, including Windows updates, Microsoft Store apps, and Microsoft 365 Apps.

"We disabled Delivery Optimization years ago. Is there any reason to revisit it?"

Yes. Delivery Optimization has evolved significantly and now offers extensive management capabilities through the Intune Settings Catalog. Administrators can configure download modes, define group boundaries, control bandwidth usage, set cache sizes, and limit uploads. If Delivery Optimization was disabled in the past, it may be worth reevaluating your configuration. When properly configured, it can help reduce bandwidth consumption, improve content distribution efficiency, and accelerate update and application deployments.

Essential policies

The following settings, available in the settings catalog under Delivery Optimization, provide you a strong starting point:

Setting	Default Value*	Recommended Value	What It Does
DODownloadMode	1 (LAN)	1 (LAN)	Keeps peer-to-peer sharing within your subnet or Delivery Optimization group.
DORestrictPeerSelectionBy	1	1	Devices discover and peer with others on the same subnet.
DOMaxCacheSize	20%	20% to 30%	Amount of local disk space allocated to the Delivery Optimization cache.
DOMinFileSizeToCache	50 MB	5 MB	Minimum file size eligible for caching and peer-to-peer distribution.
DOMaxCacheAge	259,200 seconds (3 days)	1,209,600 seconds (14 days)	Determines how long cached content remains available before cleanup.
DOMonthlyUploadDataCap	20 GB	20 GB	Limits the total amount of data a device can upload to peers each month.

*The default values in this table are for Windows 11.

The table above lists common Delivery Optimization settings, their default values, and recommended starting values. However, the best configuration depends on your network topology, device count, update cadence, and whether you’re using Microsoft Connected Cache. Use the scenario guidance below to tune from the baseline. for the full policy reference review: Configure Delivery Optimization (DO) for Windows.

The defaults provide some immediate value, but organizations often achieve better results by:

Defining peer groups
Increasing cache size
Increasing retention periods
Lowering the minimum file-size threshold when appropriate

When configuring Delivery Optimization, avoid managing the same setting from multiple locations, such as settings catalog and custom policy. Using the settings catalog as your primary management location can help reduce conflicts and simplify troubleshooting.

Windows quality updates, feature updates, and Office updates are typically the largest bandwidth consuming events most organizations face. A 1 GB cumulative update pushed to 10,000 devices means 10 TB of traffic from the internet unless Delivery Optimization lets devices share locally. This is where properly configured Delivery Optimization pays for itself immediately.

Coordinate Delivery Optimization with deployment rings. Start with a small seeder ring, typically 5 to 10 percent of devices, so those devices populate peer caches before broader rings begin hours or days later. If Microsoft Connected Cache is deployed, the same seeder ring also populates the cache node, creating a persistent local source for later rings.

Scenario 1. Large-scale update deployments

Large scale deployments vary greatly in complexity and challenges. Device count isn’t the only factor to consider. Network infrastructure and configuration can also play a role in your configuration and deployment of Delivery Optimization.

How you tune Delivery Optimization for large-scale updates depends heavily on your WAN topology. The two most common designs call for different approaches:

Star (hub-and-spoke) topology

Branches connect to a central hub; internet traffic may be backhauled. Every update byte a branch device pulls from the internet crosses the internal link between the hub and spoke.

Group boundaries: Identify local LAN configurations at branch locations. If all devices at a branch location are on a single subnet, use DODownloadMode = 1 with DORestrictPeerSelectionBy=1 to restrict peers to that subnet. If a branch site has multiple subnets, DODownloadMode = 2 with a branch-specific DOGroupID is more effective because devices can discover peers throughout the branch instead of being limited to their local subnet.

Tip: Delivery Optimization Has Evolved

Many organizations disabled Delivery Optimization during early Windows 10 deployments after experiencing unexpected WAN traffic. At that time, peer sharing controls were far less granular, making it difficult to limit content sharing to devices within the same network or site.

As a result, some organizations chose to disable Delivery Optimization entirely and missed potential bandwidth savings from peer-to-peer content distribution.

Today, modern Delivery Optimization policies provide significantly more control through features such as Group mode, Group IDs, subnet-based peer restrictions, bandwidth management settings, and integration with Microsoft Connected Cache. These capabilities help organizations realize the benefits of peer caching while maintaining tighter control over network traffic.
Bandwidth throttling: Spoke links are often the bottleneck. Use DOPercentageMaxBackgroundBandwidth to limit Delivery Optimization background downloads to 10% to 25% of available bandwidth during business hours. Configure DOSetHoursToLimitBackgroundDownloadBandwidth to define the hours when those limits apply, then relax or remove the limits outside business hours.
Cache retention: Set DOMaxCacheSize to 40% to 50% and DOMaxCacheAge to match your final deployment ring so cached content survives all ring phase days at branches. Branch peers are the only local sources. They need to hold content long enough for the full ring cycle.
Hub site: Devices at the hub have direct internet access and also typically have more bandwidth available. Standard cache settings (20% to 30%, 3 days) are usually sufficient.

Tip: Combine Peer Caching and Microsoft Connected Cache

In star (hub-and-spoke) network topologies, Microsoft Connected Cache (MCC) can deliver the greatest bandwidth savings at central hubs and larger branch offices. By caching frequently requested updates and applications locally, MCC helps reduce the amount of content that must traverse upstream WAN links.

You can configure an MCC server directly in your Delivery Optimization policy by specifying: DOCacheHost=<MCC FQDN>

When configured, Delivery Optimization continues to prioritize content from nearby peers. If the requested content isn't available from peers, devices will attempt to download it from Microsoft Connected Cache. If the content isn't present in the cache, devices automatically fall back to Microsoft's internet content source.

Think of the content retrieval process as a layered approach: Peers → Microsoft Connected Cache → Internet. This hierarchy helps optimize bandwidth usage while maintaining reliable access to updates and applications.

Distributed topology

With a distributed topology, all locations have their own local internet access. Each site reaches the internet directly, so the WAN penalty for a cache miss is lower.

Group boundaries: Set DODownloadMode=2 and set a DOGroupID. The key is that each physical site is its own peer group. DORestrictPeerSelectionBy = 1 (Subnet) is still recommended but less critical because cross-site peer-to-peer traffic is less likely.
Bandwidth limits: More relaxed than star. 25% to 50% during business hours is typical since each site has its own internet cache path.

Tip: With local internet connectivity and Delivery Optimization Group mode, many locations achieve excellent bandwidth savings with no additional infrastructure. Microsoft Connected Cache adds value primarily at the largest locations (more than 100 devices).

Scenario 2. Branch offices with limited WAN

Branch offices often see the biggest Delivery Optimization savings. Instead of every device pulling the same update over the WAN, one device can download from the internet and share locally with peers on the subnet.

Use DODownloadMode = 2 and assign a unique DOGroupID per branch location to keep peer-to-peer traffic within the branch. Set aggressive background limits (15% to 25% of link speed) to protect line-of-business applications. For very small branches with fewer than 10 devices, or locations where devices are frequently reimaged, consider adding a Microsoft Connected Cache node. A small cache server with a 100 GB drive provides a persistent local source that doesn't depend on any single peer being online.

Scenario 3. Mass provisioning and Windows Autopilot

During Windows Autopilot bulk provisioning or mass reimaging, many devices request identical content at the same time. Without Delivery Optimization, every device downloads independently from the internet cache, often saturating internet links and extending provisioning times.

For environments with repeated content consumption, such as shared devices, labs, and kiosks that get reimaged frequently, peer-to-peer distribution has a structural limitation. After a mass reimage, no device has cached content available to share. This is where Microsoft Connected Cache provides the greatest value. Because the cache node retains content on-premises independent of device state, the first device after a wipe can download from the local cache rather than the internet cache. If you're using peer-to-peer alone, consider staggering reimage schedules so that some devices always have content available to share.

Intune already uses Delivery Optimization to distribute Win32 and Microsoft Store apps, so no extra setup is needed beyond the core Delivery Optimization policies. The main tuning is around thresholds and retention. Lower DOMinFileSizeToCache from 10 MB to 5 MB so snaller app installers qualify for peer-to-peer sharing and extend DOMaxCacheAge to 7 days (604800 seconds) to accommodate app deployments that often span a full week.

During large provisioning events, be generous with cache resources. Increase DOMaxCacheSize to 50 percent or higher to ensure early devices have room to cache and share content. Set DOMonthlyUploadDataCap to 0 (unlimited) so the first-wave of devices can serve a larger number of peers. Finally, provision devices in stages whenever possible. Even a 15-minute delay between groups gives Delivery Optimization time to build peer availability before the next wave starts.

Scenario 4. Devices that move between locations

In environments where employees frequently move between locations, isolating peer traffic can be challenging. For example, a device assigned to the Group ID for Branch A may be physically connected at Branch B, causing it to search for peers across the WAN. In this scenario, use DHCP to provide the appropriate DOGroupID and, when applicable, DOCacheHost source for the device’s current location.

DOCacheHostSource=1 and set the DHCP Option 235 at the site to the FQDN of the Microsoft Connected Cache.
DOGroupIdSource=3 and set the DHCP Option 234 to the GUID for the GroupID.

Go further with Microsoft Connected Cache

Microsoft Connected Cache is an optional on-premises content cache. It complements Delivery Optimization by providing a persistent local source when peers are unavailable.

Tip: Start with Peer-to-Peer Caching First

Before deploying Microsoft Connected Cache (MCC), consider optimizing Delivery Optimization peer-to-peer caching. Many organizations achieve substantial bandwidth savings through properly configured download modes, peer groups, cache settings, and deployment rings without introducing additional infrastructure.

Peer-to-peer caching is often the simplest and most cost-effective first step because devices can share content directly with one another, reducing internet downloads and WAN utilization across the organization.

Microsoft Connected Cache becomes particularly valuable when peer sharing alone cannot fully meet business requirements, such as locations with few devices, frequent device reimaging, limited peer availability, or a need for a persistent on-premises content source. In these scenarios, MCC can complement Delivery Optimization to further reduce bandwidth consumption and improve content availability.

Microsoft Connected Cache is most valuable at small locations with few peers, in environments with frequent device resets, or anywhere large content volumes need a guaranteed local source. Devices can find the cache node in two ways:

Static (Intune policy): Set DOCacheHost to the FQDN of your Microsoft Connected Cache server in the Intune Settings catalog. Simple, static, works well for single-site deployments.
Dynamic (DHCP Option 235): Set DOCacheHostSource = 1 and configure DHCP Option 235 with the MCC server FQDN. Devices discover the correct cache node automatically based on network location. This is the preferred approach for multi-site deployments.

When using Microsoft Connected Cache, configure DODelayForegroundDownloadFromHttp to 30 seconds and DODelayBackgroundDownloadFromHttp to 60 seconds. These timeouts control how long Delivery Optimization waits for a local source before falling back to the internet cache; they don’t control download speed.

For setup details and hardware requirements, refer to: Release Notes for Microsoft Connected Cache for Enterprise and Education.

Troubleshooting tips

Slow downloads: The fallback timeout is the most misunderstood Delivery Optimization setting. It controls how long a device waits for a local source before requesting from the internet cache, not download speed. If downloads are slow, check network routing, DNS, and firewall rules.
Cache misses: Internet cache Vary headers can prevent content from being cached on the first request. Microsoft Connected Cache respects these headers, which can cause initial cache misses. The product team is actively working on a fix.
Diagnostics: Run the Delivery Optimization troubleshooter at aka.ms/DO-Fix for automated diagnostics.
PowerShell: Use Get-DeliveryOptimizationStatus in PowerShell to see real-time download source, peer count, and bytes per source for each active download.
Delivery Optimization reporting: Centralized reporting is available in the Windows Update for Business Delivery Optimization report or through PowerShell cmdlets. Monitor Delivery Optimization.

Get started

Delivery Optimization is already available on supported Windows devices you manage. The configurations in this post take minutes to deploy through the Intune settings catalog and can save significant bandwidth with every update cycle and application deployment. Start with the essential policies table, pilot the profile with a small device group, and review Windows Update for Business reports after a couple of patch cycles to measure the impact.

Many organizations achieve their goals using Delivery Optimization peer-to-peer caching alone. For scenarios where peer caching is insufficient or a persistent local cache is required, Microsoft Connected Cache is available as an additional option. The product team is active in the Connected Cache Community at aka.ms/ConnectedCacheCommunity, and feature ideas can be submitted through the Intune feedback portal at aka.ms/IntuneFeedback.

Resource	Link
Configure Delivery Optimization	Configure Delivery Optimization
Delivery Optimization Troubleshooter	Run the Delivery Optimization Troubleshooter
Microsoft Connected Cache Release Notes	View MCC Release Notes
Connected Cache Community	Join the Community
DO + MCC AMA Recording	Watch the AMA Recording
Intune Feedback	Submit Product Feedback

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

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.

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.

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.

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.

Streamlining macOS security: Automatically enable AutoFill after Platform SSO registration

Intune_Support_Team — Mon, 29 Jun 2026 18:31:55 GMT

By: Chris Kunze - Principal Product Manager | Microsoft Intune

Platform single sign-on (SSO) improves how macOS devices establish identity with Microsoft Entra ID, enabling a more secure and streamlined authentication experience. However, completing Platform SSO registration isn’t enough to deliver a fully passwordless workflow. To enable passwordless authentication in Safari, Microsoft Edge, and Google Chrome, the Company Portal AutoFill extension must also be enabled. In many deployments, this step still depends on the user.

Devices may be fully enrolled, and Platform SSO may be successfully registered, yet users can still fall back to entering credentials manually if Company Portal AutoFill is not enabled. At scale, even small manual configuration steps can lead to inconsistent results. The goal of this post is to remove that dependency by automatically enabling AutoFill after Platform SSO registration, so users receive a complete passwordless experience without any additional steps.

The challenge

After Platform SSO is deployed to a macOS device, two conditions must be met before users receive the intended passwordless experience:

Platform SSO registration must be completed
The device must complete Platform SSO registration with Microsoft Entra ID.
Company Portal AutoFill must be enabled
The Company Portal AutoFill extension must be enabled for supported browsers so credentials can be supplied automatically.

When Platform SSO registration happens after Setup Assistant, the user is prompted through the registration flow and receives a reminder to enable Company Portal AutoFill. However, enabling AutoFill is still a separate manual step that the user must complete. If the user skips or overlooks that step, the device can be successfully registered for Platform SSO while still requiring credentials to be entered manually. The result is a deployment that appears complete but does not consistently deliver the intended passwordless experience or security posture. Authentication should not depend on user action after enrollment.

Especially valuable with the “Enable Registration During Setup” setting

This approach becomes especially impactful when combined with the Enable Registration During Setup setting for Platform SSO. When used with Automated Device Enrollment (ADE), Platform SSO registration can be completed automatically during Setup Assistant before the user reaches the desktop. This helps ensure identity registration completes as part of the provisioning experience rather than requiring additional post-enrollment actions.

Automating AutoFill after Platform SSO registration

After registration has completed, AutoFill often becomes the final remaining step that still depends on user action. To close this gap, you can use a custom script to enable the Company Portal AutoFill extension after Platform SSO registration is complete.

The sample script, Check-PSSO.zsh, available in the GitHub repository, was written by the Intune Customer Experience Engineering team. The script detects when Platform SSO registration has completed on a device and then enables AutoFill automatically.

Important:

The script essentially performs four key actions:

Wait for a user session - The script detects when a user session is active to ensure the device is ready for configuration.
Verify Platform SSO registration - It confirms that Platform SSO registration has completed successfully before proceeding.
Detect the AutoFill extension - The script waits until the Company Portal AutoFill extension becomes available on the device.
Enable AutoFill automatically - Once detected, the script enables AutoFill programmatically, eliminating the need for users to manually configure the setting in System Settings.

All activities are logged locally, providing visibility for auditing and troubleshooting.

Supported browsers

The Company Portal AutoFill extension works with:

Safari (native support)
Microsoft Edge (native support)
Google Chrome (requires Microsoft Single Sign On extension)

Once AutoFill is enabled, users can authenticate across all supported browsers on their macOS device without manually entering passwords.

System requirements

macOS 15 or later
Company Portal version 5.2604.0 or later installed on the device
Platform SSO configured via an Intune SSO extension profile

Deployment via Intune

The Check-PSSO script is deployed using a lightweight, scalable approach aligned with modern macOS management practices.

The recommended method is to package the script as a payloadless PKG with a pre-install script.

High-level steps:

Build an empty PKG
Attach the Check-PSSO script as a pre-install script
Upload the package to Intune
Assign it as Required
Verify successful deployment through script logs

Detailed instructions are available in the GitHub repository.

Key Features

Polling with timeouts

The script waits for the required conditions to be met before continuing, including an active user session and completed Platform SSO registration. To avoid indefinite loops in edge-case scenarios, it uses timeouts while polling for those conditions.

Diagnostic logging and auditing

Optional verbose logging provides detailed troubleshooting information and an audit trail confirming AutoFill was enabled. Each run is logged locally under:

/Library/Logs/Microsoft/IntuneScripts/checkPSSO

Clear exit codes

Exit 0: Success
Exit 1: Failure

Benefits of automating AutoFill

Automating AutoFill helps ensure users can take advantage of passwordless authentication without additional configuration steps. It reduces reliance on user action, improves deployment consistency, improves security posture, and supports zero-touch provisioning. It also provides admins with verification through centralized logging and reporting.

Get started

If you’ve already deployed Platform SSO, automating AutoFill is a natural next step toward delivering a complete passwordless experience. By removing a manual configuration step that often depends on user action, you can improve consistency and user experience across devices. When combined with the Enable Registration During Setup setting, this helps create a true zero-touch experience from enrollment through authentication.

Learn more

Let us know if you have questions by leaving a comment below or reaching out on X @IntuneSuppteam.

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.

Microsoft Intune and Apple platform updates: What to expect after WWDC 2026

Intune_Support_Team — Thu, 25 Jun 2026 18:33:03 GMT

By Benjamin Flamm | Product Manager, Iris Yuning Ye | Product Manager - Microsoft Intune

Apple’s Worldwide Developers Conference (WWDC) is the annual starting point for the next wave of Apple platform changes. For Microsoft Intune customers, WWDC is also the moment when IT teams begin planning how new operating system capabilities will affect Apple device management, security, app deployment, and user readiness ahead of the fall OS releases. We’ve spent time watching and re-watching the sessions, sifting through new documentation with a magnifying glass, and philosophizing over the impact of what’s new this year. Just like every year, we’ll still have our day zero blog officially announcing what Intune supports for the new OS versions; however, this year we’ve heard your feedback that you’d like to know where Intune is prioritizing investments ahead of time so that you can prepare with confidence.

What’s new in managing Apple devices

Our team is absolutely thrilled by the latest WWDC announcements and what they mean for organizations using Intune to manage Apple devices at scale. Apple is executing their promise of a declarative future, and we’re excited to enable our customers to leverage the benefits of declarative device management (DDM) like efficient configurations and real time status reporting. Most importantly, Apple continues to provide new customer-delighting functionality that previously didn’t exist in the legacy protocol.

Data-driven settings

The Intune settings catalog is our data-driven experience that automatically generates UI based on a schema. Basically, Intune adds new settings very quickly. Our goal is to always provide new settings like restrictions and intelligence controls as fast as possible, but in a way that’s enterprise ready. Having to manually create policies in third party tools just to upload them into the Intune admin center is a thing of the past. That said, these are the configurations and settings announced at WWDC 2026 that will be available very soon in the settings catalog for testing on the OS 27 betas.

Allow and deny binaries on macOS

One of the biggest announcements for device management this year is the new App settings configuration which includes declarative binary management for Mac. Until now, admins have relied on third party tooling and scripting for controlling unwanted apps on macOS, which is a clunky and time-consuming process. This new configuration also brings privacy permission management to DDM, reducing the number of prompts that users see while ensuring that apps have the permissions they need.

Content caching

Content caching has been supported in mobile device management (MDM) and our settings catalog for years, but it’s becoming much more powerful as it moves to DDM in macOS 27. New status items provide richer information about the health, disk space, and usage of content cache services without requiring a separate monitoring agent. This will be especially useful for everyone who wants to significantly reduce network traffic due to large deployments such as multi-gigabyte app installations and OS updates.

Platform Single Sign-on

Platform Single Sign-on (Platform SSO) picked up a major set of upgrades this year as part of its transition to DDM: the option to require Touch ID as a built-in second factor for logging in and unlocking FileVault. Additionally, new web-based authentication that opens the door to customizable push notifications, one-time codes, and QR-code sign-in for shared-device environments.

New skip keys for Automated Device Enrollment

Our settings story wouldn’t be complete without mentioning skip keys, and we have so much to mention this year! You may have seen the news that we recently updated our Apple enrollment policies, but what you may have missed is that these use the same infrastructure as our settings catalog. Starting this year, you should now expect to see skip keys release as fast as the Apple settings catalog.

Settings, settings, and more settings

Everything we’ve talked about so far is only the tip of the iceberg for settings and what’s coming, so here’s the complete list of what you should expect to see in Intune this summer:

App Settings
- Allow/deny macOS binaries
- App privacy
Content caching
DNS Settings
DNS Proxy
Extensible SSO
Safari privacy
Web Content Filter
Apple Intelligence (Calendar)
Device restrictions
Skip keys

Network configurations are now in DDM

This is the announcement that we’ve been waiting for ever since Apple first showed us the power of DDM! While there isn’t Wi-Fi support yet, we’re thrilled to see this first step into DDM-based network configurations. The on-device user experience and admin configuration experience will see significant improvements in comparison to today’s profile model, especially when managing policies that depend on certificates for authentication. Our team is evaluating the new network configurations for our roadmap as we build support for these critical workloads in a declarative world.

Fleet monitoring and MDM status

The more device information that Apple moves to DDM, the faster Intune will become. The 15-minute check-in will soon be obsolete as MDM can solely rely on the device to detect drift or issues. This year, Apple has continued to add more device information to the DDM status channel, allowing admins to get a richer picture of the health of their device fleet. Device health reports that highlight whether a specific hardware component is operating normally, or experiencing an issue, will provide useful insights to organizations when planning their next device refresh cycle or monitoring for device issues before they affect productivity. Apple also added new status reports that show MDM-specific information for devices, such as if they’re enabled for return to service or shared iPad, and APNS-related information for MDMs to better stay in sync with devices.

macOS package uninstall and the Managed App framework

Over the past few years, Apple has been adding new features that are shifting traditional agent-based management to the DDM stack. The declarative package (.pkg) configuration introduced last year lets MDM send complex macOS packages and configurations without the constraints of the legacy install command. This year, they rounded out the story by adding package uninstall to remove data and files that were installed by a declarative package configuration as well as extending the Managed App framework to macOS. Just like with the new network configurations, our team is investigating what this means for Intune Mac management and re-evaluating our macOS roadmap.

Streamlined log collection with AppleCare

Apple introduced a new command to remotely trigger enhanced log collection which seems simple, but it has a lot packed into it. The old way involved lots of downloading and waiting and uploading and more waiting. With this latest announcement, Apple has streamlined this whole process by allowing MDMs to send a command to enable the device for logging with the correct logging state configured. The cherry on top is this new process will tell the device to directly upload its sysdiagnose to AppleCare without requiring physical access to the device or manual interaction from the device owner. It also wouldn’t be a new feature without DDM status, and devices will report their enhanced logging status every step of the way. This will reduce a lot of the friction, idle time, and “what’s actually happening?” that’s associated with getting a sysdiagnose file needed for engineering investigations. This new feature benefits IT teams, AppleCare, MDMs, and everyone in between, and our team is prioritizing this new workflow for the fall.

Return to service (RTS) gets better and better

Apple has continued to iterate on the return to service workflow since its introduction in 2023. Its first iterations showed how RTS can be useful for troubleshooting, quickly returning devices back to a fresh service state while also preserving apps across resets. This year, Apple announced 2 major improvements: the ability to trigger RTS directly from the device and the ability to configure an inactivity timeout. This makes RTS a must-have for shared device scenarios where you need to securely and quickly minimize downtime between user sessions.

MDM software updates are no more

DDM is now the only way to manage software updates, with the legacy MDM workload being fully removed from support in OS 27. We will be removing the legacy software update policies and settings from our UI in the coming months. Intune has supported DDM updates since they were first released in 2023, and we also have gold standard software update reports where you can see rich and fast OS update status every step of the way. More information is available on our Tech Community blog.

How IT teams can prepare now

Identify the Apple device populations that are most business-critical, including supervised iOS and iPadOS devices, shared devices, and managed Macs.
Review enrollment, compliance, app deployment, and software update workflows that may be affected by major OS upgrades.
Plan a beta validation ring with representative users, devices, apps, and different network conditions.
Document known business-critical apps and confirm vendor readiness timelines for the fall OS releases.
Test the available beta settings in the settings catalog and share your feedback with our team and Apple via Feedback Assistant.
Watch for Intune documentation, Message center posts, and release notes as support details become available.

Looking ahead

Apple’s fall OS releases are an important planning milestone for every organization managing Apple devices, and Intune’s priority is to help our customers confidently adopt new capabilities securely and at scale. Keep an eye out for our yearly day zero blog to learn more about Intune updates and new feature support as we get closer to the OS 27 release this fall – happy beta testing!

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

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.

How to Configure macOS Privacy Preferences Policy Control (PPPC) Using the Intune Settings Catalog

Intune_Support_Team — Wed, 24 Jun 2026 18:14:31 GMT

By: Chris Kunze - Principal Product Manager | Microsoft Intune

Privacy Preferences Policy Control (PPPC) settings on macOS are used to pre-approve privacy permissions for apps so users aren't repeatedly prompted by macOS for access requests. Common examples include Full Disk Access, Screen Recording, Camera, Microphone, Accessibility, Files and Folders, and Apple Events permissions.

Organizations commonly deploy PPPC profiles to improve the user experience, reduce support calls, and ensure management and security tools have the permissions they require to function correctly. This is especially important for tools such as Microsoft Defender, remote support applications, compliance agents, and inventory tools. PPPC profiles also help standardize privacy settings across managed Macs and support zero-touch onboarding scenarios where users can begin working without manually approving a series of permission prompts.

Intune’s settings catalog provides a straightforward way to deploy PPPC settings, but because macOS uses strict matching criteria, a few configuration details are important to get right. If these settings aren’t configured correctly, apps can either break - or worse, fail quietly. This article walks through the key configuration details that help ensure those settings are applied correctly.

How macOS evaluates PPPC entries

macOS evaluates PPPC entries using a combination of:

App identifier (Bundle ID or Path)
Code requirement (from the app’s signature)
The specific permission being granted or denied.

Apple requires each PPPC payload to use either Authorization or Allowed, but not both. If any of these values don’t align correctly, the policy won’t apply.

Configure PPPC in Intune settings catalog

Create a settings catalog profile.
In the Intune admin center, create a macOS configuration profile using Settings Catalog. Search for: Privacy Preferences Policy Control.

Figure 1 - Settings picker showing Privacy Preferences Policy Control.This is where you'll configure the PPPC permissions required by your application.
Use the Authorization field
When configuring, select the Authorization setting instead of the legacy Allowed setting whenever supported, but never both.
Get the correct code requirement

On a Mac where the application is installed, open Terminal and run:
codesign -dr - /Applications/YourApp.app
Replace /Applications/YourApp.app with the path to the application you're configuring.

The output will contain a string similar to:
designated => identifier "com.example.app" and ...
Copy everything that appears after “designated =>” exactly as displayed. You'll use this value when configuring the PPPC entry in Intune.

Note: Some applications return a multi-line code requirement. If that happens, paste the value into Intune as a single continuous string without line breaks. The content for the Identifier field can also be extracted from this command.
Figure 2 - Screenshot of a terminal window showing Chrome/ChromeDriver startup errors, including “DevToolsActivePort file doesn’t exist” and certificate-related error messages.
Configure the PPPC entry

After gathering the required information, configure the application entry.

Field Value
Identifier type Bundle ID or Path
Identifier Application Bundle ID
Code requirement Full output from the codesign command in Step 3.
Authorization Allow

Figure 3 - Screenshot of the Microsoft Intune admin center editing a OneDrive configuration profile. The main pane shows privacy and synchronization settings, while a right-side “Configure instance” panel displays Privacy Preferences Policy Control options, including an enabled setting for “Use System SSL.”
Tip: Use Bundle ID for apps whenever possible.

Field	Value
Identifier type	Bundle ID or Path
Identifier	Application Bundle ID
Code requirement	Full output from the `codesign` command in Step 3.
Authorization	Allow

Why PPPC settings may not apply

If these settings fail, they fail silently. Intune may report the policy as successfully applied, but macOS evaluates PPPC entries when the app requests access to the protected resource. Upon app launch, macOS skips any entry where the code requirement doesn’t match the app’s current binary signature without any indication that the setting is skipped. The three most common causes are:

Incorrect code requirement
The code requirement must match the application's current signing information exactly. Even a small mismatch can prevent the PPPC setting from being applied.
Mixing Authorization and Allowed
Apple’s documentation states PPPC entries should use either Authorization or Allowed, not both.
Wrong identifier type
If the PPPC entry is configured with the wrong identifier type, macOS won't match the application correctly.

Try it in your environment

If you’ve been avoiding the settings catalog for PPPC, try this approach. Pull the identifier and code requirement directly from the app using codesign, use Authorization when available, and validate the configuration with a pilot group before broader deployment.

Most PPPC issues come down to matching. Once you understand how macOS evaluates these settings it becomes much more predictable.

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

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.

Exporting all Microsoft Intune Enterprise App Management catalog apps to CSV using Microsoft Graph

Intune_Support_Team — Mon, 22 Jun 2026 17:59:40 GMT

By: Joe Lurie, Sr. Product Manager | Microsoft Intune

Managing applications at scale is one of the biggest time-consuming tasks for IT admins. Between packaging installers, writing detection rules, and keeping everything up to date - it adds up fast. That's exactly the problem Enterprise App Management in Microsoft Intune is designed to address.

Enterprise App Management gives you access to a curated Enterprise App Catalog with hundreds of popular Win32 apps that are pre-packaged, pre-tested, and ready to deploy. Microsoft handles the install commands, detection logic, and update-ready packaging. Automatic updates for catalog apps are expected to roll out in mid-2026, making the experience even more hands-off. You just pick the app, assign it, and move on.

But what if you want a full inventory of what's available in the catalog? Maybe you're evaluating which apps your organization can migrate from manual packaging, or you want to share the list with your app owners for review. In this post, I'll show you how to pull the complete catalog using Microsoft Graph PowerShell and export it to a CSV file.

Prerequisites

Before you start, make sure you have:

Intune admin permissions: An account with Intune permissions to read app and catalog data (such as Intune Administrator or a custom role with app read access).
- You will also need Microsoft Graph delegated scope: DeviceManagementApps.Read.All (you'll consent to this when connecting).
An Intune Suite or Enterprise App Management add-on license: Enterprise App Management is part of the Intune Suite or available as a standalone add-on. Note: Microsoft has announced that Enterprise App Management will also be included in Microsoft 365 E5 licensing starting July 1, 2026 - check current licensing guidance to confirm availability for your tenant.
Microsoft Graph PowerShell SDK (Beta module) installed: Note that the catalog API is currently in the beta endpoint which means cmdlet names and properties may change before reaching v1.0.

If you don't have the beta module installed yet, run:

Install-Module Microsoft.Graph.Beta.Devices.CorporateManagement -Scope CurrentUser -Force

Step 1: Connect to Microsoft Graph

First, authenticate to Microsoft Graph with the required scope:

Connect-MgGraph -Scopes "DeviceManagementApps.Read.All"

You'll get a browser prompt to sign in and consent. Once connected, you're ready to query the catalog.

Step 2: Retrieve all Catalog apps

Microsoft Graph exposes the Enterprise App Catalog through the /beta/deviceAppManagement/mobileAppCatalogPackages collection. The PowerShell cmdlet for it is:

$catalogApps = Get-MgBetaDeviceAppManagementMobileAppCatalogPackage -All

The -All parameter is important as it handles pagination automatically so you get every catalog package, not just the first page of results.

💡 Tip

To see every property available on a catalog package object, pipe the first result to Format-List.

$catalogApps | Select-Object -First 1 | Format-List *

Step 3: Export to CSV

Next, let's select the most useful fields and write them to a CSV file:

$csvPath = "C:\Temp\IntuneCatalogApps.csv" New-Item -ItemType Directory -Path (Split-Path $csvPath) -Force | Out-Null

$catalogApps | Select-Object ProductDisplayName, VersionDisplayName, PublisherDisplayName | Export-Csv -Path $csvPath -NoTypeInformation

Open the CSV in Excel and you've got a clean, sortable list of every catalog package in the Intune Enterprise App Catalog.

Putting it all together

Here's the complete script you can save and run:

# Connect to Microsoft Graph Connect-MgGraph -Scopes "DeviceManagementApps.Read.All" # Pull all Enterprise App Catalog packages $catalogApps = Get-MgBetaDeviceAppManagementMobileAppCatalogPackage -All # Export to CSV $csvPath = "C:\Temp\IntuneCatalogApps.csv" New-Item -ItemType Directory -Path (Split-Path $csvPath) -Force | Out-Null $catalogApps | Select-Object ProductDisplayName, VersionDisplayName, PublisherDisplayName | Export-Csv -Path $csvPath -NoTypeInformation Write-Host "Exported $($catalogApps.Count) catalog apps to $csvPath" -ForegroundColor Green # Disconnect when done Disconnect-MgGraph

Sample output

Your CSV will look something like this:

Product	Version	Publisher
Mozilla Firefox	`137.0.1`	Mozilla Corporation
Google Chrome	`135.0.6998.89`	Google LLC
Zoom Workplace	`6.4.6`	Zoom Video Communications, Inc.
Adobe Acrobat Reader DC	`25.001.20467`	Adobe Inc.
7-Zip	`24.09`	Igor Pavlov

Why this matters

Having a complete list of what's in the catalog is useful for a few scenarios:

App rationalization - Share the list with app owners and identify which apps you can stop manually packaging and switch to the catalog instead.
Gap analysis - Compare the catalog against your current app portfolio to see what's missing.
Change management - Track what's available over time as Microsoft continues to add new apps.
Compliance and auditing - Document which catalog apps are available for your tenant.

Wrapping up

Enterprise App Management is one of the most impactful features in the Intune Suite. It takes the most tedious parts of endpoint management - app packaging and updates - and just handles it for you. And with a short Graph script, you can get full visibility into what's available. And to see how Enterprise App Management secures your app catalog, check out the companion post here: aka.ms/Intune/EAM-Security.

Give the script a try and let us know what you think along with other Enterprise App Management topics you’d like to see by leaving a comment below or reaching out on X @IntuneSuppTeam.

Want to learn more about Enterprise App Management? Check out the official documentation for the full details.

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

Deploying Platform SSO for pre macOS 26 with Microsoft Intune: Lessons Learned

MikeGriz — Fri, 19 Jun 2026 23:33:29 GMT

By: Naveen Akkugari, Sr. Service Engineer and Michael Griswold, Principal Service Engineering Manager | Microsoft Intune

Who we are

Our internal Intune administration team at Microsoft is responsible for running Intune and Configuration Manager for the devices used by employees. We receive early access to features for evaluation and feedback using real world usage scenarios. As such, some features may be changed before the public release and be slightly different. The experience should be similar and we wanted to share our learnings when deploying platform single sign-on (PSSO). It is worth noting that since the time of this experience a new method for newer OS versions is available and you can read more about it at: New Platform SSO with registration during Automated Device Enrollment on macOS | Microsoft Community Hub.

Why we implemented Platform single sign-on (PSSO) and what we learned

As IT admins managing a growing Mac fleet, we kept running into the same gap. Our Windows devices had hardware-backed authentication, token protection, and seamless SSO through Windows Hello for Business, but our Macs were still relying on browser-based prompts with no easy way to enforce the same level of security and identity protection. Platform SSO finally closed that gap for us. It’s worth noting that new macOS allows new capabilities in this space and we are evaluating them as well. The new flow can be read about at https://aka.ms/Intune/MacPSSO-Setup.

While there were fewer pip-ups, we found the changes in the security layer to be the real value to our operations. Platform SSO binds authentication tokens (Primary Refresh Tokens) to the device’s Secure Enclave hardware. Even if a PRT is intercepted, it’s designed to not be replayed from another device. For our team, this unlocked two things we couldn’t do on macOS before:

Token protection policies: Conditional Access can now verify that tokens are device-bound, the same enforcement we had been relying on with Windows Hello for Business
Phishing-resistant MFA: Secure Enclave keys act as FIDO2 passkeys, so users authenticate with Touch ID instead of passwords or SMS codes

Getting from documentation to production took real effort for us. A password policy issue that silently blocked registration for half our pilot group, users who swiped away the registration banner without knowing what it was, and macOS updates that broke SSO overnight. This blog post is what we wish someone had written before we started.

How it works under the hood: Intune delivers the SSO extension profile → macOS prompts the user to register → the device registers with Microsoft Entra ID and gets a hardware-bound workplace (WPJ) certificate → a PRT is issued and bound to device hardware (not designed to be exported) → SSO works across Microsoft 365 apps, browsers, and Kerberos resources, all with token protection enforced.

Available authentication methods when we implemented

Capability	Secure Enclave	Smart Card	Password Sync
Passwordless and phishing-resistant	✅	✅	❌
Touch ID / passkey (WebAuthn)	✅	❌ Touch ID only	❌
Local password synced with Microsoft Entra	❌	❌	✅
Minimum macOS	13.0	14.0	13.0

Recommendation: Start with Secure Enclave. Keys are hardware-bound, phishing-resistant, and double as FIDO2 passkeys via WebAuthn, enabling browser-based passwordless login (Touch ID instead of passwords) and meeting Conditional Access multi-factor authentication (MFA) requirements. Unlike iCloud-synced passkeys, these are device-bound, aligning with Zero Trust.

Quick setup using the Intune settings catalog

Prerequisites: macOS 13+, Intune with Microsoft Entra ID, Intune Company Portal v5.2404.0+

In the Intune admin center, navigate to Devices > Configuration > Create > macOS > Settings Catalog > Authentication > Extensible SSO

Setting	Value
Extension Identifier	`com.microsoft.CompanyPortalMac.ssoextension`
Team Identifier	`UBF8T346G9`
Type	Redirect
Registration Token	`{{DEVICEREGISTRATION}}`
Use Shared Device Keys	Enabled
Screen Locked Behavior	`DoNotHandle`
URLs	`https://login.microsoftonline.com` `https://login.microsoft.com` `https://sts.windows.net` `https://login-us.microsoftonline.com`

Users see a “Registration required” notification → sign in → complete MFA → SSO works everywhere.

What the user experience looks like

Knowing what users see on their screen helps you write better rollout communications and cuts down help desk tickets.

First-time registration flow:

Profile arrives silently: After enrollment, Intune pushes the SSO extension profile to the Mac. Nothing visible to the user yet.
Registration banner appears: macOS displays a notification: “Registration required: Your organization requires you to register your device.” The user must click this to proceed. (This is our #1 learning point, users swipe it away, and there’s no simple way to retrigger it.)
Sign-in window: The user enters their Microsoft Entra ID email and password.
MFA challenge: Authenticator app push, phone call, or other configured method.
Secure Enclave key creation: macOS generates a hardware-bound key pair. The user may see a Touch ID or local password prompt to authorize this.
Registration completes: Device registers with Microsoft Entra ID, a WPJ certificate and PRT are issued. User sees a success confirmation.
SSO is active: From here, Microsoft 365 apps, Edge (natively), Chrome (with SSO extension), and Kerberos resources authenticate without prompts. Touch ID replaces password entry.

Missed the registration notification? Here is how to manually register:

This was our most common help desk ticket during rollout. If a user dismissed or missed the banner, they can still register manually through the following options:

(Recommended) System Settings → Users & Groups → Network Account Server: This is the easiest method. Go to System Settings → Users & Groups, scroll down to “Network Account Server” and click “Edit.” This opens a panel showing two sections: Network Servers and Platform single sign-on. If the Platform SSO policy is deployed, “Mac SSO Extension” will be listed under Platform single sign-on. If the device isn’t registered, there will be a “Register” button that can be selected to start the Platform SSO device registration flow.
Lock / Sign out and back in: Performing a lock or signing out of macOS followed by signing back in can retrigger the registration notification upon the next login attempt.
Wait for the notification to reappear: macOS retries the notification periodically around every 15 mins.
Last resort, reprofile: If none of the above work, an IT admin can remove and reassign the SSO extension profile in Intune. Before doing so, ensure any stale device objects are cleared from Microsoft Entra ID to avoid conflicts. Once the new profile lands on the device, the registration notification reappears.

How to verify Platform SSO registration

One of the first questions we got after rollout was “how do I know it’s actually working?” Here’s how both users and IT admins can confirm.

For IT admins (Microsoft Entra ID & Intune admin centers):

What to check	Platform SSO registered device	Non-registered device
Microsoft Entra ID → Devices	Join Type shows Microsoft Entra joined	Join Type shows Microsoft Entra registered
Intune → Device configuration	SSO extension profile shows Succeeded	Profile may show Pending, Error, or not assigned

For users (on the Mac):

System Settings → Users & Groups → Network Account Server: Scroll down in Users & Groups to “Network Account Server” and click “Edit.” If the Platform SSO policy is deployed, they will see “Mac SSO Extension” listed under Platform Single Sign-on. A registered device shows a green dot with “Registered” status and a “Repair” button (useful if registration gets into a bad state). If not registered, they will see a “Register” button instead. This is the quickest at-a-glance check for users.
System Settings → Users & Groups: Click on the user account name in Users & Groups (on macOS 14+, click the info button “i” next to the user name). When Platform SSO registration is complete, a “Platform Single Sign-on” section will be listed under the account. If Platform SSO is active, the user account shows the Microsoft Entra ID identity linked to the local account.
Company Portal app → Devices: The device should show as “Compliant” and “Microsoft Entra ID registered.” If registration failed, it shows “Registration required.”
Terminal command: Run app-sso platform -s to check Platform SSO status.

Troubleshooting Platform SSO errors

If you run into issues during deployment, here’s how you can diagnose and fix issues.

Step 1: Check the Platform SSO profile in Intune device management

Before troubleshooting on the Mac itself, confirm the profile reached the device:

In Intune: Go to Devices → select the device → Device configuration. The SSO extension profile should show “Succeeded.” If it shows “Pending” or “Error,” the device hasn’t received the policy. Check assignment groups, sync status, and whether the device is enrolled.

Then on the Mac: Go to System Settings → General → Device Management (or Profiles on older macOS). Look for the SSO extension profile (com.apple.extensiblesso). It should show as “Installed” with no errors. If the profile isn’t listed, it hasn’t been delivered yet. Check Intune assignment and device sync.

Step 2: Check registration status on the Mac

Refer to the previous section “How to verify Platform SSO registration” for steps.

Step 3: Check SSO extension logs

Run in Terminal for real-time logs:

log stream --predicate 'subsystem == "com.apple.AppSSO"' --level debug

Then prompt a sign-in (open Edge or Outlook). Look for:
Error 10002: Duplicate SSO profiles. Remove the extra one from Intune.
Error 10003: Registration failed. Usually a network issue or TLS inspection blocking auth URLs.
User cancelled: User dismissed the registration banner.
Token refresh failed: PRT could not refresh. Check network and whether the Microsoft Entra ID password was recently changed.

Step 4: Verify from the admin side

Check	How	What It Tells You
Profile delivery	Intune > Devices > select device > Device configuration	Whether the SSO profile reached the device and its install status
Registration state	Entra ID > Devices > search device > Properties	Whether the device has PSSO registration and NGC credential
Sign-in failures	Entra ID > Sign-in logs > filter by user	Error codes like `AADSTS50076` MFA required, `AADSTS700024` token issue, or `AADSTS7000218` client assertion
Token protection	Entra ID > Sign-in logs > Conditional Access tab	Whether token protection policy was applied or skipped
Company Portal version	Intune > Apps > macOS > Company Portal	Must be v5.2404.0+ for PSSO; older versions silently fail

Common error codes and fixes:

Error	Cause	Fix
`10002`	Multiple SSO extension profiles assigned	Remove duplicate profiles; keep only the Settings Catalog policy
`10003`	Registration failed network/TLS	Allowlist Apple and Microsoft auth URLs from TLS inspection
`AADSTS50076`	MFA required but not completed	User needs to complete MFA during registration
`AADSTS700024`	Client assertion invalid	Password likely needs reset; have user reset Entra ID password and retry
`AADSTS7000218`	Request body must contain `client_assertion`	Company Portal version too old; update to v5.2404.0+

Best practices

Have newer OS devices and use the new flow: New Platform SSO with registration during Automated Device Enrollment on macOS.
Have users reset their password before Platform SSO registration. During initial enrollment, if password configuration or compliance policies are applied, users are required to reset their password after device enrollment and prior to initiating Platform SSO registration. Skipping this step can result in silent registration failures that are difficult to diagnose. Ensure this is communicated as the first step in your rollout guidance.
Assign the SSO profile during enrollment, not after. Deploying during enrollment means the registration prompt shows up at first login, a natural part of setup. Retrofitting existing devices forces users to notice and click a notification banner. Many will not. macOS Tahoe (26) Simplified Setup will auto-register, removing this friction.
One SSO profile per device, no exceptions. Duplicate profiles cause Error 10002. If you are migrating from a Device Features template to Settings Catalog, remove the old one first.
Pilot with realistic scenarios. Don’t just test “can I open Outlook.” Test registration, SSO to Microsoft 365, on-prem file shares, password change mid-session, reboot behavior, and what happens when a user dismisses the registration banner. We found issues in every one of these.
Align password policies end-to-end. For Password Sync, Intune compliance and Microsoft Entra ID password policies must match: length, complexity, expiration.
Integrate legacy Kerberos properly. If you run a standalone Kerberos SSO extension, set usePlatformSSOTGT = true in its ExtensionData to reuse Platform SSO TGT instead of running duplicate flows. Requires macOS 14.6+ and Company Portal 5.2408.0+.
Enable Kerberos SSO to on-premises Active Directory and Microsoft Entra ID Kerberos Resources in Platform SSO.
Allowlist auth URLs from TLS inspection. Apple and Microsoft authentication endpoints must be excluded from proxy/TLS inspection. If they are not, registration fails silently with no error.

Challenges we faced

Challenge	What we experienced	Solution
Password must be reset before registration during the new enrollment	Half our pilot group could not register after the new enrollment as their Entra ID password had not been reset.	Require a password reset before rollout; make this step 1 in user communications
Users dismiss the registration banner	The notification is easy to swipe away. Once dismissed, there is no simple way to retrigger it.	Send screenshots and instructions before rollout; macOS Tahoe auto-registers via Simplified Setup
SSO breaks after macOS updates	After point updates, SSO stopped working until re-registration.	Restart `swcd` process; some cases required full re-registration; check release notes
Password policy mismatch	Users changed Microsoft Entra password, but local Mac password did not sync, causing lockouts.	Match Intune compliance and Microsoft Entra ID password policies exactly; test end-to-end
Browser SSO inconsistency	Edge worked natively, Chrome needed extension, Safari varied by OS.	Deploy Chrome SSO extension via Intune; test Safari on each target OS version

Conclusion

Platform SSO delivers phishing-resistant passwordless authentication, seamless cross-platform SSO, and Conditional Access compliance with hardware-backed identity. Start your implementation with Secure Enclave, deploy via Intune Settings Catalog, pilot small, then scale.

If you have questions on implementing Platform SSO, leave a comment below or reach out to us on X @IntuneSuppTeam.

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.

Triage vulnerabilities with the Vulnerability Remediation Agent, now in public preview

Intune_Support_Team — Fri, 19 Jun 2026 23:34:41 GMT

As automation and AI accelerate the pace of vulnerability discovery, the window between disclosure and exploitation continues to shrink. For IT and security teams, the challenge is no longer just finding vulnerabilities - it's prioritizing the ones that matter and acting on them before they can be exploited. To help organizations close that gap, we're pleased to announce that the Vulnerability Remediation Agent for Security Copilot in Microsoft Intune is now in public preview and rolling out to all customers.

Following a successful limited preview, the agent is now broadly available. This release brings agentic vulnerability remediation out of an early-access cohort and into the hands of every eligible organization - an important step in our continued investment in helping admins reduce exposure faster and with greater confidence. View eligibility prerequisites here.

How the agent helps you identify and triage vulnerabilities

The Vulnerability Remediation Agent uses data from Microsoft Defender Vulnerability Management to identify Common Vulnerabilities and Exposures (CVEs) across your Intune-managed Windows devices and apps, then prioritizes them for remediation. Rather than leaving admins to sift through lengthy CVE lists with little context, the agent surfaces a prioritized set of recommendations directly in the Intune admin center - accessible from both the Agents and Endpoint security pages.

When the agent runs, it evaluates vulnerability data and ranks threats based on factors such as CVSS scores, exposure impact, and affected device count, so the most critical issues rise to the top. Drilling into any suggestion provides:

The count of associated CVEs
A Copilot-assisted summarized impact analysis
Suggested actions and affected systems
Exposed devices and potential impact
Step-by-step guidance for remediating the threat using Intune

After acting on a recommendation, admins can mark it as applied, allowing the agent to retain a record for tracking remediation actions over time. The result is a meaningful reduction in the time it takes to investigate, prioritize, and remediate - strengthening overall security posture.

Introducing agentic identity for the Vulnerability Remediation Agent

With this release, the agent now operates under Microsoft Entra agentic identity - a meaningful advancement in how autonomous agents are governed and secured.

What it is. Agentic identity is a specialized identity in Microsoft Entra ID that allows the agent to operate securely and independently. During setup, the agent provisions a dedicated agentic identity and a corresponding agentic user in your tenant's Microsoft Entra directory. The agent then runs under the permissions delegated to that agentic user rather than under a human user account.

Why it matters. Agentic identity decouples the agent from any one person, ensuring its behavior is strictly bound to the permissions and scope you delegate to it. This delivers clearer accountability, a cleaner audit trail, and enterprise-grade governance for autonomous operations.

How it helps. Admins remain firmly in control. After setup, delegate the required read permissions to the agentic user in the Microsoft Intune and Microsoft Defender admin centers, then use the built-in Readiness Check to confirm everything is configured correctly before the agent runs.

Learn more in Agent identity.

Getting started: Connect → Enable → Run → Remediate → Track

One of the design goals behind the Vulnerability Remediation Agent is to make agentic security approachable, not complex. Rather than stitching together signals across multiple tools and admin centers, the agent guides admins through a clear, repeatable flow - from connecting your data to tracking measurable improvement over time.

Connect — bring Defender and Intune data together. The agent draws on Microsoft Defender Vulnerability Management for CVE intelligence and Microsoft Intune for device and configuration context. With the required Microsoft Defender and Microsoft Intune plugins in place, your vulnerability and management signals work as one. Learn more on what is needed to connect the experience.
Enable — turn on the agent. From the Agents node in the Microsoft Intune admin center, set up the agent in a few guided steps. During setup, the agent provisions its Microsoft Entra agentic identity and surfaces the permissions and plugins it needs, so you know exactly what to delegate before the first run.
Run — let automated prioritization do the heavy lifting. Once permissions are delegated and the Run Readiness Check passes, you can configure the agent to run on demand or schedule it to run automatically in the background on a cadence you define; scheduling is a unique capability that helps teams stay ahead of emerging risks without requiring constant manual intervention. Each run analyzes your environment and produces a prioritized list of recommendations ranked by CVSS score, exposure impact, and affected device count so the most critical risks rise to the top automatically.
Remediate — act with guided, Intune-ready actions. Each recommendation includes a Copilot-assisted impact summary, exposed devices, and step-by-step guidance for remediating the threat using Intune. Admins move directly from insight to action, without leaving the admin center.
Track — measure improvement over time. Recommendations can be marked as applied, and the agent retains a record of your remediation actions.

The outcome is a streamlined operating model: connect once, enable with confidence, and let the agent drive a continuous cycle of prioritization, remediation, and view progress. For full prerequisites, licensing, plugin, and role requirements, see Vulnerability Remediation Agent overview and set up.

The Vulnerability Remediation Agent represents a meaningful step toward a more proactive, AI-assisted security posture, one where admins spend less time sifting through CVE lists and more time acting on what matters most. We invite you to try the public preview today, connect your Defender and Intune data, and experience how agentic remediation can help your team stay ahead of emerging threats.

As always, we'd love to hear your feedback as we continue investing in making security in Intune faster, smarter, and more accessible. Share your tips and lessons learned in the comments below or reach out to us on X @IntuneSuppTeam.

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.

How Enterprise App Management secures your App Catalog from ingestion to device

Intune_Support_Team — Fri, 19 Jun 2026 23:32:01 GMT

By: Joe Lurie, Sr. Product Manager | Microsoft Intune

One of the most common questions I get from customers when I talk about Enterprise App Management is some version of: "Okay, but how do I know these apps are safe?"

It's a fair question. You're trusting a catalog of pre-packaged Win32 apps to land on thousands of managed devices across your organization. If you're responsible for endpoint security, you should be asking that question. This post explains how Enterprise App Management works behind the scenes, how apps get into the catalog, what happens before they're visible to your tenant, and why the architecture matters for your security posture.

The architecture: Not a new system, but an extension of what you already trust

An important design decision with Enterprise App Management is that it's not a separate app delivery system. It's an extension of the existing Intune Win32 app architecture.

From the admin perspective, everything starts in the Intune admin center. But behind the scenes, there's a clean separation between the control plane and the data plane:

Control plane: For each app being added to the Enterprise App Management catalog, Intune curates app metadata, including app version, install commands, uninstall commands, detection logic, requirements, and supported configurations. This metadata is validated and normalized before it shows up in your tenant. That's why catalog apps behave consistently whether you're deploying to 50 devices or 50,000.
Data plane: Once an app is assigned by an admin, it flows through the same Win32 app delivery and enforcement pipeline you already rely on. Your devices don't know they're installing an "Enterprise App Management app" - they're enforcing a Win32 app with well-defined intent. Same Enrollment Status Page support, same reporting, same retry logic, same Intune Management Extension. No new agent. No new runtime. And finally, Enterprise App Management apps have the same support for App Control for Business with Managed Installer which can automatically tag the apps as safe.

This is important because it means Enterprise App Management inherits all the trust and operational maturity of Win32 app management in Intune. Curated content is delivered through established, reliable infrastructure.

How Enterprise App Management apps are delivered: The ingestion pipeline

This section walks through what happens from the moment an app is sourced to the moment it appears in your catalog.

Content ingestion

It starts with the catalog. Microsoft receives app metadata, including install and uninstall commands, version info, and download URLs. The data is then ingested, flattened, transformed, and Microsoft's own identifiers are applied. After the data lands in the database, eligibility and filtering gates are applied through allow and deny lists. Apps on the allow list are permitted to download content from controlled internet locations. This process handles both net-new apps and version updates to apps already in the catalog.

Security and functional validation

This is the part that answers the "how do I know it's safe?" question. Once content ingestion is complete, every app is submitted for security and functional validation. This is a queue-driven service that runs two parallel tracks:

Static malware detection scans the installer and related artifacts for malicious content, assigning a VirusTotal score. If an app receives a non-zero score, it's blocked from proceeding, full stop. Static scanning is about establishing baseline trust before deployment. It validates that binaries are intact, that they originate from trusted sources, and they don't carry known indicators of malware or tampering. This process catches embedded malicious payloads, corrupted binaries, and known bad signatures before they can impact any device.
Dynamic analysis (detonation) runs in parallel. The app is installed and uninstalled inside a VM detonation chamber, producing install results, logs, and artifacts. This is about validating behavior, not just files. Modern threats don't always look malicious at rest; some issues only surface when an installer or application runs or interacts with the system. Dynamic evaluation catches unexpected system changes, unsafe persistence mechanisms, and activity inconsistent with enterprise deployment expectations.

If an app fails automatic validation, it goes through manual validation by Intune engineering.

Both layers are required. Static scanning provides speed and broad coverage, while dynamic scanning provides depth and behavioral assurance.

After publication: Ongoing scanning

The security story doesn't end at publication. Apps already in the catalog are periodically re-scanned. If a version that previously passed validation is later found to fail a malware scan, it's flagged and removed from the catalog. This is a critical detail - the catalog isn't a snapshot-in-time trust decision. It's a continuously validated inventory.

Update velocity

Once a new app version is received, the target is to have it available in the catalog within 24 hours. Around 80–90% of apps hit that timeline. The remainder are apps that don't pass automatic validation and require manual review, which takes longer. But the pipeline processes updates through the exact same ingestion and validation flow as new apps - no shortcuts.

Where Zero Trust fits in

If you've been following Microsoft's Zero Trust model, this pipeline should feel familiar. Zero Trust is built on three principles: verify explicitly, use least-privilege access, and assume breach. EAM's validation pipeline maps directly to these:

Verify explicitly: Every app is verified through multiple independent signals, including source integrity, static malware scanning, and dynamic behavioral analysis, before it's ever exposed to a tenant. No app gets a pass based on reputation or publisher name alone. Trust is earned through evidence, every time.
Use least-privilege access: Enterprise App Management catalog apps ship with prefilled, scoped install and uninstall commands, detection rules, and requirements. You're not handing an installer broad system access and hoping for the best. The deployment surface is defined and constrained by design.
Assume breach: This is why the pipeline doesn't stop at initial validation. Ongoing re-scanning means that even apps that previously cleared every check are continuously re-evaluated. If an app that was clean six months ago is later found to carry a risk, it's flagged and pulled from the catalog. The system assumes that trust is perishable, exactly the way Zero Trust says it should be.

In practice, this means Enterprise App Management gives you an app lifecycle that's not just convenient - it follows the same security framework your organization is likely already adopting for identity, network, and device access. The app layer is often the last piece to catch up, and Enterprise App Management closes that gap.

Here's the ingestion flow that shows how all of this fits together:

Figure 1: The Enterprise App Management ingestion pipeline: from source metadata through content ingestion, static and dynamic security validation, manual review for failures, periodic re-scanning, and finally publication to the catalog.

Takeaways

If you're evaluating Enterprise App Management or explaining it to your security team, here's what I'd suggest that you land on:

Enterprise App Management reduces the packaging tax. Pre-packaged apps with prefilled install details, detection rules, requirements, and restart behavior mean you spend less time building the same scaffolding repeatedly and more time on policy and rollout strategy.
Patching becomes more predictable. Guided update flows using supersedence and a documented expectation of 24-hour update availability give you a cadence you can plan around, not react to.
The security model is layered and continuous. Static scanning, dynamic detonation, manual review fallback, and ongoing re-scanning mean the catalog maintains a high trust bar - not just at ingestion, but over time. And it's all built on the same Win32 delivery infrastructure that you and your devices already trust.

The bottom line: Enterprise App Management isn’t just about convenience. It shifts the app lifecycle from a manual, error-prone process to one with built-in security validation, operational consistency, and governance you can defend to your security team. Rather than manually sourcing installers and creating detection rules, use this approach to streamline the process.

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

Want to go deeper? Check out the Enterprise App Management documentation and keep an eye out for upcoming changes to Intune Suite licensing that will make Enterprise App Management available in the Microsoft 365 plans you may already own. And as always, drop feedback at aka.ms/IntuneFeedback.

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 .

MDOP is out of support: What to do next with Microsoft Intune

Intune_Support_Team — Fri, 19 Jun 2026 23:35:18 GMT

By: Joe Lurie – Sr. Product Manager | Microsoft Intune

On April 14, 2026, the Microsoft Desktop Optimization Pack (MDOP) reached the end of extended support. Microsoft no longer provides security updates, bug fixes, or technical support for MDOP components. For more information, refer to: Microsoft Desktop Optimization Pack (MDOP) support extended.

If your organization still relies on parts of MDOP, it’s time to move to supported options. In most cases, including Windows desktop management, app virtualization, BitLocker administration, and Group Policy change control, you can handle the same workloads with capabilities in Microsoft Entra ID, Intune, Windows 11, and Configuration Manager.

Moving these workloads to the cloud does more than keep you supported. It removes on-premises server infrastructure you have to stand up and patch, brings management of cross-platform devices into a unified console, and connects capabilities like encryption and recovery into a Zero Trust framework with Conditional Access.

Quick start checklist

Inventory what you actually use. Confirm whether Application Virtualization (App-V) server components, Microsoft BitLocker Administration and Monitoring (MBAM), Diagnostics and Recovery Toolset (DaRT), User Experience Virtualization (UE-V), or Advanced Group Policy Management (AGPM) are still in production.
Prioritize BitLocker Management first. If you still rely on MBAM, plan your move to BitLocker management in Intune and confirm recovery key escrow is working as expected.
Plan your App-V exit. Keep existing App-V packages running where needed but shift net-new packaging work to MSIX.
Validate your PC recovery story. Document how you’ll handle common break/fix scenarios using Quick Machine Recovery, WinRE, bootable media, and Intune remote actions.
Decide how you want to handle policy change management. For cloud policy, we recommend Multi Admin Approval for sensitive actions and policy-as-code practices for versioning and review.

App-V

App-V let you virtualize applications so they could run in isolated environments without a traditional install, which helped avoid app conflicts. It was especially useful for legacy line-of-business apps that were hard to install or update cleanly.

Important
The App-V server components (Management Server, Publishing Server, Reporting Server) reached end of extended support in April 2026. The App-V client and sequencer are still included with Windows Enterprise and Education editions. They will continue to receive security fixes for the support lifecycle of the Windows versions they ship with. If you are distributing App-V packages today via Configuration Manager, that can still work. The key change is that you should not plan on using the standalone App-V server infrastructure going forward. For more details refer to: App-V in Windows support policy.

What to do instead: For new packaging work, we recommend moving to MSIX. MSIX is a modern packaging format that supports clean install and uninstall and more predictable updating. The MSIX Packaging Tool can help you convert existing installers. In Azure Virtual Desktop, MSIX App Attach can deliver apps without baking them into the base image. A good starting point is to inventory your App-V packages, identify the ones you still need, and prioritize candidates to convert to MSIX.

MBAM

MBAM gave IT admins centralized control over BitLocker, including policy enforcement, compliance reporting, and a self-service recovery portal. Many organizations used MBAM as their standard management solution.

What to do instead: We recommend replacing MBAM with Microsoft Intune’s BitLocker policy management through an Endpoint security policy. Intune management provides backup of recovery keys to Microsoft Entra ID, reporting, and Conditional Access integration so you can require encryption for access to company resources. If you already manage devices with Intune, you may only need to create a disk encryption policy and confirm recovery keys are being escrowed. For detailed guidance, review Encrypt Windows devices with BitLocker using Intune.

DaRT

DaRT provided a bootable recovery environment with advanced tools like file recovery, registry editing, and offline troubleshooting. You typically used DaRT when a machine wouldn’t boot and you needed to repair it or recover data without reimaging.

What to do instead: Windows includes the Windows Recovery Environment (WinRE) with tools like Startup Repair, System Restore, command prompt, and reset options. For many scenarios DaRT covered, WinRE is enough. You can also boot from a Windows installation USB, select "Repair your computer," and use the recovery tools for tasks like offline troubleshooting.

For managed devices, you can pair recovery options with Intune remote actions, such as restart, wipe, or collect diagnostics, or use Quick Machine Recovery. Additionally, Quick Machine Recovery can automatically detect and fix boot failures using cloud-based remediation delivered through Windows Update, with no hands-on IT intervention required for managed devices running Windows 11 version 24H2 or later. You can enable and configure it through the settings catalog in Intune, and Windows Autopilot scenarios for redeployment. These don’t replace every DaRT capability, but they cover many common use cases and work without shipping a separate recovery toolkit.

UE-V

UE-V roamed (synchronized) some user application and OS settings to persist across devices so users could sign in to a different Windows PC and keep a familiar experience. This was often used in shared workstation scenarios.

What to do instead: For Windows settings roaming, Windows Backup for Organizations syncs certain Windows settings across Microsoft Entra ID joined devices. Review the latest guidance to confirm which settings are covered and how to enable it in your environment.

Important:

Windows Backup for Organizations syncs Windows settings (theme, password, language) but doesn’t roam per-application settings for Win32 apps. Some apps may provide their own cloud-based sync. Windows Backup for Organizations is not a direct replacement for UE-V.

For user files, we recommend OneDrive Known Folder Move to back up Desktop, Documents, and Pictures so content follows the user. Many Microsoft applications also sync their own settings through the cloud, which reduces the need for an OS-level roaming solution.

Another option is to use a virtualized solution, like Azure Virtual Desktop or Windows 365. With a Cloud PC, users connect to the same environment from any device, so settings and apps are already there when they sign in. For scenarios where UE-V mattered most, like shared workstation environments, Windows 365 can be a practical alternative. And for Azure Virtual Desktop, FSLogix is a viable option.

Important:

Enterprise State Roaming does not roam per-application settings for traditional Win32 desktop apps the way UE-V did. So, Windows 365 may not be the right fit if you need settings roaming across multiple physical devices.

AGPM

AGPM brought version control, change tracking, and approval workflows to Group Policy management. Instead of an admin changing Group Policy Objects (GPOs) directly in production, AGPM enforced a check-out and check-in model with full audit history. This mattered most in environments with strict change management requirements.

What to do instead: Move to cloud-managed endpoints and replace Group Policy settings with Intune configuration profiles and security baselines. The settings catalog in Intune includes thousands of settings, including many ADMX-backed policies. If you use custom ADMX files for third-party or internal applications, you can import them into Intune. For settings that aren’t available in the catalog, custom OMA-URI profiles can sometimes be used, depending on the CSP support for that setting.

For change management, Intune offers Multi Admin Approval for certain policy changes, which can add a second-admin approval step. If you want deeper versioning and review workflows, we often see teams using Configuration as Code. Teams practicing Configuration as Code define Intune policies as code or structured data, such as in a JSON file stored outside the Intune admin center. This can be stored in version control like Azure DevOps or GitHub, and use Microsoft Graph – directly or via tooling – to deploy and reconcile the service. This enables deep versioning, peer review, and repeatable, auditable changes. And with Intune, you can use Graph API to get two years of audit events.

Summary

MDOP tool	What it did	Cloud-native replacement
App-V (Server)	Application virtualization and streaming	MSIX packaging and Intune deployment (client still supported in Windows)
MBAM	BitLocker management and recovery	Intune management of BitLocker and Microsoft Entra ID key escrow
DaRT	Bootable diagnostics and recovery	Windows Recovery Environment (WinRE), bootable USB, and Intune remote actions
UE-V	User settings roaming	Windows 365 Cloud PC, Windows Backup for Organizations, OneDrive Known Folder Move, app-native sync
AGPM	GPO version control and approval workflows	Intune settings catalog, Multi Admin Approval, policy-as-code in source control

Moving forward

By moving to cloud endpoint management, most MDOP scenarios are covered through Microsoft Intune and Microsoft Entra ID supported capabilities with less infrastructure to maintain, making it easier for you to manage.

If you haven’t started planning yet, we suggest starting with MBAM since Intune is the most direct replacement. Then, you can work through App-V, DaRT, UE-V, and AGPM based on what’s still in use.

If you’re in the middle of an MDOP exit and need help leave a comment below or reach out to us on X @IntuneSuppTeam. Tell us which components you still have and how you manage endpoints today (Intune, Configuration Manager, hybrid, or other). We can help you sanity-check dependencies, choose an order of operations, and avoid common migration pitfalls.

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.