MFA for Law Firms: How to Verify Account Protection

MFA for Law Firms: How to Verify Every Account Is Protected

Blog post - By Securing Your Law Firm

Your attorneys use an authenticator app. Your IT provider says MFA is enabled. Then a client questionnaire asks whether MFA protects every account.

Can you support that answer?

An enrolled phone proves that someone registered an authentication method. It does not prove which applications require MFA, whether an account is excluded, or whether the policy is enforcing protection.

For a law firm, those gaps can affect client correspondence, matter files, and payment instructions. The useful question is not just “Do we have MFA?” It is “Where is MFA required, and what evidence supports that conclusion?”

Registration is not enforcement

Multi-factor authentication requires more than one kind of proof of identity, such as a password and possession of a registered device. Some passwordless methods combine factors without requiring a separate password and code.

MFA protects account sign-ins. It does not decide which client files a user should access, prove that a device is safe, or verify a change to wire instructions.

For Microsoft 365, separate these three questions:

• Registration: does the user have an authentication method available?
• Enforcement: does an active control require stronger authentication for the access being attempted?
• Evidence: do the policy settings and sign-in records support the claimed coverage?

Microsoft’s Security defaults guidance also explains a common reporting trap: the older per-user MFA screen may show Disabled when Security defaults or Conditional Access supplies the protection. That label alone does not establish a gap.

Six checks for a defensible MFA answer

1. List the accounts and systems that matter

Include partners, associates, legal assistants, administrators, temporary staff, outside users, separate administrator accounts, and former users whose access should have ended.

Then list Microsoft 365, practice management, document storage, remote access, billing, and other systems holding sensitive information. Do not assume an application is protected because it uses Microsoft 365. Confirm whether it uses the firm’s identity system, has its own MFA settings, or permits another sign-in route.

Request: a dated account-and-application inventory. Identify shared access, automated identities, and service principals separately; human MFA checks do not establish protection for application credentials.

2. Identify the control that actually enforces MFA

Ask the administrator to identify the applicable Security defaults configuration, Conditional Access policies, or other enforcement mechanism.

For Conditional Access, verify the policy state, included users, target resources, conditions, exclusions, and required controls. A policy in report-only mode evaluates possible effects; it does not enforce the policy. Microsoft’s all-user MFA guidance describes testing before moving a policy to On.

Security defaults and Conditional Access have different licensing and configuration requirements. Confirm the firm’s actual license and tenant setup before recommending a change.

Request: dated configuration evidence showing the active enforcement mechanism and its scope, not just a list of registered users.

3. Explain every exception

Look for excluded groups, temporary bypasses, application exclusions, and location-based exceptions. Each exception should have a reason, accountable owner, safeguards, and review date.

Treat emergency administrator access deliberately. Microsoft’s emergency access guidance calls for strong authentication, secure credential custody, monitoring, and regular validation.

Request: an exception register and confirmation that emergency access has been tested. Never email passwords, recovery codes, or security-key secrets.

4. Review the authentication methods allowed

MFA is not one uniform level of protection. Microsoft’s authentication strengths documentation distinguishes ordinary MFA, passwordless MFA, and phishing-resistant MFA.

FIDO2 security keys and Windows Hello for Business are examples of phishing-resistant methods. Text-message codes and push approvals are not equivalent to that category. Using Microsoft Authenticator does not, by itself, identify the method’s strength.

Request: the methods permitted and used, weaker fallback options, and a practical plan for stronger protection where supported. Start with privileged access and include lost-device recovery.

5. Review sign-in evidence and test representative access

An authorized administrator should inspect recent sign-in events for representative users and applications, including administrators and relevant exceptions. Record the application, applied policies, authentication details, result, and review date.

A missing prompt does not automatically mean MFA failed. An existing authentication claim may satisfy the requirement. Microsoft’s MFA sign-in reporting guidance cautions against interpreting one log field without the wider authentication context.

Use agreed test accounts and controlled scenarios. A successful Outlook test for one attorney does not verify every user, application, or access route.

Request: a short test record stating what was checked, what happened, and what remains unverified. If logs are unavailable, record that limitation instead of assuming the result.

6. Verify recovery and access changes

What happens when a partner loses a phone? Who may reset an authentication method? How does the firm verify a caller requesting that reset?

Review MFA alongside onboarding, departures, administrator changes, and recovery procedures. The firm needs reliable access without granting control merely because someone claims to be a busy attorney.

Request: the recovery procedure, authorized approvers, and a redacted example of a completed access change.

A one-page MFA verification record

Use a simple leadership record. A status should be backed by evidence, not a verbal assurance.

Record the reviewer, date, systems included, and limitations. Keep detailed account and policy evidence in the firm’s approved secure location.

If a questionnaire asks whether MFA protects “all access,” compare that wording with the verified scope. A Microsoft 365 review cannot establish the same result for every other system.

How we can help

Ask the person who manages your accounts—an internal administrator, IT provider, or authorized specialist—for the inventory, enforcement evidence, and exception list. Resolve missing coverage through a planned rollout with testing and recovery arrangements. Do not make blanket changes just to make a dashboard look complete.

Our Law Firm Security Baseline can review agreed identity, access, email, and evidence areas. Email & Microsoft 365 Security can scope authorized sign-in protection and configuration work directly or alongside your existing provider.

If a client has asked for evidence, our Client Security Questionnaire & Evidence Support can help organize answers, identify gaps, and keep final approval with the firm. For broader context, see the Microsoft 365 Security Checklist for Small Law Firms.

The Free Zero-Access Exposure Review™ checks public signals only. It cannot verify internal MFA enforcement, private mailbox settings, or tenant policy coverage.

This article is for informational purposes only and does not constitute legal, compliance, or insurance advice.