FOCI: How the Family of Client IDs Token Mechanism Bypasses Conditional Access and What to Do About It
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
FOCI was first publicly documented by Secureworks researchers and presented at Black Hat Europe 2024. It exists because Microsoft wants seamless token sharing across its first-party apps. The security implication is that any token obtained from a FOCI app under favorable Conditional Access conditions (compliant device, satisfied MFA) can be used to access other FOCI apps under less favorable conditions (unmanaged device, different location) without re-triggering CA. For defenders, the key is understanding which apps are in the family, how attackers use stolen refresh tokens across FOCI members, and what Continuous Access Evaluation can and cannot mitigate.
Which Apps Are in the FOCI Family
Microsoft has not published an official exhaustive FOCI member list. Secureworks' research identified the following applications as confirmed FOCI members (based on their published GitHub research): Microsoft Authenticator (4813382a-8fa7-425e-ab75-3b753aab3abb), Microsoft Azure PowerShell (1950a258-227b-4e31-a9cf-717495945fc2), Microsoft Azure CLI (04b07795-8ddb-461a-bbee-02f9e1bf7b46), Microsoft Office (d3590ed6-52b3-4102-aeff-aad2292ab01c), Teams (1fec8e78-bce4-4aaf-ab1b-5451cc387264), Microsoft Intune Company Portal (9ba1a5c7-f17a-4de9-a1f1-6178c8d51223), Visual Studio Code (aebc6443-996d-45c2-90f0-388ff96faa56), Microsoft 365 Admin Center (00b41c95-dab0-4487-9791-b9d2c32c80f2), and others. The common thread is that all are first-party Microsoft apps that an employee would legitimately use. When any of these apps authenticates and returns a refresh token with the foci=1 claim, that token can be exchanged for access tokens of any other FOCI member via the standard token refresh endpoint (POST to /oauth2/v2.0/token with the refresh_token grant type and a different client_id from the FOCI family).
The Attack Scenario: Stolen FOCI Refresh Token
An attacker who steals a FOCI-capable refresh token -- via infostealer malware, phishing, or token extraction from browser storage -- can use that token to obtain fresh access tokens for any FOCI member app without re-authenticating. The original token may have been issued during a compliant-device session that satisfied a 'Require compliant device' Conditional Access policy. The token exchange request does not re-evaluate Conditional Access conditions for the new app -- it uses the existing token's claims. The attacker uses the token on their own (unmanaged, non-compliant) device to authenticate to: Microsoft Graph API (to read email, enumerate users, enumerate groups), Azure Management API (to list subscriptions and resources), Exchange Online via Teams PowerShell, or any other FOCI-member resource. From a log perspective: the token exchange generates an Entra ID sign-in log entry with Application = the FOCI member app, IP = the attacker's IP, and no MFA event (because MFA was satisfied at the original token issuance). The source device shows as whatever the token's device_id claim contains -- which may be the victim's compliant device ID, not the attacker's device.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Detection: What FOCI Abuse Looks Like in Logs
Signs of FOCI token abuse in Entra ID sign-in logs: sign-in events from a different IP address or geographic location than the previous authentication event for the same user, with no new MFA event in between. The application field shows a FOCI member app (Azure PowerShell, Azure CLI, Microsoft Graph) rather than a user-facing application. The authentication method shows 'Previously satisfied' or 'Refresh token' rather than a fresh credential. Alert on: access to Microsoft Graph or Azure CLI from IP addresses inconsistent with the user's normal location, when the previous sign-in was from a corporate IP and the current one is from a residential or VPN IP without a new authentication event. In Sentinel: AADSignInEventsBeta | where ResourceDisplayName in ('Windows Azure Service Management API', 'Microsoft Graph', 'Azure Active Directory Graph') | where AuthenticationRequirement != 'multiFactorAuthentication' | where IPAddress !in (list-of-corporate-IPs) | project TimeGenerated, UserPrincipalName, IPAddress, ResourceDisplayName, AuthenticationDetails. Correlate with Entra ID Identity Protection risk detections -- 'Unfamiliar sign-in properties' and 'Anomalous Token' are the most relevant.
Continuous Access Evaluation as a Partial Mitigation
Continuous Access Evaluation (CAE) is the primary Microsoft-side partial mitigation for FOCI token reuse. CAE-capable applications (those that implement the CAE protocol) re-validate the token's security conditions at the resource server side -- if the Entra ID tenant detects a risk event (password change, account revocation, network location change), the resource server is notified and forces a re-evaluation. For FOCI abuse: CAE helps if the attacker is using the stolen token from an unexpected location or if the account has been flagged by Identity Protection. CAE limitations: not all Microsoft apps implement CAE (Azure CLI does not as of mid-2026). CAE evaluation is asynchronous and network-change events can take minutes to propagate. CAE does not protect against token use from IP addresses that are not flagged as anomalous by Identity Protection (for example, an attacker using a residential IP that happens to be geographically near the victim). CAE is necessary but not sufficient for complete FOCI protection.
Reducing FOCI Attack Surface
There is no configuration option to disable FOCI -- it is a Microsoft platform mechanism. The practical defenses are: restrict token lifetimes using Conditional Access token session controls. Configure Sign-in Frequency to 1 hour for high-sensitivity applications (Azure Management, Microsoft Graph) -- this limits how long a stolen refresh token remains valid. Disable persistent browser sessions for administrative applications. Enable Conditional Access for Workload Identities where applicable to restrict where service principal tokens (separate from FOCI) can be used. Monitor and alert on the sign-in patterns described above. Enforce phishing-resistant MFA (FIDO2, WHfB) -- while a stolen FOCI refresh token bypasses MFA for subsequent token exchanges, phishing-resistant MFA reduces the initial token theft risk compared to TOTP or SMS MFA. Deploy Microsoft Defender for Cloud Apps with session policies that re-evaluate access on suspicious signals mid-session. Accept that FOCI is a platform behavior and focus on rapid detection of anomalous token use rather than trying to prevent the mechanism itself.
The bottom line
FOCI allows refresh tokens obtained from any Microsoft first-party app to be exchanged for tokens to other Microsoft apps without re-triggering Conditional Access. Stolen FOCI tokens -- from infostealer malware, phishing, or browser token theft -- give attackers access to Microsoft Graph and Azure APIs with the victim's permissions. Configure short sign-in frequency limits for sensitive apps, enable CAE, alert on cross-application token use from unusual IP addresses, and accept that FOCI detection requires behavioral monitoring rather than a single configuration fix.
Frequently asked questions
Is FOCI the same as the Primary Refresh Token (PRT)?
No. PRTs are device-bound tokens issued to Entra ID joined or registered devices that allow SSO across browser and application sessions on that specific device. FOCI is an application-level token sharing mechanism that allows refresh tokens from one app to be used for another app, independent of the device. Both mechanisms provide SSO-like capabilities but at different layers: PRT is device-scoped, FOCI is application-family-scoped. Stolen PRTs are also a serious risk, but the theft vector (requires device-level access or a vulnerability to export the PRT) differs from FOCI refresh token theft (which can occur via browser cookie theft or application credential storage access).
Can I block specific FOCI member apps with Conditional Access?
Yes. You can create Conditional Access policies that block or restrict access to specific FOCI member applications by adding them as target apps. For example: block Azure PowerShell (app ID 1950a258) for all users except specific admin accounts. This does not disable FOCI for other apps but reduces the blast radius by limiting which apps a stolen FOCI token can be used for. Block Azure CLI and Azure PowerShell for standard users (they should not need direct API access to Azure Management) -- this is a defensible baseline regardless of FOCI.
How does token theft via infostealer malware relate to FOCI?
Infostealer malware (Redline, Raccoon, Vidar, etc.) specifically targets browser credential stores and application token caches, including the MSAL (Microsoft Authentication Library) token cache used by Microsoft desktop apps. A stolen MSAL token cache contains FOCI-capable refresh tokens. After exfiltration, attackers use these tokens on their own infrastructure to enumerate the victim's Microsoft 365 environment, download email, and pivot to Azure resources -- all without knowing the user's password or MFA secret. This is why infostealer campaigns that target Microsoft environments are particularly dangerous: the resulting tokens provide persistent access until the token expires or the user's session is revoked.
Does revoking all refresh tokens stop ongoing FOCI abuse?
Yes, immediately revoking all refresh tokens for a suspected compromised user stops FOCI abuse because the stolen refresh token is invalidated. Revoke via PowerShell: Revoke-MgUserSignInSession -UserId user@domain.com or via the Entra admin center > Users > [user] > Revoke sessions. After revocation, the attacker's stolen refresh token returns an error on the next token exchange attempt. However, any access tokens already issued before revocation remain valid until they expire (typically 1 hour). CAE-capable applications receive near-real-time revocation signals, but non-CAE apps use the full 1-hour token lifetime. Immediate password change plus session revocation is the complete response.
Which MSAL token cache locations should I protect against infostealer access?
On Windows: the MSAL token cache for desktop applications is stored in %LocalAppData%\Microsoft\TokenBroker\Cache (for broker-managed tokens) and in %AppData%\Microsoft\Identity (for app-specific caches). Office and Teams use the Windows Credential Manager (accessible via cmdkey /list and credential vault files in %AppData%\Microsoft\Credentials). Browser-based tokens in Edge and Chrome are stored in encrypted browser profile directories. Infostealers target all these locations. Protections: enable Credential Guard to protect Credential Manager entries, configure Attack Surface Reduction rules to block credential access, and use Microsoft Defender for Endpoint's 'Block credential stealing from the Windows local security authority subsystem' behavioral rule.
How does Family of Client IDs (FOCI) work and which Microsoft applications share refresh tokens within the same family?
Family of Client IDs (FOCI) is a Microsoft OAuth implementation where certain first-party Microsoft applications share refresh tokens. When a user authenticates with one FOCI application (such as Microsoft Teams mobile), the refresh token issued is marked with a family ID. Any other application in the same FOCI family can use that refresh token to obtain an access token for any resource the user has access to, without requiring the user to re-authenticate or approve. The practical consequence: an attacker who extracts a Teams mobile refresh token (from device backup, token cache, or infostealer output) can use it to acquire an Outlook, SharePoint, or other Microsoft 365 access token directly. Known FOCI members include the Microsoft Office mobile applications, Teams, OneDrive, and Azure CLI among others. Detection: a refresh token redemption by an application client ID that does not match the application the user originally authenticated with -- check the appId field in non-interactive sign-in logs against the original interactive sign-in's appId. Mitigation: Conditional Access Token Protection (where supported) binds tokens to the original device, making extracted FOCI tokens non-transferable to attacker infrastructure.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.