You only notice your onboarding process when it breaks. A new hire unboxes a laptop, signs in, and suddenly gets stuck in a loop of “you need to set this up” prompts that never complete. Nobody’s hacked. Nothing’s “down”. You just can’t finish setup.

A Microsoft change rolling out from July 6, 2026 makes that scenario more likely if your Conditional Access policies were written with the old behaviour in mind.

What changed in July 2026 (and why it matters)

Conditional Access has a user action called Register security information. Many businesses use it to control where and how people can register MFA methods (for example, only from trusted locations, or only with certain requirements).

Until now, there was a gap: those Conditional Access policies were evaluated in places like the My Security Info experience, but not consistently during Windows Hello for Business provisioning (and macOS Platform SSO registration). Microsoft is closing that gap.

From July 6, 2026, Conditional Access policies scoped to Register security information can be evaluated during Windows Hello for Business registration. That’s good for security consistency, but it also means your onboarding and new-device setup flows can start tripping policies they never hit before.

The real-world impact on onboarding and new device setup

Think about what has to happen on a brand-new machine:

  • The user signs in for the first time.
  • The device gets joined or registered.
  • Intune enrollment and compliance checks kick in.
  • The user is prompted to set up Windows Hello for Business (PIN, biometrics).
  • The user may also be prompted to register or confirm security info.

If your Conditional Access rules are strict (and they should be), it’s easy to accidentally create a dead end.

Here are a few common “how did we lock ourselves out?” patterns:

  • Trusted location requirements collide with remote onboarding. If you only allow security info registration from the office, a remote new hire cannot complete Windows Hello for Business registration at home.
  • Phishing-resistant requirements before you have a phishing-resistant method. If you require a FIDO2/passkey-based strength for the registration step, but the user has not been issued a key yet, they may be blocked from getting started.
  • Device requirements too early. Some device-related grant controls and device targeting decisions can’t be satisfied until the device is actually enrolled and reporting in. Microsoft notes, for example, that “require compliant device” doesn’t block Intune enrollment, but your overall policy design can still create a sign-in that is awkward or impossible during first-time setup.

The key point is simple: onboarding is a special moment. You’re asking a user to prove who they are, set up strong sign-in, and get a device managed, all in one sitting.

Your lockout-prevention checklist (practical and worth doing)

Below is the checklist we use when we want Conditional Access to be strict, without breaking first-day setup.

  • Confirm which policies target “Register security information”. Start by listing every Conditional Access policy that includes the Register security information user action. These are the ones most likely to behave differently after July 6, 2026.

  • Run those policies in Report-only first. If you’re changing scope or conditions, use Report-only so you can see what would have been blocked without actually blocking it. Then review sign-in logs for the registration events that happen during onboarding.

  • Decide your onboarding locations, explicitly. If you use location conditions, write down what “allowed onboarding” means for your business:

  • Office-only onboarding. Great for in-person setups, but plan a process for remote staff.

  • Remote onboarding allowed. Then you probably want stronger proof (like a Temporary Access Pass and a phishing-resistant method soon after).

  • A short-term exception. For example, allow registration from anywhere for a small “new hire” group for 7 days, then move them into your normal policy.

  • Create (and exclude) two emergency access accounts. Microsoft’s guidance is clear: have emergency access (“break glass”) accounts for lockout recovery, and exclude them from Conditional Access policies that could prevent sign-in during an incident. These accounts should be monitored closely and used only when needed.

  • Make FIDO2/passkeys part of the plan, not a future wish. If your end goal is phishing-resistant MFA, get ready operationally:

  • Inventory who needs keys. Start with admins and anyone with elevated access.

  • Choose the authenticator types you’ll support. FIDO2 security keys are a common option, and Microsoft documents how they work in Entra ID.

  • Plan the “first credential” problem. A user often needs something to sign in the first time before they can register stronger methods.

  • Use Temporary Access Pass (TAP) for first-time setup where appropriate. TAP is a practical way to get a new user through initial sign-in and registration in a controlled way, especially when you want to avoid weaker methods like SMS during onboarding.

  • Be deliberate about device enrollment and device targeting. If you’re scoping policies based on device attributes (for example, using device filters), confirm how you’ll treat:

  • Autopilot-enrolled devices versus manually enrolled devices.

  • Corporate-owned versus BYOD.

  • Different enrollment profiles. Device attributes like enrollment profile names can be useful for targeting, but only if your enrollment process is consistent.

  • Test the exact flows your people actually use. Don’t just test “sign in to Outlook”. Test:

  • Brand-new user, brand-new laptop, off-network.

  • Brand-new user, in the office.

  • Existing user replacing a device.

  • User who lost their phone and needs to re-register.

If you do nothing else, do the last bullet. Most Conditional Access pain comes from testing a happy path that nobody uses on day one.

A simple way to think about policy design for onboarding

For onboarding, you want two things at the same time:

  • High confidence that the right person is registering the right credentials on the right device.
  • A path that can actually complete without a helpdesk rescue.

That usually means you design a short, controlled “onboarding lane” (who can register, from where, using which initial method), then you tighten down to your normal steady-state policies once the user has:

  • a managed device,
  • a strong sign-in method registered,
  • and a working recovery path.

If you would like help reviewing your Conditional Access policies and onboarding flows ahead of (or after) the July 2026 change, the Flexnet Networks team can help you tighten security without creating lockouts.

Sources