Fix Autopilot Self-Deploying Mode When ESP Account Setup Does Not Appear for FIDO2 (YubiKey) Sign-In

If your Windows Autopilot self-deploying mode build finishes the device phase, the user signs in with a FIDO2 security key such as a YubiKey, and the Enrollment Status Page (ESP) account setup phase never appears, stop blaming Win32 app assignments first.

Microsoft documents this as a known issue: when self-deploying mode is used together with Shared PC mode, the ESP account setup phase isn’t shown for users who sign in with FIDO2 (YubiKey). The same device can still show the account setup phase when the user signs in with username and password instead.

That changes the troubleshooting path. This is not automatically an Intune outage, not automatically a broken app deployment, and not automatically proof that your kiosk profile is wrong. It is a Microsoft-documented behavior specific to the combination of:

• Windows Autopilot self-deploying mode
• Shared PC mode
• FIDO2 security key sign-in
• the ESP account setup phase

If you are rolling out kiosks, shared desks, frontline carts, labs, or hot-seat devices, this distinction matters because you can lose the user-phase ESP experience even though the device-side provisioning path looked fine.

Quick fix checklist

Use this order before you reset the device again:

1. Confirm the device is using self-deploying mode, not user-driven Autopilot.
2. Confirm Shared PC mode is configured on the device.
3. Confirm the failing sign-in method is FIDO2 / YubiKey.
4. Test the same device with a username/password sign-in and see whether the ESP account setup phase appears.
5. Verify the tenant really has Use security keys for sign-in enabled, or the targeted OMA-URI policy is deployed.
6. Review the Enrollment Status Page profile and confirm it is expected to show the user/account phase.
7. Collect Autopilot and device enrollment logs before changing assignments.
8. If the device must complete user ESP reliably today, use a non-FIDO first sign-in path for provisioning and move the user back to FIDO2 after enrollment finishes.

If a password sign-in shows the account setup phase and the FIDO2 sign-in does not, you are likely in the exact Microsoft-known issue and should stop wasting time on random app repackaging.

What Microsoft says is broken

Microsoft’s Windows Autopilot known issues page states:

Enrollment status page Account setup phase isn't shown when signing in via FIDO2 (YubiKey) during self-deploying mode.

Microsoft further scopes it to this condition:

When Windows Autopilot is used in self-deploying mode with Shared PC mode configured, the Enrollment status page (ESP) Account setup phase isn't shown for users signing in with FIDO2 (YubiKey). Account setup is shown when users sign in via username/password sign-ins.

That wording is important because it gives you the fastest A/B test available:

• FIDO2 sign-in → account setup phase missing
• username/password sign-in → account setup phase appears

If that pattern is true on the same device, your problem is probably not “ESP is globally broken.” It is the documented FIDO2 plus Shared PC plus self-deploying combination.

Why this hurts shared-device admins

Self-deploying mode is attractive exactly where FIDO2 adoption is also attractive:

• shared reception devices
• nurse station or shift-worker PCs
• classroom carts
• manufacturing or warehouse terminals
• kiosk and task-worker builds

Microsoft’s self-deploying mode documentation says this deployment path is designed for kiosk, digital signage, and shared devices. It also says self-deploying mode uses ESP to prevent device access until provisioning is complete.

At the same time, Microsoft Entra’s FIDO2 documentation encourages passwordless sign-in with security keys on Windows. Those two choices make sense independently. The problem is the handoff between them in this specific Shared PC scenario.

When the account setup phase does not appear, admins often assume one of these is true:

• required user apps never targeted correctly
• ESP assignment is wrong
• the first user is bypassing ESP
• Shared PC policy broke device enrollment
• YubiKey itself is failing authentication

Sometimes those issues are real. But if the exact Microsoft-known issue applies, the missing account setup phase is expected behavior while the issue remains under investigation.

Root cause in plain English

Microsoft hasn’t published a deep engineering post for this one, but the official documentation gives enough to frame the root cause accurately:

• self-deploying mode provisions the device without the normal user-driven setup path
• Shared PC mode changes how the device handles multi-user/shared usage
• FIDO2 sign-in uses a different credential path than username/password sign-in
• in this combination, the ESP account setup phase is not shown

In other words, the practical root cause is not “your YubiKey failed.” The root cause is that the user-phase ESP visualization and processing path is inconsistent when first sign-in happens with FIDO2 in this Shared PC self-deploying scenario.

That is why a password test is so useful. It isolates the issue to the sign-in path rather than the app payload.

Logs and where to check

1. Review the Enrollment Status Page profile

In Intune admin center:

Devices > Enrollment > Windows > Enrollment Status Page

Check these settings in the active ESP profile:

• Show app and profile configuration progress
• Only show page to devices provisioned by out-of-box experience (OOBE)
• Block device use until all apps and profiles are installed
• any selected blocking apps

Microsoft’s ESP documentation says the user phase can be suppressed for later users depending on profile settings, so confirm you are testing the first expected sign-in path, not a later user scenario.

2. Confirm the device is really Shared PC

If you target Shared PC through Intune Settings Catalog or SharedPC CSP, verify the policy landed.

Useful local checks:

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

If you want a quick policy-state capture:

Get-CimInstance -Namespace root\cimv2\mdm\dmmap -ClassName MDM_SharedPC |
  Format-List *

Focus on values such as:

• EnableSharedPCMode
• EnableAccountManager
• AccountModel
• SetEduPolicies
• RestrictLocalStorage

3. Confirm FIDO2 sign-in was intentionally enabled

Microsoft’s FIDO2 Windows sign-in documentation gives two common Intune paths.

Tenant-level setting:

• Devices > Enroll Devices > Windows enrollment > Windows Hello for Business
• Use security keys for sign-in = Enabled

Targeted custom OMA-URI path:

./Device/Vendor/MSFT/PassportForWork/SecurityKey/UseSecurityKeyForSignin

with integer value:

1

If security-key sign-in was never enabled correctly, you can misclassify a different sign-in problem as this known ESP issue.

4. Collect Autopilot diagnostics before reset

From the affected device, capture the usual evidence pack:

mkdir C:\Temp -Force
Mdmdiagnosticstool.exe -area Autopilot;DeviceEnrollment;TPM -cab C:\Temp\autopilot-fido2-esp.cab

Also export MDM diagnostic details:

mdmdiagnosticstool.exe -out C:\Temp\MDMDiag

5. Check Autopilot event logs

Get-WinEvent -LogName 'Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot' -MaxEvents 200 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Format-List

This helps you distinguish a missing user-phase ESP from an earlier device-phase Autopilot failure.

6. Check device registration and enrollment state

dsregcmd /status

If the device is already properly Microsoft Entra joined and the missing behavior is only the account setup phase after FIDO2 sign-in, that supports the theory that device provisioning completed and the break is happening in the user-side setup experience.

Practical remediation workflow

Step 1: Reproduce with two sign-in methods on one pilot device

This is the most important step.

Test the same device with:

1. FIDO2 / YubiKey sign-in
2. username/password sign-in

If the password path shows the ESP account setup phase and the FIDO2 path does not, treat the issue as confirmed unless your tenant has another obvious ESP misconfiguration.

Step 2: Decide whether you need account-phase ESP during first sign-in

Some environments only care that the device phase completes. Others require user apps, certificates, or user-scoped policy to finish before the person gets the desktop.

If your build requires the account setup phase to run visibly and predictably, do not keep insisting on FIDO2 as the first sign-in method during initial provisioning until Microsoft closes the issue.

Step 3: Use a temporary first-sign-in workaround

The cleanest workaround today is usually:

• provision with self-deploying mode
• keep Shared PC mode if you need it
• complete the first sign-in with username/password if you need the account ESP phase
• move the user back to FIDO2 once enrollment and app delivery are complete

That is not as elegant as fully passwordless first touch, but it is predictable.

Step 4: Reduce dependence on user-phase ESP where possible

If your shared-device design allows it, move as much as possible to the device phase:

• device-target required apps
• device certificates instead of user certificates where appropriate
• device-targeted compliance or configuration where practical
• kiosk or shared-mode configuration that does not depend on first-user timing

The less your rollout depends on the account phase, the less painful this known issue becomes.

Step 5: Validate FIDO2 after provisioning, not instead of provisioning

Once the device is fully enrolled, validate that FIDO2 sign-in still works as your steady-state auth method. The issue Microsoft documents is about the ESP account setup phase not being shown in this scenario, not a blanket claim that YubiKey sign-in stops working everywhere on the device forever.

PowerShell and Graph commands that help

Check Shared PC MDM state

Get-CimInstance -Namespace root\cimv2\mdm\dmmap -ClassName MDM_SharedPC |
  Format-List *

Capture device registration state

dsregcmd /status

Review Autopilot event history

Get-WinEvent -LogName 'Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot' -MaxEvents 200 |
  Select-Object TimeCreated, Id, Message

Check the Autopilot record in Graph

Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "DeviceManagementServiceConfig.Read.All,DeviceManagementManagedDevices.Read.All"
Select-MgProfile -Name beta

$serial = "YOUR-SERIAL"
Get-MgDeviceManagementWindowsAutopilotDeviceIdentity -Filter "serialNumber eq '$serial'" |
  Format-List Id,SerialNumber,GroupTag,EnrollmentState,DeploymentProfileAssignmentStatus

Check the managed device after enrollment

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"
Get-MgDeviceManagementManagedDevice -Filter "serialNumber eq 'YOUR-SERIAL'" |
  Select-Object DeviceName,SerialNumber,AzureADRegistered,ManagementState,EnrollmentType,OwnerType

These commands will not fix the issue, but they help prove whether the device itself enrolled properly while the account setup experience was the missing piece.

What not to waste time on

For this exact symptom, these are usually low-value first moves:

• repackaging every Win32 app
• rotating blocking-app lists without first A/B testing sign-in method
• deleting the Autopilot hash immediately
• removing Shared PC mode before you prove the FIDO2 dependency
• blaming the YubiKey hardware before you test username/password on the same device
• assuming the entire ESP system is broken tenant-wide

The point is not that those areas can never be wrong. The point is that Microsoft already documented a narrower issue, and you should try to disprove that first.

Prevention

To reduce repeat incidents:

1. Keep one documented pilot flow for Shared PC + self-deploying + FIDO2 devices.
2. Decide up front whether your rollout truly needs the account setup phase.
3. Prefer device-targeted provisioning for shared devices whenever possible.
4. Test new passwordless changes on one hardware model and one ESP profile before broad rollout.
5. Document a fallback first-sign-in method for help desk and bench technicians.
6. Keep Autopilot diagnostics collection enabled in the ESP profile so field techs can capture evidence before a reset.

Conclusion

If ESP account setup does not appear after a FIDO2 or YubiKey sign-in on a Shared PC deployed with Windows Autopilot self-deploying mode, you may be hitting a Microsoft-documented known issue rather than a random Intune failure. The fastest proof is simple: test the same device with username/password sign-in. If account setup appears there but not with FIDO2, you have your answer.

The practical workaround is to use a non-FIDO first sign-in path when you must complete account-phase ESP, then return the device to your preferred passwordless sign-in model after provisioning finishes. Until Microsoft resolves the issue, that is usually the least painful path for kiosk and shared-device rollouts.