Entra device registration anomaly
A device was registered or enrolled against a user account.
What it detects
A device was registered or enrolled against a user account.
Conditional access commonly requires a compliant or joined device, which makes device registration the way through that requirement rather than around it: enrol a machine the attacker controls and the policy is satisfied honestly from then on. The account then passes every subsequent check, and the sign-ins look clean because they are — the trust decision was made once, at enrolment.
It is also how a stolen PRT becomes durable: a registered device gets its own token, so access survives the password reset that would otherwise end it. Related to the PRT replay rules, one step earlier in the chain.
MITRE ATT&CK mapping
False positives and triage
Device registration is routine — every new laptop and phone produces one, and onboarding weeks produce many. Read it against the account rather than on its own: a registration from an address the user has never signed in from, or one that follows a suspicious sign-in for that same user, is the case worth pursuing, as is a second device appearing for a user who already has a working one and has raised no ticket. In a tenant with predictable hardware, the device platform in the record is often the fastest tell.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 60%. Source: rules/cloud/entra_device_registration_anomaly.yaml, licensed under the Apache License 2.0.
id: cloud.identity.entra_device_registration_anomaly
version: 1.0.0
status: stable
severity: high
confidence: 0.6
platforms: [application]
mitre_techniques: [T1098.005, T1556.006]
description: |
A device was registered or enrolled against a user account.
Conditional access commonly requires a compliant or joined device, which makes
device registration the way through that requirement rather than around it: enrol
a machine the attacker controls and the policy is satisfied honestly from then on.
The account then passes every subsequent check, and the sign-ins look clean
because they are — the trust decision was made once, at enrolment.
It is also how a stolen PRT becomes durable: a registered device gets its own
token, so access survives the password reset that would otherwise end it. Related
to the PRT replay rules, one step earlier in the chain.
match:
event_action_any:
- "Add device"
- "Add device."
- "Add registered owner to device"
- "Add registered owner to device."
- "Add registered users to device"
- "Register device"
correlation_keys: [user_name, source_ip]
false_positive_guidance: |
Device registration is routine — every new laptop and phone produces one, and
onboarding weeks produce many. Read it against the account rather than on its own:
a registration from an address the user has never signed in from, or one that
follows a suspicious sign-in for that same user, is the case worth pursuing, as is
a second device appearing for a user who already has a working one and has raised
no ticket. In a tenant with predictable hardware, the device platform in the
record is often the fastest tell.
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.