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

Included in the Microsoft 365 E3 package, it introduces useful features like Conditional Access policies. These help enforce Zero Trust principles by controlling access to apps and data based on factors such as user location or device status.

Entra ID P2

Included in Microsoft 365 E5 or E5 Security, it adds powerful tools like Identity Protection, Risk-Based Conditional Access, and Privileged Identity Management (PIM). It's especially valuable for organizations with complex environments or sensitive data to protect.

image source: m365maps.com

So, what do you really need?

For most organizations looking to strengthen their security, Entra ID P1 is a solid starting point.
It provides the essential tools to improve your security posture, including Conditional Access. At the very least, make sure all end-users are licensed with P1 to enable these policies effectively.

If you need to take things further, especially in high-risk or complex environments, Entra ID P2 offers additional protection with advanced features.

Understanding your licensing is key. It helps ensure you’re not relying on basic features that may fall short of your security requirements.

---

Default settings are a threat actor’s best friend

When you create a new Entra ID tenant, it comes with Microsoft’s default settings. These defaults offer a starting point, but they’re not secure enough for most real-world environments. Identity is a common target for attackers, and weak configurations can leave your entire Microsoft 365 setup exposed.

Since Entra ID controls access across your environment, securing it is essential. The good news? You don’t need a full overhaul to make a difference. A few focused adjustments can significantly reduce your attack surface. This blog post walks you through practical changes you can make today. No complex processes, just clear steps to help improve your security posture.

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

By default, any user in Entra ID can register applications in the tenant. This creates both an app registration and a service principal, allowing the user to access APIs or services, such as Microsoft Graph, using permissions they’ve granted themselves.

It’s a level of access that should typically be restricted to administrators to avoid potential security risks.

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

Default settings let users create security groups in Entra ID. User-made groups can spiral into a mess. Think orphaned groups, over-privileged memberships, or accidental data exposure.

Restrict Access to Microsoft Entra Admin Center

By default, all users can access the Entra admin center (entra.microsoft.com) and browse certain information. They can view users, groups, and applications they own or can see access that most standard users don’t need. This visibility can unintentionally expose details like group memberships or application configurations, potentially revealing weak points. If a regular user account is compromised, this level of access could help an attacker map out your tenant.

While it’s not full admin access, it’s still more than necessary for most users.

Separately, the Azure AD PowerShell module (although deprecated) continues to allow read access. This will remain in place until the underlying APIs are fully retired. If you're still using it, now is a good time to start transitioning to Microsoft Graph PowerShell for better long-term support.

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

Guest invite settings determine who can bring external users into your organization.
By default, everyone in the tenant (including existing guests) can send invitations. Without any oversight this can quickly lead to an uncontrolled number of external accounts.

The most secure option is to disable guest invitations entirely or restrict the ability to a specific security group with the Guest Inviter role. However, for organizations that rely heavily on external collaboration, this level of control may not be practical.

A more balanced approach is to set this to “Members assigned to specific admin roles.” This limits the risk while still supporting collaboration where needed.

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…or worse. Threat actors 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

source: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/concept-understand-roles#categories-of-microsoft-entra-roles

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, threat actors 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