Intune Customer Success articles

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.

New Platform SSO with registration during Automated Device Enrollment on macOS

Intune_Support_Team — Mon, 22 Jun 2026 17:49:03 GMT

By Iris Yuning Ye, Product Manager – Microsoft Intune & Justin Ploegert, Principal Product Manager – Microsoft Entra

A new setting ‘Enable Registration During Setup’ for Platform single sign-on (PSSO) during Automated Device Enrollment (ADE) is now generally available for macOS devices in Microsoft Intune. With this new setting and a compatible version of the Intune Company Portal (5.2604.0 and newer), this feature enables users sign in with their Microsoft Entra account during Setup Assistant, complete device registration before reaching the desktop, and get immediate access to work resources and ready to be productive sooner.

Why this matters

Previously, Platform SSO registration occurred only after users completed Setup Assistant and reached the desktop. They then had to notice and act on a separate notification to finish Platform SSO registration. When Platform SSO registration isn't completed, it can cause issues with app authentication or lead to noncompliance, delaying users from getting started on the device:

Missed notifications - Users dismiss or ignore the post-enrollment PSSO prompt, leaving devices in an incomplete device registration state.
Broken app authentication - Apps like Microsoft Outlook could fail to authenticate because SSO isn’t fully configured.
Compliance gaps - Devices are flagged as noncompliant in the Intune Company Portal because Platform SSO registration isn’t completed.
Helpdesk burden - IT teams field repeated tickets for issues that should have been handled automatically during provisioning.
Migration blocker - Incomplete Platform SSO setup slows down migrating macOS devices to Intune.

Platform SSO during ADE with EnableRegistrationDuringSetup key eliminates these issues. Device registration, identity bootstrap, and credential setup all happen inline during Setup Assistant before the user ever reaches the desktop.

What the feature enables

Capability	Details
Microsoft Entra device registration during ADE	The device registers with Microsoft Entra ID before the user reaches the desktop. A hardware-bound Workplace Join certificate is issued and stored securely on the device.
Early device identity	Device identity is established early in the provisioning process, enabling immediate access to apps and resources protected by Conditional Access.
Platform SSO credentials during initial setup	When configured with Secure Enclave, Platform SSO credentials are stored in the device’s Secure Enclave, providing hardware-bound, phishing-resistant protection aligned with Zero Trust principles.
Minimized setup delays	Users arrive at the desktop already signed in and ready to work, with fewer authentication prompts, less policy wait time, and fewer setup-related app access issues.

How it works

This feature requires three policies that work together. All three must be configured correctly before enrollment starts and assigned to the same static user groups:

A Platform SSO settings catalog policy with “Enable Registration During Setup” configured to Enabled.
Intune Company Portal (version 5.2604 or newer) deployed as a line-of-business (LOB) app, which provides the Microsoft Enterprise SSO extension.
An ADE enrollment profile configured with Setup Assistant with modern authentication and Await final configuration = Yes.

When a device enrolls with these three policies in place, here's what happens:

The device powers on and begins the ADE enrollment flow.
Intune delivers the Platform SSO settings catalog policy with Enable Registration During Setup enabled.
Intune Company Portal is installed automatically as a LOB app, providing the Microsoft Enterprise SSO plug-in.
During Setup Assistant, the user signs in with their Microsoft Entra credentials. This first sign-in starts the regular enrollment process.
A second sign-in authenticates the identity in Intune Company Portal and fetches the SSO extension.
The device registers with Microsoft Entra ID, and a Microsoft Entra device registration certificate is issued.
The user arrives at the desktop fully authenticated, with SSO active and Conditional Access satisfied.

Note: During enrollment, users are prompted to enter their Microsoft Entra credentials at least twice. We're working on improvements to reduce the number of sign-ins in a future update.

Prerequisites

Requirement	Details
macOS version	macOS 26 or later.
Enrollment method	Automated Device Enrollment (ADE) through Apple Business Manager.
Intune Company Portal	Version `5.2604.0` or later, deployed as a line-of-business (LOB) app. Download it from Microsoft Download Center .
Intune role for configuration	An administrator account with, at minimum, the built-in Policy and Profile Manager role.
Group type	Assigned (static) user groups only. Dynamic groups and device groups are not supported.

Important: Review the full Platform SSO prerequisites in the Platform SSO configuration guide before you begin.
High level step-by-step configuration

Step 1: Create or update the Platform SSO settings catalog policy

In the Microsoft Intune admin center, go to Devices > Manage devices > Configuration. If this is your first time configuring Platform SSO, follow the full Platform SSO configuration guide.
Add and configure the following setting:

Setting Value Description
Authentication > Extensible Single Sign On > Platform SSO > Enable Registration During Setup Enabled Enables the Platform SSO registration process during Setup Assistant.

Setting	Value	Description
Authentication > Extensible Single Sign On > Platform SSO > Enable Registration During Setup	Enabled	Enables the Platform SSO registration process during Setup Assistant.

If using the Password authentication method, it’s recommended to add for password sync function:

Setting	Value	Description
Authentication > Extensible Single Sign On > Platform SSO > Enable Create First User During Setup	Enabled	Enables the password synchronization experience during Setup Assistant. This configuration is recommended when using the Password authentication method.

Tip: Microsoft recommends using Secure Enclave as the authentication method for the strongest hardware-backed security.

Assign the policy to your static user groups. Filter is also supported with correct static group setting.

Step 2: Install Intune Company Portal as a LOB app

Download the Company Portal for macOS PKG from the Microsoft Download Center.
In the Intune admin center, go to Apps > All Apps > Create.
Add Intune Company Portal as a macOS LOB app.
Make it a required app and assign it to the same groups as the Platform SSO policy from Step 1.

Important: Company Portal 5.2604.0 and newer is required. If you install an older version, Platform SSO fails. When Intune detects Company Portal as a deployed policy, it sends it with priority during enrollment.

And clean up the App bundle ID that are not related to Company Portal, make sure only com.microsoft.CompanyPortalMac as the relevant App bundle ID is kept.

Figure 1: Microsoft Intune admin center Add App screen for a macOS line-of-business app, showing CompanyPortal-Installer.pkg details, macOS Tahoe 26.0 minimum OS, ignore app version enabled, install as managed disabled, and included app bundle ID com.microsoft.CompanyPortalMac version 5.26040.

Step 3: Set up the enrollment profile

In the Intune admin center, go to Devices > Device onboarding > Enrollment > Apple tab.
Create or edit an Automated Device Enrollment profile with these Management settings:

Setting Value
User affinity Enroll with User Affinity
Authentication Setup Assistant with modern authentication
Await final configuration Yes
Locked enrollment Yes
Assign the profile to the devices afflicated with the users targeted as Steps 1 and 2.

Setting	Value
User affinity	Enroll with User Affinity
Authentication	Setup Assistant with modern authentication
Await final configuration	Yes
Locked enrollment	Yes

Critical: You must assign all three policies to the devices afflicated with the users targeted. If any policy is assigned to a different group, or if any step is misconfigured, enrollment will fail. In that case, wipe the device and re-enroll with all steps correctly configured.

Key things to remember

✅ Three policies, one group: Settings catalog, Company Portal LOB app, and ADE enrollment profile, all assigned to the same static groups or devices/users affliated with the groups.
✅ Static groups only: This feature does not work with device groups or dynamic groups.
✅ One SSO policy per device: If you already have a Platform SSO policy assigned to enrolled devices, make sure device is wiped appropriately before kicking of enrollment with new PSSO flow.
✅ Latest Intune Company Portal: Version 5.2604.0 or newer is required.
✅ macOS 26 required: This feature is supported on macOS 26 and newer.
✅ Secure Enclave recommended: For the strongest hardware-backed credential protection.

For more details, refer to Configure Platform Single Sign-On (PSSO) during Automated Device Enrollment for macOS devices.

Looking ahead: Reducing Platform SSO sign-in prompts

Signing in multiple times during enrollment isn't the ideal experience, and we're actively working to streamline it with a new enrollment setting that enables users to complete both Intune enrollment and Platform SSO device registration with a single sign-in. This will further simplify the onboarding experience, reduce friction for users, and bring macOS enrollment closer to a truly seamless, zero-touch provisioning flow. Stay tuned to What’s new in Intune for the release.

Related resources

As always, we'd love your feedback. If you've piloted Platform SSO during Setup Assistant, share your tips and lessons learned in the comments below or reach out to us on X @IntuneSuppTeam.

Post Updates:
6/8/26: Refreshed guidance recommending this configuration for the Password authentication method and clearer targeting language around devices and users affiliated with the groups targeted.

Known issue: Upgrading Microsoft Tunnel version 20260129.1

Intune_Support_Team — Mon, 15 Jun 2026 17:51:11 GMT

We identified an upgrade issue with the early March release of Microsoft Tunnel version 20260129.1 that caused servers to become stuck and unable to complete the upgrade. The issue can be resolved by uninstalling and reinstalling the server to a newer version (20260330.1 or later). Alternatively, we’ve created a script to help you update affected servers. This blog explains how to use the mstunnel-patch-2602 script to remediate the issue.

Before you begin

Before you run the script, make sure you have the following:

Access to the Linux virtual machine hosting the Microsoft Tunnel server
Permission to run commands with sudo
The patch script downloaded to the server from https://aka.ms/mstunnel-patch-2602

When to use this script

Use this script if your server is showing one or more of the following behaviors:

The server remains on the affected version (20260129.1) and doesn’t move to the latest version
In the Intune admin center, the server health state appears as Healthy, but the upgrade banner shows an error
The server rolls back to the affected version because of a version mismatch in Agent Settings

Identify impacted servers

The issue affects servers on version 20260129.1, use the following hash to identify whether your deployment is on this version:

Agent: sha256:abbdcd854aa5ac376aed32c828e4c84917e776a701855cd1e3febed18a3e4dae
Server:sha256:ad57d6a7ffe21f64fc1577713063ae9b180914cf65bc70b4e49be21299cfc1d3

The issue was resolved with version 20260330.1, released March 30, 2026. You can verify your servers are on this version with the following hash:

Agent: sha256:163214b94af6d91a5ef02690f891c5a41e87b1059b9530324716ee34778c1785
Server: sha256:dd62c292528e8e5aa4e7b84418efa42fd3830ec0db40467947cde8125aa17d7e

Additionally, in the Intune admin center check the server site auto upgrade setting. If auto upgrade is turned off (Automatically upgrade servers at this site = No), select "Upgrade servers" to configure the latest image for site.

Figure 1: Screenshot of the Microsoft Intune admin center showing a Microsoft Tunnel Gateway site named “SimpleSite” with theUpgrade servers option highlighted.

Run the script

After downloading the script to the server, complete the following steps.

Step 1: Enable execution permissions

If needed, make the script executable:

chmod +x mstunnel-patch-2602.sh

Step 2: Run the script

Run the script with elevated permissions:

sudo ./mstunnel-patch-2602.sh

When the script runs, it performs the following actions automatically:

Checks whether the current server is using the affected build hashes.
Creates backups of the current configuration so the system can revert if the update fails.
Stops the Tunnel agent and server services.
Updates the configuration with version 20260330.1 hashes
Pulls version 20260330.1 and forces mst-cli install without requiring additional user input

Expected results

After the script completes successfully, the server should be updated to the March 30, 2026 version 20260330.1. This remediation is intended to resolve upgrade failures caused by a version mismatch and eliminate the need for a manual uninstall and reinstall workflow.

If you have any questions or issues running the script to update your servers, reply to this post or reach out to the team on X @IntuneSuppTeam.

Post Updates:
6/15/26: Added guidance to check the server site auto-upgrade setting in Intune and use the Upgrade servers option when auto upgrade is disabled to apply the latest image.

Migrating frontline mobile devices: Aligning stakeholders before real-world testing

Intune_Support_Team — Fri, 01 May 2026 19:37:13 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 the previous article, we focused on understanding the reality of your frontline device estate - what devices you have, how they’re used, and which tasks they must support. Now that discovery is complete, the next step is to assess what you’ve found and align your people and processes before beginning real‑world testing with Microsoft Intune and representative users and devices. This is where you turn discovery into an actionable plan your team can execute in real operational conditions.

Many organizations refer to this stage as a Proof of Concept (POC) or pilot. In this article, we use these terms to describe limited real‑world validation of frontline workflows with representative users and devices, rather than internal IT feasibility testing. Use the pilot to confirm that users can reliably complete critical tasks in live operational environments before wider rollout.

Translate discovery into decisions

Discovery produces facts, but readiness requires decisions. Before beginning real‑world testing with representative users and devices, your team should be able to answer questions like:

Are we migrating “as‑is,” or do we plan on correcting identity and usage anti‑patterns such as shared credentials or personal use on corporate devices?
Which workflows are non‑negotiable and must work on day one, and which can be improved later?
Do we need to refresh hardware now, or can we migrate current devices and plan standardization at refresh time?
What are our top constraints (OS support, connectivity, etc.)?

A useful way to structure discovery output is to categorize findings and determine whether they support limited real‑world testing or require further alignment before proceeding.

Pre‑requisites for real‑world testing typically include clear ownership of devices and apps, supported OS versions, and a manageable device or OEM mix.

Items that often require alignment before real‑world testing include shared devices without a defined shared‑device model, shared credentials or unclear authentication approaches, personal use on corporate devices (which affects wipe/re‑enroll decisions), certified app or peripheral constraints, and network or certificate dependencies that could impact enrollment and compliance.

Identify the stakeholders you must align (and why)

Real‑world testing of frontline workflows depends on more than technical readiness. A clear stakeholder map helps surface operational dependencies early and ensures that limited validation activities can be conducted safely without disrupting day‑to‑day work.

Not every environment requires all of the roles listed below at this stage, but these are the most common stakeholders needed to support limited real‑world testing of frontline workflows.

Operational stakeholders

Stakeholder	Why they matter	What to align
Operations / business leadership	Define frontline outcomes and approve change windows.	Critical workflows, downtime tolerance, shift patterns, pilot locations, operational sign‑off criteria.
Funding owners / procurement	Discovery often uncovers refresh or licensing gaps.	Device and accessory funding, carrier plans, spares, and standardization strategy.
Change management	Testing may introduce new sign‑in flows or device behaviors.	Communications plan, support readiness, rollback and escalation processes, exception management.

In addition to operational alignment, technical readiness across supporting IT teams is required to ensure testing reflects production like conditions.

Technical and support stakeholders

Stakeholder	Why they matter	What to align
Endpoint or Microsoft Intune owners	Build policy, enrollment, apps, and compliance.	Device categories, management models, policy approach, rollout waves.
Architecture team	Ensure alignment with enterprise standards.	Reference architecture, lifecycle approach, dependency mapping.
Microsoft Identity / Microsoft Entra team	Underpins Conditional Access and shared‑device patterns.	Authentication model, shared device sign‑in patterns, break‑glass scenarios.
Network team	Enrollment depends on connectivity and certificate flows.	Wi‑Fi (EAP‑TLS), proxies, segmentation, roaming, known dead zones.
Security / risk / compliance	Define guardrails and exceptions.	Wipe policies, logging, least privilege, auditability.
App owners / vendors	Critical frontline workflows depend on app behavior.	Compatibility, offline behavior, deployment approach.
Support / service Desk	Manage user impact during testing.	Runbooks, escalation paths, enrollment troubleshooting, shift‑based support.
Project management (large environments)	Coordinate testing across teams.	Timeline, risk tracking, cross‑team communications.

Readiness checklist before real‑world testing

Real‑world testing often produces limited value when it focuses primarily on Microsoft Intune enrollment rather than operational use. Enrollment is a starting point, but the goal of this stage is to confirm that critical frontline workflows function reliably end‑to‑end in production‑like conditions.

Readiness area	Questions to consider before real‑world testing
Licensing	Do you have the correct Intune licenses for the devices or users in scope? Are any add-ons needed?
Identity	Is Microsoft Entra configured for your enrollment approach? Are Conditional Access policies ready for real‑world testing? For shared devices, what sign‑in model will you use?
Stakeholder alignment	Who owns the success criteria? Who approves the testing scope and change window? Who funds required accessories or device refresh?
Operational readiness	Who provides day‑to‑day support for test devices? What is the escalation path for a broken critical workflow? What is the rollback or recovery plan?
Device lifecycle decisions	Will you test by migrating existing devices as‑is, replacing end‑of‑life devices first, or using testing to define the future standard?
OEM and ecosystem readiness	Are the devices still supported by the OEM? Are required peripherals supported? Do rugged or certified requirements limit device options?

Lack of clear ownership for testing success criteria is a common cause of inconclusive pilots, particularly where operational workflows span multiple teams.

Decide what your real‑world testing must validate

Real‑world testing often produces limited value when it focuses primarily on enrollment rather than operational use. Enrollment is a starting point, but the goal of this stage is to confirm that critical frontline workflows function reliably end‑to‑end in production‑like conditions.

Real‑world testing should validate high‑value operational outcomes, ensuring:

Critical workflows function end‑to‑end
- Scanning, inventory, delivery confirmation, POS, etc.
- Session transitions match shift patterns
- Offline or degraded‑mode behavior works as expected (where relevant)
Security works without disrupting operations
- Compliance and Conditional Access do not block legitimate frontline activity
- Wipe and recovery processes are realistic for shared devices
- App protection controls align with user experience
Supportability is operationally viable
- Device reset and re‑enroll processes are documented
- Troubleshooting steps are known and repeatable
- Escalation paths exist for frontline‑impacting incidents
Representative device scenarios are included
Include the different frontline scenarios identified during discovery, such as:
- Shared vs assigned devices
- Different OEM models or OS versions
- Sites with known connectivity constraintso
- Common peripherals that may introduce migration risk (for example, scanners or printers)

Plan for future standardization (without delaying testing)

You may need to begin real‑world testing using the environment you have today. However, this stage can also be used to identify patterns that may shape future procurement and standardization decisions without delaying validation activities.

Practical prompts to add to your planning:

If you could reset procurement going forward, would you reduce OEM or device model sprawl?
What might your target “approved device set” look like for the next refresh cycle?
Which procurement models could support consistent enrollment, warranty coverage, and access to spares across shifts?

Standardization doesn’t need to be a prerequisite for real‑world testing, but it can become a valuable outcome of the migration effort over time.

Moving from assessment to real‑world testing

After you’ve aligned stakeholders, clarified dependencies, and defined what your real‑world testing must validate, you’re ready to move from assessment to limited operational testing with representative users and devices.

The key takeaway is this: discovery tells you what’s real, but readiness determines whether you can safely test it in live operational conditions.

As always, we welcome your feedback and experience. If you’ve already tested frontline workflows in operational conditions, what advice would you give organizations preparing for this stage? Share your thoughts in the comments below or reach out to us on X @IntuneSuppTeam.

Explore the From the frontlines: Frontline worker management with Microsoft Intune series for additional guidance on managing frontline workers and devices.

Speed where it matters: How Microsoft Intune helps IT prioritize time-sensitive actions

Intune_Support_Team — Thu, 30 Apr 2026 15:47:22 GMT

By: Albert Cabello Serrano | Principal Product Manager - Microsoft Intune

A closer look at how Intune delivers updates to devices and the investments we’re making to help important changes move faster and more predictably.

A common concern we hear from IT admins is, “How quickly will this change actually reach my device?” In many cases, the answer is much faster than expected. Today, 90% of policy updates, app deployments, and device actions in Intune are completed in under an hour.

So where does the idea of “8-hour latency” come from? That number reflects a routine maintenance check-in used when devices are idle - not how Intune processes meaningful changes. Intune uses notification-based, priority-driven processing so that high-impact actions, like security policy changes or remediation steps, are handled promptly and reliably as possible.

In this context, latency isn’t about making every action instant - it’s about providing predictable, prioritized delivery at global scale. The sections below break down how Intune prioritizes different types of updates and recent investments that are helping time-sensitive changes complete more consistently.

How Intune delivers changes to devices

Cloud-based device management is designed for real-world conditions; devices are not always online, fully charged, or on stable networks. Intune uses an eventual consistency model so devices can continue to be productive while converging to the desired state over time, without management actions unnecessarily disrupting users or workflows.

Because devices operate in different conditions, not all device activity is handled the same way. To manage change reliably at scale, Intune uses different types of device check-ins depending on what needs to happen.

Types of device check-ins in Intune

Device check-ins generally fall into several categories, each triggered by a different type of action:

Single‑device check‑ins: Occurs when an admin or user initiates an action on a specific device, such as starting a device action or installing an app from the Intune Company Portal.
Change‑based check‑ins: Push‑triggered check‑ins used to deliver meaningful changes to devices as soon as possible.
Client‑initiated check‑ins: Background activity that helps keep devices healthy, such as when a user signs in to a device or when malware status changes.
Maintenance check-ins: Scheduled syncs that occur at predetermined intervals and can be client or service-initiated, depending on the platform. These typically occur approximately every 8 hours.

Regardless of what triggers a check-in, any pending changes will be applied to the device when it occurs.

What happens when an admin makes a change

When an admin makes a change in Intune, such as updating a device compliance policy, deploying an app, or setting a configuration, Intune identifies the devices impacted by that change and initiates a change‑based check‑in for affected devices.

For online devices, Intune sends a push notification prompting the device to establish a management session with the service, apply the change, and report enforcement status back to Intune. If a device is offline or unreachable, the change is applied when the device next checks in through available mechanisms.

Four investments that help critical updates move forward faster

The following product changes focus on reducing device‑change latency by shortening the time between an admin action in Intune and enforcement on the device, especially during peak or constrained conditions.

1. Check-in prioritization focused on what matters most

Not all device activity carries the same urgency. Routine background check-ins can compete for service resources with devices that have important pending changes, such as compliance updates, remediation actions, or administrator-initiated configuration changes.

Intune evaluates the potential impact of delaying a device check-in on security posture, compliance state or user productivity, and dynamically prioritizes processing accordingly. This real-time prioritization model ensures that high-impact actions move forward without being delayed by lower‑impact background activity. Prioritization adapts as conditions change, helping important updates reach devices more quickly and predictably without being delayed by lower-impact background activity.

2. Built-in resilience when multiple changes occur in quick succession

Change activity often happens in bursts, with several related updates occurring in rapid succession. These periods of activity may be driven by operational needs or background processes, and can involve adjusting assignments, updating multiple policies, or rolling out configuration changes across the same set of devices.

Intune dynamically coordinates notifications, so that each change requiring action triggers a corresponding device notification, even during high-activity periods. This helps improve consistency when applying multiple updates and reduces delays across consecutive changes on devices.

Over the next several months, these improvements will extend to additional payloads delivered through the Intune Management Extension (IME), including scripts, Win32 apps, and custom compliance across both Windows and macOS platforms.

3. More timely notifications on Windows

Intune notifies devices to check-in when changes require action. If the device is offline, on an unstable network, or low on battery, notifications may be delayed. This can cause missed check-ins or delayed actions.

When notification services are delayed, blocked, or unavailable, devices may fall back to scheduled maintenance check‑ins to apply changes. For timely delivery, required notification service endpoints need to remain accessible so devices can receive management signals when updates occur.

On Windows devices, Intune complements the Windows Notification Service (WNS) with the same notification protocol that powers Microsoft Teams via the Intune Management Extension. This helps increase the likelihood that devices receive management notifications when they’re online and reachable, improving visibility into whether policy updates or device actions have reached their destination.

For more information, see the network endpoints for Intune documentation.

4. Optimized maintenance check-ins for iOS devices

Background check-ins are still important to keep devices healthy when nothing else is going on. Unlike Windows devices, iOS devices don’t have client scheduled check‑ins and depend on service‑initiated maintenance check‑ins to ensure device health and compliance.

During peak usage periods, these maintenance check‑ins can account for a significant portion of overall traffic, which can compete with devices that require immediate updates.

Intune considers device activity in the scheduling of maintenance check‑ins during peak activity, making room for higher‑impact updates, while continuing to ensure devices check in regularly. This helps manage traffic and improves responsiveness when applying policies or remediation actions.

What this means for you

For IT admins: No additional configuration or workflow changes are required to benefit from Intune’s built-in notification system. When bidirectional communication with notification service endpoints is open, devices can receive and act on updates as they become available.

For security teams: Faster delivery of device changes helps shorten the time between a policy update, a tightened Conditional Access rule, an updated compliance baseline, and a remediation action. For Zero Trust frameworks, where posture signals drive access decisions, this helps narrow the window during which a device could be out of compliance or vulnerable.

Together, these improvements reflect how Intune is evolving into a more intelligent, priority-aware system. Rather than making every action instant, the focus is on prioritizing high-impact updates so they are delivered without unnecessary delays. This approach is expanding across a number of scenarios to provide a more consistent and predictable experience, helping reduce delays for key updates.

Resources to learn more

For another perspective on this topic, read an MVP’s take on demystifying the “8-hour” timing myth in this LinkedIn post.

You can also watch the recent Tech Takeoff about this same topic to learn more about these improvements.

Also, in the April edition of the What's New in Intune blog, we introduced a new segment called Myth vs. Reality. This post is part of that series. To stay current on new capabilities and updates as they ship, follow the What's New in Microsoft Intune blog.

What myth should we debunk next? Leave a comment below or reach out to us on X @IntuneSuppTeam or @MSIntune.

Unpacking Endpoint Management is back - and we’ve got a lot to talk about

Intune_Support_Team — Tue, 21 Jul 2026 23:06:06 GMT

If you've been missing real, candid conversations about endpoint management, good news! Unpacking Endpoint Management is officially back.

This series is all about what actually works. No fluff, just practical tips, proven strategies, and honest discussions to help you optimize and simplify the way you manage and secure endpoints today (and prepare for what's next).

We're bringing together people from across Microsoft Intune, Security, and Customer Experience engineering and product teams, along with guest practitioners, to share what's worked, what hasn't, and what we've learned along the way. And yes…we're absolutely here for the tough questions.

A quick update on the hosts

Danny Guillory, a familiar face to the community and a Product Manager for Intune and Configuration Manager, will continue to host the series. He's joined this season by Rachelle Blanchard as co‑host, bringing a strong community and discovery lens to the series. Rachelle focuses on surfacing real customer questions and guiding conversations toward practical outcomes, helping ensure each episode reflects how endpoint management works in the real world.

Up next

What should we cover? Drop ideas below in the comments.

Catch up on demand

You may have missed them, but you don't have to miss out on the learnings. Watch and learn when it's convenient for you.

Policy: from hybrid to cloud-native
Device security with Microsoft Intune
Trends in endpoint management (live from Tech Takeoff 2026)

Not sure where to start? Watch our most recent episode, App management at scale with Intune, now on demand!

What's the format?

This web series is streamed live on Tech Community, LinkedIn, YouTube, and X. In addition to open discussion, we answer your questions so sign in (or sign up for) the Tech Community and RSVP to submit questions early and throughout the live show.

How do I join?

There's no call or meeting to join. Simply head to aka.ms/JoinUEM. Show up at start time, watch live, and jump into the discussion with us.

Help shape the series

This series is for you - so tell us what you want to hear. Drop a comment below with:

Topics you'd like us to cover
Tough questions you want answered
Speakers you'd love to hear from

We can't wait to get started - and even more excited to hear from you along the way.

Join the Community to get early insight into what's coming for Intune, connect with experts, and share real-world feedback that helps shape the product. 👉 aka.ms/JoinIntuneCommunity

As vulnerability discovery moves at AI speed, keeping current is foundational to reduce exposure

Intune_Support_Team — Wed, 22 Apr 2026 22:35:25 GMT

Recent advances in automation and AI are accelerating vulnerability discovery and shortening the window between disclosure and exploitation. As Microsoft outlined in our recent Security blog, this shift raises the bar for how quickly organizations need to reduce exposure across their environments.

For IT and security teams, this makes staying current on updates more critical than before. While responding to individual Common Vulnerabilities Exposures (CVE) remains essential, keeping current across devices and applications is foundational to reducing exposure as threats evolve.

This post focuses on the endpoint execution layer - how Microsoft Intune helps organizations understand their update posture, prioritize action, and reduce the time it takes for protections to land.

Introducing the security update status dashboard in Microsoft Intune

To act decisively, teams need clear visibility into where systems are current, where gaps exist, and how update deployments are progressing. Without a shared, defensible view of update status, it’s difficult to prioritize remediation or answer a basic question from leadership: “Are we patched?”

To address this, Intune is introducing the General Availability of a new security update status dashboard providing centralized visibility into update compliance across Windows Clients, Windows Servers, and Microsoft 365 Apps. The dashboard provides a clear, current view for leadership, backed by current data — without switching between multiple reports or tools.

Figure 1: Security update dashboard showing patch status for Windows clients, servers, and Microsoft 365 apps.

The dashboard surfaces:

Visibility into which devices are current on quality and feature updates, which are falling behind, and where remediation gaps exist across your Intune-managed estate
The data needed to prioritize action, track progress across deployment rings, and help demonstrate a more accurate compliance posture
Insight to where exposure is critical and needs immediate attention

Four ways to shrink your vulnerability window

The dashboard delivers visibility. The capabilities below help you act on it.

1) Windows Autopatch: deploy updates at scale with control

Windows Autopatch manages update orchestration through predefined deployment rings, releasing updates progressively across representative device groups so that quality and security updates reach broad production populations only after passing validation in pilot environments. IT teams shift from manually coordinating deployment schedules each month to focusing on policy and exception management while Windows Autopatch handles sequencing, scheduling, and rollout logic.

When critical vulnerabilities emerge, expedited update deployment allows devices to advance more quickly through the rollout process, providing security teams with an additional lever for reducing time-to-secure when AI-driven discovery shortens the window between disclosure and exploitation.

2) Hotpatch updates: Windows updates without the reboot

Even when updates deploy rapidly, protection is not realized until a device restarts, and users routinely defer reboots for hours or days. Hotpatch updates for Windows reduces this gap by applying supported security updates to in-memory processes without requiring frequent restarts. Eligible Windows 11 Enterprise devices can reach a protected state immediately after installation, helping reduce the vulnerability window.

Operationally, hotpatch updates shifts the restart requirement from monthly update to a smaller number of planned baseline updates per year, enabling organizations to deploy critical fixes without the productivity impact of forced restarts. You can enable hotpatch updates through quality update policies in Intune on supported systems.

In addition, with Autopatch update readiness, IT admins can better anticipate when planned quality or feature updates won’t reach a device, understand Autopatch and hotpatch enrollment coverage, and quickly identify blockers to bringing devices into a ready state.

3) Microsoft 365 Apps patching: keep Office and other apps current in lockstep

The Microsoft 365 Apps admin center includes Inventory and Cloud Update, giving administrators visibility into update status across connected devices by update channel so they can quickly spot systems missing the latest security updates and track progress. When an accelerated response is required, teams can tighten deadlines and move from staged rollout to immediate enforcement by removing waves, deferrals, or exclusion windows that may delay availability for specific groups, especially where channel divergence or scoped targeting leaves devices outside policy. Because expedited servicing reduces time for testing across diverse configurations, Cloud Update controls such as pausing a deployment or rolling back an update help mitigate risk while closing security gaps quickly.

4) Server updates: Configuration Manager or Azure Arc to accelerate compliance and operational workloads

For organizations managing servers, Configuration Manager helps streamline the identification, packaging, and assignment of security updates (for example, with Automatic Deployment Rules) based on classification and severity. Cloud-based sourcing through the Microsoft Update service can prevent deployment failures in distributed environments, while maintenance windows let you pre-stage updates for highly available systems and install them during defined downtime intervals - achieving compliance without unplanned service interruptions. For server estates that are Arc-enabled, you can also use Azure Arc to extend visibility and management across hybrid and multicloud infrastructure.

If you need even deeper coverage and insight, consider integrating Microsoft Defender Vulnerability Management (MDVM) to enrich update posture with vulnerability intelligence and prioritize remediation based on real exposure.

Using update currency as an enforcement signal

Deploying updates is half the job. Verifying they land - and holding the line when they don't - is the other half. Intune compliance policies let you define minimum OS build numbers, required update levels, and grace periods. Devices that fall out of compliance are flagged automatically.

Paired with Microsoft Entra ID Conditional Access, update currency can become a condition of access - checking that only current, healthy devices connect to corporate resources. This turns update posture into an enforceable control, not just a reporting metric.

Actions you can take today

The increasing use of AI in vulnerability discovery, combined with a rapidly evolving threat landscape, underscores the importance of taking proactive security measures. Here are actions you can take today:

Assess. Open the new security update status dashboard and know the baseline of your fleet. See how many Windows devices are behind on feature releases, quality updates, and Microsoft 365 Apps patches.
Automate. Configure Windows Autopatch for ring-based deployment, enable hotpatch updates on eligible devices, and set Microsoft 365 Apps servicing profiles. Enable expedited updates so you can respond to critical vulnerabilities quickly.
Enforce. Pair compliance policies with Conditional Access. Make being current a condition of access to corporate data.
Monitor. Review the dashboard weekly. Investigate deployment failures promptly and deploy proactive remediations to clear blockers.
Communicate. Share dashboard trends with security leadership and application owners. When stakeholders see the data, update compliance becomes a shared priority, not just an IT burden.
Evolve. Revisit your deployment rings, deferral windows, and compliance thresholds quarterly. Use failure patterns from the dashboard to refine your approach and evaluate Windows Autopatch for a fully managed experience that scales with your organization.

Every day a device remains out of date is potential exposure to unnecessary vulnerabilities. Intune gives you the tools, and now the visibility, to get current, stay current, and defend your organization at the speed the threat landscape demands.

Closing

Reducing exposure starts with knowing where you stand. The security update status dashboard in Intune provides a single place to understand update status across Windows devices and Microsoft 365 Apps, helping you identify lagging systems and prioritize action.

Make the dashboard part of your regular operational rhythm: review it, act on the gaps it surfaces, and track progress over time. With the right visibility and tooling, staying current becomes repeatable - not reactive.

Feature availability varies by license. Learn more about plan details and requirements here.

Read the latest Microsoft Security blog to learn how turning AI‑driven discovery into protection at scale can help secure your estate in an AI‑driven threat landscape.

Get started with Microsoft Secure Now for guidance in assessing risk and take recommended actions.

Migrating Frontline Mobile Devices: Understanding the reality of your estate

Intune_Support_Team — Wed, 15 Apr 2026 21:04:35 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.

Frontline devices have evolved from a small set of task-specific tools into the way day-to-day work gets done. As new workflows, apps, locations, and teams get added over time, device estates expand quickly, making it harder to maintain consistency and visibility.

For many organizations, the reality of the estate isn't easy to keep track of. Devices may have been purchased locally, inherited through acquisitions, shared across teams, or left unused in lockers. They may be repurposed for new workflows or kept running far longer than originally planned.

This creates a gap between what teams think they have, how they expect devices to be used, and what happens in the field.

“Frontline estates aren’t complex because teams don’t care, they’re complex because operations evolve faster than governance.” -Sucheta Gawade, Microsoft MVP

If teams don’t close this gap early, it tends to show up during pilots and cutover: devices fail in real conditions, frontline teams revert to workarounds, and the migration slows down through rework, exceptions, and avoidable disruption.

To understand the estate, teams need to start by determining what the business needs devices to do and not just who happens to use them.

Start with what devices need to do

While some devices are assigned to individual users, many are shared across shifts, used for specific tasks, or operate without a fixed user at all.

Designing a migration around users or roles can obscure what really matters: the job the device must perform, when it must be available, and the impact if it isn’t.

Anchoring on business needs helps teams:

Focus on outcomes rather than ownership models
Simplify stakeholder conversations
Make clearer tradeoffs, when required, around user experience, productivity and security

One simple way for teams to gather this information is by mapping business tasks to what devices must reliably do.

Business Task	What the device must do	When it must work	Impact if unavailable
Take payment for goods	Run secure POS applications	Store open hours	Lost revenue
Pick inventory	Scan bar codes quickly and accurately	During shifts	Orders delayed
Document patient observations	Capture and submit clinical data	During care delivery	Delayed or incomplete care

This framing applies equally across retail, healthcare, manufacturing, transport, logistics and utilities. It creates a shared language between IT, operations, and security - one that is grounded in business impact rather than tooling.

Once business needs and intended device usage are clear, the next step is understanding how those devices support frontline work day to day.

Understand how devices are used in practice

Frontline usage patterns often diverge from what business owners and IT expect. Devices may be shared across shifts or used by alternate users. They may also be repurposed to support new workflows or kept running beyond their intended lifecycle, all without IT or executive oversight.

These gaps are best identified by partnering with operational and business owners to validate real-world usage through quick workflow walk-throughs, targeted questions, and a review of how devices are accessed and supported day-to-day. Some helpful questions:

How are devices shared?
When are they offline or unavailable?
What workarounds exist to keep critical tasks moving?

It’s also critical to confirm whether corporate-assigned devices have been used for personal activity. Personally used devices may also be treated as work devices, whether authorized or otherwise. This affects wipe and re-enroll decisions because personal use can introduce data retention, user impact, and acceptance risks.

Intended usage	Actual observed use	Notes/Workarounds
Assigned device	Shared across the shift	Shared credentials used
Always connected	Intermittent Wi-Fi	Offline workarounds
Single-app device	Multi-app usage	Local exceptions for multiple apps

This is also where identity assumptions surface, particularly in environments where devices are shared but access shouldn’t be.

“Identity reality matters: shared devices should not mean shared credentials. Migration is often the right moment to address this. Otherwise, teams simply re‑platform the same risks.” -Sucheta Gawade, Microsoft MVP

Teams often uncover important dependencies at this stage. For example, some frontline workflows rely on constant connectivity, while others must function reliably in low‑bandwidth or offline conditions. Similarly, older operating systems or unsupported device models may still be in active use because replacing them has operational or budgetary implications.

Understanding these realities early helps teams avoid designing for ideal conditions that don’t exist in the field.

Ground plans in device inventory

Inventory is most valuable when it supports planning decisions, not when it aims for completeness. For frontline migrations, teams need decision relevant information rather than a perfect asset register.

Understanding how devices are procured and funded across the organization is important. For example, whether devices are purchased centrally through IT or sourced locally by business/departments. Procurement paths often explain why inventory is fragmented and help determine who owns refresh cycles, warranties, and enrollment readiness.

At a minimum, this includes:

Device types and OEMs
OS version ranges and supportability
Whether devices are active, dormant, or missing
How devices align to business-critical tasks
Where specialist or certified devices are required such as intrinsically safe or ruggedized devices

This helps surface ecosystem considerations early:

Are required apps and services supported on the OS versions in use today?
Do OEMs still support the hardware?
Do environment constraints affect enrollment, updates, or day‑to‑day operation?

These questions are not about selecting solutions yet. They’re about understanding constraints that will shape options later.

With business needs understood, usage patterns mapped, and inventory validated, teams are ready to start designing approaches that work in frontline conditions.

Migration is also a good opportunity to plan for standardization and set a future procurement standard. Even if you migrate the current estate as-is, defining an approved OEM or model catalog for future purchases improves consistency. It can also accelerate troubleshooting and strengthen lifecycle governance as devices reach end of support.

What we’ve learned

The key lesson is simple: validate reality before designing anything.

Teams that invest time here:

Reduce rework during pilots
Avoid late‑stage surprises
Have stronger conversations with operational, security, and platform stakeholders

“We don’t declare success at enrollment. We declare success when a frontline workflow can run end-to-end with predictable support.” -Sucheta Gawade, Microsoft MVP

In future articles, we’ll look at how these insights shape design decisions. In the meantime, we’re interested in hearing what gaps you’ve uncovered between intended and actual device usage in your frontline environments. Leave a comment below or reach out on X @IntuneSupportTeam.