MSA1.3 The Attack Surface of Each Identity Type

Your identity census from MSA1.2 tells you what exists. Knowing that each category faces different attack techniques — and that generic controls designed for one type leave other types exposed — is the threat model. You can't design a Conditional Access framework (MSA3), an authentication architecture (MSA2), or a detection strategy (MSA9) without understanding what attackers actually do to each identity type. This sub teaches the specific attack surface of each type using real-world incidents, current sign-in log telemetry, and the architectural controls that address each threat. The threat model applies to every tenant — regardless of size — because the attack techniques target identity properties, not specific organizations.

Estimated time: 45 minutes.

Cloud-only users — the cloud authentication attack surface

Cloud-only users authenticate entirely against Entra ID. Their attack surface is the cloud sign-in endpoint. Every attack targeting a cloud-only user produces telemetry in the Entra ID sign-in logs — which makes cloud-only users the best-monitored identity type and also the most directly attacked.

Password spray

The attacker tries a small number of common passwords (P@ssw0rd1, Summer2026!, CompanyName1) against many accounts simultaneously. The goal is to find one account with a weak password while staying below the per-account lockout threshold. Entra ID Smart Lockout (enabled by default) mitigates this by tracking failed attempts from known-malicious IP addresses, but sophisticated sprays rotate source IPs to avoid triggering Smart Lockout.

The sign-in log for a password spray attempt looks like this:

{
  "userPrincipalName":         "e.richardson@yourtenant.onmicrosoft.com",
  "status": {
    "errorCode":               50126,
    "failureReason":           "Invalid username or password"
  },
  "ipAddress":                 "185.220.101.42",
  "location": {
    "countryOrRegion":         "NL",
    "city":                    "Amsterdam"
  },
  "clientAppUsed":             "Browser",
  "riskLevelDuring":           "none",
  "appliedConditionalAccessPolicies": []
}

errorCode: 50126 — authentication failed because the password was wrong. This is the single most common error code in a spray attack. One failed attempt is noise. Dozens of 50126 errors from the same IP range across multiple accounts in a short window is a spray. The appliedConditionalAccessPolicies array is empty because the authentication failed before CA evaluation — CA only evaluates successful pre-authentication. The riskLevelDuring: none is notable — Entra ID may not flag a single failed attempt as risky, but Identity Protection's aggregate analysis (looking across the tenant for distributed spray patterns) should detect the campaign.

Architectural controls: Entra ID Smart Lockout (baseline — enabled by default). Banned password list (custom + global — prevents users from setting sprayable passwords). CA policy blocking sign-ins from anonymous networks and known-malicious infrastructure (MSA3). Password protection extending to on-premises AD (MSA1.4). Long-term: passwordless authentication eliminates the password spray attack surface entirely (MSA2).

AiTM phishing

The attack you studied in MSA0.4. The attacker deploys a reverse proxy that sits between the user and the legitimate Microsoft sign-in page. The user sees what appears to be the real login page. They enter their credentials. They complete MFA. The proxy captures the session cookie containing the authenticated MFA claim and forwards it to the attacker. The attacker replays the cookie — and the replayed request appears to Microsoft as a legitimate, already-authenticated session.

A successful AiTM sign-in produces a distinctive sign-in log entry:

{
  "userPrincipalName":         "e.richardson@yourtenant.onmicrosoft.com",
  "status": {
    "errorCode":               0,
    "additionalDetails":       "MFA completed"
  },
  "authenticationDetails": [
    {
      "authenticationMethod":          "Previously satisfied",
      "authenticationStepResultDetail": "MFA requirement satisfied by claim in the token",
      "succeeded":                      true
    }
  ],
  "deviceDetail": {
    "deviceId":                "",
    "displayName":             "",
    "operatingSystem":         "Windows 10",
    "browser":                 "Chrome 121.0.0.0",
    "isCompliant":             null,
    "trustType":               ""
  },
  "ipAddress":                 "45.77.232.18",
  "location": {
    "countryOrRegion":         "US",
    "city":                    "New York"
  },
  "riskLevelDuring":           "high",
  "riskEventTypes_v2":         ["unfamiliarFeatures", "anomalousToken"]
}

Three fields converge to reveal the attack:

authenticationStepResultDetail: "MFA requirement satisfied by claim in the token" — the user didn't complete MFA interactively during this sign-in. The session arrived with a pre-satisfied MFA claim. This happens legitimately when a user has an existing session (the MFA claim persists for the session lifetime). It happens maliciously when an attacker replays a stolen session cookie.

deviceDetail.deviceId: "" with isCompliant: null — the request came from a device that isn't registered in Entra ID. An empty device ID means no device identity was presented. isCompliant: null means the device compliance signal is absent (not false — which would mean the device is registered but non-compliant, but null — the device isn't registered at all). If Emma Richardson's normal sign-in comes from her enrolled, compliant laptop, a sign-in with no device identity is anomalous.

riskEventTypes_v2: ["unfamiliarFeatures", "anomalousToken"] — Identity Protection has flagged this sign-in with two risk detections. unfamiliarFeatures means the sign-in properties (IP, device, browser fingerprint) don't match Emma's behavioral baseline. anomalousToken (an E5 risk detection) specifically identifies token anomalies consistent with session theft.

Architectural controls: Phishing-resistant MFA (passkeys, FIDO2, CBA) — the authentication binds to the specific TLS session between the user's device and Microsoft's identity platform; the proxy can't replay it because the binding includes the proxy's TLS session, not the user's (MSA2). Device compliance in CA — blocks authentication from unregistered devices, which blocks the replayed session because the attacker's device isn't enrolled (MSA3). Token lifetime policies and CAE — reduces the window of opportunity for replay (MSA2). Risk-based CA — blocks sign-ins that Identity Protection flags as high risk (MSA3).

Token theft

After successful authentication, the attacker steals the session token — from a browser cookie (infostealer malware), a memory dump, or a compromised browser extension — and replays it from their own infrastructure. Token theft is harder to detect than AiTM because the stolen token may include all the signals that make a sign-in look legitimate: the right user, the right MFA claim, even the right location if the attacker uses a residential proxy.

The distinguishing indicator is the device signal. The attacker's machine isn't enrolled in Entra ID, so the device properties are empty or inconsistent with the user's normal device:

{
  "authenticationDetails": [
    {
      "authenticationMethod":          "Previously satisfied",
      "authenticationStepResultDetail": "MFA requirement satisfied by claim in the token"
    }
  ],
  "deviceDetail": {
    "deviceId":   "",
    "isCompliant": null,
    "trustType":   ""
  },
  "riskLevelDuring":  "medium",
  "riskEventTypes_v2": ["anomalousToken"]
}

The same "Previously satisfied" MFA claim as AiTM — but potentially from a location that looks normal (residential proxy). The device signal is the architectural anchor. If every CA policy requires a compliant device, token replay from an unregistered device fails — even if the token contains a valid MFA claim.

Architectural controls: Device compliance requirement in CA (blocks all sign-ins from unregistered devices — MSA3). Continuous Access Evaluation (CAE) — revokes tokens when critical events occur (user disabled, password changed, network location changes — MSA2). Strict token lifetime policies — reduces the window during which a stolen token is valid. Sign-in frequency policies — forces periodic re-authentication instead of relying on persistent sessions.

Assess your environment: Look at your cloud-only user count from MSA1.2. If you have break-glass accounts, they're the highest-value cloud-only identities — they bypass MFA by design and must have dedicated monitoring (MSA4). The remaining cloud-only users are fully served by phishing-resistant MFA + device compliance + risk-based CA. Check whether your tenant currently has any of these controls configured.

Check which controls protect your cloud-only accounts. If you have no phishing-resistant MFA, no device compliance CA policy, and no risk-based CA policy, your cloud-only population is protected by basic MFA only — which AiTM attacks bypass. MSA2 designs the authentication method. MSA3 designs the CA policies.

Synced users — the on-premises propagation surface

Synced users inherit every vulnerability of the on-premises Active Directory. Cloud-side controls (CA, MFA, Identity Protection) apply to their cloud authentication, but the identity itself — the password hash, the group memberships, the attributes — is sourced from on-premises AD and replicated to the cloud. This means the on-premises AD security posture is a direct input to the cloud security posture.

On-premises compromise propagation

If an attacker compromises a domain controller via vulnerability exploitation, physical access, or privilege escalation from a compromised workstation, they can extract the entire AD database using DCSync (Mimikatz), ntdsutil, or direct access to the NTDS.dit file. The database contains NTLM password hashes for every user in the domain.

With Password Hash Sync enabled (the organization's configuration), the password hashes replicated to Entra ID are derived from these same NTLM hashes. Microsoft applies an additional layer of hashing (SHA-256 with a per-user salt) before storing them in Entra ID, so the hashes aren't directly reusable in the cloud. But the attacker doesn't need the cloud hash — they have the on-premises NTLM hash, which they can crack offline to obtain the plaintext password, and then use that password to authenticate against Entra ID. For common or weak passwords, cracking time ranges from seconds to hours.

The propagation isn't limited to passwords. On-premises group memberships are replicated to Entra ID by the sync engine. If an attacker modifies group memberships in on-premises AD (adding themselves to a synced security group that a CA policy targets), the change propagates to Entra ID within the sync cycle. The attacker adds their compromised account to the group that has Conditional Access exclusions, and within minutes, the cloud exclusion applies.

The sync server as a Tier 0 target

The Cloud Sync agent (or legacy Entra Connect server) runs with a service account that has directory synchronization permissions in both on-premises AD and Entra ID. Compromising this server gives the attacker write access to Entra ID — they can modify any synced user's attributes, potentially change group memberships, and with password writeback enabled, trigger password resets that propagate from cloud to on-premises.

Microsoft's own documentation classifies the sync server as Tier 0 infrastructure, the same security tier as domain controllers. In practice, most organizations treat it as a regular member server on the same network segment as file servers and print servers. The anti-pattern from MSA1.4 — the legacy Entra Connect server running on unmonitored Windows Server 2016 with undocumented local admin accounts — is the specific incarnation of this risk at NE.

Hard-match takeover

Until Microsoft's June 2026 security change, an attacker who controlled on-premises AD could create a new AD user account with a sourceAnchor (ImmutableID) matching an existing cloud-only user who held Entra roles. When the sync engine processed this new account, it would "hard match" the on-premises identity to the cloud identity — transferring Source of Authority from cloud to on-premises. The attacker now controls a cloud-only identity (potentially a Global Administrator) through on-premises AD.

Beginning June 2026, Entra Connect Sync and Cloud Sync will block hard-matching when the target cloud identity holds any Entra role. This protection is already configurable (blockCloudObjectTakeoverThroughHardMatchEnabled: True in the organization's sync configuration, as confirmed in MSA1.4). The architectural lesson: identity synchronization is a trust relationship between on-premises AD and Entra ID, and that trust can be weaponised if the on-premises environment is compromised.

Assess your environment: If you have synced users, your sync server is a Tier 0 asset — treat it with the same security as domain controllers. Check whether password writeback is enabled (a compromised cloud account could change the on-premises password). Check whether any legacy sync servers or service accounts exist that haven't been decommissioned.

If your tenant is hybrid, check the sync infrastructure. How many domain controllers? Is the sync agent on a Tier 0 server? Is password writeback enabled? Has the legacy sync server been decommissioned, or does it still have active credentials? Each of these is a potential risk register entry.

Guest users — cross-tenant trust as attack surface

Guest users create bidirectional trust relationships between tenants. Your tenant trusts the guest's home tenant for authentication. The guest's home tenant trusts that your tenant won't leak the guest's identity attributes. Both sides of this trust can be exploited.

CVE-2025-55241 — The Actor Token vulnerability

This vulnerability, now patched, was the most severe guest identity attack disclosed to date. The attack chain worked in four steps:

Step 1 — Enumerate guest users. An attacker with standard user access in any Entra ID tenant (not admin access — standard user) could query the directory and retrieve guest user objects. Each guest object contained the guest's netId (in the alternativeSecurityIds attribute) and their home tenant ID (extractable from the UPN).

Step 2 — Craft an Actor Token. Using the netId and home tenant ID, the attacker crafted a malicious Actor Token. Actor Tokens are an internal Microsoft mechanism used for service-to-service authentication — they were never intended for external use. The vulnerability was that the token validation didn't verify whether the requesting entity was authorized to create an Actor Token for that specific identity.

Step 3 — Impersonate the guest in their home tenant. The crafted Actor Token was replayed against the guest's home tenant. Because Actor Tokens are trusted for service-to-service communication, the home tenant processed the request as if it came from a legitimate Microsoft service acting on behalf of the guest user. The attacker gained the guest's full user privileges in the guest's home tenant — bypassing MFA, bypassing Conditional Access, and generating no sign-in log entry for the impersonated authentication.

Step 4 — Escalate and pivot. With user-level access in the home tenant, the attacker enumerated Global Administrators. They repeated Steps 1–3 for each administrator — crafting Actor Tokens to impersonate administrators in the home tenant. With Global Administrator access, the attacker had full control: create new accounts, modify permissions, access all data, disable security controls. And from this newly compromised tenant, the attacker could see all guest users in that tenant — providing netIds and home tenant IDs for the next pivot. The attack was exponential.

The architectural lesson is not about the specific CVE (it's patched). The lesson is about the trust model. Every guest identity in your tenant reveals your tenant's identity to the guest's home tenant — and every guest in the guest's home tenant reveals that tenant's identity to any tenant that has invited guests from it. Guest identities are nodes in a trust graph that an attacker can traverse. Reducing guest count, restricting guest permissions, reviewing guest access regularly, and configuring cross-tenant access policies are architectural controls that reduce the graph's attack surface.

Overprivileged guests and the default permission problem

Entra ID's default guest permissions are more permissive than most architects realise. Unless the guestUserRoleId setting is changed from its default, guest users can:

• Enumerate the directory (list other users, groups, applications)
• Read their own profile properties and some properties of other users
• Query group memberships
• Read applications and service principals

Query the current guest permission level:

$authPolicy = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/policies/authorizationPolicy"
Write-Host "Guest user role ID: $($authPolicy.guestUserRoleId)"

Guest user role ID: 10dae51f-b6af-4016-8d66-8c2a99b929b3

This GUID corresponds to the "Guest User" role — the default. Three levels exist:

• a0b1b346-4d3e-4e8b-98f8-753987be4970 — same as member users (most permissive)
• 10dae51f-b6af-4016-8d66-8c2a99b929b3 — default guest (can enumerate directory)
• 2af84b1e-32c8-42b7-82bc-daa82404023b — most restricted (limited to own properties)

Run the guestUserRoleId query against your own tenant to determine your current guest permission level. If it returns the default GUID (10dae51f-...), your guests can enumerate the directory. The restricted setting (2af84b1e-...) limits guests to their own profile properties.

Check your guest permission settings. If the default guest access policy allows directory enumeration, every guest can list your users, groups, and applications. Check for stale pending invitations — any invitation older than 90 days was likely never accepted and should be revoked. If you have no cross-tenant access policies and no guest access review process, your guest population is ungoverned.

Assess your environment: Check your guest count from MSA1.2. Even a small number of guests creates trust relationships with external organizations. Query the guestUserRoleId to determine your permission level. If you have more than 10 guests, investigate whether any are stale (MSA1.8 covers this).

Workload identities — the invisible, unmonitored attack surface

Workload identities are the identity category most organizations pay the least attention to and attackers exploit the most. Research from 2025 consistently indicates that over 60% of cloud breaches involve compromised non-human identities rather than human user accounts. The reasons are structural, not accidental.

Why workload identities are exploited disproportionately

Credentials are long-lived and manually managed. In most organizations, the oldest app registration secrets are years old — far older than any human user's password. Human user passwords expire (or should), are subject to banned password lists, and are protected by MFA. Application secrets are created with a configurable expiration (or no expiration in older configurations), aren't subject to complexity requirements, and can't be protected by MFA because applications authenticate non-interactively.

Permissions accumulate and are never reviewed. When a developer registers an application and requests API permissions, the admin who consents evaluates the permissions at that moment. Nobody reviews them again. The CRM Integration registered in 2021 has the same permissions today that it had when it was created — even if the integration's requirements have changed, even if the application is no longer in use.

CA policies don't apply by default. Standard CA policies target "All Users" — which includes member and guest users but not workload identities. Service principals authenticate through the OAuth 2.0 client credentials flow: the application presents its client ID and secret (or certificate) directly to the token endpoint. No browser. No device. No MFA. No CA evaluation. The authentication succeeds or fails based solely on the credential.

Applying CA policies to workload identities requires Workload ID Premium licensing ($3/workload identity/month). Without it, workload identities are architecturally invisible to the CA framework.

Sign-in logs are separated. Workload identity sign-ins appear in the "Service principal sign-ins" log in Entra ID, not the main "Sign-ins" log. Many security teams monitor the main sign-in log and never look at the service principal log. An attacker authenticating with a stolen client secret appears only in the service principal log — if anyone is watching.

OAuth consent phishing — the workload identity creation attack

The attacker creates a malicious application and tricks a user into granting it permissions via OAuth consent. The user sees a consent prompt ("AppName would like to access your email and files — Allow?"), clicks Accept, and the application receives the granted permissions. The application now operates as a workload identity with persistent access to the user's mailbox and files — and the access persists until the consent is explicitly revoked.

If user consent is enabled for unverified publishers (the "legacy" consent policy — common in tenants that haven't been hardened), any user can grant any application permissions to their own mailbox and files. Check your consent policy in the admin center. The architectural control is an admin consent workflow (MSA4) where user consent is restricted and high-privilege permissions require admin approval.

The credential leak scenario

A developer working on the HR Data Sync integration commits the application's client secret to a public GitHub repository. The secret is indexed by automated scanners within minutes. The attacker uses the client ID and secret to authenticate as the HR Data Sync application — obtaining whatever API permissions the application holds. If those permissions include User.ReadWrite.All (common for HR integrations that need to update user attributes), the attacker can modify any user's attributes in the tenant. If they include Directory.ReadWrite.All, the attacker can create new users, modify group memberships, and grant themselves administrative access.

The detection is in the service principal sign-in log:

{
  "servicePrincipalId":   "c3d4e5f6-a7b8-9012-cdef-345678901234",
  "servicePrincipalName": "HR Data Sync",
  "appId":                "d4e5f6a7-b8c9-0123-def0-456789012345",
  "ipAddress":            "103.28.70.55",
  "location": {
    "countryOrRegion":    "VN",
    "city":               "Ho Chi Minh City"
  },
  "resourceDisplayName":  "Microsoft Graph",
  "status": {
    "errorCode":          0,
    "failureReason":      null
  }
}

The application authenticated successfully from an unexpected location. If all legitimate API calls come from your organization's Azure infrastructure or office locations, a sign-in from an unrecognised country is anomalous. But without Workload ID Premium, no CA policy evaluates this sign-in — and without service principal sign-in log monitoring, nobody sees it.

Assess your environment: Check your app registration count and credential analysis from MSA1.2. How many expired credentials exist? Does your tenant have Workload ID Premium licensing? What is your user consent policy — can users consent to any application, or is admin approval required? Check the service principal sign-in log (Identity → Monitoring & health → Sign-in logs → Service principal sign-ins) — is anyone monitoring it?

Check your app registration count, expired credential count, and Workload ID Premium licensing status. If you have expired credentials with no rotation tracking, a legacy user consent policy, and no Workload ID Premium, your workload identities bypass CA policies entirely and operate without monitoring. This is typically the highest-priority identity gap.

Managed identities — the architectural ideal

Managed identities are the safest identity type because they eliminate every structural weakness that makes workload identities dangerous. No client secret exists to leak. No certificate exists to expire. No credential exists to commit to a repository. Azure manages the entire credential lifecycle — issuing short-lived tokens via the Instance Metadata Service (IMDS), rotating the underlying key material automatically, and restricting token issuance to the specific Azure resource the identity is assigned to.

The attack surface of a managed identity is limited to the hosting Azure resource. If an attacker compromises the VM that hosts a managed identity, they can call IMDS from within the VM to obtain a token. But they can't use that token from outside the VM — IMDS is only accessible from the local network interface. And the token's permissions are limited to whatever RBAC roles the managed identity has been granted — ideally the minimum required for its function.

If your tenant has managed identities, they're the right pattern. The architectural principle going forward: every new Azure workload that needs to authenticate to Entra ID or Azure resources should use a managed identity. If an application uses a client secret instead, an ADR should document why the managed identity pattern isn't possible for that specific workload.

Managed identities are the correct pattern for Azure workloads. As you expand Sentinel (MSA8) and automation (MSA10), managed identities should be mandatory for all new Azure service authentication.

Per-type threat model — the complete mapping

This table maps each identity category to its primary attack techniques, the sign-in log evidence that reveals each attack, and the architectural controls that defend against it. Save this as a reference for MSA2–MSA4 and MSA9.

Type          Primary Attacks              Log Evidence                    Controls                         Licensing
----------    -------------------------    ----------------------------    ------------------------------   ---------
Cloud-only    Password spray               errorCode 50126 across         Smart Lockout, banned passwords,  Included
              AiTM phishing                accounts from same IP range    phishing-resistant MFA, device
              Token theft                  "Previously satisfied" MFA     compliance CA, risk-based CA,
                                           + empty deviceId + anomalous   CAE, token lifetime policies
                                           location. riskEventTypes:
                                           anomalousToken

Synced        On-prem propagation          On-prem: Security Event 4624   All cloud-only controls +         E5 + MDE
              Golden Ticket                from DC. Cloud: normal sign-   Tier 0 sync server protection,    for Identity
              Sync server compromise       in (attack is pre-auth).       on-prem DC monitoring,            (on-prem)
              Hard-match takeover          Hard-match: sync audit log     PHS over PTA/federation,
                                           shows object merge             blockHardMatch enabled

Guest         CVE-2025-55241 (patched)     Actor Token: NO log entry      Cross-tenant access policies,     E5 for risk-
              Overprivilege                (invisible). Overprivilege:    restricted guest permissions       based guest
              Stale trust                  Guest accessing resources      (guestUserRoleId=2af84b1e),       CA policies
              Consent exploitation         outside intended scope.        access reviews, lifecycle
                                           Stale: no signInActivity       management, invitation policies

Workload      Credential leak              Service principal sign-ins     Credential rotation, certificate   Workload ID
              Over-permission              log (separate from user log).  over secrets, managed identities,  Premium ($3
              OAuth consent phishing       Anomalous IP/location.         admin consent workflow, scope      /wl id/month)
              No CA evaluation             Note: invisible to standard    review, Workload ID CA policies,   for CA + risk
                                           user sign-in monitoring        SP sign-in log monitoring

Managed       Hosting resource             IMDS token request from        Least-privilege RBAC on the        Included in
              compromise (VM/App           unexpected source (rare,       Azure resource, network security    Azure
              Service compromise)          requires host-level access)    for the hosting resource

Before moving on, verify your understanding: Describe the three sign-in log fields that distinguish a legitimate sign-in from an AiTM phishing replay. Explain why each field has the value it does during the attack. Explain the CVE-2025-55241 attack chain in four steps. What made this attack exponential — how does compromising one tenant lead to compromising many?

Reusable script — the commands from this sub assembled for operational use:

Copy the per-type threat model table into your architecture package at 01-identity/identity-threat-model.md. For each identity type, add:

• Your tenant's specific count from MSA1.2 census
• Current control status (which controls exist in your environment, which are missing)
• Priority rating (which gaps are most dangerous given your identity profile)
• Module reference (which MSA module designs the fix)

This document becomes the driving input for MSA2 (which authentication methods per type), MSA3 (which CA policies target which types), MSA4 (privileged access for service principals and admin accounts), and MSA9 (which detection rules monitor which identity types).