Our MSP was unexpectedly locked out of a large customer's Microsoft admin portal by an unskippable passkey enrollment prompt. Microsoft's documentation suggested the campaign was aimed at users relying only on SMS or voice authentication, but this account already had Microsoft Authenticator and TOTP methods registered, with SMS retained as a backup for shared technician access. After temporarily registering and removing a passkey, the registration campaign was disabled across the tenant. The account may have triggered enforcement after someone selected SMS as an alternate sign-in method, or the campaign may consider any enabled SMS or voice method to be in scope regardless of other authenticators. Has anyone confirmed the exact conditions that trigger this behavior, and what is the safest way for an MSP to transition without locking out staff?
3 Answers
The campaign was not necessarily limited to people who had only SMS or voice configured. A user can be prompted if the account is in scope, the sign-in device has no registered passkey, and the user has used up the allowed postponements. If the tenant permits only a limited number of snoozes, the next sign-in can require enrollment. The documentation is easy to misread, but having Authenticator or TOTP registered does not automatically guarantee exemption.
It may be that the presence of SMS or voice keeps the account in the campaign even when stronger methods are also registered. Another possibility is that selecting an SMS fallback during sign-in marks the user for enrollment, but that needs to be reproduced in a test tenant before treating it as confirmed. Temporarily disabling the campaign, reviewing the exact targeting scope, and removing legacy methods only after alternate recovery methods are verified is the safest approach.
For an MSP, shared global-admin credentials are a serious audit and offboarding problem. A better long-term design is delegated administration such as GDAP, Lighthouse, or an MSP management platform, with just-in-time access and permissions limited to the customer and task involved. Keep tightly controlled break-glass accounts for emergencies rather than using them for routine work.
Some older delegated-access workflows had limitations in certain admin portals and PowerShell operations, so migration may need testing. That does not make shared global-admin accounts a safe default, but it is worth documenting which tasks still require another access path.
A real break-glass setup can still use physical recovery procedures, such as credentials stored in separate sealed envelopes and safes. The important part is that emergency accounts are monitored, restricted, and not used as normal technician accounts.