How do I secure a Microsoft Entra ID tenant?

Sandeep Sidhu · 2026-09-16 · 11 min read

Almost every Microsoft 365 breach at the small and mid-size end starts with a signed-in identity, not an exploited server. That is why identity is the first place to spend effort, ahead of anything on the endpoint. Microsoft Entra ID is the product formerly called Azure Active Directory. The rename was announced in July 2023. Older documentation, PowerShell modules and half the internet still say Azure AD.

A tenant somebody else set up is usually wide open in ways nobody chose deliberately. Start with the two controls that block how accounts actually get taken, then tighten the permissions that decide how far an attacker gets once they are in.

What are the two things to do first?

Block legacy authentication and require multi-factor authentication for every administrator, then for every user. These two actions stop the attack that is actually happening.

Legacy authentication uses older protocols that support only basic authentication: POP, IMAP, SMTP AUTH, MAPI over HTTP in older clients, Exchange ActiveSync with basic auth, and Office 2010 and earlier. They send a username and password and cannot present a second factor.

Sign-in logs usually show traffic on these protocols even in tenants that believe MFA is enforced. Everything further down this page is worth doing. These two come first.

Why does blocking legacy authentication come before MFA?

You enable MFA for a user, but they still get compromised. The account is takeable over a legacy protocol because the protocol has no mechanism to ask for the second factor. Enabling MFA without blocking legacy authentication leaves the door you just locked standing open next to its own frame.

Find out who is using it first. The Entra sign-in logs let you filter on client app, and the usual answers are a multifunction printer scanning to email, a line-of-business application sending SMTP, and one person's old phone mail client. Fix those first, with SMTP AUTH on a dedicated account or a proper relay.

Block it with a Conditional Access policy targeting all users, with client apps set to Exchange ActiveSync clients and Other clients, and access set to Block. This removes the path that ignores MFA entirely.

Security Defaults or Conditional Access?

Security Defaults and Conditional Access are alternatives. A tenant runs one or the other, never both.

Security Defaults is free, available on every tenant, and all or nothing. It requires MFA registration for all users, enforces MFA for administrators, blocks legacy authentication, and protects privileged actions. For a tenant with no need for exceptions it is a genuinely reasonable answer and much better than nothing.

Conditional Access needs Microsoft Entra ID P1 (included in Microsoft 365 Business Premium and E3). It gives per-policy control: who, which app, which conditions, what is required. The moment the tenant needs one exception, a service account, a location-based rule, a device compliance requirement, it is time to move from Security Defaults to Conditional Access.

Turning Security Defaults off before the Conditional Access policies are built, run in report-only mode and reviewed is how a tenant ends up briefly with no MFA at all. Build first, then switch.

Why do break-glass accounts come before any policy?

A Conditional Access policy that requires a compliant device, or an MFA method that later breaks, can lock every administrator out of the tenant, including whoever wrote the policy. A permanently excluded account is the way back in.

Create two cloud-only accounts with the Global Administrator role, permanently excluded from every Conditional Access policy. Make them cloud-only, in the .onmicrosoft.com domain, not synced from on-premises Active Directory, so an outage or a compromise of the on-premises directory does not take them with it.

Use long random passwords, stored offline and physically, split so no one person holds a whole credential. Exclude them from all Conditional Access policies, including the MFA ones. This is the deliberate, documented exception.

Alert on any sign-in. A break-glass account signing in is either a genuine emergency or an incident, and either way somebody should know within minutes. Test them on a schedule. An emergency account nobody has tried since the day it was made is a guess, not a plan.

Which MFA methods actually hold up?

Enforce multi-factor authentication for administrators first, then for all users. Use Conditional Access rather than the old per-user MFA toggles. Microsoft began enforcing mandatory MFA for sign-ins to the Microsoft Entra admin centre, the Azure portal and the Intune admin centre from October 2024, with later phases extending to command-line tooling. Administrative MFA is no longer a choice in those portals, but that enforcement covers the portals, not your users, so tenant policy still has work to do.

Methods, strongest first: FIDO2 security keys and passkeys, and Windows Hello for Business. These are phishing-resistant because the credential is bound to the origin, so a proxy phishing page cannot replay it. Certificate-based authentication is also phishing-resistant.

Microsoft Authenticator push with number matching. Number matching has been on by default since May 2023 and it is what defeats push bombing, where an attacker with a stolen password sends approval prompts until somebody taps accept. Turn on the additional context options, which show the application and the sign-in location in the prompt.

Authenticator one-time codes come next. SMS and voice calls are the weakest of the lot, because both fall to SIM swapping and to real-time phishing. Keep them as a fallback for users who genuinely cannot use anything else, never as the standard.

Configure all of this in the converged Authentication methods policy rather than the legacy MFA and self-service password reset method settings. Microsoft retired the legacy policies on 30 September 2025, so anything still configured there needs migrating.

How many Global Administrators should a tenant have?

A tenant should have fewer than five Global Administrators. Most tenants have more because the role is the default choice when the correct role is not known.

Assign the least-privileged role that does the job. Helpdesk Administrator resets passwords for non-admins. User Administrator manages users and groups. Exchange Administrator manages mail. Security Reader reads security data without changing anything. Global Reader is the read-only twin of Global Administrator and is the right role for auditors and for most reporting needs.

Review who holds privileged roles on a schedule. Include the accounts nobody thinks of as users: a former employee still enabled, the account a departed consultant was given, and the service accounts.

With Microsoft Entra ID P2 there is Privileged Identity Management, which makes privileged roles eligible rather than permanent: an administrator activates the role for a limited window, with justification and optionally approval, and it expires by itself. Standing privilege is what an attacker inherits when they take an account; eligible privilege is not.

How do attackers get in without a password?

An attacker sends a link to a user. The user clicks accept. The application asks for permission to read their mail and files. The illicit consent grant attack does not need a password at all. The user approves the request, and the attacker holds a token that survives a password reset and is not stopped by MFA.

In Enterprise applications, under Consent and permissions, set user consent to either not allowed, or allowed only for verified publishers and low-impact permissions. Then enable the admin consent workflow, so a user meeting a legitimate application raises a request instead of hitting a dead end, and an administrator decides.

Review what already has consent. Enterprise applications shows the applications in the tenant and the permissions they hold. Anything with mail or file read permissions that nobody recognises deserves an explanation.

What should ordinary users and guests not be able to do?

Ordinary users can do more in the directory than most organisations intend. In Users, under User settings, set Users can register applications to No. Set Restrict access to the Microsoft Entra admin centre to Yes. That hides the portal from non-administrators, which is worth having, but it is not a security boundary: the same directory data is still reachable through Graph and PowerShell. Decide deliberately on Users can create security groups and Microsoft 365 groups.

Under External Identities, external collaboration settings, set Guest user access to the most restrictive option: guest access restricted to properties and memberships of their own directory objects. The default lets guests read more of the directory than is usually intended. Restrict who can invite. The default in many tenants lets any member, and even guests, invite more guests.

Set Collaboration restrictions to allow or deny specific domains where the business only works with known partners. Cross-tenant access settings control what is trusted in both directions with other Microsoft tenants, including whether MFA claims from a partner tenant are accepted. Review inbound and outbound separately.

Guests accumulate. Review them, and use access reviews to expire them automatically where the licensing allows it.

What if there is on-premises Active Directory?

The Entra Connect or Entra Cloud Sync service account is highly privileged. Treat the server running Entra Connect as a tier zero asset, in the same class as a domain controller, because an attacker on it can reach the directory.

Password hash synchronisation, pass-through authentication and federation are different trust models with different failure modes. Federation with AD FS means the AD FS signing key is the keys to the tenant, which is the path the Solorigate intrusion used. Password hash sync is usually the right default for small tenants, and it keeps sign-in working when the on-premises environment is down.

If single sign-on is in use, it creates a computer account called AZUREADSSOACC in Active Directory whose Kerberos decryption key should be rolled regularly. Microsoft's guidance is every 30 days. Most tenants have never rolled it once. Exclude privileged on-premises accounts from synchronisation. Cloud administrators should be cloud accounts.

How do I keep logs long enough to investigate?

Entra sign-in and audit logs are retained in the portal for a limited period, and for a free tenant that period is short. An incident is usually discovered well after it started, so logs that have already expired are the difference between reconstructing what happened and guessing.

Route the diagnostic settings for sign-in and audit logs to a Log Analytics workspace, a storage account, or a SIEM, and keep them for as long as the organisation's obligations require. Set this up before the incident.

Microsoft Entra ID P2 adds Identity Protection, which scores sign-in risk and user risk, and two policies are worth having: require MFA on sign-in risk at medium and above, and require a secure password change on user risk at high. Neither is available without P2. On P1 the substitute is a careful Conditional Access baseline and somebody actually reading the sign-in logs.

How do I roll a policy out without locking anyone out?

A Conditional Access policy applies to real people the moment it is saved. Report-only mode evaluates it and records what would have happened without blocking anybody, and the results show up per policy in the sign-in logs.

Create the policy in report-only, leave it for a few days, read what it would have done, fix what it would have broken, then enable it. Always exclude the break-glass accounts. Always check the user scope before saving, because All users includes the account you are signed in with.

Microsoft Secure Score in the Microsoft 365 Defender portal grades the tenant against Microsoft's recommended configuration and gives specific actions with an estimated impact, and Microsoft Entra recommendations do the same for identity. Treat both as a worklist to argue with rather than a number to maximise. A score driven up by switching on things nobody in the building understands is worse than a lower score that somebody can explain.

Moorfox does not manage the tenant. None of the controls above is configured from an RMM. What Moorfox covers is the other half of the same problem, the machines the identities sign in from. A token stolen from a machine with no EDR and three months of missing patches is a tenant compromise that no Conditional Access policy sees as anomalous, because the sign-in is genuinely coming from the user's own laptop. The per-device security score grades encryption, anti-malware, EDR, patch compliance and local administrator count on every enrolled machine, which is the endpoint side of the same account takeover the identity controls are trying to prevent.

Frequently asked questions

What is the single most important setting to secure a tenant?

Blocking legacy authentication is the single most important setting. MFA does not protect an account reached over a protocol that cannot ask for a second factor, so blocking legacy auth is what makes the MFA rollout real.

Should I use Security Defaults or Conditional Access?

Use Security Defaults if the tenant needs no exceptions; it is free and much better than nothing. Move to Conditional Access as soon as one exception is needed, and build the policies in report-only mode before turning Security Defaults off, never the other way round.

What is a break-glass account and do I really need two?

Two cloud-only Global Administrator accounts excluded from all Conditional Access are needed so a policy that locks everyone out still has a way back in. Two accounts are required because one can itself be lost or compromised. Alert on every sign-in and test them on a schedule.

Is SMS good enough for MFA?

It is better than nothing and worse than everything else, because of SIM swapping and real-time phishing. Use FIDO2 keys, passkeys or Windows Hello for Business where you can, Authenticator with number matching next, and keep SMS as a fallback rather than the standard.

How many Global Administrators should a tenant have?

Fewer than five, per Microsoft's guidance. Everyone else gets the least-privileged role that does their job, and Global Reader covers most of what people ask Global Administrator for.

Can an attacker get into my tenant without a password?

Yes, through an illicit consent grant: the user approves an application's request to read their mail or files, and the resulting token survives a password reset and is not stopped by MFA. Restrict user consent and turn on the admin consent workflow.