Microsoft is retiring SMS & Voice authentication in Microsoft 365 – what does it mean for law firms?

Microsoft has announced a change to the way some users authenticate to Microsoft 365. From 1 September 2026, they will begin making passkeys the default authentication experience for users currently enabled for SMS or voice authentication. Then, from 1 February 2027, Microsoft will retire its own SMS and voice authentication services within Microsoft Entra ID.

So, what does this actually mean for firms – and do you need to do anything?

The short answer is yes, but don’t panic. Your internal IT team or Managed Service Provider (MSP) should be reviewing your Microsoft 365 environment, identifying who will be affected and developing an appropriate migration plan. However, as we have said before, outsourcing the management of your IT doesn’t mean outsourcing responsibility for it. Firms should understand what is changing and be asking their IT provider what they are doing about it.

What’s changing?

Many firms will be familiar with Multi-Factor Authentication (MFA). You enter your username and password and are then asked to prove that you really are you using a second method. For some users that second method is still an SMS text message containing a code, or occasionally an automated telephone call.

Microsoft no longer considers these sufficiently secure authentication methods. SMS in particular has weaknesses including the potential for SIM-swap attacks, phishing and interception. They are  therefore ending use of these methods and directing users towards phishing-resistant authentication, with passkeys becoming the preferred approach.

There are two important dates.

• 1 September 2026 – users who are currently enabled for SMS or voice authentication will automatically be enabled for passkeys and Microsoft will start prompting eligible users to register one.
• 1 February 2027 – Microsoft’s own SMS and voice authentication services will be retired. After the February deadline, a user whose only available MFA method is SMS or voice will not be able to logon in their normal way and will be required to register a passkey before they can continue.

While Microsoft is providing a temporary opt-out from the September changes for organisations managing their own transition, there is no such opt-out from the February 2027 retirement.

This is something your internal IT team or Managed Service Provider should be planning for now, including identifying affected users, agreeing a migration approach and putting appropriate support in place, as users will need to register their own passkeys – this cannot simply be done for them by IT.

What is a passkey?

The simplest way of thinking about a passkey is that it replaces something you know, such as a password, with something securely associated with a device or credential store that you have, which you then unlock using something such as your fingerprint, face or device PIN. Behind the scenes, passkeys use cryptographic keys rather than a password or code which has to be shared between you and the service. This is an improvement because there isn’t a password or one-time SMS code for a criminal to persuade you to hand over.

If a user is presented with a convincing fake Microsoft 365 login page today, they could potentially enter their username and password and then be persuaded to provide an MFA code. A passkey is designed to prevent that type of phishing attack because the authentication is cryptographically linked to the genuine service.

Microsoft’s implementation supports different forms of passkey. They can, for example, be associated with a user’s device, held within Microsoft Authenticator or stored in a supported credential manager and synchronised across devices. FIDO2 hardware security keys can also be used.

The precise approach a firm adopts is something that needs to be considered as part of its wider device, identity and security strategy rather than simply allowing users to choose whatever is most convenient.

Does this mean Microsoft Authenticator is going away?

No. Microsoft Authenticator itself isn’t being retired. In fact, Authenticator can be one of the places in which a passkey is held (and, depending how your environment is configured, could be the only place you’re allowed to keep it). Microsoft Authenticator also continues to support the familiar MFA notification approach – including number matching – as well as verification codes. The announcement specifically concerns Microsoft-provided SMS and voice authentication and Microsoft’s wider move towards passkeys and phishing-resistant authentication. This is relevant because firms shouldn’t interpret this announcement as meaning that everybody has to abandon their existing Authenticator configuration on 1 September.

Why is Microsoft doing this?

Fundamentally, this is about security: cyber criminals have become increasingly effective at defeating traditional usernames and passwords and at persuading users to approve or disclose the second factor intended to protect their account. SMS is particularly problematic because it wasn’t originally designed as a secure authentication technology.

Passkeys change the equation because they are resistant to phishing, SIM-swap and replay attacks. For security conscious organisations this should be seen as a positive development as it will reduce the attack options available to threat actors.

The information held within your Microsoft 365 environment is extremely valuable. Email alone potentially provides an attacker with confidential client and matter information, financial information and the ability to impersonate partners and staff – including in communications with clients and third parties.  Microsoft Entra ID Authentication provides access to documents, Teams, SharePoint and numerous connected business applications through integrated single sign-on. Strong identity security is therefore more important than ever.

 What should we be doing now?

Partners and management teams don’t need to become experts in configuring Microsoft Entra authentication policies – that’s what your IT team or MSP is there for. However, there are some important questions you can ask:

• How many of our users currently have SMS or voice authentication enabled, and how many are still actively using it?  Microsoft provides tools which allow administrators to identify these users. Your IT provider should therefore be able to tell you the scale of the issue rather than simply saying that they’re “looking at it”.

• What authentication method are we moving them to?  Passkeys will be Microsoft’s preferred direction, but your provider should be able to explain the approach it is recommending for your firm and why.

• When are we going to make the change?   There is plenty of time before February 2027, but we’d strongly recommend not treating that as the target implementation date. Authentication changes affect every user and inevitably generate questions and support requirements. A controlled pilot followed by a managed rollout is far preferable to users discovering the change when they are trying to log in.

• How are we going to communicate it?   This is probably as important as the technology. Users need to know what a passkey is, why they’re being asked to register one and what the genuine Microsoft registration process will look like. There is a certain irony in improving protection against phishing by unexpectedly asking hundreds of people to follow a new security registration process. Clear communication and user education should therefore form part of the project.

• What happens with exceptions?   There may be users, devices or operational scenarios where the firm’s preferred approach isn’t suitable. Those exceptions should be identified during planning rather than after deployment. Microsoft is providing a route for organisations with a genuine requirement to retain SMS or voice authentication to use a customer-managed telecommunications provider through the Microsoft Security Store. That shouldn’t, however, be seen as a reason to simply preserve the status quo. Microsoft’s clear recommendation is to move users towards phishing-resistant authentication wherever possible.