Rogue Device Registration: Stop Attackers Planting Trusted Devices in Your Tenant

An attacker who registers their own device in your identity provider stops being a stolen session and becomes a trusted endpoint, with tokens that survive password resets and policies that treat the device as one of yours. Device registration is the step that turns a phished credential or token into long-lived access: in Microsoft Entra ID a registered device can obtain a Primary Refresh Token (PRT), and in Okta a new Okta Verify enrolment becomes a factor the attacker controls. This guide covers what registration grants, the tenant settings that decide who can register and how many devices, how to require strong authentication for the registration step itself, the log events and queries that surface rogue devices, and how to respond. It is for identity engineers and detection teams running Entra ID or Okta. The initial phishing technique that usually precedes this is covered in the Device Code Phishing Guide, and this page does not repeat it.

Key takeaways

• Registration is persistence, not just access. MITRE ATT&CK tracks it as T1098.005 Account Manipulation: Device Registration, with APT29 and Scattered Spider among the procedure examples.
• The defaults are permissive. In Entra ID, "Users may join devices to Microsoft Entra ID" defaults to All, the per-user device quota defaults to 50, and the tenant-wide MFA requirement for registration defaults to No.
• Protect the registration step with Conditional Access. The "Register or join devices" user action lets you require an authentication strength at the moment a device is added, and Microsoft recommends it over the legacy device setting.
• Registered is not the same as healthy. A rogue device can be registered without ever being managed or compliant, so access policies that accept "registered" or "known device" as a trust signal give the attacker what they wanted.
• Every new device should match a reason. Correlate "Register device" and Okta device.enrollment.create events with onboarding tickets, recent device code or risky sign-ins, and dormant accounts.

Why device registration is an attacker objective

Most identity attacks start with something short-lived: a password, a session cookie or a refresh token. Device registration converts that into a durable foothold. The device record becomes an object in the directory, bound to keys the attacker holds, and many access policies then grant it more trust than an unknown browser.

• Token durability: in Entra ID, a registered or joined device can request a PRT, which gives single sign-on to every application the user can reach and carries a device claim. See the Entra ID Primary Refresh Token (PRT) Security Guide for how the PRT is protected and revoked.
• Policy bypass: policies that require "a registered device" or that relax MFA for known devices treat the attacker's machine as trusted.
• MFA persistence: in Okta and other MFA platforms, registering a new authenticator device gives the attacker a factor of their own. MITRE notes that some self-enrolment flows need only a password, which makes enrolling a first device on an inactive account especially easy.
• Internal phishing and denial of service: ATT&CK also records registered devices being used to send internal phishing from a trusted context, and mass registration being used to exhaust tenant device quotas.

The clearest public example is Storm-2372. Microsoft reported in February 2025 that the actor moved within a day to requesting device codes under the Microsoft Authentication Broker client ID. The resulting refresh token was used to obtain a token for the Device Registration Service, register an actor-controlled device in Entra ID, and then obtain a PRT with the new device identity to reach organisational resources and collect email. Full actor detail is in the Storm-2372 (device code phishing) threat actor profile.

Device identity types and what each one grants

The exposure depends on which kind of device identity can be created and by whom. Entra ID has three, and Okta models devices around Okta Verify.

Two settings in the Entra device settings blade deserve particular attention. "Registering user is added as local administrator on the device during Microsoft Entra join" controls local admin on the joined device only, and does not grant a directory role. "Manage Additional local administrators on Microsoft Entra joined devices" assigns the Microsoft Entra Joined Device Local Administrator role, which applies to every joined device in the tenant, so keep that role assignment small and reviewed.

Locking down who can register, and how many devices

Device settings live under Entra ID, Devices, Device settings, and need the Cloud Device Administrator role to change. The table gives Microsoft's documented defaults and our recommended hardened target; the targets are our recommendations, not Microsoft defaults.

If you use Intune, add enrolment restrictions as a second layer. "Enrollment device limit restrictions" accept 1 to 15 devices per user, and device platform restrictions can block personally owned enrolment per platform. Microsoft states plainly that enrolment restrictions are not security features, because a compromised device can misrepresent its attributes, so treat them as hygiene and keep the identity-layer controls as the real barrier. They also do not apply to Entra join, Autopilot or bulk enrolment, for which the Entra device quota is the hard limit.

In Okta, the equivalent levers are the authenticator enrolment policy (who may enrol Okta Verify and with what prior assurance), the requirement for an existing strong factor before adding a new one, and device lifecycle states: a device can be suspended or deactivated, and deactivation stops it being linked to Okta Verify factors. See the Okta Security Hardening Guide for the wider baseline.

Requiring strong authentication for the registration step

The Conditional Access user action "Register or join devices" evaluates a policy at the moment a device is added, independent of which application the user was signing in to. Microsoft's documented policy is:

1. Turn off the legacy setting: set "Require multifactor authentication to register or join devices with Microsoft Entra ID" to No.
2. Create the policy: include All users, exclude emergency access accounts, and under Target resources choose User actions, Register or join devices.
3. Grant control: Require authentication strength. The built-in Multifactor authentication strength is the documented baseline; a phishing-resistant strength is stronger where every registering user already has a passkey or Windows Hello for Business. If you rely on external authentication methods, use "Require multifactor authentication" instead, because external methods are currently incompatible with authentication strength.
4. Report-only first: run the policy in Report-only and review its impact before switching it On.

MFA at registration has a known limit: an attacker who already holds a refresh token carrying an MFA claim, as in device code phishing, may satisfy a plain MFA requirement. That is why the strongest designs layer three things.

• Phishing-resistant strength for registration: raises the bar from "has an MFA claim" to "proved possession of a bound credential now".
• Block device code flow: use the Conditional Access authentication flows condition to block device code flow for everyone who does not need it, as Microsoft recommends after Storm-2372. The Conditional Access Guide covers the policy design.
• Location or network conditions: where registration only happens during onboarding at known sites, add a named location condition, and use a Temporary Access Pass for the first credential so a password alone never enrols anything. MITRE's mitigation M1032 lists both ideas, along with blocking new enrolment for inactive accounts.

Detecting rogue registrations

Registration events are rare and high-signal in most tenants, which makes them good detection material. The core events are below.

Correlation queries worth building

Described here as logic rather than finished rules, so you can express them in KQL, Splunk or your SIEM of choice.

• Registration after device code or broker sign-in: join "Register device" audit events to the same user's sign-ins in the preceding hour where the authentication protocol was device code, or where the client was the Microsoft Authentication Broker from an unfamiliar location. This is the Storm-2372 pattern. Microsoft's own hunting query for the campaign filters the Defender XDR CloudAppEvents table on the Device Registration Service account display name to list newly registered devices.
• Registration by a dormant or recently reset account: any new device for an account with no sign-in for 30 or more days, or within 24 hours of a password or MFA reset (these thresholds are our suggested starting points; tune them to your tenant). This matches MITRE detection DET0036 analytic AN0103 and the APT29 dormant-account procedure.
• Burst registrations: more than a small number of devices registered by one user, or tenant-wide spikes, which can indicate quota exhaustion attempts or automated tooling.
• New device followed by mailbox or file access: a PRT-based sign-in from a device created within the last day, followed by bulk mail or SharePoint access. See the Entra ID Sign-In and Audit Log Detection Guide.
• Okta enrolment without a matching help desk or onboarding event: device.enrollment.create for a user who had a factor reset or a new session from an unusual network in the previous hours. The Okta System Log Detection Guide covers the System Log fields.

Metrics that show the controls work

• Percentage of registrations and joins covered by a Conditional Access policy that required an authentication strength (target: 100 percent outside break-glass).
• Number of users with more devices than your quota policy intends, and the trend after lowering the quota.
• Percentage of new device registrations matched to an onboarding, replacement or ticket record within 24 hours.
• Median time from a rogue-registration alert to device disable and session revocation.
• Count of stale device objects with no activity in 90 days, which hide rogue devices in noise.

Responding to a rogue device

Treat a confirmed rogue registration as an account compromise with persistence, not a hygiene issue. Order matters, because removing the device before revoking tokens can leave refresh tokens alive.

1. Preserve evidence: export the device object (device ID, registration time, owner, OS, trust type) and the related audit and sign-in events before changing anything.
2. Disable the device: disable the device object in Entra ID, or suspend or deactivate it in Okta, so device-based policies stop accepting it.
3. Revoke sessions: revoke the user's refresh tokens and sessions (Microsoft Graph revokeSignInSessions in Entra ID; clear user sessions in Okta), then reset the password.
4. Review authentication methods: remove any MFA method, passkey or Okta Verify enrolment added during the compromise window. The Account Takeover Response Playbook covers the rest of the account clean-up.
5. Check what the device reached: mailbox rules, OAuth consents, file downloads, BitLocker or LAPS secret reads, and any further devices registered from the same session.
6. Delete and close: delete the device object once evidence is held, and record the root cause (device code phishing, help desk reset, password spray) to drive the preventive fix.

Rolling out the controls without breaking onboarding

1. Inventory first: list every device object with registration date, trust type, owner and last activity. Find users above 10 devices and devices with no owner.
2. Map legitimate registration paths: Autopilot, Intune Company Portal, Windows "Add work account", mobile app brokers, kiosk and shared devices, and any automation account that pre-creates devices.
3. Deploy the Conditional Access user action in Report-only for two to four weeks, and check which registrations would have failed and why.
4. Turn on alerting for the correlation queries above before tightening, so you have a baseline.
5. Lower the device quota in steps (for example 50 to 20 to 10), watching help desk tickets.
6. Restrict join to a group and block device code flow outside named exceptions.
7. Switch the policy On with a pilot ring first. Roll back by returning the policy to Report-only; the device settings can be reverted instantly by a Cloud Device Administrator.
8. Clean up stale devices on a schedule, so a rogue object cannot hide among thousands of abandoned ones.

Small organisations without Intune can still get most of the value: set join to a named group, lower the quota, add the Conditional Access user action and alert on every "Register device" event, which will be low volume. Large enterprises should make the onboarding system the source of truth and alert on any registration it did not expect.

Framework mapping

Common failure patterns

• Leaving join and registration at All with a quota of 50: any phished user can add dozens of devices, and nobody notices because nothing alerts.
• Turning on both MFA controls: leaving the legacy "Require multifactor authentication to register or join devices" setting at Yes alongside the Conditional Access user action, which Microsoft says stops the user action policy being properly enforced.
• Trusting "registered" as a compliance signal: access policies or third-party integrations that accept any registered device as trusted, instead of requiring a compliant or hybrid joined device.
• Password-only first enrolment: new starters, or dormant accounts, can enrol their first MFA device with just a password, which is exactly the path MITRE documents for APT29.
• Removing the device but not the tokens: deleting the rogue device without revoking refresh tokens and reviewing authentication methods leaves the attacker able to register again.
• Stale device sprawl: thousands of inactive objects make a single rogue device invisible in reviews. The Orphaned and Dormant Accounts guide applies the same discipline to accounts.

Practitioner checklist

• Set "Users may join devices to Microsoft Entra ID" to Selected (an enrolment group) or None where Autopilot handles joins.
• Lower "Maximum number of devices" from the default 50 to a figure that fits real use.
• Set the legacy device MFA setting to No and create a Conditional Access policy on the "Register or join devices" user action requiring an authentication strength, tested in Report-only first.
• Block device code flow with the authentication flows condition for everyone without a documented need.
• Use a Temporary Access Pass, not a password, for first credential and device enrolment, and block enrolment for inactive accounts.
• In Okta, require an existing strong factor before a new Okta Verify enrolment and review the authenticator enrolment policy.
• Alert on "Register device", "Add registered owner to device" and device.enrollment.create, correlated with device code sign-ins, resets and dormant accounts.
• Restrict non-admin BitLocker key recovery and keep the Joined Device Local Administrator role small.
• Run a stale-device clean-up on a schedule and report device counts per user monthly.
• Rehearse the rogue-device response: preserve, disable, revoke sessions, review methods, check reach, delete.

Standards and references

• MITRE ATT&CK: Account Manipulation: Device Registration (T1098.005)
• Microsoft Learn: Manage device identities in the Microsoft Entra admin center
• Microsoft Learn: Require multifactor authentication for device registration
• Microsoft Learn: Microsoft Entra audit log activity reference
• Microsoft Security Blog: Storm-2372 conducts device code phishing campaign
• Microsoft Learn: Create device platform and device limit enrollment restrictions in Intune
• Okta Developer: Event types
• Okta Help: Device assurance policies

Related NHI Mgmt Group resources: Device Code Phishing Guide · Entra ID Primary Refresh Token (PRT) Security Guide · Device Trust and Posture Guide · Storm-2372 (device code phishing) threat actor profile · Conditional Access Guide