Entra guest auth method change
A GUEST identity changed its own authentication method — a new phone number or authenticator registration on an account whose home is another tenant.
What it detects
A GUEST identity changed its own authentication method — a new phone number or authenticator registration on an account whose home is another tenant.
Guests are the weakest link in a tenant's identity posture and the least watched. They are invited for one project, keep their access after it ends, and sit outside the reviews, the MFA campaigns and the leaver process that cover employees, because none of those own the account. Nobody notices a guest that has not signed in for a year.
When a dormant one wakes up and re-registers its second factor, the second factor is now the attacker's. From there the guest's existing access — shared sites, Teams channels, delegated mailboxes — is reachable with credentials that pass every control, because the account is legitimately entitled to all of it.
Keyed on the #EXT# marker Entra puts in every external identity's principal name, so this stays a guest-only finding and does not restate the tenant-wide security-info rule.
MITRE ATT&CK mapping
False positives and triage
Guests do legitimately re-register: a new phone, a rebuilt laptop, a lost authenticator. The question is whether anything else about the account changed at the same time. Check when the guest last signed in before this — a registration after months of silence is the shape that matters, while a guest active all week replacing a device is routine. Check the source address and country against where the partner organisation actually is. Then check what the guest can reach: if the answer is a finance site or an executive's calendar, treat the registration as a takeover until the partner confirms otherwise, by a channel other than email to that account. Tenants that onboard many partners will see volume here; scope the rule to guests holding sensitive access rather than raising the threshold.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 65%. Source: rules/cloud/entra_guest_auth_method_change.yaml, licensed under the Apache License 2.0.
id: cloud.identity.entra_guest_auth_method_change
version: 1.0.0
status: stable
severity: high
confidence: 0.65
platforms: [application]
mitre_techniques: [T1556.006, T1098.005, T1199]
description: |
A GUEST identity changed its own authentication method — a new phone number or
authenticator registration on an account whose home is another tenant.
Guests are the weakest link in a tenant's identity posture and the least
watched. They are invited for one project, keep their access after it ends, and
sit outside the reviews, the MFA campaigns and the leaver process that cover
employees, because none of those own the account. Nobody notices a guest that has
not signed in for a year.
When a dormant one wakes up and re-registers its second factor, the second factor
is now the attacker's. From there the guest's existing access — shared sites,
Teams channels, delegated mailboxes — is reachable with credentials that pass
every control, because the account is legitimately entitled to all of it.
Keyed on the `#EXT#` marker Entra puts in every external identity's principal
name, so this stays a guest-only finding and does not restate the tenant-wide
security-info rule.
match:
provider_any: [Office365, AzureAD]
raw_message_contains_any:
- "registered security info"
- "security info registration"
- "Register security info"
- "changed default security info"
- "StrongAuthenticationMethod"
- "StrongAuthenticationPhoneAppDetail"
- "User registered security info"
raw_message_regex: "#EXT#"
correlation_keys: [user_name]
false_positive_guidance: |
Guests do legitimately re-register: a new phone, a rebuilt laptop, a lost
authenticator. The question is whether anything else about the account changed at
the same time. Check when the guest last signed in before this — a registration
after months of silence is the shape that matters, while a guest active all week
replacing a device is routine. Check the source address and country against where
the partner organisation actually is. Then check what the guest can reach: if the
answer is a finance site or an executive's calendar, treat the registration as a
takeover until the partner confirms otherwise, by a channel other than email to
that account. Tenants that onboard many partners will see volume here; scope the
rule to guests holding sensitive access rather than raising the threshold.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.