Welcome to this blog series focused on fortifying 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 companies overlooking the untapped capabilities of their licensed tools. My aim is to shed light on these missteps and guide you toward strengthening your environment.

Entra ID licensing unraveled

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.

---

Threat actors ❤️Entra default settings

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

---

Roles and Admins

Managing 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.

• Keep Global Administrators to under five. Enough for backup without handing out privileged keys like candy.

• Ditch M365 licenses that tie admin accounts to apps, data, or services. An admin account doesn’t need that kind of leash.

• 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 ensure you can still 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.

Authentication methods

Per-user MFA is the clunky, old-school way of doing things. Enabled one user at a time through the legacy MFA portal in Entra ID, it’s a relic from Azure AD’s early days. It ties MFA to individual profiles with minimal control. Think app passwords and basic methods like SMS or simple push. This setup doesn’t scale. It doesn’t integrate with Conditional Access, leaving you with a fragmented, outdated system. And forget about phishing-resistant Passkeys or centralized enforcement. Those aren’t even an option here.

Microsoft is pulling the plug on this, along with legacy Self-Service Password Reset (SSPR), by September 30, 2025. That’s your deadline to migrate to modern Authentication Methods in Entra ID. Act now, or risk getting stuck with a broken setup.

Start by reviewing the Legacy MFA settings. In the Microsoft Entra admin center. Go to Protection > Users > All users > in the top menu, look for Per-user MFA. This opens the legacy MFA portal. Now, check for any users that are either enforced or enabled and make sure to document them. There are also certain scripts for this.

Next, open the Service settings and document any current policies and methods you have:

Lastly, check your current Self-Service Password Reset (legacy) settings. As Microsoft clearly states, these settings can now be managed in one converged policy.

Now is a great time to get ahead of the curve and shift away from traditional MFA methods like SMS and voice calls, which are increasingly susceptible to risks such as interception and phishing. Incorporating this into your change management strategy and sharing a clear roadmap with your end users will help smooth the transition. I’d suggest disabling authentication options like SMS, voice calls, and email unless there’s a specific need for them or at least restricting their use to a defined group of users with limited alternatives.

Once you have decided what you want to go with, you can then either go with the automated migration, by selecting Begin automated guide – or do it manually, by clicking on change.

Wrap-up

Stay tuned for part 2!