Users with Risky MFA Settings: Account Compromise & Lateral Movement Risk

Why this risk matters

User accounts with weak or missing MFA are consistently the entry point for business email compromise, ransomware delivery, and data theft. Once an attacker controls a regular user account, they have access to email, files, Teams, and any application the user can reach — and a foothold to escalate further.

Overe flags user accounts where MFA is not registered, relies on SMS or voice calls, or where the account is excluded from Conditional Access policies that enforce authentication controls. While the individual impact of a standard user account compromise is lower than an admin account, the volume of users at risk and the consistency with which these accounts are targeted makes this a high-priority area.

Attackers rarely need admin access to cause significant damage. Access to a single user's mailbox is often enough to conduct invoice fraud, intercept sensitive communications, or pivot to other accounts through internal phishing.

What happens if this is abused

  • Credential phishing or password spray attack succeeds against an account with no or weak MFA
  • Attacker accesses mailbox, OneDrive, SharePoint, and Teams without triggering sign-in alerts
  • Internal phishing emails sent from the compromised account to colleagues and partners
  • Business email compromise conducted from within the organisation's trusted sending domain
  • Sensitive documents, financial data, or client information exfiltrated
  • Account used as a pivot point to attempt privilege escalation or lateral movement to other accounts
  • Persistence maintained through inbox rules or OAuth app consent even after a password reset

When this is expected or acceptable

Most standard user accounts should have MFA enforced with no exceptions. Some scenarios require judgment.

Shared accounts or service desk aliases are sometimes configured differently, though best practice is to move these to dedicated service accounts or shared mailboxes without interactive sign-in. A shared mailbox account that cannot receive MFA prompts may have a legitimate technical reason for exclusion — this should be documented and reviewed.

Temporary exclusions during MFA rollout or device migration are common. These should be time-bound and tracked, not left open indefinitely.

SMS MFA is still better than no MFA for standard users, but it should not be treated as a finished state. Any user still on SMS should be prioritised for migration to the Microsoft Authenticator app or a hardware key.

Checks to perform before taking action

Before modifying any user account's authentication settings:

  • Confirm whether the account is a named individual, a shared account, or an automated service account
  • Check the account's last sign-in date and whether it is still in active use
  • Identify whether the account is excluded from any Conditional Access policy and whether that exclusion is documented
  • Review whether MFA is registered at all, or whether the user is relying solely on a password
  • Check sign-in history for unusual IP addresses, countries, or device patterns
  • Review Overe for any related alerts or Defender risk signals tied to this account
  • Confirm whether the account has access to sensitive data, finance systems, or privileged applications

Safe remediation steps

  1. Use Overe to review the full list of users with risky MFA settings and prioritise by sign-in activity and data access scope
  2. For users with no MFA registered, enforce registration through Conditional Access and require completion before the next sign-in
  3. For users relying on SMS or voice MFA, communicate the migration path to Microsoft Authenticator with number matching
  4. Enable number matching in the Microsoft Authenticator authentication policy if not already active tenant-wide
  5. For accounts excluded from MFA policies, review and remove exclusions that are not documented and intentional
  6. For inactive accounts with risky MFA, consider whether the account should be disabled before remediation
  7. Document exceptions with a named owner and a review date

Where direct remediation is required, Overe provides links to the appropriate Microsoft admin controls to complete the action safely.

Supporting documentation

Microsoft: Configure Microsoft Entra multifactor authentication - https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-getstarted

Microsoft: Number matching in Microsoft Authenticator - https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-number-match

Microsoft: Manage authentication methods in Microsoft Entra ID - https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods-manage

Related risks and follow-on checks

  • Admins with risky MFA settings
  • Conditional Access MFA bypass paths
  • Conditional Access exclusions creating risk
  • Dormant users
  • Risky forwarding rules
TBD CTA