Entra ID: đź”’Lock It or Lose It #1 - The Basics


Welcome to this blog series focused on securing your Entra setup. Here I will explore the frequent vulnerabilities I often encounter while evaluating various tenant configurations. Repeatedly, I notice problems arising from untouched Microsoft defaults or organizations overlooking the untapped capabilities of their licensed tools. My aim is to shed light on these missteps and guide you toward strengthening your environment. Just a heads-up: these recommendations are based on my own preferences and experiences from various implementation projects across different environments.
👉 Always test, validate, and monitor changes before rolling anything out in production. Build your own understanding of what works best for your organization!
Entra ID licensing explained
Before we dive into the nitty-gritty details, let’s tackle one topic that often confuses people: licensing. Entra ID offers a variety of plans, each bringing something unique to the table. Getting a handle on what you’ve got can pave the way for a smoother journey ahead. Here’s the fast breakdown of the key ones:
Entra ID Free
This is the basic toolkit you’re handed when you first spin up your tenant. It covers simple identity management…like user and group handling, single sign-on for certain apps, and multi-factor authentication. It’s a decent jumping-off point, but for security… it’s pretty much the bare minimum.
Entra ID P1
P1 steps things up a notch. Bundled with the Microsoft 365 E3 package, it throws in some compelling extras like conditional access policies. Think of them as the magic ingredient for zero trust. It’s a must-have if you’re looking to secure apps and data based on stuff like user location, device status, or other factors.
Entra ID P2
This one’s for those ready to push security into overdrive. Included in Microsoft 365 E5 or E5 Security bundles, it unlocks the full arsenal: Identity Protection, Risk-Based Conditional Access, and Privileged Identity Management (PIM). If you’re safeguarding a bigger, trickier setup or handling sensitive data, Entra ID P2 changes the game.
image source: m365maps.com
So, what do you really need?
For most outfits aiming to shore up their defenses, Entra ID P1 hits the mark nicely. It delivers the core tools to ramp up your security game. At a minimum, ensure all your end-users are equipped with it so you can roll out conditional access. If you’re itching to go further and throw up even tougher roadblocks against threats, Entra ID P2 adds that vital extra shield.
Grasping your licensing means you won’t be caught off guard, stuck with basic features that fall short of the protection you actually need.
Default settings are a threat actor’s best friend
When you set up a fresh Entra ID tenant, you’re handed Microsoft’s default settings. They give you a starting point, sure, but they’re nowhere near secure enough. Threat actors are always sniffing around for weak spots, and a lax identity setup is practically a welcome mat for chaos.
Entra ID serves as the gatekeeper for your Microsoft 365 world. If it falls, everything’s up for grabs. Bolstering your defenses isn’t just smart…it’s non-negotiable. The good news? A handful of sharp tweaks can shrink your attack surface.
This blog post zeroes in on practical security adjustments you can tackle today. No massive revamps, no convoluted processes, just impactful steps to lock down your environment. Let’s get started.
Entra ID user settings
Here are some of the easy wins I’d suggest tackling right away.
Users can register apps
Out of the box, any user in Entra ID can set up their own applications in the tenant. This spins up an app registration and a service principal, allowing them to tap into APIs or services (think Microsoft Graph) with permissions they’ve green-lit themselves. That’s a privilege that should be locked down to administrators only.
Restrict non-admin users from creating tenants
Out of the box, users can create new tenants. Separate Entra ID instances, via self-service sign-ups (for instance when starting a free trial). This can lead to sprawl and the main administrator account being linked to the initial tenant. To avoid this link disabling self-service sign-ups is a good start.
Users can create security groups
Right from the start, users can spin up new tenants. Standalone Entra ID instances through self-service sign-ups (like when kicking off a free trial). This can spiral into chaos and tie the primary admin account to the original tenant. A solid first step to dodge this mess is to turn off self-service sign-ups.
Restrict Access to Microsoft Entra Admin Center
Straight out of the gate, every user can log into the Entra admin center (entra.microsoft.com) and poke around. They can peek at users, groups, and apps they own or have eyes on. Regular users don’t need that kind of window into the system. They might spot more than they should (like group memberships or app setups) or trip over settings that reveal soft spots. A compromised account with admin center access could sketch out your tenant for an attack. It’s not full admin power, but it’s still too much. On another note, the Azure AD PowerShell module, even hough it’s deprecated, still hands out read access. That’ll stick around until the underlying APIs are completely phased out. If you’re still leaning on it, now’s a smart time to shift toward Microsoft Graph PowerShell for future-proofing.
Show keep user signed in
The “Keep me signed in” option determines whether users stay logged in after closing their browser. If enabled, it creates a persistent cookie that maintains the session even after the browser is restarted. On corporate devices with SSO, this setting is redundant, but on unmanaged devices, it can pose a security risk by keeping accounts accessible indefinitely. I recommend switching this off.
Guest user access
The default is limited access, meaning guests can see group memberships they’re in and some directory data. That’s enough for a compromised guest to scope out your tenant. Think user lists or group structures, before escalating an attack. It is recommended to switch to the most restrictive option. With the most restricted option, guests lose visibility into other users, groups, or directory objects beyond their own account.
Guest invite settings
The Guest invite settings control who gets to bring outside users into your organization. Right off the bat, everyone in the tenant, including guests, can send out invites. These can spiral into a flood of external accounts before you know it. The tightest fix is to shut down guest invitations completely, or at least limit the power to a specific security group tagged with the Guest Inviter role. That said, for organizations leaning hard on external collaboration, such rigid controls might not fly. Striking a balance between security and productivity, setting this to “Members assigned to specific admin roles” seems more practical.
User consent for applications
By default, users can grant third-party applications permission to access their data. This can lead to data exposure, shadow IT, and even account takeovers. Attackers have historically abused this feature by tricking users into consenting to malicious OAuth apps disguised as legitimate services. However, this type of attack is less common today. Instead threat actors are increasingly leveraging legitimate third-party applications, such as CRM systems or other business tools, to gain access and misuse granted permissions.
You could consider setting up an admin approval for this, which means if a user wants to connect an external app which isn’t already registered in the tenant, they can submit a request.
An admin is then notified by email and can review whether the app meets security and compliance standards before granting access
Entra Roles
Built-in directory roles
Let’s talk about roles and administrators in Entra ID. Microsoft offers a set of built-in roles, currently around 60 built-in directory roles, designed to cover most scenarios. Microsoft continuously adds new roles as Entra ID expands, while some older roles are phased out as services merge or evolve. That’s why it’s a good idea to regularly review which roles are actually being used in your tenant. What was relevant a year ago might not be today.
Custom role
In most cases, the built-in roles will do just fine. But sometimes, you need something more precise. That’s where custom roles come into play. A custom role is useful when you need fine-grained control over what an admin can and cannot do. For example:
You want an admin to create and modify certain policies, but not delete them.
You need to grant permissions for managing a specific service without giving full access to the entire admin center.
In these cases, you can create a custom role by selecting specific API permissions in Microsoft Graph. It’s a powerful option but one you should use sparingly.
Entra ID role categories
Entra ID and Role-Based Access in Microsoft 365
Microsoft 365 includes multiple services like Entra ID, Intune, Exchange, Purview, and Defender XDR. Some have their own RBAC (role-based access control) systems, while others, like Teams, SharePoint rely on Entra roles for admin access. Azure, on the other hand, has its own separate RBAC system for managing resources.
Each service manages access separately, storing roles outside Entra with unique permission rules. To simplify admin control, Microsoft added built-in Entra roles that map to permissions in other services.
Types of Entra roles
Entra specific roles: Manage Entra ID itself (e.g., Conditional Access Administrator, Groups Administrator)
Service specific roles: Control individual Microsoft 365 services via Entra (e.g., Exchange, Intune, SharePoint, Teams)
Cross-service roles: Apply across multiple services (e.g., Global Administrator, Security Administrator).
For a full list, check out the link above.
What can you do to secure your roles & admins?
Managing Entra Admin roles isn’t just about dishing out permissions, it’s about keeping risks in check and ensuring the right folks have just the access they need, no excess baggage.
Steer clear of on-premises synced accounts for admin roles. They are a weak link. If your Active Directory takes a hit, attackers can ride that privileged escalator straight to your cloud resources. And the reverse is true too. Stick with cloud-native Entra ID accounts instead. They cut off that escalation route, shrinking your attack surface nicely.
Use the principle of least privilege. Meaning that users, systems, or services should only have the permissions they absolutely need to get the job done. Nothing more. This minimizes risks, reduces mistakes and strengthens security against attacks. Privileged Identity Management plays a vital role in this. But more on that subject in another blog post!
Limit Global Administrators to less than five.
Skip licenses that plug admin accounts into apps, data or services. An admin account doesn’t need to be licensed.
Set up phishing-resistant MFA - like a Passkey - and aim to lock it in as required. I’ll spend more details on this in a future blog post!
Deploying Privileged Access Workstations enhances security and imposes rigorous controls over the locations where administrative accounts can be utilized.
Self-Service Password Reset (SSPR) might be great for regular users, but for admins? Not so much. Allowing admins to reset their own passwords creates an unnecessary security risk. If an attacker gains access to an admin’s authentication method, they could compromise a high-privilege account.
A Temporary Access Pass is a time-limited, one-time passcode that allows users to sign in and set up a new authentication method without needing a password. Instead of relying on traditional passwords for Entra administrators, use TAP when onboarding or reboarding an admin. This ensures a secure and streamlined process, allowing them to register a phishing-resistant authentication method, such as a Passkey, right from the start. I will be writing a separate blog about this in the next blog series.
Emergency access accounts 🦺
Emergency access accounts (aka break-glass accounts) are your last resort when everything else goes wrong. If your primary admins get locked out due to a misconfigured policy, MFA failure or other issue, these accounts could most likely ensure that you can regain control.
Create at least two cloud-native emergency access accounts. Keep them completely separate from your normal admin accounts, and never use them for daily operations.
Use FIDO2 hardware security keys for strong, phishing-resistant authentication. Store these keys in fireproof safes at two different locations. The PINs should only be known by a select few authorized personnel.
Exclude from Conditional Access (CA) policies. These accounts must always be accessible. Place them in a security group that is excluded from all CA policies to prevent accidental lockouts.
Limit exposure with Administrative Units. Restrict their scope to minimize risk.
Monitor activity closely. These accounts should never be used under normal circumstances. Any unexpected login attempts are a red flag, track sign-ins and audit logs for anomalies.
Test and validate regularly. An emergency account that doesn’t work when you need it isn’t much of an emergency account. Schedule periodic tests to confirm they’re still functional and secure.
Next blog post
In my next blog post, we’re diving into authentication methods:
Entra ID: đź”’Lock It or Lose It #2 - Authentication Methods
Subscribe to my newsletter
Read articles from Thijs Hurenkamp directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by

Thijs Hurenkamp
Thijs Hurenkamp
Cloud enthusiast specialized in Microsoft technology with an emphasis on Microsoft 365, Azure and more.