We're redesigning our new-hire onboarding flow so users register both Windows Hello for Business and a passkey through Microsoft Authenticator as early and smoothly as possible.
Our current setup uses two Conditional Access policies. One requires registration with a custom authentication strength that includes Temporary Access Pass (TAP), Windows Hello for Business, FIDO2, and certificate-based authentication. The other requires phishing-resistant MFA, with exclusions for several services because they caused conflicts during Autopilot.
Devices are provisioned using pre-provisioning. After a TAP is generated, the user sees the "Let's keep your account secure" prompt, followed by the Windows Hello setup indicating that a passkey must be saved on the device. After selecting Next, the process fails and the setup breaks.
If I manually open Microsoft Authenticator and register the passkey first, then run the process again, everything works much better. Windows Hello is configured later during the account setup portion of the Enrollment Status Page.
The workflow technically works, but it requires very detailed instructions for new hires, and I'm not comfortable relying on broad resource exclusions. Another option would be to use automation or group membership to enforce phishing-resistant MFA only after device onboarding is complete, but that adds complexity and introduces the risk of users remaining excluded if the automation fails.
Has anyone found a cleaner and more reliable way to handle passkey and Windows Hello registration for new hires during Autopilot?
3 Answers
We use an automation workflow that temporarily excludes newly onboarded users from the authentication-strength policy. After a short delay, it checks whether the user has registered a passkey and removes the exclusion once registration is confirmed. It works, but it does add operational overhead and needs monitoring so a failed job doesn’t leave someone excluded indefinitely.
We reduced that risk by checking on several scheduled days after the hire date. Users who still haven’t registered a key receive reminders, and the exclusion is removed on the final deadline regardless of registration status. Anyone who registers earlier is removed immediately.
We had better results using TAP only as the bootstrap method and enforcing phishing-resistant MFA after enrollment has completed. Trying to force every registration step during Autopilot made the setup very fragile. Once the device and account are fully enrolled, the user can complete the remaining passkey and Windows Hello steps without breaking the provisioning flow.
A dynamic group based on the hire-date attribute can provide a simpler approach. For example, newly hired users can be included for only a limited period and excluded from the stricter policy during that window. After the window expires, they automatically fall out of the group and the phishing-resistant MFA requirement applies. I’d still add reporting or alerts so you can identify users who reach the deadline without registering a passkey.
That’s the concern I have too. It feels like we’re building a workaround for a provisioning flow that should work natively, and a failed automation job could become a security issue.