Most of a Conditional Access deployment is about people who already exist. The harder problem, and the one baselines almost never address, is the person who does not exist yet. A new hire on their first morning has no registered MFA method, no enrolled device, and no history. Every control you built assumes an identity that is already established, and the moment that identity is being established is the softest moment in the entire tenant. It is where an attacker holding a stolen password wants to be, and it is where your framework either has an answer or has a hole. This article is that answer.
Two events on day one are more consequential than they look. The first is a user registering their first authentication method, because whoever registers it controls the account from then on. The second is a device enrolling into Intune, because a compliant device is a credential in this framework, the thing that satisfies device-trust policies for the rest of its life. Both of those events have to happen, and both of them are privileged acts that the framework deliberately gates. The trick is gating them without making it impossible to onboard anyone, and the mechanism that squares that circle is the Temporary Access Pass.
Why registration is the real target
Consider what happens without registration protection. A new user’s password is set and communicated, often through a channel that is not as private as anyone pretends. Before that user logs in for the first time, anyone holding the password can go to the security-info page and register their own authenticator as the account’s MFA method. Now the attacker has MFA on the account, satisfies your MFA policies perfectly, and owns the identity. Every downstream control you built is intact and useless, because it is protecting an account the wrong person controls. This is not theoretical. It is one of the most reliable ways accounts are taken over, and it works precisely because the registration moment is the one moment most tenants leave unguarded.
So the framework puts security-info registration behind MFA, and enrollment behind MFA with a fresh challenge every time. Which immediately raises the obvious objection: if registering a method requires MFA, and the new user has no method, how does anyone ever start? That circularity is exactly the problem the Temporary Access Pass solves, and it is why the framework treats the TAP not as a convenience but as the spine of onboarding.
The Temporary Access Pass as the spine
A Temporary Access Pass is a time-limited passcode that Entra treats as a strong credential. Because it satisfies MFA, it breaks the circularity: an administrator issues a TAP to the new user, and that TAP lets them through the registration-protection policy to register a real method, through the enrollment policy to bring up their device, and in the same motion it can bootstrap Windows Hello for Business so the user finishes onboarding already passwordless. One credential, controlled by IT, distributed deliberately, carries the user across every gate that would otherwise block a person with no methods.
The discipline around it is simple and worth stating plainly. The TAP is issued with a short lifetime and, where the process allows, as one-time use, so it is a key that opens the door once and then expires. It is handed to the user through a channel separate from wherever their initial password went, because a TAP and a password arriving together in the same inbox recreates the exact risk the TAP was meant to remove. And it is issued close to when the user actually starts, not stockpiled days ahead. Get those three things right and the TAP is both the most secure and the least painful way to start a user, because the user never fights an MFA prompt they cannot satisfy and never registers a method under an unprotected window.
The prerequisite for all of this is that the Temporary Access Pass method is enabled in the tenant, which the framework’s prerequisite script turns on during the build. If it is off, none of this works, and the registration policies you enabled in ring two become a wall with no gate. That is why onboarding is a named dependency of ring two and not an afterthought.
Autopilot, and doing this at scale
A single new hire with a TAP is straightforward. The interesting question is how this behaves when you are onboarding devices in volume, and the answer depends on which Autopilot model you use, because each one meets the enrollment MFA policy differently.
User-driven Autopilot with a Temporary Access Pass is the default path for a new hire receiving their own machine. The user powers on the device, and during the out-of-box experience the TAP satisfies the enrollment MFA requirement and the registration protection at once, joins the device to Entra, and brings up Windows Hello on the far side. Microsoft supports this specifically for Entra ID-joined devices, which is the framework’s default posture anyway. Hybrid-joined devices are the exception, and a telling one: they require the user to authenticate with another method before a TAP can set up Windows Hello, which is one more reason the framework treats hybrid join as a stop-gap rather than a destination. For the cloud-native path this article assumes, user-driven Autopilot with a TAP is the flow to reach for unless a reason pushes you elsewhere.
Pre-provisioning is the answer when a technician is staging hardware in bulk. The technical phase of pre-provisioning, the part where the device is prepared before it ever reaches the user, authenticates as the device and asks nothing of a user, so a technician can run a stack of laptops through it without a single MFA prompt. The user’s one MFA moment happens later, at their first sign-in on the finished machine, which is exactly where it belongs. If your process has technicians completing full user-driven enrollment on behalf of users, and hitting MFA walls doing it, the fix is not to weaken the policy. It is to switch that process to pre-provisioning, because the friction is a signal that the wrong provisioning model is in use.
Self-deploying mode covers the devices with no user at all, the kiosks and shared and single-purpose machines. It authenticates the device through its hardware trust and never involves a user credential, so the enrollment MFA policy, which targets users, simply never applies. That is correct behavior, not a gap.
The one that fights you, handled honestly
Windows Autopilot device preparation, the newer provisioning model, has a rough edge with this framework that is worth naming rather than hiding. During its automated enrollment steps a device can hit MFA friction against the enrollment policy and stall in the out-of-box experience. There is also an enrollment-wide gotcha to clear first, and it is a documented one: the tenant setting that requires multifactor authentication to register or join devices has to be set to no when a Conditional Access policy already governs the register-or-join action, because otherwise the two controls collide and fight each other. Where device preparation still snags after that, the honest handling is a scoped, temporary exclusion: a provisioning exclusion group on the enrollment policy that is populated for an onboarding wave and emptied afterward, or a trusted named location fenced to the staging bench’s egress. Both are exceptions under the runbook’s rules, which means owned, time-boxed, and reviewed, not a standing hole punched in the policy and forgotten. The framework does not pretend this model is frictionless. It gives you a way to run it that does not become a permanent weakness, and it tells you to close the exception when the wave is done.
The people the smartphone assumption forgets
Every onboarding design quietly assumes the new user has a smartphone to put an authenticator on, and a meaningful slice of the workforce does not. Frontline staff, shop-floor and warehouse workers, anyone whose role does not come with a phone. The framework’s answer is that the Temporary Access Pass still bootstraps them, and the method they register at the far end is a hardware security key or a hardware OATH token rather than an app. Nothing about the registration-protection policy assumes a phone. It assumes a method, and a FIDO2 key is a stronger method than a phone anyway. Shared-device workers get the same treatment, paired with shared device mode on the endpoint so the sign-in frequency controls behave per user on a device that many people touch. The point is that the phoneless case is designed for, not discovered when the first frontline hire cannot complete setup.
Onboarding is where the framework’s whole philosophy is visible in miniature. The registration moment is protected because it is the real target. The protection is made livable by a mechanism, the TAP, that is designed in rather than bolted on. The scale cases each have a defined path, and the awkward case is handled with a governed exception instead of a shrug. A user who starts this way lands on their first day already passwordless, already enrolled, already inside every control, and never once had to fight a prompt they could not answer. That is what it looks like when day one is designed.
Repo: github.com/VirtualCaffeineIO/vcio-ca-framework
Conditional Access
‹ Previous: [CA 4.2] Enabling in Rings: An Order That Doesn’t Break Things
Next: [CA 4.4] Operating the Framework: Exclusions, Reviews, and Drift ›
