Testing Your MFA Rollout

Deploying MFA is not the finish line — verifying it actually works is. Organisations frequently assume that once MFA policies are configured and users are enrolled, they are protected. In practice, misconfigurations, overlooked accounts, legacy protocol gaps, and user workarounds can leave significant holes in your MFA coverage without anyone realising.

This lesson covers how to test and validate your MFA deployment so you can confirm it is genuinely protecting your organisation — not just appearing to.

Why Testing MFA Matters

MFA configurations can fail silently. A Conditional Access policy with the wrong scope might exclude entire user groups. A legacy protocol left unblocked might allow password-only authentication. An account created after the MFA rollout might never have been enrolled. Without deliberate testing, these gaps persist — and attackers find them before you do.

Testing is also essential for compliance. Auditors and certification bodies do not just ask whether MFA is “enabled” — they ask for evidence that it is enforced, monitored, and verified. Testing produces that evidence.

Phase 1: Coverage Audit

The first step is confirming that every account that should have MFA enrolled actually does. Both Microsoft 365 and Google Workspace provide reporting tools for this:

• Microsoft 365 — in the Microsoft Entra admin centre, use the “Authentication Methods → User Registration Details” report to see which users have registered MFA and which methods they use. Export this list and cross-reference it against your full user directory.
• Google Workspace — in the Admin console, use “Reporting → User Reports → Security” to see 2SV enrolment status. Filter for users who have not enrolled.

Pay particular attention to:

• Newly created accounts — accounts created after the MFA rollout may not have been enrolled if your onboarding process does not include MFA setup
• Service accounts — automated accounts that may have been excluded from MFA policies
• Guest and external accounts — collaborators who access your environment but may not be covered by your MFA policies

Phase 2: Enforcement Testing

Coverage (users are enrolled) is not the same as enforcement (users are required to use MFA). Test whether MFA is actually required by attempting to log in without it:

• Test with a standard user account — attempt to log in using only a username and password, without completing the MFA step. The login should be blocked.
• Test with an admin account — perform the same test with a privileged account. This is especially important because admin accounts are the highest-value target.
• Test from different locations — if your Conditional Access policies apply MFA based on location, test from both trusted and untrusted networks to confirm the policy triggers correctly.
• Test on different devices — verify MFA is required on mobile devices, personal laptops, and shared workstations, not just managed corporate devices.

Phase 3: Bypass Testing

This is the most critical phase. Can MFA be bypassed through legacy protocols or misconfigurations?

• Test legacy email protocols — attempt to connect to email using IMAP or POP3 with basic authentication (just username and password). If the connection succeeds, legacy authentication is not properly blocked and MFA can be bypassed.
• Review Conditional Access exclusions — check whether any user groups, applications, or conditions are excluded from your MFA policies. Each exclusion is a potential bypass path.
• Test the break-glass account — verify that your emergency access account works as intended, but also confirm it is monitored and alerts fire when it is used.
• Check for app passwords — some platforms allow users to generate “app passwords” for legacy applications. These are single-factor credentials that bypass MFA. Review whether any exist and whether they are still needed.

Phase 4: Ongoing Monitoring

MFA is not a one-time project. It requires ongoing monitoring to ensure coverage remains complete as your organisation changes:

• Weekly enrolment check — review whether any new accounts have been created without MFA enrolment. Integrate MFA setup into your joiners process.
• Monthly exception review — check your exception register. Have any exceptions expired? Are compensating controls still in place?
• Sign-in log monitoring — review sign-in logs for authentications that did not require MFA. Both Microsoft and Google provide sign-in logs that show whether MFA was satisfied for each login. Any password-only authentications to protected resources indicate a gap.
• Alert on MFA deregistration — set up alerts for users who remove their MFA methods. This could indicate a compromised account where the attacker is removing MFA to maintain access.

Documenting Your Test Results

For compliance and audit purposes, document your testing with:

• Date of test and who performed it
• Scope — which accounts, systems, and scenarios were tested
• Results — what passed and what failed
• Remediation — what was done to fix any failures
• Next test date — when testing will be repeated

This documentation serves as evidence for Cyber Essentials, ISO 27001, and cyber insurance applications. It shows not just that MFA is configured, but that it has been verified to work.

Why This Matters

Untested security controls provide false confidence. Organisations that assume MFA is working because it was configured six months ago may discover during an incident — or an audit — that significant gaps exist. Regular testing transforms MFA from an assumed control to a verified one.

Testing also demonstrates due diligence. If your organisation suffers a breach despite having MFA, evidence that you regularly tested and verified your deployment shows a mature security posture — which matters for regulatory response, insurance claims, and reputational management.

What to Do Now

• Run a coverage audit today — export your MFA enrolment report and identify any unenrolled accounts
• Test enforcement by attempting a password-only login to your email platform with a test account
• Verify that legacy authentication protocols are blocked by testing IMAP/POP3 connectivity
• Check for any existing app passwords and determine if they are still necessary
• Document your test results and schedule the next test (recommended: quarterly)
• Set up ongoing monitoring for sign-ins that bypass MFA and for MFA deregistration events

Evidence to Collect

• MFA enrolment report showing percentage of accounts enrolled, exported with date
• Test results documenting enforcement and bypass testing with outcomes
• Sign-in log samples showing MFA was required and satisfied
• Confirmation that legacy authentication is blocked (test results)
• A schedule for recurring MFA testing (quarterly recommended)

Common Mistakes

• Assuming MFA is working because it was configured. Configuration is not the same as enforcement. Test that MFA is actually required — do not assume the policy is applied correctly to all accounts and scenarios.
• Testing only once during initial deployment. Your environment changes constantly — new users, new applications, policy changes. Quarterly testing catches drift before attackers do.
• Ignoring legacy protocol bypass paths. The most common MFA bypass in Microsoft 365 environments is through legacy protocols that were never blocked. This should be the first thing you test.
• Not monitoring for MFA deregistration. An attacker who gains access to an account may remove MFA to maintain persistent access. Alerting on MFA method changes catches this activity early.

---

Knowledge Check

---