🏢🧑💼TS - Default User Permissions
What this policy is about 🏢
Microsoft ships every new tenant with the front door unlocked. Default user role can create app registrations. Default user role can create tenants. Default user role can read all user objects. Default user role can invite guests. Default user role can do all of that without anyone ever knowing.
This is the policy that walks around the tenant flipping each of those defaults to the correct value, which in almost every case is "no, why would you let someone do that?" 🔒
It's four clicks. Maybe five. It's the single highest-ROI Entra config you'll touch this quarter.
Why this matters 🎭
Walk through what an unprivileged user can do in a fresh tenant, as of 2026:
- Create app registrations. Including app registrations they then grant themselves user-level consent on. This is how "I'll just connect this AI tool to my mailbox" turns into a Mail.Read.All consent grant that nobody noticed for three months. 📬
- Create new tenants. A regular user can spin up an entirely new Entra tenant under their own credentials and link it however they want. There is no MKB use case for this. None.
- Read every user in the directory. Including admins. Including their UPNs, departments, manager relationships. The starter kit for a credible phishing campaign comes pre-bundled. 🎣
- Invite guests. Which means any user can paste a Hotmail address into a "share with" dialog and the guest is now a member of the directory with cross-tenant context.
- Visit the Entra admin center. They can't change much, but they can read the org chart, the conditional access policies, the named locations. Threat actors love that page.
None of this is theoretical. All of it is the default. And the fix is six toggles on one page.
🛠️ Configuration Settings
Configured under Entra admin center → Identity → Users → User settings and Identity → External Identities → External collaboration settings. Tenant-wide.
User settings
| Setting | Value | Why |
|---|---|---|
| Users can register applications | No | App registrations create new identities in your directory. Letting Greg from sales spin up "GregBot for Outlook" with whatever permissions he clicked through is not a vibe. Admins create app registrations. Users consume them. |
| Users can create tenants | No | Zero legitimate MKB use cases. Pure attack surface. |
| Restrict access to Microsoft Entra admin center | Yes | Non-admins don't need the admin center. The page exists for the four people in IT, not for the hundred people not in IT. |
| Users can use preview features for My Apps | No | Preview = beta. You don't want your fleet on the beta channel of an identity portal. |
| Show keep user signed in | No | Yes-everywhere kept-signed-in tokens are exactly the kind of thing CAE was invented to fix. Don't fight CAE. |
| LinkedIn account connections | Disabled | The LinkedIn integration is opt-in cross-account linking, which is wonderful for marketing data and terrible for identity security. |
Default user role permissions
| Setting | Value | Why |
|---|---|---|
| Users can read other users | No | Default is "Yes" and that's how phishing-list-as-a-service stays in business. Restrict to "Members can read members but not all attributes" via Default User Role override (it's a single toggle). |
| Users can read all groups | No | Same logic. Group names disclose project structure, M&A activity, layoffs. |
| Users can register devices | Yes | This one stays on. Compliant device registration is the whole point of the Entra + Intune dance. |
| Restricted user can sign in | No | Disable the legacy "restricted user" carve-out entirely. |
External collaboration
| Setting | Value | Why |
|---|---|---|
| Guest user access | Restricted access (Most restrictive) | Guests get the bare minimum: their own object, the resources explicitly shared with them. They cannot enumerate the directory. |
| Members can invite guests | No | Invitations go through admins (or the Cross-Tenant Access Settings flow once that's configured). Random members forwarding invites is a vector. |
| Guests can invite | No | Guests inviting guests is how an unauthorized vendor invites two of their colleagues, and now you have three external accounts in your directory that nobody at the customer's office can name. |
| Admins and users in the guest inviter role can invite | Yes | The legitimate invitation path. |
| Enable guest self-service sign up via user flows | No | This is for B2C/customer-facing scenarios. Not applicable to internal MKB tenants. |
| Collaboration restrictions | Allow invitations only to specified domains | Maintain a per-tenant allowlist of partner domains. Default deny. The allowlist itself is the deliverable of the Cross-Tenant Access policy in this same Entra section. |
Admin consent + user consent for apps
| Setting | Value | Why |
|---|---|---|
| User consent for applications | Allow user consent for apps from verified publishers, for selected permissions | Users can consent only to apps from Microsoft-verified publishers, and only to low-risk delegated permissions (read profile, sign in). Anything else needs admin consent. |
| Group owner consent for apps accessing data | Do not allow group owner consent | Group owners don't make tenant-wide decisions about app permissions. |
| Admin consent requests | Yes, enable + designate reviewer accounts | Users can request admin consent through a workflow instead of being told "ask IT" and then giving up. Approvers get a notification, not a screenshot in Teams. |
Caveats ⚠️
License fit. All of these settings are included in Entra ID Free. They work on Business Premium and every higher SKU. The reason MKB tenants don't have them set is not licensing. It's that nobody ever clicked the toggles.
LinkedIn integration sometimes pushed back on. Marketing teams occasionally request the LinkedIn account connection because it shows colleague photos in Outlook. Outlook does this without the connection now. The connection itself is an identity-layer integration that does much more than the photo. Hold the line.
App registration restriction has a learning curve. Some users (devs, citizen-developer types) will be surprised they can no longer create app registrations. The right answer is a documented "request app registration" workflow that routes to the admin, not flipping the toggle back on because it caused tickets in week one. 🎫
Restricted admin center matters more than it sounds. The default lets any user browse to entra.microsoft.com and read the entire directory. Restricting access means they get a "you don't have permission to view this" page instead of an org chart. Subtle, important. 🚪
Reversibility. Tenant settings are clean-revert. Flipping a toggle back applies on the next sync. None of these tattoo. Which is good, because it also means there is nothing stopping them from being flipped back later if a privileged account gets phished. Set up an audit log alert on changes to the User Settings blade.
💡 SuperVision tip
Baseline policy. Golden Master → Entra → Tenant → Default User Permissions. Same six-ish toggles across every customer.
Tag candidates:
- Partner-domain allowlist for guest invitations: per-tenant. Each customer has their own set of partner domains (their accountant, their lawyer, their main supplier).
- Admin-consent reviewer accounts: per-tenant. Usually the customer's primary admin contact plus the MSP's tenant-engineer.
Everything else is fleet identity. Same value across every tenant.
Drift detection. Daily, not quarterly. These six toggles are the kind of thing a phished privileged account will flip first because flipping them creates persistence. If "Users can register applications" goes from No back to Yes, that's not a config drift. That's an attacker preparing the next step. 🚨
Onboarding. When taking over a new tenant, do this first, before any CA work. The CAs assume an unprivileged user can't enumerate the directory to find admin accounts. If this baseline isn't in place, the CAs are designed against a directory that doesn't exist.
Audit log retention. Set Entra audit log retention to the maximum your tenant SKU allows (Business Premium = 30 days; you'll want longer via Log Analytics export). Tenant-settings changes are the canary you want a long tape on.
👥 Assignment scope
Tenant-wide. There are no groups. There are no exclusions. There is no "this user should be allowed to register apps". If they should, they should have the Application Developer role assignment, not a tenant-wide unlock.
🔗 Related
- 🔐🧑💼AMP - Authentication Methods (the methods policy that the new default-permissions floor leans on)
- 🌐🧑💼XT - Cross-Tenant Access Defaults (the partner-allowlist mechanism for guest invitations)
Six toggles. Maybe five. Most consequential thing you'll click in Entra this month. ⚡