Microsoft Entra Token Protection: Stop Stolen Microsoft 365 Sessions From Bypassing MFA

An employee signs in to Microsoft 365 and approves MFA. The prompt is real. Outlook opens normally. Nothing appears broken.

The problem is that an attacker was sitting between the employee and Microsoft during the sign-in. The attacker did not only collect a password. They captured the authenticated session that Microsoft issued after MFA succeeded.

That stolen session token can become a shortcut into email, files, and collaboration. To Microsoft 365, the attacker may initially look like a user who has already signed in.

This is why small and midsize businesses need to think beyond the question, “Do we have MFA?” MFA remains essential, but modern identity protection also has to address what happens after authentication.

Microsoft Entra Token Protection is a Conditional Access session control designed to reduce token replay. It cryptographically binds supported sign-in session tokens to the device where they were issued. If an attacker steals a protected token and tries to reuse it from another device, Microsoft Entra can reject it.

For businesses using Microsoft 365, that creates a practical opportunity to strengthen Exchange Online, SharePoint Online, and Microsoft Teams against a class of attacks that can get past traditional password-and-code MFA.

It is not a universal shield, and it should not be enabled tenant-wide without testing. Used correctly, however, Token Protection can add an important layer between one successful phishing interaction and a much larger cloud compromise.

Why Microsoft 365 Session-Token Theft Matters Now

The buyer-relevant keyword cluster for this topic includes Microsoft Entra Token Protection, Microsoft 365 token protection, Microsoft 365 session token theft, session hijacking prevention, adversary-in-the-middle phishing, AiTM phishing protection, MFA bypass prevention, device-bound tokens, Conditional Access token protection, and Microsoft 365 identity security for small business.

These searches connect to a business concern that is easy to misunderstand: an organization can have MFA enabled and still suffer account takeover.

In April 2026, Microsoft described a financially motivated campaign that combined credential theft with session-token replay. Attackers used adversary-in-the-middle, or AiTM, infrastructure to capture authenticated sessions, maintain access, search for payroll and HR information, create inbox rules, and request direct-deposit changes. Microsoft observed non-interactive sign-ins recurring about every 30 minutes until the sessions were revoked.

In September 2026, Microsoft reported another active cloud intrusion pattern that began with fake IT help-desk calls, texts, passkey lures, and single sign-on themes. After compromising identities, attackers added authentication methods, used Microsoft Graph for reconnaissance, and accessed data in SharePoint, OneDrive, and Exchange.

These reports do not mean every business faces the same campaign. They do show why identity, email, files, and collaboration cannot be secured as separate systems. A Microsoft 365 identity may connect all of them.

How an Attacker Can Get Past Traditional MFA

MFA is designed to require more than a password. It can stop many password-spraying, credential-stuffing, and stolen-password attacks.

But not every form of MFA is phishing-resistant.

In an AiTM attack, a malicious site proxies the victim's sign-in to the legitimate Microsoft service. The employee enters a password and completes the expected MFA step. The attacker relays that process in real time and captures the session material returned after successful authentication.

The attacker may then replay the session from another device. Because the token represents a completed sign-in, the attacker may not need to enter the password or satisfy the same MFA prompt again.

Session tokens can also be stolen through infostealer malware, malicious browser extensions, compromised endpoints, or other attacks against browsers and local authentication material.

The business impact can extend well beyond one inbox:

• read or search email for invoices, contracts, payroll, customers, and vendors
• create inbox rules that hide replies or security warnings
• send convincing messages from a trusted account
• access or download SharePoint and OneDrive files
• use Teams to impersonate an employee or contact coworkers
• inspect organizational relationships through Microsoft Graph
• add an authentication method or approve a malicious application
• target payroll, payment, and account-recovery workflows
• steal data for extortion or future fraud

This does not make MFA ineffective. It means businesses should use phishing-resistant authentication where practical and protect the sessions created after authentication.

What Microsoft Entra Token Protection Does

Token Protection is sometimes called token binding. It is available as a Microsoft Entra Conditional Access session control.

On a supported, registered device, Microsoft Entra issues a Primary Refresh Token that is cryptographically tied to that device. When a supported application requests access to a protected Microsoft 365 resource, Entra checks whether the session uses the required device-bound token flow.

The result is straightforward: a protected token copied to an attacker-controlled device should not work there because the attacker does not have the device key needed to use it.

As of October 2026, Microsoft's published documentation lists Token Protection as generally available for native applications on Windows, iOS/iPadOS, and macOS. Supported Microsoft 365 resources for native applications include:

• Exchange Online
• SharePoint Online
• Microsoft Teams

Windows support also extends to Azure Virtual Desktop and Windows 365 in supported scenarios.

Microsoft lists common native applications such as Outlook, Teams, OneDrive, Word, Excel, PowerPoint, OneNote, Loop, To Do, and Microsoft Copilot among the supported application set. Exact operating-system, application, update-channel, registration, and broker requirements vary by platform and can change, so deployment should always start with Microsoft's current compatibility guidance.

The feature requires Microsoft Entra ID P1. Microsoft's licensing documentation says Entra ID P1 is included with Microsoft 365 Business Premium. That makes Token Protection relevant to many SMBs already using Business Premium, but administrators still need to confirm licensing for every user placed in policy scope.

What Token Protection Does Not Do

Token Protection is valuable partly because it is specific. It solves a defined problem; it does not replace the rest of Microsoft 365 security.

It Does Not Cover Every Browser Session

Microsoft's current documentation says native application support is generally available across the listed platforms, while browser-based support remains limited. Browser support is not a universal way to protect Outlook on the web, SharePoint in a browser, or every SaaS session.

An organization should not assume that enabling Token Protection for supported native clients makes all browser use safe.

It Does Not Cover Every Application or Device

Older Office clients, specialized PowerShell modules, Teams Rooms, some virtual desktops, bulk-enrolled devices, automation scenarios, guest access, and other workflows can require special handling or may be unsupported.

This is the main reason to avoid a rushed tenant-wide rollout. A poorly scoped policy can block legitimate work while still leaving unsupported access paths available.

It Does Not Remove Phishing or Malware

Employees may still receive phishing email, fake help-desk calls, malicious text messages, Teams impersonation, unsafe attachments, or malware. Token Protection can make some stolen tokens less useful, but the original attack still needs to be prevented, detected, and investigated.

It Does Not Replace Phishing-Resistant MFA

Passkeys, FIDO2 security keys, and Windows Hello for Business can resist phishing because authentication is bound to the legitimate service. Token Protection addresses the session-token layer. The controls complement each other.

Our guide to phishing-resistant MFA for Microsoft 365 explains why high-risk users should move beyond text messages, phone calls, and manually entered codes.

It Does Not Replace Incident Response

If compromise is suspected, the business may still need to disable the account, revoke sessions, remove unauthorized authentication methods, reset credentials, inspect inbox rules and forwarding, review application consent, isolate devices, and determine what data was accessed.

Use the Microsoft 365 account-compromise first-hour checklist as a starting point. Do not assume that one policy makes containment unnecessary.

Who Should Small Businesses Protect First?

The long-term objective may be broad coverage across compatible users and applications. The first pilot should be narrower.

Prioritize users whose compromised sessions could create immediate financial, operational, or data risk:

• Microsoft 365 and Microsoft Entra administrators
• owners and executives
• finance, accounting, payroll, and HR staff
• employees who approve payments or bank-detail changes
• users with broad SharePoint or OneDrive access
• legal, healthcare, or regulated-data users
• IT support staff and outside administrators
• employees who manage customer or vendor relationships

This is not only a security ranking. It is also a testing strategy. A finance user may depend on an Excel add-in. An administrator may use PowerShell. A remote employee may work on an unmanaged device. An executive may switch frequently between native apps and browsers.

The pilot must represent real work, or it will not reveal the dependencies that matter.

A Safe Microsoft Entra Token Protection Rollout Plan

1. Confirm Licensing, Device State, and Ownership

Verify that users in scope have the required Entra licensing. Confirm whether their devices are Microsoft Entra joined, hybrid joined, or registered in a supported way.

Identify who owns:

• Conditional Access policy design
• device registration and compliance
• application updates
• sign-in-log review
• user communication and support
• emergency-access procedures
• policy exceptions and review dates

Token Protection depends on identity and device state working together. If nobody owns one side of that relationship, deployment problems will be difficult to diagnose.

2. Inventory Applications and Access Patterns

Document how pilot users reach Exchange Online, SharePoint, Teams, and related services.

Include:

• Outlook, Teams, OneDrive, and Office desktop versions
• Windows, macOS, iOS, and iPadOS devices
• browser-based workflows
• shared workstations
• virtual desktops and Windows 365
• Teams Rooms and resource accounts
• PowerShell modules and administrative scripts
• Power Query and Office add-ins
• guests and outside collaborators
• automation and service accounts
• unmanaged or personally owned devices

This inventory helps distinguish an expected incompatibility from an attempted policy bypass.

3. Protect Emergency Access

Maintain well-controlled emergency-access accounts and exclude them from the initial policy as Microsoft recommends. These accounts should not be used for ordinary administration, email, or browsing.

Document how they are monitored and tested. An emergency account that nobody can access is not a recovery control. An emergency account used every day is not an emergency account.

4. Start in Report-Only Mode

Microsoft's September 2026 Windows deployment guide recommends beginning with a pilot group, creating the Conditional Access policy in report-only mode, and reviewing both interactive and non-interactive sign-in logs before enforcement.

Report-only mode helps answer:

• Which sign-ins would satisfy Token Protection?
• Which applications are still using unbound token flows?
• Are devices missing the required registration state?
• Are operating systems or clients outdated?
• Would browser or specialized application use be blocked?
• Are expected automated processes affected?

Run the pilot long enough to include normal weekly and monthly workflows. A two-hour test may miss payroll, month-end reporting, travel, remote work, or periodic administrative scripts.

5. Review Interactive and Non-Interactive Sign-Ins

Do not review only the sign-ins where a user typed a password.

Microsoft 365 applications regularly refresh access in the background. Microsoft's guidance specifically calls for reviewing interactive and non-interactive sign-in data and checking the Token Protection - Sign In Session status.

Investigate unbound results. Depending on the status, they may point to missing device state, unsupported registration, unsupported operating systems, or clients that are not integrated with the expected platform authentication broker.

The objective is not to create a large exception list. It is to identify legitimate dependencies, modernize them where possible, and make any remaining exception narrow, owned, documented, and time limited.

6. Enforce in Stages

After the report-only data is understood:

1. enforce the policy for a small, reliable pilot group
2. monitor support tickets and sign-in logs
3. test Outlook, Teams, OneDrive, and Office workflows
4. validate travel, remote access, and device replacement
5. expand by department or device group
6. review exclusions after each phase

Microsoft warns that selecting overly broad resources or leaving browser client conditions in scope can cause unintended failures. Follow the current platform deployment guide rather than copying a generic Conditional Access policy from an old checklist.

7. Close Alternate Access Paths

Attackers look for the route with the least resistance. Microsoft recommends requiring compliant devices for known platforms and blocking unknown platforms where appropriate so an attacker cannot simply claim a different device type to avoid the intended control.

Review Token Protection alongside:

• phishing-resistant MFA for high-risk users
• Conditional Access for managed or compliant devices
• legacy authentication blocks
• risk-based access policies where licensed
• application-consent restrictions
• administrator role separation
• Microsoft Defender for Endpoint and device hardening
• Defender for Office 365 Safe Links and Safe Attachments where licensed
• user phishing reporting and rapid triage
• external forwarding and mailbox-rule monitoring
• SharePoint, OneDrive, and Teams sharing governance

Our Microsoft 365 security checklist for small businesses can help place these controls into a broader tenant review.

Connect Token Protection to Email Security

Token theft is an identity attack, but email is often where the business feels the damage.

A compromised Exchange Online session can expose years of conversations, vendor names, invoice patterns, employee relationships, and sensitive attachments. It can let an attacker send from a real account or create rules that hide replies. That is why a technical identity control should connect to operational email controls.

Small businesses should also:

• configure anti-phishing, impersonation, anti-malware, and anti-spam policies
• use Defender for Office 365 protections where licensing supports them
• review SPF, DKIM, and DMARC for owned domains
• monitor forwarding and unusual inbox-rule changes
• set reasonable outbound sending controls and investigate unusual volume
• give employees a working report-phishing process
• verify payroll, banking, and vendor-payment changes outside email and Teams
• preserve sign-in, audit, email, endpoint, and file-access logs for investigation

Token Protection can make replay harder. It cannot stop a finance employee from acting on a fraudulent request sent through a legitimately compromised account. Business-process verification remains necessary.

A Practical SMB Readiness Checklist

Before enforcing Microsoft Entra Token Protection, ask:

• Do we have Microsoft Entra ID P1 licensing for every user in scope?
• Are employee devices registered in a supported way?
• Do we know which native and browser applications employees actually use?
• Are Office, Outlook, Teams, OneDrive, and operating systems current?
• Have we inventoried PowerShell, add-ins, virtual desktops, room systems, and automations?
• Are emergency-access accounts documented, secured, monitored, and tested?
• Has the policy run in report-only mode through representative workflows?
• Is someone reviewing interactive and non-interactive sign-in results?
• Do exclusions have an owner, justification, compensating control, and expiration date?
• Are high-risk users also using phishing-resistant MFA where practical?
• Do Conditional Access policies restrict unmanaged and unknown devices appropriately?
• Can the team revoke sessions and investigate a suspected token-theft incident quickly?
• Are email, file, Teams, endpoint, and identity signals reviewed together?

If several answers are “no,” the business does not need to abandon the control. It needs a staged readiness plan.

How CybarWorks Can Help

Microsoft 365 security should protect the business without creating avoidable interruptions.

CybarWorks can help small and midsize businesses:

• review Microsoft 365 and Microsoft Entra licensing
• assess Token Protection readiness and compatibility
• inventory devices, applications, and high-risk workflows
• design Conditional Access policies with safe pilot groups
• analyze report-only and sign-in-log results
• strengthen MFA and move high-risk users toward phishing-resistant methods
• review Defender for Office 365, email authentication, and mailbox protections
• improve SharePoint, OneDrive, Teams, and external-sharing controls
• document exclusions, emergency access, and account-compromise response
• build a practical identity and email security roadmap

If your business has MFA but has never assessed session-token theft, contact CybarWorks. We can help determine where Token Protection fits, what it will and will not cover, and how to test it without disrupting the work Microsoft 365 is supposed to support.

Frequently Asked Questions

Can attackers bypass Microsoft 365 MFA?

Attackers may capture and replay an authenticated session token through adversary-in-the-middle phishing, malware, or another compromise. The user may have completed MFA legitimately, but the attacker reuses the resulting session. Phishing-resistant authentication, secure devices, Conditional Access, Token Protection, monitoring, and rapid session revocation reduce this risk.

What is Microsoft Entra Token Protection?

Microsoft Entra Token Protection is a Conditional Access session control that requires supported sign-in session tokens to be cryptographically bound to the device where they were issued. A stolen protected token should not be reusable from an attacker-controlled device.

Does Microsoft 365 Business Premium include Token Protection licensing?

Token Protection requires Microsoft Entra ID P1. Microsoft states that Entra ID P1 is included with Microsoft 365 Business Premium. Confirm licensing and feature availability for all users before enforcement.

Does Token Protection secure Outlook, Teams, and OneDrive?

It can protect supported native applications when they access supported resources such as Exchange Online, SharePoint Online, and Microsoft Teams. Coverage depends on the platform, app version, device registration, authentication broker, policy scope, and Microsoft's current support matrix.

Does Token Protection secure browser access?

Not broadly. Microsoft's October 2026 documentation lists only limited browser-based support for selected web applications accessing Azure Resource Manager. Businesses still need phishing-resistant authentication, device controls, browser and endpoint security, risk monitoring, and other Conditional Access policies for web access.

Should a small business enable Token Protection for everyone immediately?

No. Start with a representative pilot in report-only mode, inspect interactive and non-interactive sign-ins, resolve compatibility issues, protect emergency access, and then enforce in stages. A rushed rollout can block legitimate applications or users.

Work Cited

• Microsoft Learn. Token Protection in Microsoft Entra Conditional Access.
• Microsoft Learn. Token Protection deployment guide for Windows.
• Microsoft Learn. Protecting tokens in Microsoft Entra.
• Microsoft Learn. Microsoft Entra licensing.
• Microsoft Security Blog. Investigating Storm-2755: “Payroll pirate” attacks targeting Canadian employees.
• Microsoft Security Blog. Passkey-themed social engineering leads to identity and cloud compromise.