Bye-bye passwords: Switching to phone sign-in for Microsoft authentication

For decades, we have accessed IT systems using a set of credentials consisting of a username and a password. All the way back to when end users primarily worked through a session in an old-school mainframe up until Active Directory, this has pretty much been the case.

The way the systems (as they were called back then) were secured was through the use of so-called security boundaries such as firewalls. In addition, when the demand for being able to connect to internal corporate systems over the Internet saw the light of day, perimeter networks (aka DMZ) and virtual private network (VPN) solutions became popular. On top of that, organizations started to deploy two-factor solutions in order to optimize the security further.

Nowadays, most enterprise organization end users still use a username and password (usually Active Directory-based) combined with two-factor authentication to access cloud services and on-premises systems. Although this method works pretty well, Microsoft has put a lot of resources into improving the end-user experience even further. Agreed, we already have Windows Hello for Business, which is a native component of Windows 10, that supports face recognition, PIN code, picture passwords, and device-based dynamic lock as depicted below.

phone sign-in

If the end user’s Windows 10 device is either Azure AD joined or Azure AD Hybrid joined, these features can already be used to login to access Microsoft cloud services such as the workloads in Office 365. And yes, these features are awesome and are already gaining momentum. But what if I told you Microsoft has just made a new sign-in feature available (currently rolling out to tenants worldwide), that makes it possible to login with your work or school account without using a password or any of the above features? Yes, that sounds insane, right? But the fact is that this is now possible with the use of what is referred to as “phone sign-in.” Those of you using Microsoft accounts might be aware of the feature already since Microsoft made it available to consumers a while back. This article will talk about “phone sign-in” for Enterprise organizations for which it is what is brand new. So how do I get started with phone sign-in? I hear you grumble. Well, there are of course certain requirements. The two most important ones are 1) your organization must have an Azure Active Directory tenant and 2) your end users should already be using the Microsoft Authenticator app to login to SaaS applications such as the workloads in Office 365.

Note: The Microsoft Authenticator app is available for the iOS and Android platforms. To the single reader out there still using a Windows Phone, I have to disappoint you. Microsoft no longer offers the app to your platform. Time to move on…

If your organization uses Office 365, then you already have an Azure Active Directory tenant and your end users most likely already use the Microsoft Authenticator for Azure based multifactor purposes. If this is the case, it is very easy to utilize “phone sign-in,” which is a pure user-driven feature. If not, then I highly recommend you switch to Microsoft Authenticator-based MFA instead of SMS/text. If you do not use MFA (enabled or enforced) in your respective organization yet, you should put down your coffee cup and immediately stop reading the rest of this article. Instead, you should go enable or enforce MFA ASAP as you are currently using a setup extremely vulnerable to hackers.

I will not cover end-user adoption of the Microsoft Authenticator app in this article. For guidance on these matters, please see the Microsoft documentation here.

Enabling phone sign-in on the device

The first thing you or your end users have to do to take advantage of phone sign-in is to open the Microsoft Authenticator app on your iOS or Android device. Now click on the drop-down arrow to the right of the account and then Enable phone sign-in as shown below.

phone sign-in

You will now see the following screen, where you need to click Continue. Notice in this particular case, my mobile device is not registered in Azure AD, which is why I have the yellow exclamation mark.

phone sign-in

Depending on whether your device is registered in Azure AD, you might be asked to register your device. Bear in mind, you are limited to register phone sign-in with only one organization at a time.

Testing Phone sign-in authentication

In order to test Phone sign-in authentication, let’s first open a browser and access the Office 365 Portal. One thing that changed with the new sign-in experience that was launched some months ago was that the username and password were separated from each other login-wise. So on the first page, you specify the username (email address/UPN) and when clicking next, you get to the password page.

phone sign-in

On the next page is where the interesting stuff is going on in regards to phone sign-in. As you can see below, we have the option of choosing Use the Microsoft Authenticator app instead. By clicking this link, we switch from password-based sign-in to phone sign-in. Next time you try to login, this will be the default setting.

phone sign-in

After clicking the link, we are provided with the following page, which will show a random number (in this case 16).

phone sign-in

Switching to our iOS or Android device, we have an approval request to deal with. The request shows three numbers and we, of course, have to select the correct one.

phone sign-in

Once we have selected the correct number on our mobile device, we are granted access to the Office 365 Portal.

As you can see, this is a very useful feature that should be welcomed by most users. And it doesn’t stop here. You might already be aware that you can approve Azure MFA requests going to the Microsoft Authenticator app from your Apple Watch. Guess what? Same is true with phone sign-in.

So after reading this article, you are probably eager to switch to your lab environment in order to test out the phone sign-in feature. This is all good. Just bear in mind what I said earlier. This feature is currently rolling out to Azure AD tenants worldwide, so it may not have shown up in your respective tenant just yet. Also, with the number of Azure AD tenants that exists, it may take a while before the feature reaches yours (depending on factors such as region, etc.).

By the way, for additional Q&As about phone sign-in, you may want to check the FAQ over at the Microsoft Docs site. You can find it here and it is pretty comprehensive. For instance, it talks about why phone sign-in is considered safe by Microsoft and things like how phone sign-in works in conjunction with Azure MFA.

About The Author

6 thoughts on “Bye-bye passwords: Switching to phone sign-in for Microsoft authentication”

  1. Hmm, I cannot say I am happy with this being pushed by MS. Not all companies supply their employees with a mobile device, so we are now expected to supply our own equipment for corporate logins ?

  2. Hello Ian,

    Thanks for your feedback.

    So feature should just be considered as an additional option. Whether an organization wishes to utilize it is completely optional.

    However, enabling MFA is strongly recommended. This works with office phones as well.


  3. It’s not being pushed, IT-admins are free and able to use it if they want.

    Seems to me the same kind of problem when BitLocker is suddenly activated and needs the recovery key before booting the OS. Security v.s. usability.

    When you primary auhentication cellphone isn’t working / has no service (temporary), then you can fall back to (nearly all options need to be pre configured before as you’ll understand):

    – Pre-made one-time passcodes (2 for example, hard-copy, no further discription and store them in your wallet / car)
    – A second back-up (cell)phone for authentication (office, colleague or home)
    – Microsoft Authenticator app can generate OT-passcodes (I think the app is able to operate (few hours) with temporary loss of internet connection).
    – Your IT-admin (at the office / connected) can give you (on individual user basis) an one-time bypass through MFA. Simply skip the first verification.
    – Your IT-admin is able to set a static one-time passcode (risky, static OTP will be forgotten / case closed at IT-desk / employee kwows it, but keeps quiet in order to maintain the “better user experience”.

    But what you want to do in an area without cell coverage? No service = no contact with your IT-admin. An back-up 4G-LTE SIM won’t work either. Depending on the implementation / configuration of the MFA solution (especially strong security policies), you won’t need your cellphone all day long. Tokens get cached for X hours, internetbrowers cookies (O365 / Azure MFA) will remain your session active for great period.

    Otherwise, quickly create an local non-domain Windows account, name it like a default but strange service account “WDAGUtilityAccount” or “.NET Framework 4 Helper” and make it member of the ‘Device Owners’ group (never saw a colleague checking these kinds of local groups (other dan Users , Guests and Administrators).

    Access to Windows from anywhere guaranteed, without MFA, user GPO’s and maybe if you’re lucky even without an custom shell like RES / Ivanti. Or shrink your hard drive a little bit 30 / 40 GB, and perform a second install / dual boot (all partitions of every OS BitLocker enabled). That’s what I did, and it has been a life saver 2 / 3 times. Yes, got a boot password before OS will initialize. Windows password crackers boot CD’s, CMOS reset and attach the HDD to other system is a waste of time.

    @ Ian, so you gonna tell your boss the company shouldn’t take measures to protect their information / business. Personally I prefer MFA above losing my job due to old-fashioned risky IT strategies.

    Regards, Luc (The Netherlands)

  4. I hate Microsoft. MFA completely down for the entire Monday.

    Why didn’t my company listen to us when we said to use Google instead of Microsoft. Microsoft are knuckleheads for real.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top