Attackers Register Their Own Devices to Stay In. Close That Door in Entra

There is a step in the attack kill chain that gets far less attention than phishing or token theft: after compromising a user, the attacker joins their own device to your Entra tenant. From that point on they are not a suspicious sign-in anymore. They are a trusted device in your inventory, and they can come back whenever they like.

Microsoft 365 makes this easy, because as of November 2024 the default tenant settings let any user register or join any device into your active device inventory in Entra. This post covers the policies we recommend for restricting device registration to approved people, approved workflows, and approved moments.

What the defaults actually allow#

Think about how devices enter Entra today. There are really two major workflows:

• Through the out-of-box experience, when a new employee onboards or a workstation gets replaced
• Ad-hoc, whenever a device gets joined or registered outside of a planned rollout

The second path is the problem. When a user signs into desktop applications on any device, they get prompted to register that device with Entra, and there is no approval workflow in front of it. That is how asset inventories fill up with devices nobody vetted.

Why an open registration door is worth closing#

Without strict policies, letting any user register or join a device creates a back door for an attacker who compromises an account:

• Persistence. By joining their own device to your network, attackers maintain ongoing access without needing to repeatedly compromise the account. They hide as a trusted device.
• A polluted asset inventory. Registered personal devices bloat the device list, which makes it harder to track the approved, compliant devices you actually manage.

Pick your tier: Layer 1 versus Layer 2 controls#

We group these controls in two tiers. Layer 1 protections are settings we try to enable by default in every tenant we manage. Layer 2 protections are a step up because they involve:

• A deeper level of organizational maturity
• A higher impact on end users
• Another SOP your team has to support

The three policies below run roughly in that order, from enable-everywhere to enable-when-ready.

Policy 1: Put MFA in front of the register-or-join action#

Requiring multi-factor authentication specifically for device registration is simple and effective. Even if an attacker holds a compromised token (think adversary-in-the-middle attacks or cookie hijacking), the registration attempt triggers a fresh MFA prompt they cannot satisfy:

• Use case: an attacker tries to register a device and gets challenged for additional MFA, blocking the registration without the correct credentials.
• Implementation: create a new Conditional Access policy in Entra ID that enforces MFA for the user action of registering or joining devices. Any attempt to add a device then requires verification beyond username and password.

Policy 2: Limit who can join devices at all#

Restricting device joins to an approved-users group limits who can add devices in the first place. This control earns its keep in high-security environments and anywhere contractors or temporary staff are in the mix. The tradeoff: your user onboarding workflow needs a step that temporarily adds a new hire to this group while their workstation gets set up.

• Implementation: in Entra ID, configure the "Users may join devices to Entra ID" setting to restrict device joins to a specified group. For example, assign the onboarding team to handle device registrations rather than leaving the door open to everyone.
• Benefit: only approved users can join devices, which keeps unwanted hardware out of your environment.

Policy 3: Gate registration behind a Temporary Access Pass#

For the most controlled approach, require a Temporary Access Pass (TAP) to authorize device registrations. This reduces password-sharing risk during new-hire onboarding and ensures each registration window is temporary and verified by IT, so users cannot blindly register any device to Entra:

• How it works: IT generates a TAP with a limited validity window. New employees or new devices authenticate with the pass, and the time limit also narrows the window an attacker could use for device persistence.
• Implementation: in Entra ID under Authentication Methods, confirm TAP is activated in the policies. Configure an authentication strength for TAP that you can reference in Conditional Access. Then build a Conditional Access policy targeting the register-or-join-devices user action, exactly like Policy 1, but requiring the TAP authentication strength. Device registration is now restricted to a pass that IT controls.
• Added security: every registration requires coordination with IT, so nothing enters the inventory unreviewed.

Where this fits in the bigger device-access picture#

Registration hardening is one leg of a three-part standard for device access. The other two are requiring managed devices for sign-in and containing the personal devices you cannot manage. Deploy all three and the only devices touching corporate data are ones somebody approved.

How to verify these policies exist across tenants#

If you manage more than a handful of tenants, checking each one for these policies by hand does not scale. CloudCapsule automates Microsoft 365 security assessments: connect a tenant and within minutes you have a full security report mapped to the CIS Controls, including whether the device registration protections above are in place.