fix(m365): entra_users_mfa_capable produces mass false positives when AuditLog.Read.All is missing

[b-abderrahmane]

Issue search

• I have searched the existing issues and this bug has not been reported yet

Which component is affected?

Prowler CLI/SDK

Cloud Provider

Microsoft 365

Steps to Reproduce

1. Register an M365 service principal with all required permissions except AuditLog.Read.All
2. Run a scan against the M365 provider (API or CLI)
3. Observe entra_users_mfa_capable reports every enabled user as FAIL
4. The scan completes as completed with 100% progress — no warnings visible

Expected behavior

A clear signal that the check could not run due to insufficient permissions — either a single descriptive FAIL or a scan-level warning.

Actual behavior

_get_user_registration_details() in entra_service.py catches the 403 ODataError, logs it, and returns an empty dict. Every user then gets is_mfa_capable=False by default. The check dutifully reports all users as "not MFA capable" — completely indistinguishable from genuine findings.
In our environment this showed all users as false-positive critical findings that masked the real number.

Root cause

# entra_service.py, _get_user_registration_details()
except Exception as error:
if error.__class__.__name__ == "ODataError" and \
error.__dict__.get("response_status_code", None) == 403:
logger.error(...) # logs it, but...
return registration_details # ...returns empty dict → all users default to is_mfa_capable=False

This is not limited to one method. At least 5-6 other M365 Entra service methods have the same pattern — catch exception, log, return empty default. Downstream checks cannot distinguish "API returned no data" from "API call was denied".
The existing _get_directory_sync_settings() method already solves this correctly by returning a (data, error_message) tuple, and entra_seamless_sso_disabled checks for directory_sync_error before consuming data. But this pattern is not applied consistently.

Scope of the problem

Service layer — 5-6 Entra methods silently swallow 403 errors:

• _get_user_registration_details → affects entra_users_mfa_capable, entra_break_glass_account_fido2_security_key_registered
• _get_authentication_method_configurations → affects entra_authentication_method_sms_voice_disabled
• _get_oauth_apps → already returns None (check handles it), but error not tracked
• _get_authorization_policy, _get_conditional_access_policies, _get_groups, _get_organization, _get_admin_consent_policy, _get_default_app_management_policy
  Scan layer — no concept of "completed with warnings". A scan that couldn't run checks due to missing permissions shows the same green completed badge as a fully successful scan.

Suggested fix

We have a working implementation on a fork that:

1. Adds generic error tracking to M365Service base class (_api_errors dict, api_error_for(), _collect_api_error(), _is_permission_error())
2. Updates all 11 Entra _get_* methods to detect permission errors and record them via the base class
3. Updates 3 affected checks to call api_error_for() and emit a single descriptive FAIL instead of false positives
4. Includes tests (342 passed)

Branch: fix/m365-silent-permission-errors

Happy to open a PR if the team agrees with the approach. We can also discuss the scan-level warnings separately.

Operating System

Alpine Linux (container: prowlercloud/prowler-api:5.22.0)

Prowler version

5.22.0

Python version

3.12

Pip version

N/A (poetry-managed)

Context

Tested live on an AKS cluster running the Prowler API. The SP had a wrong role ID in the IaC config (AppRoleAssignment.ReadWrite.All instead of AuditLog.Read.All), which went undetected because Prowler reported false positives instead of flagging the permission gap.

[HugoPBrito]

Thanks for reporting this @b-abderrahmane,

This is a recurring issue across Prowler, and it doesn’t have an easy solution. Not because the code itself is difficult to fix, but because of how we want to handle the user experience.

One option is to flag missing permissions through errors in the specific API calls that require them, or to return a FAIL when the configuration is incomplete due to missing permissions — as we already do in some Microsoft 365 checks. However, extending this approach consistently across all providers, checks, and permissions would require a significant amount of work.

The main challenge is that if we don’t return a FAIL and the user doesn’t check the logs, a “no findings” result can be even more misleading than a permission error. A user might think everything is fine, when in reality there could be failing findings that weren’t evaluated due to missing permissions. Because of this, we’ve often chosen to favor false positives over false negatives or silent gaps.

That said, this approach is not perfect and can lead to confusion, as in your case. A better solution would be a more refined handling:

• Allow attributes to remain empty when data cannot be retrieved
• Clearly indicate in the extended status when data couldn’t be accessed due to missing permissions
• Log permission issues even more explicitly during data retrieval
• Maintain current behavior where necessary, but improve visibility of these limitations

Errors should already appear in the logs, but improving how we surface this information in the results — especially through status extended — would make it much clearer for users why a check failed or couldn’t be evaluated.

Thanks for reporting this. I wouldn’t recommend opening a PR at this point, at least for the whole problem, since there isn’t a straightforward solution. The team will work on improving this behavior in future versions to make it much clearer and more user-friendly.

Nevertheless, feel free to open a PR just for this permission, as we did for some M365 Exchange checks, and adding tests to ensure everything works as before or better.

[b-abderrahmane]

Hi @HugoPBrito

Thanks for your answer!

That makes sense, I understand that the team already has plan for rolling this out and it's quite a significant change. When that happens and if you need an extra pair of eyes feel free to ping me.

For now I will open a PR with a pretty narrow scope fixing only this specific issue and matching the existing patterns and without introducing any new mechanisms.