Understanding the MFA Report

The MFA Report provides visibility into the multi‑factor authentication (MFA) status of user accounts in supported Microsoft 365 organizations. This report is used to review whether MFA is enabled for accounts and to document MFA configuration state observed by the platform.

The report reflects configuration state, not authentication activity. It does not determine whether an account has successfully used MFA, and it does not enforce MFA settings or take response actions. Its purpose is to surface MFA configuration so it can be reviewed in context alongside other investigation or reporting findings.

This report is generated from Microsoft 365 integrations and is read‑only.

What the report shows

The MFA Report indicates whether MFA is enabled for each applicable account, based on information retrieved from Microsoft. The report is intended to provide a centralized view of MFA configuration across the selected organization and time context.

Because the report focuses on configuration state, it should be interpreted as a snapshot of how MFA is configured at the time the report is generated, rather than as a record of user sign‑in behavior.

Account inclusion and exclusions

The MFA Report does not include all account types. In particular:

  • Guest accounts are excluded

  • Blocked accounts are excluded

These exclusions are intentional and reflect how Microsoft exposes MFA configuration data for different account categories. As a result, the absence of an account from the report does not necessarily indicate a reporting error.

Microsoft licensing considerations

Availability and detail within the MFA Report depend on Microsoft licensing. For Microsoft 365 tenants, Microsoft Entra ID Premium (P1 or higher) provides more complete MFA‑related data. Without appropriate licensing, MFA information may be limited or unavailable.

This report reflects the data Microsoft makes available through its APIs for the connected tenant. Licensing constraints are determined by Microsoft and are outside the control of Kaseya SIEM.

For information about where this report appears and how to generate it, see Using the Reports module.

Why MFA results may differ from Microsoft admin views

It is common for MFA Report results to differ from what is shown in Microsoft admin portals. Differences do not necessarily indicate incorrect reporting. Common reasons include:

  • Delayed synchronization between Microsoft services

  • Cached data in Microsoft management interfaces

  • Recent changes to user MFA settings that have not fully propagated

  • Differences in how MFA configuration is surfaced across Microsoft tools

In some cases, the MFA Report may reflect more recent configuration data than certain Microsoft admin views, because it is retrieved directly through Microsoft APIs.

How this report is used

The MFA Report is typically reviewed after or alongside investigation, when teams are validating account posture or documenting security configuration. It is often used together with other configuration reports or investigation context to understand whether MFA is enabled for relevant accounts.

The report does not provide a risk assessment or compliance determination. Interpretation should always consider organizational policy, account role, and surrounding investigation context.

Reporting boundaries

Consistent with reporting across Kaseya MDR, the MFA Report is descriptive rather than prescriptive. It does not generate alerts, influence detection logic, or initiate response actions. It records what the platform can observe about MFA configuration at the time the report is generated.

When to use this report

Use the MFA Report when you need to:

  • Review whether MFA is enabled for user accounts

  • Validate MFA configuration as part of an investigation

  • Document MFA posture for internal review or customer communication

  • Retain a record of MFA configuration state for audit or follow‑up purposes

If you are still determining what activity occurred or whether an alert requires action, investigation workflows should come first. This report is most effective once investigation has already established context and scope.

Related articles

  • Reports overview: Explains the purpose of reporting in Kaseya MDR, where reports fit in the investigation lifecycle, and what reporting is used for and what it does not replace

  • Using the Reports module: Describes how to access and work with reports in the UI, including generating reports, applying filters, exporting data, and scheduling report delivery.

  • Mailbox Forwarding Rule Report: Provides interpretation guidance for another configuration‑focused report, including account inclusion rules and how to understand report output correctly.