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
- While conditional access policies prevent logins unless MFA is complete, it does not mean the user has actually setup MFA. Cork is validating that the user has enrolled in at least one secure, secondary authentication method.
- 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