Architecting Secure Intune Loaner Devices: Shared PC Mode, Web Sign-In, and Passwordless Authentication

Architectural Premise & The Real-World Challenge

Deploying stateless loaner laptops in an enterprise environment sounds straightforward on paper: enable Shared PC mode, ship the device, and let Windows handle the cleanup. However, standard documentation glosses over the severe operational friction that occurs when these technologies are scaled to thousands of endpoints. In high-throughput scenarios—such as hospital shift changes, field service depots, or corporate loaner kiosks—standard implementations break down due to local profile bloat, locked file handles, and authentication deadlocks.

A truly secure, zero-touch loaner device must achieve three goals: guarantee absolute user data isolation, enforce phishing-resistant authentication without complex Windows Hello for Business (WHfB) enrollment cycles, and automate the device lifecycle so that IT never has to manually touch the hardware between deployments. Achieving this requires a tight orchestration of Windows Autopilot Self-Deploying mode, the SharedPC Configuration Service Provider (CSP), Web Sign-in, and Microsoft Graph-driven remote resets.

Under the Hood: Execution Engine & Mechanics

To build a resilient architecture, we must understand how Intune policies translate to local operating system behaviors. When you deploy a "Shared Multi-User Device" profile from the Intune admin center, the configuration is delivered via the OMA-DM SyncML channel directly to the Windows Device Management Enterprise Diagnostics Provider. This bypasses the Intune Management Extension (IME) agent entirely, operating natively within the OS configuration engine.

The SharedPC CSP and Registry Realignment

When Windows receives the SharedPC CSP instruction, the local configuration engine writes directly to the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedPC registry hive. This configuration controls the shpcsvc (Shared PC Account Manager) service. Unlike the standard User Profile Service (profsvc), shpcsvc is specifically engineered to aggressively prune profiles based on policy-defined thresholds.

To verify the applied settings on a physical endpoint during forensic validation or troubleshooting, query the WMI namespace directly from an elevated terminal:

Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" -ClassName "MDM_SharedPC"

This query exposes the active configuration state of the Shared PC policy engine, revealing whether local account creation, guest access, and deletion policies have successfully bound to the client operating system.

Web Sign-In and Passwordless Flow Mechanics

In a standard multi-user deployment, users are prompted for a traditional username and password. On a loaner device, enforcing phishing-resistant authentication means we must enable Web Sign-In. This allows the Windows Logon UI (logonui.exe) to instantiate an isolated, secure browser frame directly on the lock screen, processing SAML and OAuth authentication flows directly against Entra ID.

This flow is governed by the Policy CSP node: ./Device/Vendor/MSFT/Policy/Config/Authentication/EnableWebSignIn. When enabled, it sets the registry value:

Hive: HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Authentication
Value Name: EnableWebSignIn
Type: REG_DWORD
Value: 1

This mechanism allows the device to process FIDO2 security keys, Microsoft Authenticator passwordless notifications, and temporary access passes (TAP) directly at the workstation lock screen without ever exposing a traditional password entry field to potential local keyloggers or shoulder surfers.

Enterprise Edge Cases & Scale Gotchas

Deploying this solution to a fleet of thousands of devices reveals several critical failure modes that are absent from lab environments.

1. The Profile Deletion Failure Loop

By default, shpcsvc attempts to delete user profiles on sign-out or when free disk space falls below the defined threshold. However, third-party agents—such as endpoint detection and response (EDR) sensors, data loss prevention (DLP) drivers, or even the Microsoft Teams background update service—frequently lock handles in the user's registry hive (NTUSER.DAT) or app data folders during logoff.

When shpcsvc encounters a locked file, profile deletion fails silently. Over time, these orphaned profiles accumulate, consuming disk space until the system runs out of storage, causing subsequent user logons to fail with "The User Profile Service failed the sign-in" error. To mitigate this, you must configure the deletion policy to trigger aggressively and leverage proactive remediations to forcefully terminate hung processes holding handles on user hives during sign-out.

2. Web Sign-In and Conditional Access Deadlocks

If your organization enforces strict Conditional Access (CA) policies requiring compliant devices or hybrid Entra joined states, Web Sign-In can deadlock. During the initial sign-in on a newly provisioned loaner device, the device may not have completed its compliance evaluation loop in Intune. Because Web Sign-In executes authentication in the cloud context, Entra ID evaluates the CA policy, flags the device as non-compliant, and blocks the user from signing in. This prevents the user from logging in to trigger the very compliance sync required to mark the device as compliant.

Key Configuration Parameters and Registry Paths

The following table maps the exact CSP configurations, their corresponding registry paths, and the behavioral outcomes required to establish a secure, self-cleaning loaner device.

Production Implementation & Automation

To achieve a true zero-touch lifecycle, loaner devices should be programmatically reset when they are returned to the IT depot. Relying on users to sign out or technicians to manually trigger a local reset introduces human error. The following production-grade PowerShell script utilizes the Microsoft Graph API (v2) to identify a target loaner device by its serial number, assert safety checks, and execute a remote Autopilot Reset. This forces the device back to the initial logon screen while preserving its enrollment state, completely purging all cached user data.

# Required Scopes: DeviceManagementManagedDevices.PrivilegedAdmin.All
# Target Execution: Administrative Staging Host

[CmdletBinding(SupportsShouldProcess = $true)]
param (
    [Parameter(Mandatory = $true)]
    [string]$DeviceSerialNumber
)

try {
    Write-Verbose "Importing Microsoft.Graph.DeviceManagement module..."
    Import-Module Microsoft.Graph.DeviceManagement -MinimumVersion 2.0.0 -ErrorAction Stop

    # Query the managed device from Intune based on serial number
    Write-Verbose "Querying Intune for device with Serial Number: $DeviceSerialNumber"
    $device = Get-MgDeviceManagementManagedDevice -Filter "serialNumber eq '$DeviceSerialNumber'" -ErrorAction Stop

    if (-not $device) {
        Write-Error "Device with serial number $DeviceSerialNumber not found in Intune."
        exit 1
    }

    Write-Host "Found Device: $($device.DeviceName) (ID: $($device.Id))" -ForegroundColor Cyan
    Write-Host "OS Version: $($device.OsVersion) | Compliance State: $($device.ComplianceState)" -ForegroundColor Gray

    # Safety Check: Verify the device is targeted as a loaner before triggering reset
    if ($device.Model -match "Virtual" -and -not $PSCmdlet.ShouldProcess($device.DeviceName, "Trigger Autopilot Reset on Virtual Machine")) {
        Write-Warning "Execution bypassed by user safety check."
        exit 0
    }

    if ($PSCmdlet.ShouldProcess($device.DeviceName, "Trigger Remote Autopilot Reset")) {
        Write-Host "Initiating remote Autopilot Reset command..." -ForegroundColor Yellow
        
        # Direct Graph API invocation to ensure v2 endpoint behavior
        $uri = "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices('$($device.Id)')/cleanWindowsDevice"
        $body = @{
            keepUserData = $false
        } | ConvertTo-Json

        Invoke-MgGraphRequest -Method POST -Uri $uri -Body $body -ContentType "application/json" -ErrorAction Stop
        
        Write-Host "Autopilot Reset command successfully queued for $($device.DeviceName)." -ForegroundColor Green
    }
}
catch {
    Write-Error "An error occurred during lifecycle execution: $_"
    exit 1
}

Step-by-Step Deployment Verification

Architectural Takeaways & Decision Matrix

When selecting the mechanism for multi-user workstations, architects must choose between Shared PC Mode, Kiosk Mode, or standard user deployments. The decision matrix below outlines when to use each configuration based on security boundaries and session requirements.

For enterprise loaner fleets, Shared PC Mode combined with Web Sign-In represents the optimal balance of security and usability. It provides users with a complete, familiar Windows desktop environment while enforcing strict cryptographic isolation between sessions. By automating the backend lifecycle via Microsoft Graph, you can eliminate manual depot work and ensure that every user receives a fresh, secure, and fully compliant endpoint.