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.

• 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
• SIM swap attack succeeds against an account using SMS MFA, giving the attacker full authentication capability before the user is aware they have lost control of their phone number

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.

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

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.

Overe Auto-Response: The Disable MFA alert can be configured in Overe to trigger automatic session revocation or account block when MFA is removed from a user account. Review your Auto-Response settings under Org Config > Auto-Response to ensure MFA removal events trigger an appropriate automated response.

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

After reviewing user MFA settings, also check these related risk areas:

• Admins with Risky MFA Settings — weak MFA on admin accounts carries a higher individual impact; prioritise admin accounts alongside standard users in the same review cycle
• CA MFA Bypass Paths — a user with MFA registered may still be able to authenticate without completing it if they fall into a CA gap; check both together to understand the full authentication posture
• Conditional Access Exclusions — users excluded from MFA-enforcing policies face the same risk even if MFA is registered; review exclusions as part of the same assessment
• Dormant Users — dormant accounts with weak MFA are particularly dangerous as they generate no behavioural signals; check both in the same review
• Risky Inbox Forwarding Rules — account compromise often ends with forwarding rules; check for active forwarding on any mailbox associated with a weak MFA account