Under the Hood: How Brokered Authentication Works on iOS & Android

Section 1: Introduction

Who This Is For

This blog is written for Level 300+ IT admins, endpoint engineers, and identity architects who already understand the basics of Microsoft Intune, Conditional Access, and Entra ID. If you’re here, you’ve likely deployed Intune, configured Conditional Access policies, and pushed Authenticator or Company Portal to devices — but you’ve also hit that moment where authentication behavior on a mobile device doesn’t match what you expected, and you’re not sure which app is doing what.

The Core Problem: One Concept, Two Platforms, Completely Different Behavior

One of the most commonly asked questions in the Intune community is deceptively simple: “Is Microsoft Authenticator or Company Portal the broker?” The answer isn’t a single app — it depends on the platform, and more importantly, it depends on what we mean by “broker.”

The reason this is so confusing is that iOS and Android handle brokered authentication in fundamentally different ways — not because Microsoft chose to build them differently, but because the underlying operating systems forced it.

iOS: The Sandboxing Constraint

Apple enforces strict app sandboxing on iOS. Every app runs in its own isolated container. Apps cannot directly share data, tokens, or runtime state with each other. There is no equivalent of Android’s AccountManager or Intent system that allows apps to freely pass authentication context between themselves.

This creates a hard architectural constraint: on iOS, token sharing between apps from different publishers can only happen through two mechanisms — a shared Keychain access group (limited to apps from the same Apple Developer account, using the com.microsoft.adalcache group) or a designated broker app that acts as a centralized token intermediary.

Because of this, iOS mandates a single designated authentication broker — Microsoft Authenticator. It is the only app on iOS that MSAL (Microsoft Authentication Library) recognizes for brokered token acquisition across apps from different vendors. Company Portal on iOS does not perform authentication brokering — its role is device registration, enrollment validation, and compliance attestation.

This is why, when you see a redirect to Company Portal on iOS during authentication, it’s not acting as the auth broker — it’s being called to evaluate device compliance for a Conditional Access policy. The authentication itself already happened (or is happening) through Authenticator.

Android: The Open Broker Model

Android’s architecture is fundamentally different. Apps can communicate through Intents, Bound Services, and the system-level AccountManager API. This means multiple apps can technically act as authentication brokers.

On Android, MSAL recognizes three broker-capable apps: Microsoft Authenticator, Intune Company Portal, and Link to Windows. When multiple broker apps are installed, MSAL automatically identifies the active broker — historically defaulting to whichever was installed first, though recent MSAL versions handle broker selection more intelligently.

This open model means Android admins face a different set of challenges: broker priority conflicts, Work Profile isolation affecting broker communication, and enrollment-type-dependent behavior that changes which app handles what.

What This Blog Covers

This is not a setup guide. We won’t walk through “how to configure email on iOS.” Instead, we’ll go deep into:

• How MSAL discovers and communicates with brokers on each platform
• The exact token acquisition flow on iOS vs Android, and why they differ
• How Conditional Access policies interact with the broker and compliance layers
• The role of Apple’s Enterprise SSO Extension and how it changes the broker equation
• Real log analysis

Section 2: MSAL & the Broker Architecture

What MSAL Actually Does

Before we talk about brokers, we need to understand MSAL — the Microsoft Authentication Library. MSAL is the SDK that app developers integrate into their applications to acquire security tokens from Microsoft Entra ID. When you open Outlook on your iPhone or Teams on your Android device, the app doesn’t handle the OAuth 2.0 token acquisition flow by itself. It delegates that to MSAL, which in turn decides how to get that token — either by handling it locally (embedded webview, system browser) or by handing off to a broker app.

Think of MSAL as the decision engine. The app says “I need an access token for Microsoft Graph.” MSAL then determines: Is there a valid cached token? Can I silently refresh it? Do I need user interaction? And critically — is there a broker app installed that I should route this through?

The standard MSAL token acquisition pattern follows three steps:

1. Try silent acquisition first — Check the local token cache for a valid access token or use a cached refresh token to get a new one without user interaction.
2. If silent fails, go interactive — Present the user with a sign-in experience, either through a system browser, embedded webview, or broker app.
3. Cache the result — Store the acquired tokens for future silent acquisition.

Where brokers change the game is step 2 (and to some extent, step 1). When a broker is present and configured, MSAL routes token requests through the broker instead of handling them directly. This shifts the token cache, the SSO state, and the Conditional Access evaluation into the broker’s domain.

What Is a Broker, Really?

An authentication broker is a separate application on the device that acts as a centralized intermediary for identity operations. Instead of every app independently managing its own authentication flow, apps delegate to the broker, which provides:

• Device-wide SSO — The user signs in once through the broker, and that session is shared across all MSAL-integrated apps. Without a broker, SSO is limited to apps from the same publisher sharing a keychain group (iOS) or apps using the same system browser session.
• Device identification — The broker manages the device certificate created during Workplace Join or Entra ID registration. This is what allows Conditional Access policies to evaluate whether a request is coming from a “known” or “compliant” device.
• Application identity verification — The broker validates that the calling app is legitimate by verifying its redirect URI and signature against the app registration in Entra ID.
• Token binding — Tokens acquired through a broker can be bound to the device, meaning they can’t be exported and replayed from another device. This is a security property that browser-based flows can’t provide on their own.

How MSAL Discovers the Broker — iOS vs Android

This is where the platform divergence begins.

iOS Broker Discovery:

On iOS, MSAL uses the canOpenURL: API to check whether a broker app is installed. Specifically, it queries for the URL schemes msauthv2 and msauthv3. These schemes must be declared in the calling app’s Info.plist under LSApplicationQueriesSchemes — this is an Apple requirement since iOS 9, where Apple locked down which URL schemes an app can query.

If MSAL detects that a broker (Authenticator) is installed, it routes the authentication request through a URL scheme-based handoff. The broker processes the request, authenticates the user, and calls back to the originating app via the registered redirect URI (msauth.<bundle.id>://auth). The originating app’s AppDelegate intercepts this callback via the openURLmethod and passes it back to MSAL to complete the flow.

Key constraint: Because iOS sandboxing prevents apps from directly sharing tokens or state, the broker becomes the onlyway to achieve cross-publisher SSO. Apps from the same Apple Developer account can share tokens via the shared keychain (com.microsoft.adalcache), but apps from different publishers — say, a third-party LOB app and Microsoft Outlook — can only share SSO state through the broker.

On iOS, only Microsoft Authenticator acts as the MSAL authentication broker. Company Portal does not participate in MSAL token brokering.

Android Broker Discovery:

Android’s broker discovery is more complex because multiple apps can serve as brokers. MSAL for Android communicates with the broker through Android’s Bound Service mechanism. If binding to the service fails, MSAL falls back to the AccountManager API (which requires the READ_CONTACTS permission).

Three apps can host the Microsoft Authentication Broker component on Android: Microsoft Authenticator, Intune Company Portal, and Link to Windows. When multiple broker-capable apps are installed, MSAL automatically identifies the active broker. In earlier MSAL versions, the first broker app installed would take precedence — so if you installed Authenticator before Company Portal, Authenticator would remain the active broker. Recent MSAL versions handle this selection more intelligently.

Unlike iOS, Android’s open inter-process communication model (Intents, Bound Services, Content Providers, AccountManager) means the broker can function as a true system-level component. The broker creates a “Work account” entry visible in Android’s device Settings, manages token storage centrally, and broadcasts account change events that other apps can listen for.

The SSO Extension — iOS’s Other Broker

There’s a third player on iOS that doesn’t quite fit the traditional broker model: the Apple Enterprise SSO Extension. Deployed via an MDM configuration profile, the SSO Extension intercepts authentication requests at the OS level beforethey hit the traditional MSAL broker flow.

The SSO Extension comes in two types — Redirect and Kerberos. The Redirect type (which is what Microsoft’s implementation uses) intercepts HTTP authentication challenges to configured URLs and routes them through the extension, which lives inside the Authenticator app but operates as a system-level extension.

This means on a fully configured iOS device, you effectively have two layers:

1. SSO Extension — Intercepts auth requests from any app (including those that don’t use MSAL) at the OS level
2. MSAL Broker — Handles token acquisition for MSAL-integrated apps through Authenticator

We’ll go deep into the SSO Extension in Section 6, but it’s important to understand now that it changes the broker equation significantly — it can provide SSO to apps that were never built to support MSAL brokering.

Primary vs Fallback Behavior

What happens when the broker isn’t available?

On iOS, if Authenticator isn’t installed, MSAL falls back to the system browser (Safari via ASWebAuthenticationSession) for interactive authentication. This provides limited SSO through shared browser cookies but loses device identification, token binding, and seamless Conditional Access support. If the app is configured to require brokered auth (e.g., for Conditional Access requiring a compliant device), the flow will fail and prompt the user to install Authenticator.

On Android, if no broker app is installed, MSAL similarly falls back to the system browser. However, the redirect URI configured for broker mode won’t work with the browser directly — you’d need an Intent filter configured in the app manifest to handle the broker redirect URI in the browser fallback scenario. If Conditional Access policies require a managed device, MSAL will prompt the user to install a broker app.

In both cases, the message is clear: for enterprise environments with Conditional Access, the broker isn’t optional — it’s required infrastructure.

Section 3: iOS/iPadOS — Deep Dive

The Broker on iOS: Microsoft Authenticator

On iOS, Microsoft Authenticator is the sole authentication broker. This isn’t a design preference — it’s an architectural necessity driven by Apple’s sandboxing model. Let’s walk through exactly what happens when an MSAL-integrated app requests a token on iOS.

Device Registration & the Foundation of Trust

Before brokered authentication can work, the device needs to establish an identity with Entra ID. This happens during device registration (Workplace Join or Entra ID registration), and it’s the critical foundation everything else builds on.

During registration, two cryptographic key pairs are generated:

1. Device key (dkpub/dkpriv) — Used to identify the device itself
2. Transport key (tkpub/tkpriv) — Used to decrypt the session key that protects the PRT

On iOS, the private keys are generated and stored in the Secure Enclave — Apple’s hardware-isolated security processor. The public keys are sent to Entra ID during registration. This is what makes the device “known” to Entra ID and is the prerequisite for everything that follows: PRT issuance, Conditional Access device claims, and compliance evaluation.

The Authenticator app manages this entire registration process on iOS. When you see “Register your device” in Authenticator, this is what’s happening under the hood — key generation in the Secure Enclave, public key exchange with Entra ID, and establishment of the device identity.

The Primary Refresh Token (PRT) — The Real SSO Enabler

The PRT is arguably the most important artifact in the entire broker flow, and it’s frequently misunderstood.

A PRT is a JSON Web Token (JWT) issued by Entra ID exclusively to Microsoft first-party token brokers. It is not a regular refresh token — it’s a device-bound, multi-resource token that enables SSO across all MSAL-integrated apps on the device.

Key characteristics of the PRT on iOS:

• Only registered devices can get a PRT. No device registration = no PRT = no device-wide SSO.
• It’s valid for 90 days and is renewed every 4 hours during active use. On iOS specifically, there’s also an opportunistic renewal when the device is charging, occurring no more than once every two days (subject to iOS resource allocation).
• It’s only issued and renewed during native app authentication — not during browser sessions.
• It carries device and user claims — including the device ID, compliance state, and MFA claim. These claims are what Conditional Access evaluates.
• The private keys protecting it are bound to the Secure Enclave — making PRT theft extremely difficult on iOS compared to platforms without hardware-backed key storage.

Here’s the critical connection: when an MSAL-integrated app (say, Teams) needs an access token, it doesn’t go directly to Entra ID. It asks the broker (Authenticator), which uses the PRT to silently request an access token for the specific resource. Entra ID validates the PRT, evaluates Conditional Access policies using the device and user claims embedded in the PRT, and returns the resource-specific access token. The user never sees a login prompt — that’s SSO.

Token Acquisition Flow — Step by Step

Here’s what actually happens when an MSAL-integrated app requests a token on a registered, compliant iOS device:

1. App calls MSAL’s acquireTokenSilent — MSAL first checks its local token cache. If a valid access token exists, it’s returned immediately. No broker involved.
2. Cache miss → Broker handoff — If no valid token exists (expired, wrong scope, etc.), MSAL checks for the broker. On iOS, it calls canOpenURL: with the msauthv2/msauthv3 URL schemes to detect Authenticator.
3. URL scheme-based IPC — MSAL constructs a token request and opens Authenticator via its URL scheme. Because iOS sandboxing prevents direct IPC, this URL scheme mechanism is the only way apps from different publishers can communicate.
4. Authenticator processes the request — The broker validates the calling app’s identity (redirect URI, bundle ID signature), retrieves the PRT from the Secure Enclave-protected keychain, and constructs a token request to Entra ID.
5. Entra ID evaluates the request — The token endpoint receives the PRT-backed request and evaluates:
   • Is the PRT valid and device-bound?
   • Does the user have a valid session?
   • Do any Conditional Access policies apply?
   • If CA requires device compliance → Entra ID checks the device’s compliance state (reported by Intune via Company Portal)
   • If CA requires MFA → Does the PRT carry an MFA claim?
6. Token issued → Callback — Entra ID returns the access token (and potentially a new refresh token). Authenticator passes this back to the calling app via the registered redirect URI (msauth.<bundle.id>://auth). The app’s AppDelegate intercepts the callback via openURL and hands it to MSAL.
7. MSAL caches the token — The access token is cached locally for future silent acquisition.

Where Company Portal Fits — The Compliance Broker

This is where the confusion starts. Company Portal on iOS is not an authentication broker. It doesn’t participate in MSAL token acquisition. But it plays a critical role that’s adjacent to authentication: compliance attestation.

When you have a Conditional Access policy that requires “device compliance” or “require device to be marked as compliant,” here’s what happens:

• Intune evaluates whether the device meets your compliance policies (OS version, encryption, jailbreak detection, etc.)
• Company Portal is the Intune management agent on iOS that reports device state back to Intune
• Intune syncs the compliance state to Entra ID
• When the broker (Authenticator) presents the PRT to Entra ID, Entra ID checks this compliance state as part of CA evaluation

So Company Portal’s involvement is indirect — it feeds the compliance signal that Entra ID evaluates during the broker flow. The redirect to Company Portal that users sometimes see isn’t authentication brokering — it’s Intune prompting the user to complete enrollment, install required profiles, or remediate a compliance issue that’s blocking the CA policy.

Device Attestation — The Hardware Trust Layer

This is where things get really interesting and is increasingly critical for zero trust architectures.

Apple introduced Managed Device Attestation (MDA) in iOS 16 / iPadOS 16.1. This leverages the Secure Enclave to cryptographically prove to Apple’s attestation servers that:

• The device hardware is genuine (not a virtual machine or emulator)
• The device is actually managed by an MDM
• The OS integrity is intact (not jailbroken or tampered with)
• The device identity (serial number, UDID) is legitimate

How does this connect to the broker flow? In two ways:

1. MDM-Level Attestation (DeviceInformation command): The MDM server (Intune) can issue a DeviceInformationquery with attestation keys. The device contacts Apple’s attestation servers, and the response — signed by Apple’s Enterprise Attestation Root CA — is returned to Intune. Intune uses this to verify device authenticity, which feeds into the compliance state that ultimately affects Conditional Access evaluation during broker-mediated authentication.

2. ACME Certificate Attestation: Intune now supports the ACME protocol (replacing SCEP) for certificate issuance on Apple devices. During ACME enrollment, the device generates a hardware-bound private key in the Secure Enclave and requests attestation from Apple. The resulting certificate is cryptographically proven to be on a genuine, managed device. These ACME certificates are more tamper-resistant than SCEP certificates because the private key physically cannot be extracted from the Secure Enclave.

Microsoft announced Intune support for ACME and MDA. The MDM enrollment certificate itself can now be hardware-bound via the Secure Enclave, meaning it survives neither backup/restore nor device wipe — providing strong anti-spoofing protection.

So the trust chain looks like this:

Secure Enclave → Apple Attestation Servers → Intune (via MDA/ACME) → Compliance State → Entra ID → Conditional Access evaluation during PRT-based token acquisition through Authenticator broker

Device attestation doesn’t replace the broker — it strengthens the entire chain by providing hardware-rooted proof that the device presenting the PRT is actually the device it claims to be.

MDM Enrolled vs MAM-Only — Different Broker Paths

The broker behavior changes significantly depending on the enrollment type:

MDM Enrolled (Fully Managed / Supervised):

• Device is registered with Entra ID during enrollment
• PRT is issued and managed by Authenticator
• Company Portal reports full compliance state to Intune
• Conditional Access has full device claims (compliant, managed, device ID)
• SSO Extension (if deployed) provides OS-level SSO for all apps
• Device attestation (MDA/ACME) is available

MAM-Only (App Protection without enrollment):

• Device may or may not be registered with Entra ID
• Authenticator still acts as broker, but the PRT may lack device compliance claims
• Company Portal is required on the device but functions as a “broker plugin” for MAM policies — it doesn’t report MDM compliance
• App Protection Policies are enforced at the app layer, not the device layer
• Conditional Access policies requiring “compliant device” will fail because there’s no MDM compliance state
• CA policies requiring “approved client app” or “app protection policy” will work

This is one of the most common misconfigurations: setting a CA policy to require device compliance on a MAM-only enrolled device. The authentication through Authenticator succeeds, but the CA evaluation fails because there’s no compliance signal — and the admin sees a confusing “non-compliant device” error in Entra sign-in logs even though no compliance policy was ever evaluated.

App Protection Policy Broker Behavior

App Protection Policies (APP) add another layer of complexity. When an app is protected by an APP policy:

• The app must use MSAL for authentication (or be wrapped with the Intune App SDK)
• The Intune App SDK checks for the presence of a broker (Authenticator on iOS)
• If the user isn’t registered, Authenticator will prompt for Entra ID registration
• The APP policy is delivered after authentication, based on the user’s identity
• APP-managed data (cut/copy/paste restrictions, encryption, etc.) is enforced independently of device compliance

The key distinction: APP policies are user/app-level controls evaluated after broker authentication, while compliance policies are device-level controls evaluated during CA as part of the broker flow. They’re complementary but operate at different layers.

Section 4: Android — Deep Dive

The Multi-Broker Model

Android’s authentication broker architecture is fundamentally different from iOS, and it stems from a key platform difference: Android allows inter-app communication. Apps can talk to each other through Bound Services, Intents, Content Providers, and the system-level AccountManager API. This means Android doesn’t need a single designated broker — multiple apps can host the broker component.

On Android, three apps can act as the Microsoft Authentication Broker:

1. Microsoft Authenticator
2. Intune Company Portal
3. Link to Windows

All three ship with the same embedded broker component. From MSAL’s perspective, they’re functionally equivalent as brokers — the difference is in what else they do (MFA, device management, Windows linking).

Broker Discovery and Priority on Android

When an MSAL-integrated app needs a token, here’s how MSAL finds and communicates with the broker:

Step 1: Bound Service (preferred) MSAL first attempts to communicate with the broker via Android’s Bound Service mechanism. This is the preferred path because it doesn’t require any special Android permissions. MSAL binds to the broker’s authentication service and communicates directly.

Step 2: AccountManager (fallback) If the Bound Service connection fails (which can happen due to battery optimization killing the broker app, or certain enterprise configurations restricting service binding), MSAL falls back to the Android AccountManager API. This fallback requires the READ_CONTACTS permission — which is why some apps display a confusing “allow access to contacts?” prompt during authentication. The app isn’t actually reading contacts; it needs the permission to access AccountManager.

If you see the error BROKER_BIND_FAILURE, it means both paths failed. The two most common fixes: disable battery/power optimization for the broker app, or grant the READ_CONTACTS permission.

Step 3: Multiple brokers installed — who wins? When more than one broker-capable app is installed, MSAL needs to pick one. In older MSAL versions, the rule was simple: the first broker installed on the device wins. If you installed Authenticator before Company Portal, Authenticator would remain the active broker even after CP was installed. In recent MSAL versions, the library identifies the active broker more intelligently on its own. However, this historical behavior is still the source of many troubleshooting headaches — particularly when an admin pushes Company Portal during enrollment and Authenticator is installed later by the user.

How Android Broker Authentication Differs from iOS

The core flow is similar (app → MSAL → broker → Entra ID → token), but the mechanics are different:

• IPC mechanism: On iOS, it’s URL scheme-based (msauthv2/msauthv3) — a one-way open-and-callback pattern. On Android, it’s Bound Service or AccountManager — a direct two-way communication channel. This makes Android broker communication faster and more reliable.
• Token storage: On iOS, the broker stores tokens in the shared Keychain (com.microsoft.adalcache). On Android, the broker creates a “Work account” entry in the system’s AccountManager of type com.microsoft.workaccount. This account is visible in the device’s Settings → Accounts, which gives both users and admins a direct way to verify broker registration is working.
• PRT behavior: PRTs work the same conceptually — the broker acquires and manages the PRT, which enables device-wide SSO. But on Android, the PRT renewal is more straightforward since the broker can maintain a persistent service. On iOS, PRT renewal is subject to iOS’s aggressive background execution limits (opportunistic updates while charging, no more than once every two days).
• Device certificate: On both platforms, the broker manages the device certificate created during Workplace Join / Entra ID registration. On Android, this certificate is stored in the Android Keystore (hardware-backed on devices with a TEE or StrongBox). The private key, like on iOS’s Secure Enclave, doesn’t leave the hardware.

Enrollment Types and Their Impact on Broker Behavior

This is where Android gets significantly more complex than iOS. Android Enterprise offers four main enrollment types, and each one changes how the broker operates.

1. Personally-Owned Work Profile (BYOD)

This is the most common BYOD scenario. A Work Profile is created as an isolated container on the user’s personal device.

Broker implications:

• Company Portal is installed inside the Work Profile during enrollment
• The broker operates within the Work Profile container — it cannot access or manage apps in the personal profile
• SSO through the broker only extends to apps inside the Work Profile
• Personal profile apps authenticate independently (no broker SSO)
• If the user installs Authenticator in their personal profile, it’s a completely separate instance from the one in the Work Profile — they don’t share tokens or state
• The device is registered with Entra ID, but compliance evaluation only covers the Work Profile

This Work Profile isolation is one of the biggest sources of confusion. Users who install Authenticator personally and then set up a Work Profile often wonder why they’re prompted to sign in again — it’s because the personal-side Authenticator and the Work Profile Authenticator are sandboxed from each other.

2. Corporate-Owned, Fully Managed (COBO)

The entire device is managed. No personal/work separation — everything is corporate.

Broker implications:

• Microsoft Authenticator is automatically installed during enrollment and cannot be uninstalled
• The broker operates device-wide with no container boundaries
• SSO extends to all apps on the device
• Full device compliance is evaluated and reported
• Conditional Access has complete device claims
• Single broker instance, no ambiguity

This is the simplest broker scenario on Android.

3. Corporate-Owned, Personally Enabled (COPE)

The device is corporate-owned but has both a Work Profile (managed) and a personal profile (user’s space).

Broker implications:

• Similar to BYOD Work Profile, but with more device-level control
• The broker runs inside the Work Profile
• SSO is contained within the Work Profile
• Admins have more control over the personal profile (can enforce restrictions, wipe the device) but the broker boundary is still the Work Profile
• From a broker perspective, COPE behaves very similarly to BYOD Work Profile for authentication — the key differences are in what device-level policies admins can enforce

4. Dedicated Devices (COSU — Corporate-Owned, Single Use)

Kiosk or shared-use devices. Typically no individual user affinity.

Broker implications:

• The Microsoft Intune app is automatically installed during enrollment
• For Shared Device Mode (Entra ID shared mode), Microsoft Authenticator is automatically installed and configured
• Shared Device Mode enables a global sign-in/sign-out — when a user signs out, all tokens, accounts, and cached data across all participating apps are cleared
• The broker handles the single-account constraint — only one account can be signed in at a time
• Apps must be built to support Shared Device Mode (using SingleAccountPublicClientApplication in MSAL)

Device Attestation on Android

Android has its own attestation mechanisms that parallel Apple’s MDA:

Hardware Key Attestation: Android devices with a hardware-backed Keystore (TEE or StrongBox) support key attestation. During device registration, the broker can generate attestation-backed keys that prove the private key was generated inside secure hardware. This is similar to iOS’s Secure Enclave-based key generation.

Play Integrity API (formerly SafetyNet): Google’s Play Integrity API provides device-level integrity signals — is the device genuine? Is the bootloader locked? Is Google Play Services legitimate? Intune leverages these signals as part of compliance evaluation. A device that fails Play Integrity (rooted, custom ROM, etc.) can be flagged non-compliant, which feeds into Conditional Access.

Android’s attestation chain for broker-mediated auth: Hardware Keystore → Key Attestation / Play Integrity → Intune Compliance → Entra ID → Conditional Access evaluation during PRT-based token acquisition through broker

The end result is the same as iOS — hardware-rooted trust signals flow through the compliance pipeline and ultimately influence whether the broker can successfully obtain tokens under Conditional Access policies. The main difference is that Android’s attestation relies on Google’s infrastructure (Play Integrity, hardware attestation) while iOS relies on Apple’s (Secure Enclave, Apple Attestation Servers, ACME).

MAM-Only on Android — The Company Portal Difference

Here’s an important Android-specific nuance: on Android, Company Portal is the required broker for MAM-only (App Protection without enrollment) scenarios. This differs from iOS where Authenticator is always the broker.

In a MAM-only scenario on Android:

• Company Portal must be installed (even without MDM enrollment)
• CP acts as the broker for MAM-protected apps
• The device gets registered with Entra ID (Workplace Join) through CP
• App Protection Policies are delivered after broker authentication
• There’s no device compliance — CA policies requiring compliance will fail
• CA policies requiring “app protection policy” will work

The same misconfiguration trap from iOS applies: if you require device compliance in CA for MAM-only Android devices, authentication will succeed but CA will block access.

Common Android-Specific Broker Issues

A few scenarios that are unique to Android:

• Battery optimization killing the broker: Android aggressively kills background services to save battery. If the broker app is killed, MSAL’s Bound Service connection fails, triggering the AccountManager fallback (or outright failure). Fix: exempt the broker app from battery optimization.
• Work Profile blocking AccountManager: Some enterprise configurations use the “Add and remove accounts” restriction to prevent users from adding personal accounts into the Work Profile. This can inadvertently block MSAL’s AccountManager fallback, causing BROKER_BIND_FAILURE errors. The broker only adds accounts of type com.microsoft.workaccount, but the blanket restriction blocks all account types.

• Broker priority after OS upgrade: Major Android OS upgrades can sometimes reset or change the active broker, especially if app data is migrated differently. If SSO breaks after an OS upgrade, check which broker is active by looking at the Work Account in Settings → Accounts.
• Dual Authenticator instances in Work Profile: As mentioned, the personal-side Authenticator and Work Profile Authenticator are entirely separate. Users who set up MFA in their personal Authenticator and then expect it to work in the Work Profile will be confused. The MFA registration needs to exist in the Work Profile instance of Authenticator.

Section 5: Conditional Access — Under the Hood

Why This Section Matters for Broker Understanding

Conditional Access (CA) is where the broker flow and compliance flow converge. Most “broker confusion” scenarios — like the redirect to Company Portal on iOS, or authentication succeeding but access being blocked — stem from not understanding when and how CA evaluates claims during the broker-mediated token flow. This section explains the mechanics.

The Token Issuance Flow With Conditional Access

When a broker presents a PRT to Entra ID and requests an access token for a resource (e.g., Exchange Online), the token endpoint doesn’t just blindly issue a token. It runs the request through the CA engine first. Here’s the evaluation sequence:

1. Identity evaluation — Who is the user? Which tenant? Is the account enabled?
2. Signal collection — Entra ID gathers signals from the incoming request:
   • Device ID and device state (from the PRT’s device claims)
   • Compliance state (synced from Intune to Entra ID)
   • User risk level (from Entra ID Protection)
   • Sign-in risk level
   • Network location / IP address
   • Client app type (modern auth, legacy, browser)
   • Application being accessed
3. Policy matching — Which CA policies apply to this user + app + condition combination?
4. Grant control evaluation — Does the request satisfy the required controls?
5. Session control evaluation — Should any session restrictions apply?
6. Token issuance or denial — Access token is issued, or an error (typically AADSTS53003) is returned.

The critical detail: the device compliance claim is not generated by the broker. The broker (Authenticator/CP) presents the PRT which contains the device ID. Entra ID then looks up that device ID in its directory and checks whether Intune has marked it as compliant. The compliance signal flows from the device → Company Portal → Intune → Entra ID, entirely separate from the authentication flow. The broker just provides the device identity that allows Entra ID to perform the lookup.

Grant Controls and Their Broker Implications

Each grant control interacts differently with the broker flow. Understanding these interactions is key to troubleshooting.

“Require multifactor authentication”

When the PRT was originally acquired with MFA (the user completed MFA during initial device registration or sign-in), the PRT carries an MFA claim. Entra ID sees this claim and satisfies the MFA requirement without prompting the user again — this is why MFA feels “invisible” on managed devices with a broker. If the PRT doesn’t carry an MFA claim, the user gets an MFA interrupt.

Important: the MFA claim on the PRT is set during PRT acquisition. If you enable an MFA-requiring CA policy after the user already has a PRT without MFA, the PRT won’t satisfy the requirement until the user re-authenticates with MFA and a new PRT is issued.

CA evaluates grant controls in a specific order: MFA first, then Device State, then Terms of Use. If MFA fails, you’ll see the “interrupt” in sign-in logs even if the other controls would have passed.

“Require device to be marked as compliant”

This is the grant control that triggers the most confusion with brokers. Here’s exactly what happens:

• The broker presents the PRT containing the device ID
• Entra ID checks: Is this device ID registered? → If no, fail with “device not registered”
• Entra ID checks: Does Intune report this device as compliant? → If no, fail with “device not compliant”
• The compliance state is evaluated at the time of token request, not cached in the PRT

This is why you sometimes see: “Authenticator signed in fine, but then it sent me to Company Portal.” The authentication succeeded (broker worked), but the CA compliance check failed, and the user is being redirected to CP to remediate the compliance issue (install a required profile, update OS version, etc.).

Important exceptions: The “require compliance” control doesn’t block Intune enrollment itself, and it doesn’t block Microsoft Authenticator from accessing the UserAuthenticationMethod.Read scope needed for registration. This prevents a chicken-and-egg problem where you can’t register because you’re not compliant, and you can’t become compliant because you can’t register.

“Require approved client app”

This control validates whether the app making the request is on Microsoft’s approved client app list. The broker isn’t directly involved in this evaluation — Entra ID checks the app ID against the approved list. However, the broker is needed because this control requires device registration, and the broker manages registration.

“Require app protection policy”

This verifies that the Intune App SDK has reported an active App Protection Policy for the requesting app/user combination. The flow is: app authenticates via broker → Intune SDK checks in with Intune service → Intune confirms APP is applied → Entra ID evaluates the control.

This control works on MAM-only devices (no MDM enrollment required), making it the preferred approach for BYOD scenarios. But the broker (Authenticator on iOS, CP on Android) must still be present for device registration.

“Require Microsoft Entra hybrid joined device”

This only applies to Windows devices (domain-joined + Entra ID registered). It doesn’t apply to iOS or Android and won’t be evaluated for mobile broker flows.

Compliant vs. Managed vs. App-Protected — Different Claims, Different Paths

One of the most important distinctions for mobile admins:

• Compliant = MDM enrolled + passes all compliance policies → Requires full MDM enrollment, Company Portal reporting compliance to Intune, Intune syncing to Entra ID. The broker provides device identity; compliance is evaluated server-side.
• Managed = Device is registered with Entra ID (Workplace Join or Entra ID Join) → The broker handles this during registration. A device can be managed (registered) but not compliant (doesn’t meet compliance policies).
• App-protected = App Protection Policy is applied to the user/app → Doesn’t require MDM. Requires broker for device registration, plus Intune App SDK in the app. Evaluated independently of device compliance.

These three states can overlap or be independent. A MAM-only device is managed (registered) and possibly app-protected, but never compliant (no MDM). A fully enrolled device can be all three. A CA policy requiring compliance will block MAM-only devices even though the broker authentication succeeds perfectly.

Session Controls and the Broker

Session controls don’t block access — they modify how the session behaves after access is granted.

Sign-in Frequency (SIF): Forces re-authentication at a defined interval. When SIF is configured, the broker’s PRT-based silent SSO is interrupted at the specified interval, and the user must re-authenticate interactively. The PRT itself isn’t invalidated — it’s the session lifetime that’s being restricted.

Persistent Browser Session: Controls whether browser sessions persist after closing the browser. This doesn’t directly affect the broker on mobile (it’s more relevant for web-based sign-ins), but it can impact apps that fall back to browser-based auth when the broker is unavailable.

Continuous Access Evaluation (CAE): CAE is where the broker lifecycle gets interesting. Traditional token flow: broker gets an access token, token is valid for 60-90 minutes, no further evaluation until expiry. With CAE, the model changes fundamentally:

• Access tokens for CAE-enabled resources (Exchange, Teams, SharePoint, Graph) can have lifetimes up to 28 hours
• The resource provider (e.g., Exchange Online) continuously evaluates whether the token should still be honored
• If a critical event occurs (password change, account disabled, admin revokes sessions, high user risk detected, network location violation), the resource provider sends a 401 + claims challenge back to the client
• The MSAL-integrated client (which declared the CP1 capability) recognizes this challenge, bypasses its token cache, and requests a new token from Entra ID via the broker
• Entra ID re-evaluates all conditions with the new context and either issues a fresh token or blocks access

For mobile broker flows, CAE means:

• Tokens last much longer (up to 28 hours) under normal conditions — fewer interruptions
• But security events trigger near-real-time revocation — the broker handles the re-authentication seamlessly
• The broker’s PRT is the key — when the client receives a CAE claims challenge, it uses the PRT to acquire a fresh access token. If the PRT itself is invalid (user’s password changed, account disabled), the user gets prompted to sign in again

Critical events that trigger CAE evaluation include user account disabled/deleted, password change/reset, MFA enabled, admin revocation of all refresh tokens, and high user risk detection. IP-based policy enforcement is instant; other events may have up to 15 minutes of propagation latency.

Token Protection — Device-Bound Tokens

Token Protection (in preview/GA progression) adds another layer where the broker is essential. When Token Protection is enabled in a CA policy:

• Access tokens are cryptographically bound to the device that requested them
• The broker is responsible for generating the proof-of-possession (PoP) key during token acquisition
• If a token is exfiltrated and used from a different device, the resource provider rejects it because the PoP proof doesn’t match
• This directly ties into the PRT — since the PRT is already device-bound (private key in Secure Enclave/Keystore), Token Protection extends this binding to individual access tokens

For enterprise admins, Token Protection is the ultimate answer to token theft attacks — but it requires the broker to be present and functioning correctly, because without the broker there’s no hardware-backed key to bind to.

The Most Common CA + Broker Misconfiguration

To tie it all together, here’s the single most common scenario that generates confusion and support tickets:

Scenario: Admin creates a CA policy requiring “device compliance” for all cloud apps, targeting all users. A user with a personal (MAM-only) device installs Outlook, signs in successfully through the broker, then gets blocked.

What happened:

1. User opens Outlook → MSAL contacts broker (Authenticator on iOS, CP on Android)
2. Broker presents PRT → Entra ID authenticates successfully
3. CA engine evaluates: policy requires compliance
4. Entra ID looks up device ID → device is registered (managed) but NOT enrolled in MDM
5. No compliance state exists → CA returns AADSTS53003: Access blocked
6. User sees: “Your device doesn’t meet compliance requirements” or gets redirected to Company Portal

The fix: Either enroll the device in MDM (so compliance can be evaluated), or change the CA policy to use “require app protection policy” instead of “require compliance” for BYOD scenarios.

This scenario plays out identically on both iOS and Android, and it’s the #1 reason admins think “the broker is broken” when it’s actually working perfectly — the authentication succeeded, it’s the CA policy that’s blocking access.

Section 6: Enterprise SSO Extension (iOS Specific)

What the SSO Extension Actually Is

The Enterprise SSO Extension is often confused with the broker, but it operates at a completely different layer. Here’s the distinction:

• MSAL Broker (Authenticator): Handles token acquisition for apps that integrate MSAL. The app explicitly calls MSAL, which routes to the broker. This is an app-level integration.
• Enterprise SSO Extension: Intercepts authentication requests at the OS level through Apple’s Extensible SSO framework. It works transparently — the app doesn’t need to know about it. This is a system-level integration deployed via MDM.

The Enterprise SSO Extension lives inside the Authenticator app on iOS (and inside Company Portal on macOS), but it’s activated separately through an MDM configuration profile. Simply installing Authenticator doesn’t enable the SSO Extension — the MDM must push the configuration.

This is a critical requirement from Apple: the SSO Extension can only be activated on MDM-enrolled devices through a deployed configuration profile. MAM-only / BYOD-without-enrollment devices cannot use it.

Redirect Type vs Kerberos Type

Apple’s Extensible SSO framework supports two extension types, and both can run on the same device simultaneously (but require separate configuration profiles):

Redirect Type (Microsoft’s implementation):

• Designed for modern authentication protocols: OAuth 2.0, OpenID Connect, SAML2
• Microsoft’s Enterprise SSO plug-in uses this type
• Intercepts HTTP authentication requests to configured URLs (Microsoft’s identity endpoints like login.microsoftonline.com, login.microsoft.com, etc.)
• Routes intercepted requests through the SSO Extension broker, which uses the PRT to silently authenticate
• This is what provides SSO to apps that don’t use MSAL

Kerberos Type (Apple’s built-in):

• Designed for on-premises Active Directory / Kerberos authentication
• Acquires and manages Kerberos TGTs from on-premises AD
• Not for Microsoft Entra ID — requires a traditional on-premises AD domain
• Used for accessing on-premises file shares, intranet websites, and Kerberos-authenticated resources
• On iOS, only activates after receiving an HTTP 401 Negotiate challenge

For Entra ID-based authentication (which is what this blog is about), you want the Redirect type. If you also need on-premises Kerberos SSO (e.g., accessing on-prem SharePoint or file servers), deploy the Kerberos type as a separate profile alongside the Redirect type.

How the SSO Extension Changes the Broker Equation

Without the SSO Extension, SSO on iOS works like this:

• App calls MSAL → MSAL routes to Authenticator broker → Broker uses PRT → Token returned
• Apps that don’t use MSAL get no SSO benefit — each one requires independent sign-in

With the SSO Extension deployed, a second SSO layer exists:

• MSAL apps still use the traditional broker flow (SSO Extension enhances this but doesn’t replace it)
• Non-MSAL apps that use Apple’s native networking stack (like WKWebView, ASWebAuthenticationSession, or URLSession) have their authentication requests intercepted at the OS level
• Safari and other browsers can participate in SSO without any Microsoft SDK integration
• The SSO Extension uses the same PRT that the broker manages, providing a unified SSO experience

This is the game-changer: the SSO Extension extends Entra ID SSO beyond MSAL-integrated apps to any app that authenticates through Apple’s standard networking APIs and targets Microsoft Entra ID endpoints.

The Authentication Flow With SSO Extension

Here’s what happens when a non-MSAL app (e.g., a third-party LOB app using a webview, or Safari opening portal.office.com) triggers authentication on a device with the SSO Extension:

1. The app initiates an authentication request to a Microsoft Entra ID URL (e.g., login.microsoftonline.com)
2. Apple’s networking stack detects the URL matches the SSO Extension’s configured URL list
3. The networking stack redirects the request to the SSO Extension (inside Authenticator)
4. The SSO Extension checks for a valid PRT
5. If PRT exists → Extension silently acquires an access token using the PRT and returns it to the app. No user interaction.
6. If no PRT exists → Extension presents the authentication UI (the “bootstrap” flow). The user signs in, a PRT is acquired, and the token is returned.
7. Subsequent requests from any app to the same URLs are handled silently via the PRT

For MSAL apps, the flow is slightly different — MSAL detects the SSO Extension and routes through it directly, which can be even faster than the traditional URL scheme-based broker handoff.

Key Configuration Options That Affect Broker Behavior

Several SSO Extension configuration keys directly impact how the broker and SSO Extension interact. These are configured in the MDM profile:

browser_sso_interaction_enabled (Key: 1) This is critical for Conditional Access. When enabled, it allows non-MSAL apps (including Safari) to participate in SSO and use the interactive authentication flow. Without this, CA requiring device state information from non-MSAL apps will fail because the app can’t communicate its device identity.

disable_explicit_app_prompt (Key: 1) When apps present their own sign-in UI and pass a prompt=login parameter, the broker normally honors that prompt and shows the sign-in screen. Enabling this key overrides the prompt and uses the account picker from the broker instead, reducing unnecessary sign-in interruptions.

device_registration (Key: provided via the Enable_SSO_On_All_ManagedApps configuration) Enables just-in-time device registration through Authenticator when a user launches an app. If the device isn’t registered yet, the SSO Extension triggers registration before completing the authentication flow.

AppPrefixAllowList Specifies which non-MSAL apps can participate in SSO. For example, adding com.microsoft. allows all Microsoft apps (even those not using MSAL) to use the extension. You can add third-party app bundle IDs to extend SSO to LOB apps.

Interaction Between SSO Extension and Traditional Broker

This is where admins get confused — they’re not competing; they’re complementary:

The SSO Extension doesn’t disable or bypass the traditional broker — it augments it. MSAL apps can use either path, and the SSO Extension generally provides a smoother experience because it avoids the URL scheme-based app switching.

Known Conflicts and Edge Cases

TLS Inspection / Break-and-Inspect Proxies: The SSO Extension requires direct, uninspected connections to Microsoft’s identity endpoints. If your organization uses TLS inspection on corporate networks, the following domains must be excluded from inspection: login.microsoftonline.com, login.microsoft.com, sts.windows.net, and Apple’s associated domain validation endpoints. TLS inspection on these URLs will silently break the SSO Extension — authentication appears to work but SSO fails, and you’ll see certificate validation errors in the Authenticator logs.

SSO Extension + Web Enrollment / JIT Registration: There’s a known issue where Company Portal on iOS can’t recognize an enrolled device when the SSO Extension policy hasn’t been delivered yet. If the SSO Extension profile arrives after Company Portal, CP may fail to detect enrollment status. The recommended deployment order is: enroll device → deploy Authenticator → deploy SSO Extension profile → then deploy Company Portal.

Secure Enclave Key Migration: Microsoft announced a transition from storing Entra ID device registration keys in Apple’s Keychain to the Secure Enclave. New registrations will use Secure Enclave by default. Applications or MDM solutions that accessed device registration keys through Keychain directly will need to update to use MSAL and the Enterprise SSO plug-in. This won’t affect most enterprise deployments, but custom apps that bypassed MSAL and read keys from Keychain will break.

PRT and SSO Extension State Mismatch: If the SSO Extension is removed (profile deleted) while the PRT still exists in Authenticator, apps that were relying on the OS-level SSO will suddenly lose SSO, but MSAL apps will continue working through the traditional broker. Conversely, if Authenticator is removed but the SSO Extension profile still exists, the Extension has no broker to invoke and all SSO fails. The SSO Extension depends on Authenticator being installed — the Extension is literally packaged inside the Authenticator app binary.

Why You Should Deploy the SSO Extension

For any MDM-enrolled iOS deployment using Entra ID, the SSO Extension should be considered a mandatory component, not an optional enhancement. Without it:

• Non-MSAL apps require separate sign-in
• Safari doesn’t participate in SSO
• Conditional Access device claims are unavailable to non-MSAL apps
• Users get more authentication prompts
• LOB apps without MSAL integration can’t leverage the PRT

With it:

• Near-universal SSO across all apps and Safari
• Conditional Access works consistently across MSAL and non-MSAL apps
• Fewer authentication prompts = better user experience
• JIT device registration simplifies enrollment flows
• Consistent security posture across all apps

Section 7: Logs & Troubleshooting — Real World

This is where theory meets practice. This section is the proof layer. I captured live iOS system logs using the macOS Console app connected to a managed device via USB, then traced every step of the brokered authentication flow. These are real logs from a production Intune-managed device, annotated with what’s actually happening at each step.

7.1 — Capturing iOS Broker Logs 

Connect your iOS device to your Mac via USB. Open Console.app. Select the device from the left sidebar. Logs stream in real time. Use these process filters to isolate broker activity:

Microsoft Authenticator     Auth broker, PRT operations, token acquisition
Company Portal              Compliance check-in, enrollment, WPJ registration
AppSSODaemon                Enterprise SSO Extension evaluation
SpringBoard                 UIOpenURLAction (URL scheme broker invocation)
securityd / coreauthd       Keychain; Secure Enclave operations

Reproduce the sign-in scenario you want to trace, then export the log stream for analysis. In a typical sign-in, expect 10,000 to 15,000 lines of system logs in a 2-minute window. The key is knowing which lines matter

7.2 — Phase 1: Broker Invocation via URL Scheme

When an MSAL-integrated app calls acquireToken(), MSAL routes the request to Microsoft Authenticator via URL scheme. The first thing you see in Console is SpringBoard dispatching the UIOpenURLAction:

13:13:41.335 SpringBoard [(FBSceneManager):sceneID:com.microsoft.azureauthenticator-default]
          Sending action(s) in update: UIOpenURLAction

▶ SpringBoard dispatches the URL scheme call to Authenticator. This confirms MSAL found the broker via canOpenURL: for msauthv2/msauthv3.

13:13:41.343 Microsoft Authenticator   [(FBSceneManager):sceneID:com.microsoft.azureauthenticator-default]
                                        Received action(s) in scene-update: UIOpenURLAction

▶ Authenticator receives the broker request. It wakes up in the background (NotVisible) — the user never sees the app switch.

7.3 — Phase 2: Secure Enclave Access & PRT Retrieval

Once invoked, Authenticator immediately accesses the Secure Enclave to retrieve the device’s private keys and PRT:

13:13:41.372 Microsoft Authenticator   Creating LAContext new cid:14
13:13:41.377 Microsoft Authenticator   LAContext[3:7831:17913] created new cid:14

▶ LAContext = Local Authentication context. This is Authenticator accessing the Secure Enclave to retrieve the PRT and device key pair. The cid (context ID) tracks this specific hardware key operation.

13:13:41.385 Microsoft Authenticator   canEvaluatePolicy:2 on LAContext[3:7831:17913] cid:15 returned YES

▶ Policy evaluation succeeded — the Secure Enclave is accessible and the device key is intact. If this returns NO, the device registration may be corrupted and re-registration is needed.

Simultaneously, Authenticator accesses the app group container for shared token storage:

13:13:41.368 Microsoft Authenticator   container_create_or_lookup_app_group_path_by_app_group_identifier: success

▶ App group containers allow Authenticator to share tokens with other Microsoft apps in the same app group (com.microsoft.adalcache). This is how the MSAL token cache works across apps on iOS.

7.4 — Phase 3: Token Acquisition & The Nonce Challenge

The actual token exchange follows a two-step protocol. First, a nonce request that returns HTTP 400 (by design), then the real token request:

13:13:42.284 Microsoft Authenticator   Task FD864AE2-...; sent request, body S 3138
13:13:42.642 Microsoft Authenticator   Task ;FD864AE2-..;; summary for task success
    {transaction_duration_ms=459, response_status=400, protocol=C;h21D;,
     request_bytes=4711, response_bytes=1545}

▶ HTTP 400 is EXPECTED here. This is the PRT nonce challenge. Entra ID returns a server nonce that Authenticator must sign with the device key to prove possession.

13:14:03.378 Microsoft Authenticator   Task 51C0B; sent request, body S 2159
13:14:03.690 Microsoft Authenticator   Task -...&; summary for task success
    {transaction_duration_ms=316, response_status=200, reused=1,
     request_bytes=3223, response_bytes=4209}

▶ HTTP 200; token issued. The 2159-byte request contains the signed nonce + PRT + device certificate. The 4209-byte response contains the access token + refresh token.

13:14:03.723 Microsoft Authenticator   Task E3D6455> sent request, body S 2891
13:14:04.646 Microsoft Authenticator   Task <DE3D6455gt; summary for task success
    {transaction_duration_ms=924, response_status=200, reused=1,
     request_bytes=3464, response_bytes=8813}

▶ Second token request; likely for a different resource (e.g., Graph API or Intune). The larger 8813-byte response suggests this token carries additional claims.

7.5 — Phase 4: SSO Extension Evaluation (Before, During & After Deployment)

This is where the logs get really interesting. We captured the device in three states: before the SSO Extension profile was deployed, during deployment, and after. Here’s what each phase looks like:

Before SSO Extension Profile

Without the SSO Extension MDM profile, Authenticator still attempts to check for it:

13:14:02.786 Microsoft Authenticator   SOAuthorizationCoordinator::tryAuthorize
13:14:02.793 Microsoft Authenticator   SOAuthorizationCoordinator::tryAuthorize:
    The requested URL is not registered for AppSSO handling. No further action needed

▶ SOAuthorizationCoordinator is Apple‘s Extensible SSO framework. No SSO Extension profile deployed, so authentication falls back to the standard MSAL broker path.

Company Portal also checks the SSO Extension:

13:22:40.417 Company Portal   -[SOAuthorization beginAuthorizationWithParameters:]
    identifier = 49A51170-..., operation = wpjOperation_getExtensionData,
    url = mask.hash:;gd3rFOH5m6; enableUI = 1

▶ Company Portal calls wpjOperation_getExtensionData; checking if the SSO Extension can provide Workplace Join data for the device identity.

13:22:40.418 AppSSODaemon   com.microsoft.CompanyPortal is managed: NO
13:22:40.420 AppSSODaemon   not AppSSO URL: <mask.hash: ’3dcTiDi9XIt;
13:22:40.420 Company Portal   SOClient credential:;private;,
    error: Error domain: com.apple.AppSSO.AuthorizationError

▶ Phone is managed: NO; means the SSO Extension profile hasn’t been installed yet.No AppSSO URL; means the URL isn’t in the registered list. Result: AuthorizationError: SSO Extension not available.

SSO Extension Profile Deployment:

The moment the MDM profile arrived. Watch AppSSODaemon react in real time:

13:23:36.536 AppSSODaemon   ManagedConfiguration effective settings changed,
    re-performing query for continuous discovery

▶ MDM pushed the SSO Extension profile. AppSSODaemon detects the ManagedConfiguration change and immediately begins extension discovery.

13:23:36.536 AppSSODaemon   Beginning discovery for flags: 0, point: com.apple.AppSSO.idp-extension
13:23:36.641 AppSSODaemon   Completed discovery. Final # of matches: 3
13:23:36.641 AppSSODaemon   PKDiscoveryDriver; delivering update to host (3 plugins)

▶ 3 SSO extensions discovered; these are the redirect-type extensions registered by Authenticator’s binary. The SSO Extension host is now active.

13:23:36.658 AppSSODaemon   +[SOExtensionManager _sendNotificationsLoadedExtensions:new:removed:]
13:23:36.658 AppSSODaemon   -[SOConfigurationHost _extensionsLoaded:]

▶ Extensions loaded and registered with the configuration host. The SSO Extension is ready to intercept authentication requests.

After SSO Extension Is Active:

With the profile installed, Company Portal’s next SSO Extension check shows a critical change:

13:24:06.637 AppSSODaemon   com.microsoft.CompanyPortal is managed: YES

▶ Phone is managed: YES; the SSO Extension profile now recognizes Company Portal as a managed app. Compare from 90 seconds earlier. This single line confirms the profile deployed successfully.

13:24:06.637 AppSSODaemon   com.microsoft.CompanyPortal teamIdentifier: SGGM6D27TK

▶ Team identifier SGGM6D27TK is Microsoft Corporation‘s Apple Developer Team ID. AppSSODaemon validates this to ensure only legitimate Microsoft apps interact with the SSO Extension.

7.6 — Phase 5: Company Portal Compliance Check-In:

Company Portal runs its compliance cycle independently from the broker flow:

13:13:37.074 Company Portal   Creating new background assertion
13:13:37.074 Company Portal   Sending handshake request attempt #1 to server
13:13:37.075 Company Portal   Handshake succeeded
13:13:37.075 Company Portal   Identity resolved as
    app;com.microsoft.CompanyPortal(FEEDEEEE-DDDD-CCCC-BBBB-0000000001F5)

▶ Company Portal wakes up with a background assertion (iOS grants limited background execution time). The identity string is a fixed system identifier

13:13:37.210 Company Portal   Task BE6830BE; sent request, body N 0
13:13:37.374 Company Portal   Task BE6830BE; summary for task success
    {transaction_duration_ms=275, response_status=200, protocol;,
     request_bytes=195, response_bytes=2524}

▶ First call: compliance status check-in to Intune. The 2524-byte response contains the device‘s compliance policy assignments and current evaluation state.

13:13:38.549 Company Portal   Task ;7F630B07; sent request, body S 1165
13:13:38.750 Company Portal   Task <7F630B07-...; summary for task success
    {response_status=200, request_bytes=1492, response_bytes=256}

▶ Second call: compliance state attestation. CP sends device state (1165 bytes). Intune returns the result (256 bytes; pass/fail + timestamp).

13:13:38.758 Company Portal   Task 745C7047; sent request, body S 582
13:13:38.886 Company Portal   Task;745C7047; summary for task success
    {response_status=200, reused=1, request_bytes=647, response_bytes=76}

▶ Third call: acknowledgment (76-byte response = minimal ACK). Compliance state synced. Intune updates the device record in Entra ID, making the compliance claim available for CA evaluation.

13:13:39.207 Company Portal   Got system group container path from MCM for
    systemgroup.com.apple.configurationprofiles

▶ CP reads the MDM configuration profiles container to determine enrollment state, managed app list, and SSO Extension configuration; the same path AppSSODaemon uses.

7.7 — Android: Reading Logcat for Broker Operations

Next on Android Enterprise, I captured live Android logs via ADB Logcat from a Samsung device (Android 14) enrolled in MAM-WE (Without Enrollment). The device has Outlook, Teams, Edge, and Company Portal installed — no MDM enrollment. These logs reveal how Android’s broker architecture differs fundamentally from iOS.

Phase 1: Broker Discovery — Company Portal as MAM-WE Broker

When Outlook launches, MSAL immediately discovers the active broker. On MAM-WE, this is Company Portal — not Authenticator:

16:44:00.324 OneAuthLog   Returning cached broker:
    com.microsoft.appmanager::WhUdh04ZkQ...

▶ MSAL identifies the active broker package. com.microsoft.appmanager is the Company Portal Hub (Intune app manager component). On MDM-enrolled devices, this would be com.azure.authenticator instead.

16:44:05.764 OneAuthLog   prodCompanyPortal is the active AccountManager broker.

▶ Confirmed: Company Portal is the AccountManager broker for this MAM-WE device. This is the critical difference from MDM — Authenticator is NOT the broker for MAM-only scenarios.

16:44:05.765 OneAuthLog   Broker Strategies added: ContentProviderStrategy, BoundServiceStrategy,

▶ Two IPC strategies are available. ContentProviderStrategy (preferred) uses Android Content Providers for broker communication. BoundServiceStrategy is the fallback using Android Bound Services.

Phase 2: Silent Token Acquisition via Broker:

16:44:00.333 OneAuthLog   Executing with IIpcStrategy: ContentProviderStrategy
16:44:00.334 OneAuthLog   Broker operation name: MSAL_ACQUIRE_TOKEN_SILENT
    brokerPackage: com.microsoft.appmanager

▶ MSAL sends a silent token request to Company Portal via Content Provider IPC. This is the Android equivalent of iOS’s URL scheme call to Authenticator.

16:44:02.312 OneAuthLog   Key: access_token_expiry_time, Value: 2026-03-04T17:02:29.000Z
16:44:02.312 OneAuthLog   Key: request_eligible_for_broker, Value: true
16:44:02.312 OneAuthLog   Key: broker_app_used, Value: true
16:44:02.313 OneAuthLog   Key: broker_duration, Value: 1621
16:44:02.313 OneAuthLog   Key: write_token, Value: ART-1125b56d|FRT-1125b56d|AT|ID
16:44:02.313 OneAuthLog   Key: broker_response_latency, Value: 1

▶ Token acquired successfully in 1621ms. Four tokens written: App Refresh Token (ART), Family Refresh Token (FRT), Access Token (AT), and ID Token (ID). The FRT enables SSO across all apps in the Microsoft “family” — this is how cross-app SSO works on Android.

Phase 3: Device Registration State — The MAM-WE Signature

16:44:05.768 OneAuthLog   Broker operation name: MSAL_GET_DEVICE_MODE
    brokerPackage: com.microsoft.appmanager
16:44:05.830 OneAuthAuthenticationProvider   readDeviceInfo typeL NONE

▶ readDeviceInfo type: NONE — this is the unmistakable MAM-WE signature. No device registration, no device certificate, no PRT. Compare to MDM where this would show type: WORKPLACE_JOINED or AZURE_AD_REGISTERED. This is why “Require compliant device” CA policies fail for MAM-WE users.

Phase 4: Cross-App Token Sharing — Android’s SSO Mechanism:

16:44:05.733 TokenSharingManager_v1.7.1   Library works in release mode
16:44:05.775 TokenSharingManager_v1.7.1   Connecting to com.microsoft.skydrive ver:1.7.1
16:44:05.803 TokenSharingManager_v1.7.1   Connecting to com.microsoft.emmx ver:1.7.1
16:44:05.832 TokenSharingManager_v1.7.1   Connecting to com.microsoft.office.excel ver:1.6.12
16:44:05.855 TokenSharingManager_v1.7.1   Connecting to com.microsoft.office.outlook ver:1.7.1
16:44:05.860 TokenSharingManager_v1.7.1   Connecting to com.microsoft.office.powerpoint ver:1.6.12
16:44:05.862 TokenSharingManager_v1.7.1   Connecting to com.yammer.v1 ver:1.7.1

▶ TokenSharingManager proactively connects to every installed Microsoft app to share account state. This is how Android achieves cross-app SSO without relying solely on the broker — it actively pushes account data to all apps. This has no equivalent on iOS (where SSO requires either the shared keychain group or SSO Extension).

16:44:05.870 TokenSharingManager_v1.7.1   Connected to com.microsoft.office.outlook
16:44:05.891 TokenSharingManager_v1.7.1   Fetched accounts from com.microsoft.office.outlook
16:44:05.892 TokenSharingManager_v1.7.1   Disconnecting from com.microsoft.office.outlook

▶ Pattern: Connect → Fetch accounts → Disconnect. Repeats for each app. After this, all Microsoft apps on the device share the same account state.

16:44:05.774 TokenSharingManager_v1.7.1   Skipping package
    com.microsoft.windowsintune.companyportal because SDK version isn’t compatible

▶ TokenSharingManager skips Company Portal itself — CP is the broker, not a token consumer. The SDK version check ensures compatibility between the sharing library versions across apps.

Phase 5: The IntuneAppProtectionPolicyRequired Exception:

16:44:58.254 OneAuthLog   Received a
    com.microsoft.identity.common.exception
    .IntuneAppProtectionPolicyRequiredException from Broker: unauthorized_client

▶ This is the MAM enrollment handshake. After initial token acquisition, the app discovers it needs an App Protection Policy. The broker returns unauthorized_client with the IntuneAppProtectionPolicyRequiredException — this triggers the Intune MAM SDK to begin APP 

16:44:00.170 ActivityManager   Start proc com.microsoft.windowsintune.companyportal
    :omadm_client_process for content provider
    {com.microsoft.windowsintune.companyportal/
     com.microsoft.omadm.apppolicy.AppPolicyContentProvider}

▶ Android starts the Company Portal’s OMADM (Open Mobile Alliance Device Management) process specifically for the AppPolicyContentProvider. This is the MAM policy delivery channel — separate from the authentication broker.

16:44:00.699 ActivityTaskManager   START com.microsoft.office.outlook/
    com.microsoft.intune.mam.client.app.startup.MAMStartupActivity

▶ Outlook launches through MAMStartupActivity. The Intune MAM SDK intercepts app startup to enforce APP before the app content loads. This is the Intune SDK wrapper in action.

16:44:00.875 InsetsSourceProvider   target=Window{d34cfb1 u0
    com.microsoft.windowsintune.companyportal/
    com.microsoft.intune.mam.client.app.startup.BiometricActivity}

▶ Company Portal’s BiometricActivity launches briefly — this is the MAM enrollment biometric/PIN verification. The user may see a brief fingerprint or PIN prompt before the app content appears.

Phase 6: Cross-App SSO — Edge Silently Signs In:

16:45:36.314 cr_EdgeSignInLogger   EdgeSignInManager: AcquireTokenSilently start,
    param = {mAccountType=AAD(2), mScopeIdentifier=’EdgeSyncKeyDataScope’}
16:45:37.744 cr_EdgeSignInLogger   EdgeSignInManager: AcquireTokenSilently success,
    result = {mExpireTime=1772643274000,
    mEdgeAuthErrorInfo={mPrimaryError=0, mSecondaryError=0}}

▶ Edge silently acquires tokens for 9 different scopes (Sync, Admin Center, Graph, Workspace, Substrate, Account Image, Office Feed, MSN) — all succeed without user interaction. This proves cross-app SSO is working via the FRT (Family Refresh Token) + TokenSharingManager combination.

7.8 — Common Scenarios: Logs to Diagnosis

Scenario 1: MAM-only user hitting compliance CA policy (AADSTS53003)

This is the #1 most common mobile Conditional Access failure in the field.

What the user sees: “You can’t access this right now” or a redirect loop between Authenticator and Company Portal.

Entra sign-in log shows:

• Error code: 53003
• Failure reason: “Access has been blocked by Conditional Access policies”
• Conditional Access tab: Policy requiring “Require device to be marked as compliant” → Failed
• Device info tab: Device ID may be populated (device is registered) but Compliant = No (no MDM enrollment)

What happened: The user signed in through the broker (Authenticator), so the PRT carried the device ID. Entra ID looked up the device and found it registered but not MDM-enrolled. Without MDM enrollment, there’s no compliance evaluation. The CA policy requiring compliance fails.

Fix: Change the CA policy to use “Require app protection policy” instead of “Require device to be marked as compliant” for BYOD/MAM users. Or create a separate CA policy that targets mobile platforms with the app protection control.

Scenario 2: iOS native Mail stuck on “Verifying” (missing SSO Extension)

What the user sees: Native iOS Mail app shows “Verifying…” indefinitely when adding a work account, or prompts for password repeatedly.

Entra sign-in log shows:

• Client app: “Mobile apps and desktop clients” or “Browser”
• Incoming token type: none (not primaryRefreshToken)
• Device info: Device ID empty or not present
• CA result: May fail if policies require managed device or compliant device

What happened: The native Mail app doesn’t use MSAL. Without the SSO Extension, it authenticates through a standard webview and cannot access the PRT or present device claims. The broker is irrelevant because Mail doesn’t call MSAL.

Fix: Deploy the Enterprise SSO Extension profile via MDM with browser_sso_interaction_enabled set to 1. This allows Mail (and other non-MSAL apps) to participate in SSO through the OS-level interception.

Scenario 3: Redirect loop between Authenticator & Company Portal (iOS)

What the user sees: Tapping “Sign In” in an app → Authenticator opens → redirects to Company Portal → CP redirects back to Authenticator → loop.

MSAL client logs show:

[MSAL] Beginning broker flow.
[MSAL] Resolved authority, validated: YES
[MSAL] Received broker response with error: user_interaction_required

Entra sign-in log shows:

• Initial sign-in for “Microsoft Authentication Broker” → Success
• Followed by CA evaluation → Grant control “Require device to be marked as compliant” or “Require approved client app” → Failed
• Interrupt reason: “User action required — device enrollment needed”

What happened: Authentication succeeded, but CA required compliance. Entra ID issued an “enrollment remediation” response. The broker (Authenticator) can’t handle enrollment, so it redirects to Company Portal. Company Portal checks enrollment status, finds the device not enrolled (or enrolled but not compliant), and redirects back to the broker to re-authenticate. Loop.

Fix: One of the following:

• If the user should be MDM-enrolled: Complete enrollment through Company Portal first, wait for compliance to sync (can take 5–15 minutes), then sign in to the app
• If the user is MAM-only: The CA policy is misconfigured for this user group — switch to app protection policy requirement
• Force compliance sync: In Company Portal → Settings → Sync (or Check Status) to push a fresh compliance check to Intune → Entra ID

Scenario 4: APP not applying on Android (wrong broker)

What the user sees: Signs in to a managed app, but no App Protection Policy is applied — no “managed by your organization” banner, no restrictions.

Company Portal logs show:

MAMServiceEnrollmentTask: Enrollment failed for package <app.package>
No URL for MAMService

What happened: On Android for MAM-only scenarios, Company Portal must be the broker for APP enrollment to work. If Authenticator was installed first and is acting as the broker, the MSAL authentication succeeds but the APP enrollment through Company Portal fails because the auth token was issued through a different broker.

Fix: Ensure Company Portal is installed. For MAM-only Android, the recommended order: install Company Portal → user signs in to Company Portal → then opens the managed app. If Authenticator was installed first, clear Authenticator’s account data and sign in through Company Portal first.

Scenario 5: Token cache corruption (persistent sign-in failures after OS upgrade)

What the user sees: After an iOS or Android major OS upgrade, apps that previously worked with SSO now prompt for sign-in repeatedly, and signing in fails or loops.

iOS MSAL logs show:

Broker application token not found. (status: -25300)

repeatedly, even after successful interactive sign-in.

Android Logcat shows:

AccountManagerCommunicateToBroker: Failed to get result from Broker Content Provider

What happened: Major OS upgrades can invalidate the keychain entries (iOS) or broker cache (Android). On iOS, the PRT stored in the keychain may have been wiped or the Secure Enclave key binding changed. On Android, particularly Android 15, known issues with broker Content Provider communication have been reported.

Fix:

• iOS: Uninstall and reinstall Authenticator → user re-authenticates → new PRT issued
• Android: Clear Authenticator app data (Settings → Apps → Authenticator → Clear Data) → reinstall if needed → re-authenticate
• In both cases, the user will need to complete MFA again since the PRT (and its MFA claim) is gone

Scenario 6: BROKER_BIND_FAILURE on Android enterprise (Work Profile)

What the user sees: App in Work Profile can’t sign in; gets generic “sign-in failed” error.

Logcat shows:

MsalClientException: BROKER_BIND_FAILURE

Android settings show: Work Profile → Accounts → no com.microsoft.workaccount present.

What happened: The admin has a Work Profile restriction “Add and remove accounts” set to Block. This prevents the broker from creating the work account entry in AccountManager within the Work Profile. Without the AccountManager account, the broker can’t store or retrieve tokens.

Fix: In Intune → Device Configuration → Device Restrictions profile for Android Enterprise Work Profile: Set “Add and remove accounts” to “Not configured” (allow). This doesn’t mean users can add arbitrary accounts — the Work Profile still constrains which accounts are permitted.

7.9 — Using Correlation IDs: Client-to-Server Mapping

The single most powerful troubleshooting technique for brokered auth:

1. Reproduce the failure on the device
2. Immediately collect client logs (MSAL logs from the app or broker diagnostic data)
3. Find the Correlation ID in the client logs (it’s a GUID, usually labeled MSALCorrelationIDKey on iOS or correlation_idon Android)
4. Go to Entra admin center → Sign-in logs → Add filter → Correlation ID → paste the GUID
5. You now have the exact server-side record of what happened: which CA policies were evaluated, what device claims were present, what grant controls failed, and what error was returned.

This bypasses all the guesswork. The Correlation ID is the bridge between “the user says it doesn’t work” and “here’s exactly why.”

Section 8: Decision Matrix

This matrix answers the question every admin eventually asks: “For this specific combination of platform, enrollment type, and policy requirement — what exactly happens with the broker, and will it work?”

8.1 — Platform × Enrollment × Broker Behavior

Key takeaways from this matrix:

• iOS always uses Authenticator as the auth broker, regardless of enrollment type
• Android MAM-only is the only scenario where Company Portal is the auth broker (not just the compliance broker)
• “PRT Issued = Yes” doesn’t mean compliance claims are present — that requires MDM enrollment
• SSO Extension extends SSO scope dramatically on iOS, but only works on MDM-enrolled devices
• Work Profile on Android constrains SSO to within the profile — personal apps don’t get broker SSO

8.2 — CA Grant Control × Enrollment Type: Will It Pass?

The critical pattern: MAM-only devices pass every grant control except “Require compliant device.” This single mismatch causes the majority of mobile CA failures in production.

8.3 — App Type × SSO Extension × Auth Path

Note: This table applies to iOS only. Android doesn’t have an SSO Extension equivalent — SSO scope on Android is determined by broker availability and enrollment type (see 9.1).

8.4 — Troubleshooting Decision Tree

Use this when a user reports “I can’t sign in” or “I keep getting asked to sign in” on a mobile device:

Step 1: Is the broker installed?

• iOS: Is Authenticator installed? → No → Install it. Authentication will fall back to browser without it.
• Android: Is Authenticator or Company Portal installed? → No → Install one (CP required for MAM-only).

Step 2: Is the broker working?

• iOS: Check MSAL logs for “Broker version V2-broker-nonce found installed on device”
• Android: Check for com.microsoft.workaccount in Settings → Accounts
• If no → Broker discovery is failing. Check URL schemes (iOS) or <queries> manifest (Android).

Step 3: Is the PRT issued?

• Entra sign-in log: Look for incoming token type = primaryRefreshToken
• If no → Device may not be registered. Check Authenticator → device registration status.

Step 4: Is CA failing?

• Entra sign-in log: Check Conditional Access tab for failed policies
• Error code 53003 → Identify the specific failed grant control
• Compliance failure → Is the device MDM-enrolled? Is compliance state synced?
• APP failure → Is the Intune SDK reporting active policy? Is Company Portal installed (Android)?

Step 5: Is it an SSO Extension issue? (iOS only)

• Is the SSO Extension profile deployed? Check in Settings → General → VPN & Device Management → Management Profile → look for SSO Extension payload
• Is browser_sso_interaction_enabled set? Without it, non-MSAL apps and Safari won’t participate
• Are TLS inspection exclusions configured for Microsoft identity endpoints?

Step 6: Is it a token/cache issue?

• If the above all check out but auth still fails: Clear broker cache (reinstall Authenticator), re-register device, re-authenticate. The PRT or token cache may be corrupted.

Section 9: Summary & Key Takeaways

The Core Mental Model

Brokered authentication on mobile isn’t one system — it’s an orchestration between four distinct layers that must all align: the MSAL client library inside apps, the broker app (Authenticator or Company Portal), the MDM compliance state from Intune, and the server-side Conditional Access evaluation in Entra ID. When things work, the user sees seamless SSO. When they don’t, you need to know which layer broke and why.

Platform Differences That Matter

iOS and Android approach brokered auth from fundamentally different architectural philosophies:

iOS enforces strict app sandboxing. Apps can’t share state, so everything routes through a single designated broker — Authenticator. IPC happens via URL schemes, a constrained mechanism that requires careful configuration (Info.plist entries, redirect URIs, app registration). The SSO Extension was Apple and Microsoft’s answer to extending SSO beyond MSAL apps, intercepting auth at the OS level. But it only works on MDM-enrolled devices — MAM-only is excluded by design.

Android’s open model allows multiple broker hosts, richer IPC through Bound Services and AccountManager, and device-wide token sharing. But this openness introduces its own complexity: battery optimization kills broker services, Work Profile boundaries isolate SSO, broker priority depends on installation order, and the AccountManager permission model adds a dependency that catches many deployments off guard.

The Compliance Trap

The single most impactful takeaway from this entire article: the broker handles authentication, not compliance. Authenticator issues the PRT and manages SSO. Company Portal (on iOS) handles compliance attestation and reports to Intune. Intune syncs compliance state to Entra ID. Conditional Access evaluates all of this during token issuance.

When you require “compliant device” in a CA policy, you’re requiring the entire chain: MDM enrollment → compliance policy evaluation → state sync to Entra ID → device lookup during token issuance. MAM-only devices will always fail this check, regardless of how well the broker is configured. Use “Require app protection policy” for BYOD.

What You Should Deploy

For any production iOS deployment with Entra ID:

• Authenticator (required — it IS the broker)
• Company Portal (required for compliance reporting if MDM-enrolled)
• Enterprise SSO Extension profile (should be mandatory for all MDM-enrolled devices)
• Correct CA policies scoped to enrollment type

For any production Android deployment with Entra ID:

• Authenticator (primary broker for MDM scenarios)
• Company Portal (required for MAM-only; also the compliance broker)
• Battery optimization exclusions for both apps
• Correct <queries> manifest entries for Android 11+

The Troubleshooting Instinct

When mobile auth breaks, resist the urge to start changing CA policies or reinstalling apps. Follow the signal:

1. Get the Correlation ID from client logs
2. Look it up in Entra sign-in logs
3. Check the Conditional Access tab for which specific control failed
4. Check the Device info tab for whether device claims were present
5. Check the incoming token type — primaryRefreshToken means the broker worked; anything else means it didn’t

This five-step process resolves the vast majority of mobile broker issues in under ten minutes.

Looking Ahead

The brokered authentication landscape continues to evolve. The Secure Enclave for device keys , the deprecation of “approved client app” CA control, improvements to MSAL broker selection logic on Android, and continued enhancements to the Enterprise SSO Extension all signal that Microsoft is investing heavily in making mobile authentication both more secure and more transparent. The fundamentals covered in this article — PRT mechanics, broker IPC, CA evaluation flow, and the compliance chain — will remain the architectural foundation even as surface-level configurations change.

Understanding these mechanics doesn’t just help you troubleshoot — it helps you design enrollment strategies, CA policies, and app deployment sequences that work correctly from day one.