MFA coverage evidence: Microsoft 365 and Google Workspace

Enabled is not the same as covered

An MFA claim rests on three facts. Coverage evidence shows all three for the same date:

• A policy requires it. Security defaults or a Conditional Access policy in Microsoft 365; 2-Step Verification enforcement in Google Workspace.
• Every account has a method registered. A policy that requires MFA does not show who has set it up. The export does, one row per account.
• The exceptions have names. Accounts outside the policy, each with a reason and an owner, are evidence. An unexplained gap in the export is a finding.

Microsoft 365: three things to capture

Do these in the Microsoft Entra admin center for each tenant, in one sitting, on the same working day each month.

1. The policy. Take a dated screenshot of whichever control enforces MFA: security defaults, which are free and need no license, or the Conditional Access policy that requires MFA, with its users, exclusions and state visible. The two do not run side by side: organizations that move to Conditional Access "must disable security defaults", and Conditional Access needs at least Entra ID P1 (Microsoft Learn).

2. The registration report. Under Authentication methods, open Activity and choose User registration details from the side menu. It lists each user with the methods registered, the default method and whether they are capable of MFA. Microsoft names Reports Reader as the least privileged role that can view it, and lists an Entra ID P1 or P2 license as a prerequisite for the usage and insights reports it belongs to (Microsoft Learn). Microsoft Graph returns the same data (below).

3. A sign-in sample. In the sign-in logs, open a few recent interactive sign-ins and screenshot the Authentication Details tab. It lists the policies that applied, such as Conditional Access, per-user MFA or security defaults, and the methods used, in order (Microsoft Learn). Capture it in the same session: Entra keeps sign-in logs for 7 days on the free tier and 30 days on P1 or P2 (Microsoft Learn).

One trap. The per-user MFA page (Users, All users, Per-user MFA) is the list most people find first, and in a tenant that uses Conditional Access it shows nearly everyone as Disabled. That is expected. Microsoft's page says: "Enabling Microsoft Entra multifactor authentication through a Conditional Access policy doesn't change the state of the user. Don't be alarmed if users appear disabled." (Microsoft Learn). Sent to a carrier, that list reads as no coverage at all. Send the registration report instead.

Microsoft Graph PowerShell pulls that report in one command, so every tenant's monthly run is identical. The scope is read-only:

Connect-MgGraph -Scopes "AuditLog.Read.All"

# One row per user: admin role, registered, capable, methods
Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
  Select-Object UserPrincipalName, UserType, IsAdmin, IsMfaRegistered, IsMfaCapable,
    @{n='Methods'; e={$_.MethodsRegistered -join ';'}} |
  Export-Csv "mfa-registration-$(Get-Date -Format yyyy-MM).csv" -NoTypeInformation

It reads the same /reports/authenticationMethods/userRegistrationDetails data as the portal report (Microsoft Graph). Filter a copy on IsMfaRegistered to get the follow-up list, and keep the full export as the evidence.

Google Workspace: two things to capture

1. The enforcement setting. In the Admin console, go to Security, Authentication, 2-step verification (super administrators only) and screenshot the enforcement setting for each organizational unit or group: Off, On, or on from a date. If you use a new user enrollment period, which can run from 1 day to 6 months, note it too: during that window new users can sign in with a password alone, so anyone inside it belongs on the exception list (Google Workspace Admin Help).

2. The security user report. Go to Reporting, User reports, Security. The columns that matter are 2-Step Verification enrollment, 2-Step Verification enforcement and 2-Step Verification protection; a user secured by a passkey counts as Protected even without 2SV turned on. Download it as CSV or to a Google Sheet (up to 100,000 rows). The report needs the Reports administrator privilege, does not show today, and its 2SV enrollment data can be up to 48 hours old, so record the data date shown under the graph heading with your export (Google Workspace Admin Help).

What the monthly export must show

• Every enabled account, admins and guests included if they are in scope. Check it against the active user list for the same day.
• Per account: registered or not, the methods, and whether it holds an admin role. Admin accounts are the rows a carrier reads first.
• The policy evidence for the same date, so the registration list and the enforcement setting describe the same tenant on the same day.
• The exception list: each account outside the policy, with the reason, how it is protected instead, the owner and a review date. Break-glass accounts usually sit here: excluded from Conditional Access, protected by a passkey or certificate, and tested on their own schedule with the break-glass checklist.
• Who exported it and when, in UTC, plus the data date for the Google report.

Timestamp and hash the file

An export only helps later if nobody can claim it was edited. Two habits cover that:

1. Keep the original as downloaded. Name it with the month, the client and the source, for example 2026-10_client_m365-mfa-registration.csv, and do any filtering or notes in a copy.

2. Record its SHA-256 on the day you export it. On Windows: Get-FileHash .\file.csv -Algorithm SHA256. On macOS: shasum -a 256 file.csv. On Linux: sha256sum file.csv. Write the hash, the export time, the person and the row count in the evidence log next to the file.

Anyone can recompute the hash later and compare. A match shows the file has not changed since you recorded it; it does not show that the report was right when Microsoft or Google produced it.

The control, written down

Monthly is the cadence for this control in our calendar of what carriers ask for at renewal, for two reasons: sign-in logs age out in 7 to 30 days, and every joiner and leaver changes coverage. Twelve dated exports answer a question about the whole policy year. One screenshot from renewal week answers it for one day.

For MSPs: one export per tenant

Each client tenant has its own policy, its own exceptions and its own drift. Put the export on each client's schedule, assign it to a named technician, and file it with that client's other evidence, next to the restore test log. The technician who pulls the report provides the evidence; someone at the client should sign off on the control, so the MSP is not the only party vouching for its own work.

Questions

Is a screenshot of security defaults enough on its own?

It shows the policy, not the people. Under security defaults Microsoft decides when each user is prompted, and the screenshot cannot show who has registered. Add the registration report, or the sign-in sample if the tenant has no P1 or P2 license.

Do passkeys count in Google's report?

Yes. The 2-Step Verification protection column counts a user secured by a passkey as Protected, even if that user has not turned on 2SV.

Next step

ControlLedger's control library includes MFA exports. Schedule one per client every month; the assigned technician logs pass, fail, exception or not applicable and attaches the export and the policy screenshot, which are hashed with SHA-256 on upload, and every run goes into that client's Evidence Pack. On the Solo and MSP plans a client contact can co-sign each result through a magic link. ControlLedger records who attested to what, and when. It does not pull the report from Microsoft 365 or Google Workspace, and it does not verify that MFA is on. The help page goes from signup to the first pack. Free for one client, no credit card.