The identity problem is changing
Microsoft 365 security depends heavily on identity. An attacker who obtains a password, steals a session, abuses an app consent, or convinces a user to approve a fraudulent sign-in may gain access to email, files, calendars, financial information, and administrative controls.
Microsoft’s current identity guidance emphasizes phishing-resistant authentication, including passkeys based on FIDO2, Windows Hello for Business, Microsoft Authenticator passkeys, and hardware security keys. Microsoft describes passkeys as credentials using public-key cryptography that are bound to the service where they were created, making them resistant to common phishing and replay techniques.
Microsoft has also published a retirement timeline for Microsoft-provided SMS and voice authentication in Microsoft Entra ID. Beginning February 1, 2027, users whose only available method is Microsoft-provided SMS or voice may be required to register a passkey to continue signing in. Microsoft states that organizations should prepare before that date.
What is confirmed
The following points are confirmed by Microsoft documentation:
- Passkeys are supported as a phishing-resistant authentication method in Microsoft Entra ID.
- Phishing-resistant MFA is intended to replace weaker methods over time, not simply add another prompt.
- Microsoft-provided SMS and voice delivery are scheduled for retirement in Microsoft Entra ID beginning February 1, 2027.
- Users relying only on those methods may encounter a blocking registration requirement.
- Organizations with a business, regulatory, or operational need for SMS or voice may need to configure a customer-managed telecom provider.
The exact user experience depends on tenant configuration, authentication policies, licensing, device support, and the methods currently registered by each user.
Which offices are affected
This matters to any office using Microsoft 365 or Microsoft Entra ID, especially those with:
- Administrators who still rely on SMS or voice.
- Employees who have never registered a passkey or authenticator method.
- Shared workstations or older mobile devices.
- Contractors and vendors with guest access.
- Line-of-business applications that use service accounts or legacy authentication.
- No documented emergency access process.
Small offices are especially vulnerable to disruption because one administrator or bookkeeper may be the only person who can restore access, approve a policy change, or contact a vendor.
A safer migration sequence
Start with an inventory rather than a tenant-wide change.
- Export or review users, administrators, guests, service accounts, and authentication methods.
- Identify accounts that use SMS or voice as their only method.
- Identify all privileged accounts and require stronger authentication for them first.
- Confirm that each administrator has two secure recovery paths that do not depend on the same device.
- Review Conditional Access policies and exclusions.
- Check whether legacy authentication or unmanaged applications remain active.
Next, pilot passkeys with a small group that includes an administrator, an office manager, and a user with a different device type. Document enrollment, replacement, lost-device, and help-desk procedures before expanding.
Protect recovery accounts
Emergency access accounts should be tightly controlled, monitored, and used only when ordinary administrative access is unavailable. Store credentials securely, protect them with phishing-resistant methods where supported, and test the process without making the accounts broadly known or routinely used.
Avoid creating a single “break glass” account that depends on one person’s phone. An office should know who can access recovery credentials, how that access is approved, and how the event is reviewed afterward.
Review access beyond MFA
MFA does not answer every identity question. Review:
- Global Administrator and other privileged roles.
- Inactive accounts and guest users.
- Mailbox forwarding and transport rules.
- Suspicious OAuth or application consent.
- Sign-ins from unexpected locations or devices.
- Conditional Access exclusions.
- Service accounts that still use passwords.
Microsoft’s Secure Future Initiative guidance recommends moving user-based automation toward workload identities where appropriate. This is a design decision that should be tested carefully because changing an automation account without understanding its dependencies can interrupt operations.
Prepare users without causing panic
Explain that the change is a security modernization and an access-continuity project. Give users a clear enrollment window, approved instructions, and a support path. Never ask users to send codes, passwords, or recovery information by email or chat.
Teach a simple verification rule: Microsoft will not need a worker to reveal a one-time code to a caller or approve an unexpected sign-in. A suspicious prompt should be denied and reported.
What remains uncertain
Microsoft’s published timeline is clear, but the practical impact on an individual tenant depends on configuration. Some organizations may already use passkeys, Authenticator, or a customer-managed telecom provider. Others may have hidden dependencies in older applications.
Do not wait until the retirement date to discover those differences. Run an access-method review, pilot stronger authentication, and keep dated evidence of the decisions and tests.
A 90-day action plan
- Days 1–30: inventory authentication methods, privileged accounts, guests, service accounts, and policy exclusions.
- Days 31–60: enroll administrators and selected users in passkeys or another phishing-resistant method; test recovery.
- Days 61–90: expand enrollment, remove unnecessary SMS and voice dependencies, review alerts, and document exceptions.
The practical objective is not merely to satisfy a Microsoft deadline. It is to ensure that the office can prove who is signing in, limit what each identity can do, and recover access when a normal device or account is unavailable.