NEW Autopilot OOBE Sign-In Fails for Federated Secondary Domain — “isn’t in our system”

[kaplish]

Hello everyone,


We’ve run into an issue during Windows Autopilot user-driven provisioning with a secondary domain that’s federated to JumpCloud.

• Primary domain: stmarksschool.org (verified, managed — works fine)
• Secondary domain: stmarkstech.org (verified, federated to JumpCloud)
• UPN tested: [email protected]
• The secondary domain has the correct CNAME DNS records for enterpriseenrollment and enterpriseregistration.
• Federation with JumpCloud is configured and working correctly — signing into https://portal.office.com with the UPN redirects to JumpCloud and allows successful access to M365 apps.
• The test user has proper Intune (A5) licensing and exists in Entra ID.

When I attempt to enroll a Windows 11 device via Autopilot (OOBE) using this federated secondary domain, I get the following error immediately after entering the UPN:

“stmarkstech.org isn't in our system. Make sure you typed it correctly.”

However:

• If I use a UPN from the primary domain (stmarksschool.org) or the default onmicrosoft.com domain, Autopilot enrollment works perfectly.
• The same [email protected] account signs into Office.com with no issues, proving federation is set up correctly.

I’ve verified:

• The domain is fully verified and federated in Entra.
• Intune configuration and Autopilot profile assignment are correct.
• DNS records are in place.
• The issue happens on multiple freshly imaged Windows 11 devices, both pre-provisioned and user-driven.

Has anyone encountered this behavior before with federated secondary domains during Autopilot enrollment?
Is there anything additional that must be configured on Microsoft’s side to make a federated secondary domain usable during the OOBE sign-in step?

Any guidance or insight would be greatly appreciated.