It's Time to Hang Up on Phone Transports for Authentication

Published Nov 10 2020 09:00 AM 69.3K Views

In my blog Your Pa$$word doesn't matter, I laid out the key password vulnerabilities, and in response to a gazillion “but other creds can be compromised, too” DMs and emails, I wrote All our creds are belong to us, where I outlined vulnerabilities in credentials other than passwords and highlighted the promise of passwordless, cryptographically protected creds like FIDO, Windows Hello, and the Authenticator App.

Today, I want to do what I can to convince you that it’s time to start your move away from the SMS and voice Multi-Factor Authentication (MFA) mechanisms. These mechanisms are based on publicly switched telephone networks (PSTN), and I believe they’re the least secure of the MFA methods available today. That gap will only widen as MFA adoption increases attackers’ interest in breaking these methods and purpose-built authenticators extend their security and usability advantages. Plan your move to passwordless strong auth now – the authenticator app provides an immediate and evolving option.

It bears repeating, however, that MFA is essential – we are discussing which MFA method to use, not whether to use MFA. Quoting an earlier blog, “Multi-factor Authentication (MFA) is the least you can do if you are at all serious about protecting your accounts. Use of anything beyond the password significantly increases the costs for attackers, which is why the rate of compromise of accounts using any type of MFA is less than 0.1% of the general population.”

The Usual Suspects

It’s worth noting that every mechanism to exploit a credential can be used on PSTN – OTP. Phish? Check. Social? Check. Account takeover? Check. Device theft? Check. Your PSTN account has all the vulnerabilities of every other authenticator and a host of other issues specific to PSTN.

Not Adaptable

Because so many devices rely on receiving PSTN messages, the format of the messages is limited – we can’t make the messages richer, or longer, or do much of anything beyond sending the OTP in a short text message or a phone call. One of the significant advantages of services is that we can adapt to user experience expectations, technical advances, and attacker behavior in real-time. Unfortunately, the SMS and voice formats aren’t adaptable, so the experiences and opportunities for innovations in usability and security are very limited.

Transmitted in the Clear

When SMS and voice protocols were developed, they were designed without encryption. From a practical usability perspective, we can’t overlay encryption onto these protocols because users would be unable to read them (there are other reasons too, like message bloat, which have prevented these from taking hold over the existing protocols). What this means is that signals can be intercepted by anyone who can get access to the switching network or within the radio range of a device. As I said in the earlier “All Your Creds” blog, “an attacker can deploy a software-defined-radio to intercept messages, or a nearby FEMTO, or use an SS7 intercept service to eavesdrop on the phone traffic.” This is a substantial and unique vulnerability in PSTN systems that is available to determined attackers.

Easy to Social Engineer

It’s worth noting that most PSTN systems are backed by online accounts and rich customer support infrastructure. Sadly, customer support agents are vulnerable to charm, coercion, bribery, or extortion. If these social engineering efforts succeed, customer support can provide access to the SMS or voice channel. While social engineering attacks impact email systems as well, the major email systems (e.g. Outlook, Gmail) have a more developed “muscle” for preventing account compromise via their support ecosystems. This leads to everything from message intercept, to call forwarding attacks, to SIM jacking.


Subject to Mobile Operator Performance

Unfortunately, PSTN systems are not 100% reliable, and reporting is not 100% consistent.  This is region and carrier dependent, but the path a message takes to you may influence how long it takes to get and whether you get it at all. In some cases, carriers report delivery when delivery has failed, and in others, delivery of messages can take a long enough time that users assume messages have been unable to get through. In some regions, delivery rates can be as low as 50%! Because SMS is “fire and forget,” the MFA provider has no real-time signal to indicate a problem and has to rely on statistical completion rates or helpdesk calls to detect problems. This means signal to users to offer alternatives or warn of an issue is difficult to provide.


Subject to Changing Regulations

Due to the increase in spam in SMS formats, regulators have required regulations on identifying codes, transmit rates, message content, permission to send, and response to messages like “STOP.” Unfortunately, however, these regulations change rapidly and are inconsistent from region to region and can (and have) resulted in major delivery outages. More outages, more user frustration.

Limited Context

In practical terms, the text or voice mediums limit how much information can be communicated to a user – SMS carries 160 characters, 70 if not using GSM, and once we get into languages which require encoding, the practical limit without message splitting is only around half that. Phishing is a serious threat vector, and we want to empower the user with as much context as possible (or, using Windows Hello or FIDO, make phishing impossible) – SMS and voice formats restrict our ability to deliver the context under which authentication is being requested.

Authentication Evolved

Ok, to recap: you’re GOING to use MFA. Which MFA? Well, for most users on their mobile devices, we believe the right answer is app-based authentication. For us, that means the Microsoft Authenticator. The Authenticator uses encrypted communication, allowing bi-directional communication on authentication status, and we’re currently working on adding even more context and control to the app to help users keep themselves safe. In just the last year, we’ve added app lock, hiding notifications from the lock screen, sign-in history in the app, and more – and this list will have grown by the time you plan your deployment, and keep growing while SMS and voice keep sitting still.

Hang up on PSTN and pick up the Microsoft Authenticator – your users will be happier and more secure because you did.

Stay safe out there,

Alex (Twitter: @alex_t_weinert)


Makes sense! However SSPR requires to enable another method besides the app. What should be the second one - by the book? There is not that much choice.

Occasional Contributor

Great article. What are your thoughts on using email as a 2FA?

Senior Member

I agree on PSTN not being that reliable and secure anymore. However, solely relying on an authenticator app introduces quite a dilemma when the phone is lost or changed. Although MFA registrations may be restored in the app, OTP codes and notifications are disabled until re-registered with Azure MFA. But you can't restore these factors without another one to get there. I guess another possession factor such as a security key (e.g. FIDO) will have to get more common to completely dispense on PSTN.

Frequent Visitor

Too bad that the Microsoft Authenticator app doesn't provide any context to the authentication request (no location/IP, no target application etc.). Our users will click on Approve without knowing if it was them or not. You guys have a lot of work to do.

Regular Visitor

I currently use SMS-based MFA, and understand its problems, which you've laid out well.


But what scares me about using the Authenticator app is that a large number of my users are, well... inattentive, to put it charitably, and would be highly likely to approve any authentication request they got without giving any further thought to whether it was legit. Too many of them seem to have a genetic predisposition to clicking things like "Yes", "Allow" without understanding (or even bothering to read) what they're clicking on.


At least with SMS, if a fraudulent logon attempt generates an OTP, the user can't funnel that back to bad guy, and that's why I'm sticking with SMS for now.



Occasional Visitor

Do the regulations also prevent something like this:


sending an encrypted captcha over multiple messages, 


your app then uses private key to decrypt and show the captcha, and the user looks at the captcha and enters it to proceed

PSTN is used by wired phones and in most countries only does voice calls.  SMS is generally to mobile phones which doesn't use PSTN.  it uses GSM.


But yes, I agree with moving away from passwords/passcodes/pass phrases to more secure FIDO type mechanisms


@Alex Weinert Sounds all nice and dandy until your users replace their cell phones at the store and then realize they are locked out of business accounts.  This is why SMS is handy as a backup.


If you want SMS gone then you will have to change the defaults in your MFA registration.  The second default method Is always phone/SMS when the minimum methods is set to 2 for SSPR combined experience.


Finally, your force push of app lock was a bad idea and only steered more of our users away from Authenticator.   Was the risk of phone theft so much that you had to force it on everyone?  You can't lock a hardware token which is likely on a key ring, and just as likely to be intercepted as a phone.  Poor choice. 


@Joseph_Moran Yes, Authenticator is long overdue for adding context information like the name of the app and location of the requestor in the push event.  They should be doing this and not features like App Lock, IMO. 


Occasional Visitor

I understand all your points, but there are some situations--that involve a LOT of people--where a telephone call is the ONLY way to verify MFA.  Specifically, there are a military, civilian, and contractors that work in Sensitive Compartmented Information Facility (SCIF) that is used to process classified information.  Cell phones are strictly forbidden.  If you're lucky, they have a containers for cell phones outside the SCIF.  But trying to verify with other than a phone call (since it's right on the desk) is nearly impossible.  DoD rules require you to lock your workstation if you leave it.  So to try to use an app is cumbersome at best, because once the the request hits the screen, you have to lock your workstation, wait for the CAC reader to finish writing to the CAC, remove your CAC (because that's also a requirement), run out of the SCIF, and hope you're in time to hit approve on the app.  If you're trying to use the pseudo-random generated code.  The time is even longer.  Because now I have to badge into the SCIF, run to my computer, put my CAC in the reader, log into the system and hope that I'm in time again.


Given that the phone systems and phone lines are run through a military base and likely a switch, it's much more secure than you're usual landline.


Again, I get the emphasis on moving away from phone and text MFA, but there ARE situations where it's not only appropriate, but necessary!

Occasional Visitor

App-based authentication is great. Lots of sites have implemented it, and I see users across the spectrum eagerly picking it up.


But who you need to be convincing are banks and financial institutions. I can't find a single one (at least in the U.S.) who uses app-based TOTP under the MS Authenticator/Google Authenticator/Authy regime.  I know of a few that experimented with RSA tokens back in the early to mid-2000s, but in recent years, it's as if they all just quietly dropped the idea and fell back on email and SMS as 2FA.


I've tried finding out myself why this is. I've heard various theories -- regulatory hurdles, technical inertia, or cost. I've even asked my own bank, and got a non-answer answer.  But surely the APIs for implementing it can't be any more difficult or costly than setting up an SMS gateway?

Valued Contributor

Thank you @Alex Weinert for your valuable weblog.

Agreed with all points, however one drawback with MFA app is in case someone steal the phone , then user would have hard time and it prevents them from login to their accounts. Especially based on my discussion with IT Professionals from all over the world, almost all countries don't have strong and reliable police to recover their phones and they end up buying new phone and reinstall everything. This is one of scenario where I usually support cloud-based backup.

Frequent Contributor

@Alex Weinert We've migrated many customers to MFA during the last couple years (100,000+ users) and of course this has improved security a LOT.


However, as previous commenters have pointed out, we do have had incidents where user just by laziness has answered "Approve" on authentication notifications in the app and let the perpetrator in since they had the username/password. No matter how much security education effort we put in, this happens on a regular basis I'm afraid. I would think not more than 0,01% of our user base but that's enough to create huge problems.


What plans do you have for minimizing the risk for this? Adding more information to the push notification? Forcing the user to select a correct number out of three as you do on Personal Microsoft Accounts?


I don't know what planet you live on, mister, but on the planet where most users live , they are used to clicking on Agree Allow OK and so on without thinking. So having authenticator app with notifications and Allow button in very many cases renders the second factor useless.

There is also no context in the authenticator app on what IP address or the connecting application is , so Authenticator app is just as context-absent.



This blog post is spot on and I appreciate having all the weaknesses lined up. However, the app is not the silver bullet replacement even though it is a good solution.


I agree with most comments about the app needing improvements to prevent users from being... users. Also the comments about a phone not always being an option is very true for our org. Our staff members often work in environments where mobile phones are strictly forbidden (meaning SMS is useless anyway). We also have the legal dilemma of requiring some staff to install an app for work on a personal device – far from everyone have a company issued phone. You will face issues on many levels when asking staff to do this.


As a result, I am still hoping to see a lot more investments in FIDO/hardware MFA capabilities. We are issuing OTP credit card style hardware tokens as an excellent option to the app (although expensive). However, the reliance on third party apps for programming/administration of these tokens can be made a lot smoother with better integrations in AAD. It should be equally easy to issue a hardware token as it is to issue the app.

Occasional Contributor
Occasional Contributor

@jerrydunn SMS can contain more information: last 4 digits of account number, the amount, etc, than just "approve" in any generic MFA app.

please read:



Your single "OK, approve" might send money to a different account far far away, while SMS-based MFA allows for more details and potentially discovery of this fraud.

Senior Member

On the MFA Authenticator App concerns and the fact that users will blindly click "Approve" on something, they have no idea (Absolutely shocking btw) maybe we just allow admins to turn that function off. When a user requires to do MFA they open the app and acquire the code. Old school.


For our Front Line workers that have no email accounts and such but do log into other enterprise apps the challenges for them managing userid/passwords is a significant challenge. SMS is simplistic enough to allow that authentication with lower risk.


Again no silver bullet. But there are enough options that you can use for the right situation and address the right risks. As long as you can leverage the configuration of persona-based MFA this would be the best option for now I believe.

Occasional Visitor

While I agree with you, Microsoft should follow their own advise. I attempted to install hardware security key to my microsoft live account, but the system does not let me remove the phone number and SMS as a possible authentication method. As a result, the account could be compromise by a SMS hack bypassing the hardware key. If Microsoft really believe SMS is dead, they should have offered an option to remove SMS form the microsoft live accounts.

Occasional Visitor

Nice information...

Azure cloud and cloud migration services provider...

microsoft azure cloud services



Frequent Contributor

@Alex Weinert A lot of questions and suggestions in this post, any comments if any of the features mentioned is coming? Would help a lot in our discussion with customers.

Version history
Last update:
‎Nov 09 2020 10:42 PM
Updated by: