Streamlining macOS security: Automatically enable AutoFill after Platform SSO registration
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: Microsoft supports Intune’s ability to deploy scripts, but not the scripts themselves. Microsoft fully supports Intune and its script deployment capabilities. However, Microsoft does not provide support for individual scripts, including scripts published in Microsoft GitHub repositories. These scripts are provided as examples only. You are responsible for reviewing, validating, and testing their behavior in your environment before deploying them broadly. 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 Platform SSO for macOS Company Portal for macOS Payloadless Packages in Intune (Tech Community) Microsoft shell-intune-samples Repository 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.
Deploying Platform SSO for pre macOS 26 with Microsoft Intune: Lessons Learned
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.Migrating frontline mobile devices: Identity considerations for assigned and shared devices
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: For individually assigned devices, phishing-resistant, passwordless authentication methods are the recommended approach, such as Passkeys. 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. 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. 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.MDOP is out of support: What to do next with Microsoft Intune
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
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. 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. 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. 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 SSO in ADE profile (new article): Add Platform SSO policy to ADE Profile on macOS devices SSO scenarios: Platform SSO scenarios for macOS devices Platform SSO configuration guide for macOS devices using Microsoft Intune Common Platform SSO scenarios for macOS devices Install Company Portal for macOS as a macOS LOB app Set up automated device enrollment (ADE) Troubleshoot the Microsoft Enterprise SSO Extension plugin on Apple devices macOS Platform single sign-on known issues and troubleshooting 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.
