Multi-factor authentication is the single highest-value control a small tax firm can implement. The IRS, the FTC, and every cyber insurance carrier require it. The problem is rollout. Done wrong, MFA breaks workflow, frustrates staff, and gets disabled within a month. Done right, it takes 2 weeks and stays in place forever.
This is the 2-week plan we run with new managed-security clients. It assumes a 3 to 10 person firm using Microsoft 365 or Google Workspace, common tax software, and a client portal.
Week 1: pick the app and prep the inventory
Choose one authenticator app and standardize on it across the firm. Microsoft Authenticator is fine for Microsoft 365 shops. Google Authenticator works everywhere. Authy works if your team uses mixed devices. Do not let staff pick their own.
Make a list of every system that holds client data or grants access to it. Put them in priority order based on risk.
- Email (Microsoft 365, Google Workspace)
- Tax software (Drake, ProSeries, Lacerte, UltraTax, ATX)
- Client portal (Citrix, SmartVault, eFileCabinet, Verifyle)
- Document storage (Dropbox, OneDrive, Google Drive)
- Banking and payment processing
- CRM and practice management software
- Anything with admin access (DNS, web hosting, VPN)
For each system, find the MFA setup page, write down the URL, and note whether it supports authenticator apps or only SMS. Authenticator apps are dramatically more secure than SMS. Use SMS only when nothing else is available.
Day 1 of week 2: enable on email first
Email is the hub. If a phisher gets your email, every password reset on every other system is theirs. Enable MFA on email before anything else.
Schedule a 30-minute walkthrough with the entire team. Each person enables MFA on their own email account during the meeting, with the lead person available to fix any issues. Do not send a written guide and hope. Do it together.
Days 2 through 5 of week 2: the rest
Group the remaining systems. Most firms can knock out MFA on 5 systems per day with one person leading.
- Day 2: tax software and client portal
- Day 3: document storage and CRM
- Day 4: banking and payment processing
- Day 5: admin systems (DNS, hosting, VPN, registrar)
For each system, set up MFA, document where the recovery codes are stored (a password manager, not a sticky note), and note the date in your WISP under technical safeguards.
Handling pushback
Two complaints come up every time. Address them upfront.
"It slows me down." MFA adds 5 to 10 seconds per login on each device the first time. After that, the device is remembered for 30 to 90 days depending on the system. The actual time cost is under 30 seconds per week per person. Compare that to the time cost of a breach: 3 to 6 weeks of disruption per affected employee.
"My phone is personal, I do not want work apps on it." Two responses. The authenticator app does not access personal data and does not let your firm access the phone. If a staff member still refuses, issue a $25 USB security key (Yubikey or equivalent) as the second factor. Same effect, no app on the personal device.
After rollout
Three things keep MFA from drifting back to nothing within 6 months.
- Disable SMS-based MFA on every account that supports app-based. SMS is vulnerable to SIM-swap attacks and is no longer considered defensible by most insurers.
- Set a calendar reminder every 90 days to verify MFA is still enabled on every system. Add a screenshot to the WISP folder as evidence.
- Onboard new employees with MFA on day one as part of their setup checklist, not as something to come back to later.
What this looks like in your WISP
When the FTC or IRS asks how you protect client data, they want a specific answer. After this rollout, your WISP can say:
"All systems holding customer information require multi-factor authentication using app-based authenticators. SMS-based MFA is disabled where alternatives exist. Recovery codes are stored in our password manager. MFA enforcement is verified quarterly and logged in our compliance folder."
That sentence is the difference between a WISP that holds up under audit and one that does not.
