Background
I work with many clients and have done in my current employment since March 2020. It’s fair to say that I have access to multiple client environments; some of which I developed and provisioned, and some of which I help support. Along with my personal accounts, this means my Microsoft Authenticator app is used for 59 accounts!
I’ve also had my phone for almost 5 years. As one of the first iPhone X’s on the market, the last past year has been a struggle for keeping the available storage in check. It was time for a new phone.
New phone time
The new iPhones were out in September 2022, and I had my eyes on the iPhone 14 Pro with 1TB of storage (the other extreme, but now I know I won’t run out of storage anytime soon!).
Apple products are great for upgrading. Switched the new phone on, sat it beside the old one and it automatically prompted me to transfer all my files, apps, and settings. At the end of the transfer my old phone prompted me to reset it, so I could sell it on or give it to a family member. I decided against this, at least until I saw everything was secure, transferred, and working on the new phone.
Microsoft Authenticator
One of the things I use multiple times per day is Microsoft Authenticator. All my native AAD accounts are device enrolled and Passwordless enabled (this will become important soon).
Alongside my native accounts, I have federated accounts – these count for about 80% of the accounts I have. I can’t use my federated accounts for Passwordless sign-in, but they are used for push-notifications for multi-factor authentication (MFA) against client tenants.
I also have multiple accounts used for MFA one-time passwords (OTPs), for discord, GitHub, LinkedIn, Pluralsight, etc.
Action required
I opened my authenticator, all my Azure Active Directory (AAD) accounts, both native/local and federated had action required warning underneath them.
My new device fingerprint wasn’t the same as my old device, and I need to re-enrol my new iPhone on all of my AAD accounts.
For my native/local accounts, I could use my password to enrol the new Microsoft Authenticator app as a new trusted device… but for my native accounts I use Passwordless, therefore I did not know what my password was!
Moreover, for my federated accounts, since there is no “password handling” in the federated tenant, I could not go down the password reset route and the only option I was presented with was to scan a QR code as if I was setting up Microsoft Authenticator from scratch.
For some of my federated accounts, I had setup my phone number as an authentication method first, before enrolling the Microsoft Authenticator app. These accounts allowed me to MFA via SMS and setup the new phone, for the others… I was stuck.
Well, almost. If there is another administrator with the correct role to manage authentication methods (e.g., authentication administrator) then they could remove my old iPhone from the authentication methods.
This would force me to setup a new MFA method when signing in next time. This administrator could also add a new authentication method and setup my phone number as an authentication method to reinforce that the account remains secure.
Seems a lot of work, especially when we are talking about over 50 AAD accounts. This would take forever.
The brainwave
I didn’t wipe my old device!
There was no-one else I required bar myself if I used my old device to authenticate then transfer the authentication method over to my new device. Heading over to aka.ms/mfasetup, I successfully logged into my corporate account using Passwordless on my old device.
From this screen I was able to add a new method, my new device’s Microsoft Authenticator app.
Once I was enrolled, I could remove the old device from the list of authentication methods, just in case it fell into the wrong hands.
Success!
I was able to login with my new phone, and setup Passwordless authentication for native accounts. All I had to do now was switch organisation, use my old phone for MFA, register my new phone, delete the old, and setup a phone sign-in method (if I ever lose the device, I can use SMS as an MFA method in the future).
I then proceeded to do this for the remaining accounts, which did take a long time and was very repetitive, but this was much better than contacting each client and getting their IT support staff to reset the sign-in methods for me.
Takeaways
If you’re changing your phone, don’t wipe the existing phone until you’ve recovered all your Azure Active Directory accounts and enrolled them on the new device. The Microsoft Authenticator cloud backup and recovery steps does not mean you can instantly start using all your accounts like normal. This is due to the credential being tied to a specific device and never sent over the network; therefore, you must prove your identity and enrol the new device before the credential is created.
Top comments (4)
Sounds like a pain. Passwordless comes with a price. I hope we find a better way around this.
There’s always a balance between account security and convenience. If you’re always changing devices, perhaps Passwordless is a pain and not worth it, for this very reason. The real trouble was with federated accounts where there was no option to reset a password or use SMS as the sign-in method.
I still thing Passwordless is the future, and one of the upcoming blogs will be about this very topic. I’ll be sure to reference your comment 🙂
Someone has had a similar experience and has been advised to use a "break glass" account.
yammer.com/cepartners/#/threads/sh...
I think this also applies to Google Authenticator, too.