The first two weeks of January 2022 produced three near-identical phone calls. A CISO, an IT director, and a security architect at three unrelated clients had each spent part of the holiday break reading about MFA prompt-bombing, and each opened the call the same way: is push approval through Microsoft Authenticator still defensible, and can Azure AD do better than SMS. The honest answer was yes, but not by flipping a toggle. Passwordless sign-in with FIDO2 security keys and Windows Hello for Business has been generally available in Azure AD for a while now. What none of these three shops had was the unglamorous plumbing to roll it out to a few thousand people without setting the helpdesk on fire in week one.
That plumbing is this month's field note. Across the three estates - two hybrid Azure AD-joined enterprises and a state agency call center running mostly shared kiosks - we spent January building Temporary Access Pass bootstrap policy, sourcing physical keys for a distributed workforce, standing up break-glass accounts we'd actually trust under audit, and shaping a Conditional Access structure that can absorb Microsoft's promised authentication-strength controls later this year. None of this required new licensing. All three tenants already had what they needed sitting in Azure AD; they just hadn't operationalized it.
Why SMS and push MFA stopped being good enough
NIST flagged SMS one-time codes as a restricted authenticator back in the 800-63B draft years ago, and enterprises are only now catching up, mostly because SIM-swap fraud finally got expensive enough to notice. But the sharper problem in January 2022 is push fatigue. The mechanics are simple: an attacker who already has a valid password - phished, stuffed from a breach dump, or bought - just sends approval requests to the victim's phone until one gets tapped, often late at night or in a burst timed to look like a real sign-in retry. Microsoft's own threat intelligence wrote up Nobelium using exactly this pattern against a support agent in 2021, and it doesn't take a nation-state budget to repeat it.
One of our clients came close to a real incident this way in December: an on-call engineer, half asleep, approved a 2 a.m. push he assumed was a stuck VPN reconnect. Sign-in risk in Azure AD Identity Protection flagged the session as atypical travel and Conditional Access still required a compliant device, so the blast radius was near zero - luck plus a second control, not the MFA prompt doing its job. Microsoft's number-matching feature for Authenticator, which forces the user to type a code shown on the sign-in screen back into the app instead of tapping "approve," is sitting in our tenants right now as an opt-in preview. It helps. It is not the default experience yet, and we are not designing a 2022 rollout around a preview toggle - we are designing around FIDO2 and Windows Hello for Business, which do not have an "approve" button an annoyed user can tap by reflex at all.
The Temporary Access Pass bootstrap problem
Every passwordless rollout runs into the same chicken-and-egg problem: how does a user with no FIDO2 key yet and no Windows Hello for Business gesture yet prove who they are well enough to register one? Azure AD's answer, Temporary Access Pass, reached general availability in November, and by January it's the piece doing most of the load-bearing work in our bootstrap flow. TAP is a time-limited passcode an admin issues in place of a password, good for signing in once to complete registration, then it expires.
The policy has real knobs, and we've had to argue clients out of the lazy defaults:
# Configure the Temporary Access Pass authentication method policy (Graph beta)
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
$tapPolicy = @{
id = "TemporaryAccessPass"
state = "enabled"
isUsableOnce = $true
minimumLifetimeInMinutes = 60
maximumLifetimeInMinutes = 480
defaultLifetimeInMinutes = 60
defaultLength = 8
} | ConvertTo-Json
Invoke-MgGraphRequest -Method PATCH `
-Uri "https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/TemporaryAccessPass" `
-Body $tapPolicy
One-time-use, capped at eight hours, is our floor for onboarding batches. For a lost-key reset on an existing user we tighten that to sixty minutes and one use, full stop - a reusable TAP sitting on an account for a week is a standing password by another name, and it defeats the entire point of the exercise. We also learned quickly to restrict who can issue one. Azure AD's Authentication Administrator role can set a TAP for a regular user; only Privileged Authentication Administrator can do it for anyone holding an admin role, and we scope that role tightly rather than handing it to the whole helpdesk queue.
Key logistics at enterprise scale
Software decisions are the easy part. Getting several thousand physical FIDO2 keys into the hands of a distributed workforce, without a registration desk turning into a line out the door, is the part nobody puts in the slide deck. We standardized on USB-A and USB-C keys with NFC for the phone-tap crowd, ordered against real device inventories rather than headcount (nobody needs three form factors), and pushed self-service registration through the My Security Info portal for anyone with a laptop and a working camera or fingerprint reader. Frontline and shared-device populations don't get that luxury, so kiosk users get a key managed like a physical badge: checked out at shift start, checked in at shift end, tied to a shared-device sign-in pattern rather than a person.
We stage all of this in rings rather than a single cutover, and the ring definition is the one piece of this program worth writing down as a table instead of prose:
| Ring | Population | Method | Graduation signal |
|---|---|---|---|
| 0 | IT and security | FIDO2 key, mandatory | Zero standing passwords for admin sign-in |
| 1 | Executives, finance | FIDO2 key or WHfB | Targeted phishing simulation fails against the group |
| 2 | Knowledge workers | WHfB primary, key as backup | MFA-related helpdesk tickets flat or falling |
| 3 | Frontline, shared kiosks | Badge-style key checkout | Zero shared-account passwords remaining |
Ring 0 matters more than the table implies. If the people running the rollout are still on push MFA when they configure Conditional Access policies that will eventually lock out the rest of the company, they are the softest target in the building, and they know it.
It also gives us the Conditional Access groundwork we actually want. Azure AD doesn't yet have a native control for requiring a phishing-resistant method inside a Conditional Access policy - Microsoft only previewed that authentication-strength concept at Ignite in November - so we fake it with dynamic security groups keyed off completed FIDO2 or WHfB registration, and point Conditional Access policies at group membership instead of method type. When the real control ships later this year, we relabel groups instead of rebuilding four tenants' worth of policy.
Windows Hello for Business without breaking hybrid join
All three environments are hybrid Azure AD joined, with on-premises AD still doing real work, so we're deploying Windows Hello for Business on the two deployment models that are actually mature: hybrid key trust and hybrid certificate trust. Microsoft previewed a third option, cloud Kerberos trust, at Ignite in November - it drops the on-prem PKI and CRL distribution that certificate trust demands - but it's a preview, and we don't put preview authentication plumbing between an executive and their mailbox. Key trust is our default; certificate trust stays reserved for the one client whose smart-card policy requirements aren't going away just because a cloud alternative exists.
Hardware is the real constraint, not policy. TPM 2.0 is table stakes and mostly present across each fleet already, but fingerprint readers and IR cameras are inconsistent on anything older than about three years old, and PIN-as-fallback is doing more work than the marketing implies. A device-bound PIN is not a password - it's useless without the specific TPM it was created on - but it is still something-you-know, and we tell clients plainly that a WHfB rollout that's ninety percent PIN and ten percent biometric is still a massive improvement over a shared network password. Provisioning runs through Intune's WHfB configuration profile wherever the device is Intune-managed rather than the legacy GPO path; the two remaining GPO-managed subsidiaries are the reason this rollout has three separate project plans.
Break-glass accounts we actually trust
None of this matters if a Conditional Access misconfiguration locks out every admin at once, so break-glass comes before enforcement, not after. Each tenant now has two emergency-access accounts: cloud-only, never synced from on-prem AD, excluded by name from every Conditional Access policy, with long, high-entropy credentials split across two physically separated storage locations. They are not used for daily admin work, ever - that's what Privileged Identity Management and eligible role activation are for - and any sign-in against them fires immediately:
SigninLogs
| where UserPrincipalName in ("breakglass1@tenant.onmicrosoft.com", "breakglass2@tenant.onmicrosoft.com")
| where TimeGenerated > ago(1d)
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, ResultType
We wire that query to an alert rule, not a dashboard nobody opens. A break-glass sign-in outside a scheduled quarterly test is an incident by definition, and the runbook says so in writing before the first policy ever goes into enforce mode.
The helpdesk reset workflow
This is where most passwordless projects quietly fail, because the reset path becomes the new weak point the moment the old one gets locked down. A user loses their key, or their phone dies before a work trip, and calls the helpdesk. The temptation is to make that call fast. We've made it deliberately a little slower instead: identity is verified through a channel the caller doesn't control - a callback to a number on file, or a video check-in with a manager who can see a face - before anyone issues a TAP. The pass is single-use, short-lived, and logged against the ticket number. Whoever issues it doesn't get to skip re-registration; the user completes a fresh FIDO2 or WHfB enrollment on the spot, and the TAP is dead the moment that finishes, not at the end of its eight-hour window.
We also started tracking weekly TAP issuance volume as a security metric in its own right, alongside the helpdesk ticket count everyone already watches. A flat or falling trend after the initial onboarding wave means the rollout is sticking. A rising trend three months in means either the hardware is failing at a rate worth investigating, or someone downstream has figured out that calling the helpdesk is easier than stealing a password - exactly the failure mode this program exists to close off.
If you're facing this
If your MFA story is still SMS or bare push approval and you're waiting for a headline incident to fund the fix, the tooling to do better is very likely already sitting unused in the Azure AD tenant you're paying for today. Talk to us before you write the SOW - the sequencing of TAP policy, key logistics, break-glass, and only then enforcement matters more than which vendor's key you buy, and getting it backwards is how these projects stall in ring one.