Entra ID default user settings: what every user can do without a role
Without any admin role, an Entra ID user has meaningful rights by default: creating app registrations, groups and even new tenants. These settings often date back to when the tenant was created and have never been reviewed.
Where these settings live
Most of them are set under Entra ID user settings and, technically, in the tenant's authorization policy, which holds the default permissions of the user role. Group and device settings complete the picture. Defaults can change, so check the current Microsoft documentation and compare it with your actual configuration.
Application registration
By default, any user can register applications. Registering an app does not grant permissions on your data, but it creates objects the user owns, often with no oversight. These applications are sometimes used as a foothold for internal phishing or persistence.
The usual recommendation is to turn this setting off and give registration rights through the Application Developer role, assigned to those who need it, or through a request process.
Creating groups and tenants
- Security groups: users can create them by default. Depending on your organisation, reserve this for administrators or the relevant teams.
- Microsoft 365 groups: their creation is governed by a separate group setting that can limit it to members of a designated group. Each group also creates a shared mailbox, a SharePoint site and often a team.
- Tenant creation: by default, a user can create a new tenant in which they become Global Administrator, outside any governance. The restriction setting is worth enabling.
Self-service sign-up. Also check that external users cannot join your tenant through email-verified sign-up, and that self-service purchases are controlled. These are governed by separate settings.
Reading the directory
By default, a user can read information about other users, groups and applications. That is what lets an attacker with a single ordinary account map out the tenant. A setting to block this exists, but it disrupts many legitimate scenarios, notably in Outlook and Teams. It is rarely usable as is; it is better to be aware of it and compensate by detecting bulk enumeration.
Access to the admin center
The setting that restricts access to the Entra admin center to administrators is not a security boundary: it blocks neither Microsoft Graph, nor PowerShell, nor other tools. It can be turned on to discourage curiosity, but it must never be presented as a protection. To genuinely block access to admin tools, you need a Conditional Access policy targeting the relevant applications.
Other settings to review
- Whether users can read the BitLocker keys of their own devices;
- LinkedIn account connections;
- Whether users can join or register devices, and the maximum number per user;
- User consent to applications, handled in a separate setting but inseparable from this review.
In the tenants we audit, these settings have almost always been left at their original values.
What an audit checks
- Authorization policy values: app registration, security group and tenant creation, reading other users.
- How Microsoft 365 group creation is configured.
- Applications registered by non-admin users.
- Tenants created by users in the organisation, where this can be established.
- Whether admin tools are actually protected by Conditional Access.