How do you find sign-ins not protected by MFA in Microsoft Entra ID?

How sign-in data reveals where MFA is missing

in microsoft entra id, the fastest way to spot sign-ins not protected by MFA is to work from the sign-in logs and isolate successful authentications that completed without an MFA challenge or without MFA satisfaction recorded. That gives you the practical gap list, not just a policy statement. It is especially useful for finding exceptions that stay hidden in normal access reviews.

Because this is a sign-in analysis problem, the key question is not only whether MFA exists in the tenant, but whether the recorded authentication path actually enforced it for the sign-in you are reviewing. MFA Guide is useful here because it separates phishing-resistant MFA from weaker methods and highlights common bypass paths such as legacy authentication and exclusion-heavy rollouts.

For microsoft entra id administrators, the practical filter is usually a combination of status, authentication requirement, and sign-in result details. A successful sign-in with no MFA claim is the event you want to retain, then compare it to the user, application, location, and policy context so you can tell whether the absence of MFA was expected or accidental.

Which sign-ins to compare against policy coverage

The most useful comparisons are the ones that explain why a sign-in escaped MFA enforcement. That usually means looking at excluded users, service accounts, legacy protocols, break-glass accounts, and conditional access paths that were intentionally left outside the control set. Those populations matter because they can look legitimate in the log while still representing a standing authentication gap.

Reviewing exclusions at the same time as the sign-in record helps you separate policy design from policy failure. A user may authenticate successfully without MFA because the account was explicitly excluded, the app used a legacy flow, or the sign-in was handled through an exception path that was never revisited after rollout. The goal is to identify which of those cases is still justified and which is now exposure.

When the problem is broader than one or two exceptions, it often reflects an MFA rollout that has not been fully normalized across identity types and apps. The Workforce Identity Security Guide is relevant because it treats MFA, SSO, recovery, and session control as one operating model rather than separate projects, which is exactly how gaps stop reappearing.

How to close the gap without creating new blind spots

Once you have the list, the remediation sequence should focus on policy coverage first, then exception cleanup. Tighten the conditional access scope, remove unnecessary exclusions, retire legacy authentication, and make sure high-risk break-glass paths are tightly controlled and monitored. If a sign-in path cannot satisfy MFA, it should be treated as a deliberate exception with an owner and expiry, not as an informal workaround.

For high-value accounts and recovery paths, the issue is often not only sign-in enforcement but also how the account was enrolled, reset, or recovered. That is why a broader identity control model matters: if one path can still authenticate without the intended factor set, the policy is not complete even if most users are covered. The IAM and Identity Provider Buyer's Guide helps frame those provider and lifecycle choices as part of MFA coverage, not just a product selection exercise.

After tightening the policy, re-run the same sign-in query and confirm the previously uncovered events are either blocked, stepped up, or explained by a documented exception. If the same accounts still appear, that is a sign your enforcement boundary is wrong, not that the user population is unusually difficult.

Risk and Threat Considerations

Unprotected sign-ins are risky because they create authenticated access paths that may be invisible to teams who assume MFA coverage is already universal. That is especially dangerous for legacy authentication, service credentials, and break-glass accounts, where attackers can aim for the weakest path rather than the most obvious one.

Failure mechanism: A sign-in succeeds through a path that is outside MFA enforcement, often because of an exclusion, unsupported protocol, or exception account that was never revisited after rollout.

Impact: Attackers or unauthorized users can obtain durable access with only a password or other single factor, which increases the chance of account takeover, lateral movement, and persistence.

Practitioner Guidance

What to verify: Confirm that the sign-in event shows both successful authentication and the absence of MFA satisfaction, then verify whether the account, app, or protocol was intentionally excluded. If the record is ambiguous, treat it as an enforcement investigation, not a reporting issue.

Common mistake: Teams often focus on “MFA enabled” status instead of actual sign-in enforcement. That misses legacy authentication, exceptions, and account classes that can still log in without the factor being applied.

Decision rule: If a successful sign-in can reach production systems without MFA and the path is not a tightly controlled break-glass exception, close it or reclassify it as a high-risk finding.

Practitioner takeaway: The useful unit of analysis is the sign-in event, not the tenant setting, because only the event tells you whether MFA was actually enforced at the point of access.

Related resources from NHI Mgmt Group

• How do you find sign-ins using legacy authentication in Microsoft Entra ID?
• How do you investigate AI agent sign-ins in Microsoft Entra Agent ID?
• How do you block risky sign-ins with Conditional Access in Microsoft Entra ID?
• How do you block sign-ins from specific countries with Conditional Access in Microsoft Entra ID?