Device settings in Entra ID: joining, local administrators, LAPS and clean-up

Who can join and register devices

Two separate settings need examining. The first decides who can join a device to Entra ID: all users, a selection or nobody. The second decides who can register a personal or mobile device. By default, all users can do both.

For joining, restricting it to a group (desktop team, deployment accounts) is usually sensible, especially if devices are provisioned through Windows Autopilot. A user who joins an unmanaged device themselves creates a trusted object in the directory, which may satisfy some access conditions.

The maximum number of devices per user is also worth lowering: the default is generous and makes it easier for an attacker holding a compromised account to register devices.

Requiring MFA for registration

The "Require multifactor authentication to register or join devices" setting still exists, but Microsoft now recommends using Conditional Access instead, with the "Register or join devices" user action. That lets you require an authentication strength or a specific location. The two mechanisms should not be combined: if you use Conditional Access, turn the directory setting off.

Local administrators on joined devices

On an Entra-joined device, several populations become local administrators:

• holders of the Global Administrator role;
• members of the "Microsoft Entra Joined Device Local Administrator" role;
• by default, the user who performed the join.

The last point is the most problematic: every user who joins their own workstation becomes its administrator. A setting now lets you control this behaviour (all, selected or none), and Windows Autopilot profiles can also create standard users. As for the device local administrator role, it applies to every joined device: if it is assigned widely, one compromised account gives administrator access to the whole fleet. Finer-grained options exist in Intune, such as targeted local group management policies.

Windows LAPS with Entra ID

Windows LAPS can back up the local administrator password to Entra ID instead of Active Directory. Setting it up takes two steps: enable LAPS in the Entra ID device settings, then deploy a policy (usually through Intune) that defines the managed account, complexity, lifetime and the action taken after the password is used.

The thing to watch afterwards is who can read the passwords. Reading is restricted to certain roles, such as Cloud Device Administrator or Intune Administrator, or to custom roles with the corresponding permission. Each retrieval is logged and is an event worth tracking. Along the same lines, check whether users can recover the BitLocker keys of their own devices, a neighbouring setting on the same page.

Cleaning up stale devices

Inactive devices clutter the directory, distort inventories and are needless trusted objects. The last activity timestamp attribute lets you find them. The approach we recommend:

1. set an inactivity threshold that fits your usage cycles;
2. disable the devices concerned first, rather than deleting them;
3. wait for an observation period to catch mistakes;
4. delete afterwards, once the impact has been checked.

Two pitfalls come up often. Deleting a device deletes the BitLocker recovery keys stored with it in Entra ID. And hybrid joined devices must be cleaned up on the Active Directory side: deleted only in Entra ID, they come back at the next synchronisation. Devices registered in Autopilot also need particular care.

What an audit checks

• Who is allowed to join and register devices, and the maximum per user.
• MFA required for registration, through the setting or Conditional Access, without duplication.
• Members of the joined device local administrator role and the behaviour for the joining user.
• Whether Windows LAPS is enabled and who can read the passwords.
• The setting governing BitLocker key recovery by users.
• The volume of stale devices and whether a clean-up procedure exists.