Ask who owns patching for a domain controller and you get an answer within seconds. Ask who owns the version of Microsoft Authenticator on the finance director's personal Android phone and you usually get silence. That gap mattered this month.
What the flaw did
CVE-2026-80097 is an elevation of privilege flaw in Microsoft Authenticator for Android, rated CVSS 8.6. Microsoft fixed it on 8 September in version 6.2606.4246. In late October, the researchers who found it published how it worked, and it has since been widely reported.
On Android, Authenticator does more than show MFA prompts. It acts as the authentication broker: other Microsoft apps such as Teams and Outlook ask it for tokens instead of signing in themselves. The researchers found that a malicious app with no Android permissions at all could abuse an exposed component to pose as a trusted Microsoft app. The broker would then hand it access, refresh and ID tokens in plain text. In their testing, those tokens carried delegated Microsoft Graph access to the user's mail, calendar, files, SharePoint and chat.
No exploitation in the wild has been reported, and the attack needs a malicious app on a phone that has a work account signed in. But consider what that requirement means in practice: one sideloaded game on a personal phone, and the attacker gets a work session that has already passed MFA.
The phone is part of the identity perimeter
We spend a lot of effort hardening sign-in: Conditional Access, phishing-resistant methods, token protection, risk policies. All of that happens at Entra ID. After that, the token lives somewhere, and on mobile that somewhere is the broker app.
That makes Authenticator on Android an identity component, in the same category as the Primary Refresh Token on a Windows laptop. Yet most organisations treat it as something the user installed from a shop. On managed laptops, a broker update is just another monthly patch. On phones, especially personal phones, nobody is watching the app version, and the app's own auto-update setting is the only control.
If an app can hand out tokens for your tenant, it belongs in your patch scope, whoever bought the phone.
Decide who owns it
The fix here is mostly organisational. Three questions to settle this week:
- Who owns mobile app versions? Usually the endpoint team for corporate devices. For personal devices, someone has to own the policy even if they can't own the device.
- What is the minimum bar for a phone that holds a work account? A supported OS, a recent security patch level and a current broker app, written down and enforced.
- Who tells users when it matters? A short, specific message ("update Authenticator today, here's how to check") gets results that a policy document never will.
What to do in a Microsoft estate
Corporate-owned Android
- Deploy Authenticator through managed Google Play in Intune and set its update priority to high, so updates install promptly instead of waiting for the device to be idle and charging.
- Use Intune's discovered apps reporting to find devices still running a version below 6.2606.4246.
- Require a minimum OS security patch level in compliance policy, and require compliant devices in Conditional Access.
Personal Android (BYOD)
- You can't see every app, so set the floor you can enforce: Conditional Access requiring an app protection policy, plus device conditions such as minimum OS version and patch level.
- Tell users directly. Ask them to check the Authenticator version under the app's settings and turn on automatic updates in Google Play.
- Restrict what an unmanaged device can reach. Browser-only access for sensitive apps reduces what a stolen mobile token can do.
For the SOC
- A token taken from a broker is used somewhere else. Watch for a user's mobile client sessions, typically non-interactive sign-ins for Teams, Outlook or Graph clients, appearing from networks or countries where the user isn't.
- Watch for Graph-heavy mailbox and file access from an unfamiliar IP shortly after normal mobile activity. That pattern looks the same however the token was stolen, which is why it's worth building once.
- Bring Intune and sign-in data into one place. A device that is out of date and an unusual session for the same user are two halves of the same story.
The wider point
Much of what we've written this month is about tokens rather than passwords: token replay into 79 organisations, device code phishing, stealers taking AI tool tokens, and now a broker that could be talked into handing them over. Attackers have moved past the sign-in. The places tokens are stored and handed out deserve the same ownership and patching discipline as the sign-in itself.
The Authenticator fix has been out for seven weeks. If you can't say how many of your users' phones have it, that's the gap to close, and it says more about your mobile governance than this one CVE does.
If you'd like help mapping where tokens live in your estate and who owns each one, talk to our team.