MFA Rollout Best Practices: A Phased Plan for Regulated Firms

A successful MFA rollout comes down to six decisions made in order: define the scope, pick methods by risk, prepare your identity systems, pilot with a small group, plan for lost devices and exceptions, and measure adoption after launch. Most failed rollouts skip the second half of that list. They switch MFA on, then discover that help desk queues, legacy applications and unmanaged exceptions erode the protection they paid for.

This guide is written for managing partners, IT directors and security leads at law firms, oil and gas operators and other regulated mid-sized organizations. It follows U.S. federal guidance and adds what we see in the field.

TL;DR

• Start with administrator accounts and senior leadership email, then expand to every user, application and remote access path.
• Match the method to the risk: phishing-resistant authenticators (such as FIDO2) for privileged and critical access, simpler methods only where the risk is lower.
• Pilot with IT and help desk staff first, then widen in waves. Fix enrollment and support problems while the group is small.
• Write the recovery process before launch: lost devices, replacement authenticators and exceptions need identity revalidation, not a phone call to the help desk.
• Measure adoption, failed sign-ins and exceptions every month. An MFA deployment is a program, not a project.

Table of Contents

• Why MFA needs a plan, not a switch
• Step 1: Define scope by risk
• Step 2: Choose methods by assurance level
• Step 3: Prepare identity systems and legacy applications
• Step 4: Pilot, then expand in waves
• Step 5: Communicate, train and enroll safely
• Step 6: Plan for lost devices, recovery and exceptions
• Step 7: Measure, monitor and maintain
• Our perspective: what we see in regulated organizations
• Getting help with your MFA program
• FAQ
• Sources

Why MFA needs a plan, not a switch

Turning on a second factor sounds simple. In practice, an organization has dozens of sign-in paths: email, VPN, remote desktop, cloud applications, practice management and document systems, field and operational technology access, vendor portals. Each one is a place where a stolen password can still work if MFA is missing.

The Canadian Centre for Cyber Security frames the purpose plainly: MFA increases resilience to credential-based attacks, and organizations should consider it for all users, systems, applications and network endpoints, with administrative accounts and senior management email accounts first. That ordering is the backbone of a good plan. It protects the accounts attackers want most before you have solved every edge case.

For regulated organizations there is a second reason. Frameworks such as SOC 2, HIPAA, PCI DSS and CMMC, and the questionnaires cyber insurers send, all expect to see MFA on remote and privileged access. A documented rollout gives you evidence for auditors, not just a technical control. Our guide to the controls small and mid-sized businesses must show to win cyber insurance covers how MFA fits into that review.

Step 1: Define scope by risk

Begin with an inventory. You cannot protect sign-in paths you have not listed. CISA's identity and access management guidance recommends inventorying all systems and the sensitivity of their data, then prioritizing high-value targets and privileged access first.

A workable inventory has four columns:

1. Application or access path (email, VPN, remote desktop, billing system, SCADA gateway, vendor portal).
2. Who uses it (partners, associates, contractors, field engineers, vendors).
3. What it holds (client files, privileged communications, health data, payment data, operational controls).
4. Current sign-in method (password only, password plus SMS, SSO, shared account).

Shared accounts deserve special attention. A shared mailbox or a shared login on a field terminal cannot answer the question "which person is signing in?", so MFA loses most of its value. Move those to named accounts or to delegated access where you can.

A practical priority order

Law firms should note that threat actors target lawyers' mailboxes because of what they hold. Our overview of law firm cyber threats explains why partner and billing accounts sit in wave 2, not wave 4.

Step 2: Choose methods by assurance level

Not every second factor is equal. Text message codes and push approvals are better than a password alone, but both can be defeated by phishing or by repeatedly prompting a user until they approve. CISA encourages all organizations to move to phishing-resistant MFA as part of longer-term zero trust planning, while recognizing that some applications cannot support it immediately.

The federal IAM guidance gives the same direction: select methods based on assurance level and use case, with phishing-resistant authenticators such as FIDO2 for privileged and critical software access, and policy enforced through a central identity service that supports risk-based, conditional access.

In plain terms:

• Administrators, partners with access to sensitive matters, and anyone who approves payments: hardware security keys or platform passkeys.
• General staff on managed devices: authenticator app with number matching, or passkeys where supported.
• Fallback only: SMS or voice codes, kept for users who have no alternative and for a defined time.

Expect trade-offs. Practitioner research notes that higher-assurance second factors can add friction for users and administrators, which can hurt adoption. That is a reason to stage the stronger methods by risk tier, not a reason to avoid them. The people with the most powerful accounts get the strongest factor.

Use conditional access to reduce prompts

A central identity service lets you adjust the demand to the situation. A sign-in from a managed laptop on a known network can need less friction than one from a new country at 3 a.m. Risk-based rules mean users see fewer unnecessary prompts, which lowers fatigue and the temptation to approve anything that appears.

Step 3: Prepare identity systems and legacy applications

The most common technical blocker is not the authenticator. It is the application that cannot use one. CISA's guidance is to integrate MFA into a centralized SSO or identity service instead of bolting it onto each system. Legacy applications that lack modern authentication should be upgraded, limited to internal networks, or replaced.

Before wave 1, work through this checklist:

1. Clean the directory. Remove stale accounts, disabled staff and unused service accounts. Every orphaned account is an MFA gap.
2. Connect applications to single sign-on where they support it, so one policy covers many systems.
3. Block legacy authentication protocols that skip MFA, such as older email protocols, once you confirm nothing business-critical depends on them.
4. List the exceptions you already know about: scanners, line-of-business software, shared devices, equipment in field locations. Give each an owner and a compensating control.
5. Decide your enrollment rules (see Step 5) before anyone registers a device.

Operational environments need extra care. Offshore platforms, remote sites and plant systems often have limited connectivity and shared consoles. Our offshore facility cybersecurity risk management guide and the piece on remote monitoring cyber risk show how remote access paths into those environments become the weakest link, which is where MFA belongs first.

Step 4: Pilot, then expand in waves

Resist the all-staff launch. The federal guidance recommends a phased rollout that starts with small, technically literate groups such as IT staff before the general population. A pilot with IT and help desk staff lets you test authenticators, refine communications and anticipate support issues before they hit everyone.

Once IT is stable, broaden the pilot. Vendor guidance suggests a pilot group drawn from across the business, including people who need different levels of access. A good pilot has an assistant, an associate, a finance user and a remote worker, because each will hit a different problem.

For each wave, define up front:

• Entry criteria: the previous wave's help desk volume has settled.
• Duration: long enough to cover a full billing cycle, a court filing deadline or a shift rotation, so you see real workflows.
• Success measures: enrollment rate, sign-in failure rate, tickets per user.
• Rollback plan: who can pause the wave, and how.

A realistic example: a 60-person firm might run wave 1 with four IT and operations staff, wave 2 with the partners and their assistants, and then move the remaining staff in two or three cohorts, a department at a time. Moving by department keeps the help desk's workload predictable and lets managers answer questions for their own teams.

Step 5: Communicate, train and enroll safely

People accept MFA when they understand why it exists and what will happen on day one. The Canadian Centre for Cyber Security recommends awareness campaigns on the benefits of MFA and training sessions on the new methods. The same guidance notes that awareness and training can reduce MFA fatigue and teach users to report phishing and MFA spamming.

A short communication sequence works better than one long email:

1. Two to three weeks before: a message from a managing partner or executive explaining the reason, the date and what changes.
2. One week before: a one-page guide with screenshots, and the times of live enrollment sessions.
3. Launch day: support staff on call, and a clear way to report a prompt the user did not initiate.
4. One week after: a reminder, plus a note on the most common problems and fixes.

Teach one behavior above all: if you get an approval request you did not start, deny it and report it. Attackers who already hold a password rely on users approving out of habit. Ongoing training keeps that habit alive; see our guidance on a risk-based cadence for security awareness training and our governance playbook for managing partners, since leadership visibly using MFA first is the strongest adoption signal.

Make enrollment itself secure

Enrollment is an attack surface. If an attacker can register their own phone on a stolen account, MFA protects them. The IAM guidance says the enrollment process must give adequate assurance that the authorized user is the one enrolling, for example by using multiple communication channels. Practical options are in-person or video enrollment with a manager, a one-time link sent to a verified channel separate from the sign-in, and a time limit on any enrollment link.

Step 6: Plan for lost devices, recovery and exceptions

This is the section most rollout plans leave out, and the one that determines whether the control holds under pressure. A person will lose a phone on a business trip. Someone will get a new device and have no old one to transfer from. A senior partner will demand a bypass.

The federal guidance sets the standard. Exceptions should be minimized and managed within a policy framework, and any self-service recovery needs robust identity revalidation. If a device is lost, you need a process to quickly disable that authenticator and issue a replacement, ideally using a backup authenticator kept in a secure location.

Write these rules down before launch:

• Lost or stolen device: the user reports it through a defined channel; support disables the authenticator immediately; a new one is issued only after identity revalidation.
• Help desk verification: support never resets MFA based on a phone call or email alone. Use a manager callback, a video check or an in-person step.
• Backup methods: issue two security keys to administrators, one kept in a secure location.
• Exception register: every exception has an owner, a reason, a compensating control and an expiry date. Review it monthly.
• Users who cannot use the preferred method: offer an alternative of equal assurance where possible, such as a hardware key for a user who cannot carry a personal phone.

The help desk is the favorite target of social engineers, so train it as carefully as you train users.

Step 7: Measure, monitor and maintain

Go-live is the midpoint. Okta's deployment guide suggests you track MFA adoption and use with auditing tools and refine policies using observations and user feedback. For a regulated organization, a monthly report to leadership should include:

Usability numbers matter more than they seem. A Michigan state-government pilot evaluated by RTI International found success rates of 81% for emailed access codes and 85 to 90% for text messages in a 2015 study. Those are older, public-sector figures, but they show the point: a meaningful share of attempts can fail at the delivery step, so track failures and offer better methods.

Maintenance has its own duties. The IAM guidance calls for routine testing and rapid patching of MFA infrastructure and a robust inventory of deployed authenticators so you can identify those needing replacement. Review your methods at least annually, and retire SMS as you gain passkey and key coverage.

Our perspective: what we see in regulated organizations

We work with law firms, energy operators and compliance-driven mid-sized companies, and the pattern repeats. The technical rollout is rarely what fails. What fails is ownership. Nobody is accountable for the exception list, the help desk reset procedure or the monthly metrics, so six months later the strongest policy has quietly accumulated bypasses.

Three points we give every client:

1. Treat MFA as evidence. Auditors, clients and insurers ask not only whether MFA exists but where it is enforced and how exceptions are governed. A written scope, a wave plan and an exception register answer those questions in minutes.
2. Spend the strongest factor where the damage is largest. A hardware key for fifteen privileged users does more for your risk than a uniform method for everyone.
3. Fix the recovery path first. An attacker who can talk a help desk into a reset has no use for your authenticator.

For firms without a full-time security leader, assigning these responsibilities to a part-time executive function is often the difference between a rollout that finishes and one that stalls.

— vCISO

Getting help with your MFA program

If you do not have an in-house CISO to own scope, method selection, exceptions and reporting, CISOSafe provides that leadership as a virtual CISO. Our team builds the risk-based rollout plan, aligns it to the frameworks you answer to, and prepares the policies and evidence auditors ask for. See our vCISO, compliance program and risk assessment services or start at CISOSafe to talk through your environment.

FAQ

Which accounts should get MFA first?

Start with administrator accounts and the email accounts of senior leadership, as the Canadian Centre for Cyber Security advises. Then move to remote access and finance users, and finally to everyone else. This order protects the highest-impact accounts while the process is still being tested.

Is SMS-based MFA good enough?

It is better than a password alone, but it is not phishing-resistant. CISA encourages organizations to move toward phishing-resistant methods, so use SMS only as a fallback with a plan to retire it. Privileged users should move to security keys or passkeys first.

How long does an MFA rollout take?

It depends on application count, legacy systems and staff size, so no single figure applies. A small firm can often complete waves in weeks, while an organization with operational technology and vendors needs longer. Set exit criteria for each wave instead of a fixed calendar.

What should we do when someone loses their phone?

Disable the lost authenticator immediately, then issue a replacement only after verifying the person's identity through a channel other than the one that was lost. A backup authenticator stored securely speeds this up for administrators. Never allow a reset based on an email or call alone.

How do we handle legacy applications that do not support MFA?

Follow CISA's guidance: upgrade them, restrict them to internal networks, or replace them. In the meantime, record each one in your exception register with an owner and a compensating control, such as access only through a protected remote gateway.

Sources

• Steps for effectively deploying multi-factor authentication, Canadian Centre for Cyber Security
• Identity and Access Management Recommended Best Practices for Administrators, CISA
• Implementing Phishing-Resistant MFA, CISA
• Multi-Factor Authentication Deployment Guide, Okta
• Saving Time on Your MFA Rollout, IANS Research
• NSTIC State Government Pilot evaluation, RTI International

Recommended

• Security Program Roadmap: A 12-Month Plan for Regulated Firms
• Close FTC Safeguards Rule Gaps in 90–365 Days for Mid Market Firms
• NIST RMF Explained for Security and Compliance Teams
• SEC Cybersecurity Disclosure Rules: What Compliance Officers Must Do