Review MFA registration events in Defender XDR

An authentication-method change deserves a closer look during an account investigation. The useful details are who made the change, which account was changed, and what happened around the same time.

These are reference hunting queries. They have not been run against a live tenant for this revision.

Check the available events

CloudAppEvents depends on Defender for Cloud Apps and the connected workloads. Start by checking the action names your tenant actually receives:

CloudAppEvents
| where Timestamp >= ago(14d)
| summarize Events = count(), LastSeen = max(Timestamp) by ActionType
| order by Events desc

Look for authentication-method operations and inspect a sample record. The labels below are examples; confirm them in your results before relying on the filter. An empty result can mean missing ingestion, different labels, or no matching activity.

Collect the investigation details

CloudAppEvents
| where Timestamp >= ago(14d)
| where ActionType in~ (
    "User registered security info",
    "Admin registered security info",
    "User changed default device"
)
| project
    Timestamp, ActionType, AccountDisplayName, AccountId,
    AccountObjectId, IsAdminOperation, ObjectName, ObjectId,
    IPAddress, CountryCode, City, UserAgent, ReportId
| order by Timestamp desc

The output keeps event identifiers for follow-up. Keep the original record available when exporting results.

AccountObjectId identifies the account associated with the activity. For an administrative operation, confirm the actor and affected account in the audit record before assigning an alert entity. They may be different people.

Review the change

Check the Entra audit record for the exact method operation, result, initiator, and target. Correlate it with sign-ins and help-desk work around the event time.

Useful questions during triage:

• Was the change part of a device replacement or account recovery?
• Does the IP match a known office, VPN, or mobile provider?
• Did the account have other sensitive changes in the same period?
• Was the registration followed by sign-ins using the new method?

IP geolocation is approximate. A different country alone is weak evidence, especially for VPN and mobile traffic. Generic Update user events need inspection of the changed properties before treating them as authentication-method changes.

Building a detection

A historical baseline must end before the event being assessed. Comparing a month’s registrations with the same month’s sign-ins introduces later activity into the baseline.

Scheduled detections also have their own data windows. Microsoft’s documented hourly lookback for Defender data is four hours; a 30-day comparison in the query cannot restore data excluded by that window. Keep the baseline outside the rule or validate an enrichment available on the event.

Start with an alert-only rule and review expected registrations, travel, and account recovery activity. Keep method removal and default-method changes as separate test cases. This query does not establish coverage for all of them.

References

• CloudAppEvents schema and ingestion requirements
• Custom detection requirements and lookback periods