A practical best-practices guide for hardening Microsoft Entra ID: multi-factor authentication, Conditional Access, privileged access, application identities, external access, and monitoring. The controls that stop the majority of real Microsoft 365 incidents, in priority order.

Identity is where the highest-impact, lowest-effort security wins live in Microsoft 365. The patterns below are ordered roughly by impact, so if you only have time for the first few, you will still close the gaps that matter most.

1. Require strong, phishing-resistant authentication

Multi-factor authentication is the single most effective control in Entra ID, but not all MFA is equal. SMS and voice codes are phishable and SIM-swappable. Move toward phishing-resistant methods: the Microsoft Authenticator app with number matching, FIDO2 security keys, Windows Hello for Business, or certificate-based authentication.

• Cover everyone. Require MFA for all users, not just administrators. Attackers pivot through standard accounts.
• Use authentication strengths. Define strength policies so high-value applications and privileged actions demand phishing-resistant methods specifically.
• Retire weak methods. Audit who is still on SMS or voice, and who still relies on legacy per-user MFA rather than Conditional Access enforcement.
• Clean up registration. Stale or missing authentication-method registration is a gap. Confirm every active user has strong methods registered.

2. Build a Conditional Access baseline, then keep it complete

Conditional Access is the policy engine that decides who can access what, from where, on which device, and with what authentication strength. The common failure is not missing policies but coverage gaps: a policy that excludes a group that should no longer be excluded, a policy stuck in report-only, or an application that no policy actually covers.

A solid baseline set includes: require MFA for all users; block legacy authentication; require compliant or hybrid-joined devices for sensitive applications; require phishing-resistant strength for administrators; and risk-based policies that step up or block on sign-in and user risk. Then the ongoing job is verification, confirming the policies still cover every user and app as the tenant changes. Senserva's Conditional Access analysis surfaces coverage gaps, risky exclusions, and policies that look protective but are disabled or report-only.

3. Block legacy authentication

Legacy authentication protocols, older mail clients, POP, IMAP, and SMTP AUTH, cannot perform MFA, so they are the favorite path for password-spray and credential-stuffing attacks. Block legacy authentication tenant-wide with Conditional Access, after using sign-in logs to identify and migrate any remaining legitimate legacy clients. This one change closes a disproportionate share of real attack paths.

4. Minimize standing privilege with PIM

The damage an attacker can do is decided by how much standing privilege exists when they get in. Most tenants have too many Global Administrators and too many roles assigned permanently rather than just in time.

• Minimize Global Administrators to a small, named set. Use least-privilege roles (User Administrator, Helpdesk Administrator, Security Reader) for routine work.
• Make privileged roles eligible, not active, with Privileged Identity Management (PIM), so admins elevate just in time with approval and justification, and access expires automatically.
• Set role-management policies: require MFA and approval on activation, cap activation duration, and alert on privileged role changes.
• Do not forget Azure RBAC. Directory roles are only half the picture; subscription Owner and Contributor assignments carry equivalent risk.

5. Use Identity Protection for risky users and sign-ins

Entra ID Identity Protection scores user risk and sign-in risk using Microsoft's signal. Review risky users and risky sign-ins regularly, and wire risk into Conditional Access so a high-risk sign-in is challenged or blocked automatically rather than waiting for a human to notice. Confirm that risk remediation (password reset on high user risk) is configured, and investigate detections like impossible travel, anonymous IP, and leaked credentials.

6. Configure and monitor break-glass accounts

Every tenant needs emergency access ("break-glass") accounts that can get in if MFA infrastructure or a Conditional Access policy locks everyone out. Best practice: at least two cloud-only accounts, excluded from MFA and Conditional Access policies, with long random passphrases stored securely offline. Critically, these accounts must be tightly monitored: alert on any sign-in, because a break-glass login should be rare and deliberate. An unmonitored excluded account is a backdoor; a monitored one is a safety net.

7. Govern applications, consent, and service principals

Application identities are the most overlooked part of Entra ID security. A malicious OAuth consent grant or an over-permissioned app can read mail and files without ever touching a password, and it survives password resets.

• Restrict user consent so users cannot grant arbitrary third-party apps access. Require admin consent beyond a small set of low-risk delegated scopes.
• Audit OAuth grants and application permissions for broad scopes like Mail.ReadWrite, Files.ReadWrite.All, and Directory.ReadWrite.All, and justify each.
• Enforce credential hygiene: find long-lived or expiring client secrets and certificates, and rotate them.
• Hunt risky service principals, especially high-privilege ones with recent credential changes.

8. Lock down guest and external access

External collaboration is valuable but expands the identity boundary. Set external collaboration settings to the least-permissive level your business allows, control who can invite guests, and apply Conditional Access to guest users. Review cross-tenant access settings and periodically recertify guest accounts so access does not outlive the project that needed it.

9. Strengthen passwords and self-service reset

Even in a passwordless push, password hygiene matters. Enable Entra Password Protection to ban weak and custom-banned passwords (including brand and local terms attackers guess), and turn on self-service password reset (SSPR) with strong verification so resets do not become a helpdesk social-engineering vector. The long-term direction is passwordless: phishing-resistant methods that remove the password as an attackable secret entirely.

10. Monitor sign-in and audit logs

Identity security depends on visibility. Confirm sign-in logs, audit logs, and provisioning logs are flowing and retained. Microsoft's default sign-in log retention is 14 days, so route logs to a SIEM such as Microsoft Sentinel for longer history and correlation. Senserva brings Entra, Microsoft 365, Defender, and Sentinel log sources into one model and checks log health so a silent gap does not surface only during an investigation.

Frequently asked questions

Require phishing-resistant MFA for every user and block legacy authentication. Compromised credentials are behind the majority of Microsoft 365 incidents, and these two changes are low effort for very high impact.

Yes. Microsoft renamed Azure Active Directory (Azure AD) to Microsoft Entra ID in 2023. The service and most concepts are the same; the name and some portal locations changed.

As few as practical, typically a small named set, with the role assigned as PIM-eligible rather than permanently active. Standing Global Admin access is the single biggest amplifier of an incident, so day-to-day work should use least-privilege roles.

Restrict user consent so users cannot grant arbitrary apps access, require admin consent beyond a small set of low-risk scopes, and regularly audit existing OAuth grants and application permissions for over-broad access and stale credentials.

Use Identity Protection for risky users and sign-ins, alert on break-glass account use, and retain sign-in and audit logs beyond the 14-day default by routing them to a SIEM such as Microsoft Sentinel.

Next: read the full how to harden Microsoft 365 guide, or scan your own tenant free.