Playbook: How a 9-Person CPA Firm Should Respond to a Tax Software Portal Vulnerability During Tax Season

This is a playbook for a scenario we structure engagements around regularly across the Inland Empire and Orange County. The firm described is a composite — no specific client. The mechanics, controls, and remediation steps are the real engagement structure we use.

Picture a 9-person CPA firm in Orange County — two partners, four senior associates, two preparers, and one front-office admin. The book is mixed: roughly 60% individual tax, 30% small-business tax and bookkeeping, 10% advisory.

The stack: a cloud-hosted tax-prep platform with a web portal for client document exchange and e-signature, Microsoft 365 for email and file storage, a small on-prem file server for legacy work papers, and a third-party document-management platform on top of it. That is the modal small-firm stack.

The triggering scenario: late February, the tax-prep platform vendor issues a security advisory. A credential-stuffing wave is hitting the client portal across the vendor's customer base. The vendor is rate-limiting the login endpoint and rolling out forced password resets, but the advisory tells customers to immediately enable MFA on all firm-user accounts and review activity logs.

The firm's existing IT vendor — a one-person break-fix outfit — reads the advisory, forwards it to the firm, and goes silent. The managing partner calls us asking what "actually doing something about this" looks like.

Before any remediation, a 48-hour discovery is non-negotiable. At a firm this size the picture is almost always the same.

The tax-prep platform was set up by the original IT vendor several years earlier with a single shared admin account that both partners use. Junior staff have individual portal accounts, but MFA is typically off across the board — usually because someone said it "slowed down e-filing during deadline weeks."

Password complexity sits at the platform default. The shared admin password has not been rotated since the account was created.

Microsoft 365 is usually on a Business Basic license — email-only, no Defender, no Conditional Access, no Intune. MFA is enabled for the partners but not the rest of the firm. Legacy authentication protocols are still on because somebody is running an old email client at home and nobody has gone back to clean it up.

The document-management platform sitting on top of the file server has its own login system, separate from M365. A handful of users carry domain-admin rights on the file server because the original IT vendor did not want to deal with permission tickets.

Client portal sharing is happening through three different channels — the tax-prep platform's portal, the document-management platform, and ad-hoc OneDrive links sent by individual staff. No one can give a clean answer to "who has access to which client folder."

The firm has a written information security plan on file — the IRS Pub 4557 Safeguards Rule (16 CFR Part 314) requires one — but it was written years ago, names a former IT vendor, and describes controls that no longer exist.

An audit at a firm this size will typically surface six findings that matter:

• Credential reuse across portal and personal email on the shared partner admin account. The same password is often set on the tax-prep portal admin login, the document-management platform admin login, and one of the partner's personal email accounts. Once a personal account has appeared in a public breach corpus — and at this firm size, it almost always has — that credential is already in the data attackers are stuffing against the vendor's portal.
• MFA off on most staff accounts. Not just the tax-prep portal — also the document-management platform, the firm's bank login, and the e-signature provider. Any single one compromised would give an attacker enough to redirect client refunds.
• Legacy authentication protocols still enabled on the M365 tenant. POP3 and IMAP basic auth on. These protocols bypass MFA entirely. Sign-in logs at a tenant this size typically show anywhere from a few hundred to several thousand failed legacy-auth attempts from a dozen-plus countries in any 30-day window — a clear credential-stuffing pattern.
• Multiple users with domain-admin rights on the file server. Most of them have never administered anything; the rights were granted to skip ACL configuration during onboarding years earlier.
• No tenant-side anti-phishing or impersonation rules. Default M365 anti-phishing policy at the lowest tier. Lookalike-domain detection off. Safe Links off.
• The firm's written information security plan is several years stale. References controls and a vendor that no longer exist. From a Pub 4557 audit perspective, the document on file actively misrepresents the firm's posture.

The single highest-value control for a firm this size is multi-factor authentication on every account that touches client data — not just the partners, every account, every platform.

The remediation runs as a two-week sprint with the partners signing off on order of operations. Tax season is active, so the sequence is built for minimum disruption.

1. Kill the shared admin account on the tax-prep portal. Create individual partner admin accounts with unique strong passwords stored in a firm-wide password manager. Rotate the shared password as a holdover only until the new individual accounts are tested, then disable it entirely. Enable MFA on both partner admin accounts via an authenticator app.

2. Enable MFA across every staff account on every platform that handles client data. Tax-prep portal, document-management platform, M365, e-signature provider, firm's bank. Push it out vertical-by-vertical over three days so support load stays manageable. Anyone still using a legacy email client moves to a modern client with OAuth-based authentication.

3. Disable legacy authentication protocols on the M365 tenant. Turn off basic auth for POP, IMAP, SMTP, and Exchange Web Services. Test with the firm's email clients before flipping the master switch. The credential-stuffing pattern in the sign-in logs typically stops within 24 hours.

4. Clean up the file server permission model. Pull domain-admin rights from anyone who does not need them. Replace ad-hoc shares with role-based group permissions (Tax, Advisory, Admin, Partners) and audit the ACLs against the firm's actual reporting structure.

5. Upgrade M365 to Business Premium and turn on what they are already paying for. Defender for Business, Conditional Access policies (block legacy auth, require MFA, block sign-ins from countries the firm does not work in), Safe Links, Safe Attachments, anti-phishing impersonation rules including lookalike-domain detection. Our Microsoft 365 security baseline walks through what this configuration covers.

6. Rewrite the IRS Pub 4557 information security plan from scratch. Document the actual current controls, name the people responsible for each, set a quarterly review cadence, and build an incident response runbook specific to a tax-prep portal compromise. The plan now matches reality — the only version of that document that is worth anything in an examiner conversation.

7. Standardize client document exchange on a single channel. Retire the ad-hoc OneDrive links. Client portal sharing goes through the tax-prep platform's portal for tax documents and the document-management platform for advisory work — with clear staff training on which goes where.

When this playbook runs cleanly, here is what the firm exits with.

The firm finishes tax season with no portal-related incidents. Credential-stuffing waves against the vendor typically continue for weeks; vendor incident reports usually list customer firms that lost client data. A firm that ran this playbook is not among them.

Failed login attempts against the firm's M365 tenant from legacy authentication protocols drop to zero within 48 hours of the cutoff. Conditional Access policies block sign-in attempts from countries outside the U.S. on the partners' accounts — attempts the partners would never have known about under the old configuration.

A written information security plan only earns its keep when it matches what the firm actually does. Anything else is a document an examiner will use against you.

The written information security plan now matches what the firm actually does. The next examiner conversation is a short one.

MFA — which partners often resist for years because they have been told it will slow them down — adds roughly four seconds per login. Staff stop complaining within a week.

Two things worth taking from this.

First — vendor-side breaches happen, and the only thing standing between a vendor's credential-stuffing wave and your client data is MFA on your account. Not the vendor's MFA on their account. Yours. The tax-prep platform you log into, the document-management platform, the e-signature provider, the bank. Every account that handles client tax data needs MFA, period. The modal small CPA firm in this region has a stack where any single compromised credential would walk an attacker straight to client SSNs.

Second — IRS Pub 4557 and the FTC Safeguards Rule (16 CFR Part 314, revised 2023) are not optional, and an out-of-date written information security plan is worse than no plan because it actively misstates your posture. A plan written years ago that references controls you no longer have is a document an examiner will use against you. Plans are living documents. They get reviewed quarterly, updated when controls change, and signed by the responsible partner.

If you want to see where your firm sits against IRS Pub 4557 and the FTC Safeguards Rule, our security baseline assessment walks through it methodically, and our free 12-question self-check gives a rough grade in three minutes. The financial-services overview at /industries/financial-services covers the broader CPA / RIA / insurance pattern we work with.