User has MFA disabled

Associated with

Inboxes

Underlying signals

IDAM MFA Disabled (RS24)

Reasonings

• Regular user, and
  • Shared inboxes and distribution groups should be ignored and should never have this event
• MFA connection does not have any secondary authentication factors configured, or
  • A user may be enrolled to have MFA enabled, but they may not have actually configured secondary factors
• Email connection does not have secondary authentication configured
  • An inbox may have policies that force MFA, but the user may not have actually configured secondary factors

Resolutions

• Configure a secondary authentication factor, or
• If user is being offboarded, consider turning their inbox into a shared mailbox, or deactivating the user entirely

Additional Considerations

• User/inbox must be seen from an integration that would relay MFA information
  • A user existing only in an email security platform would not raise this event
• If in Entra, a user’s MFA state is Enabled or Enforced, it is important to know this does not necessarily mean they have configured a secondary factor.
  • For both statuses, “If the user has no registered authentication methods, they receive a prompt to register the next time they sign in using modern authentication”
  • https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-userstates#microsoft-entra-multifactor-authentication-user-states