Top 10 Entra ID misconfigurations to fix first

Across audits, the same Entra ID weaknesses show up again and again. None of them are exotic — they are everyday gaps that attackers actively exploit. Here are the ten worth fixing first, in rough order of impact.

1. Legacy authentication not blocked

Legacy protocols (POP, IMAP, SMTP AUTH, older Office clients) bypass modern controls including MFA. Leaving them enabled is one of the most exploited gaps in Entra ID. Block legacy authentication with a conditional access policy — after checking sign-in logs for anything still using it.

2. Privileged accounts without MFA

Global Administrators and other privileged roles without enforced MFA are the highest-value target in your tenant. Every admin account must require phishing-resistant MFA, no exceptions.

3. Too many Global Administrators

The more Global Admins you have, the larger your attack surface. Keep the count minimal, use least-privilege roles for day-to-day tasks, and reserve Global Admin for the few who truly need it.

4. No Privileged Identity Management (PIM)

Standing privileged access is a liability. PIM makes privileged roles just-in-time and time-bound, with approval and audit. Without it, admin rights are permanent — and permanent rights get abused.

5. Guest access left wide open

Default guest settings often let external users enumerate far more than necessary, and guests frequently lack enforced MFA. Restrict guest permissions and require MFA for external identities.

6. Weak or absent conditional access

Conditional access is the policy engine of Entra ID. Gaps — no baseline MFA policy, no device or location conditions, unprotected admin portals — leave the front door ajar. Build a coherent set of policies and review them regularly.

7. Insufficient log retention

If sign-in and audit logs are not retained long enough (or exported to a SIEM), you cannot investigate an incident after the fact. Ensure retention meets your investigation and compliance needs — commonly 180 days or more.

8. Self-service settings too permissive

Users being able to register applications, consent to third-party apps, or invite guests without oversight creates a steady stream of risk. Tighten self-service and app consent settings, and require admin consent for anything sensitive.

9. Stale accounts and unused credentials

Disabled-but-not-removed accounts, unused service principals and lingering credentials expand your attack surface silently. Review and clean them up on a schedule.

10. No break-glass account strategy

Emergency access ("break-glass") accounts must exist, be excluded from conditional access that could lock you out, use strong unique credentials, and be monitored. Getting this wrong means either lockout or an unmonitored super-account.

How to prioritise the fixes

Not all ten carry equal weight. Block legacy authentication and enforce phishing-resistant MFA on admins first — those two close the widest, most-exploited paths for the least effort. Reducing the Global Admin count and rolling out PIM come next, because they shrink the blast radius of any single compromise. Log retention and self-service tightening are important but rarely the thing an attacker hits on day one. A weighted score that costs a failed foundational control more than a failed hardening one reflects exactly this ordering.

Turning findings into a plan

A list of ten problems is not a remediation plan until each has an owner, a portal path and a target date. The value of an audit that carries the remediation step and the framework reference on every finding is that the plan half-writes itself: each row becomes a ticket with the fix and the justification already attached. Re-running the audit after the work then proves the regression is closed rather than assumed.