Your firm has MFA. Here is how attackers sign in anyway.

Multi-factor authentication does not stop an attacker who steals the session cookie your browser receives after you complete the MFA prompt. The attacker never needs your password again, and never sees a second prompt.

This is the attack pattern behind most of the account takeovers being worked in 2026, and it is the reason a firm can have MFA switched on everywhere and still lose a mailbox.

What is adversary-in-the-middle phishing?

It is a phishing page that sits between your staff member and the real Microsoft 365 or Google sign-in page, relaying both directions in real time.

The staff member clicks a link in an email. The page looks like the real sign-in page because it is the real sign-in page, proxied. They type the password. The real service sends the real MFA prompt.

They approve it, because they are the one signing in and nothing looks wrong. The service returns a session cookie — the small piece of data that tells the browser "this person is authenticated, stop asking."

The proxy keeps that cookie. The attacker loads it into their own browser and is now signed in as that staff member, without a password and without triggering MFA, because as far as the service is concerned the authentication already happened.

How common is this?

Cisco Talos reported that authentication abuse was the most prevalent security weakness in its Q2 2026 incident-response engagements, observed in 65 percent of cases — up from 35 percent the previous quarter (Cisco Talos, IR Trends Q2 2026).

The same report names the methods: adversary-in-the-middle proxies, session-token theft, MFA fatigue, self-enrolled devices, and OAuth device-code phishing.

Stolen sessions are collected at scale. SpyCloud recaptured 8.6 billion stolen cookies and session artifacts exposed through malware infections in 2025 (SpyCloud, 2026 Identity Exposure Report).

And the takeovers themselves are not rare events at the edges.

Proofpoint monitored roughly 63 million cloud accounts across a year; about 3 million were targeted for compromise and approximately 17,000 were successfully taken over (Proofpoint, account takeover research).

Why does this matter specifically for an accounting firm?

Because the FTC Safeguards Rule requires multi-factor authentication, and a control that is switched on is not the same as a control that is working.

The Safeguards Rule (16 CFR Part 314) applies to tax preparation firms by name — § 314.2(h)(2)(viii) classes "an accountant or other tax preparation service that is in the business of completing income tax returns" as a financial institution — and requires MFA for anyone accessing customer information.

The IRS restated the underlying obligation in IR-2026-92 on 18 August 2026, and Publication 5708 supplies the fill-in Written Information Security Plan template.

A firm that implements MFA, documents it in its WISP, and then loses a mailbox to session theft has met the letter of the requirement and still suffered the breach.

There is a second exposure, on the insurance side. Cyber applications ask whether MFA protects email and remote access, and on most forms the completed application is attached to and made part of the policy.

"We have MFA" is a statement your firm will be held to at claim time — which makes it worth knowing whether the MFA you have is the kind that survives this attack.

What actually stops it

Not all MFA is equal against this attack. The distinction is whether the second factor is bound to the site the user is actually on.

Passkeys and hardware security keys are phishing-resistant because the credential is cryptographically tied to the real domain. A proxy sitting on a lookalike domain cannot make the key sign for it.

One limit worth stating plainly: phishing-resistant factors stop the proxy from obtaining a session in the first place.

A second limit, and a different attack: in device code phishing there is no lookalike domain at all, because the victim types the attacker's code into Microsoft's genuine sign-in page, so a factor that proves the site is real has nothing to object to.

They do not protect a session cookie that is already sitting in a browser on a machine running infostealer malware, which is what SpyCloud's figure counts. That is the gap the next three controls cover.

Alongside that, three controls limit the damage when a cookie does get stolen:

• Conditional access policies that check device compliance and location, so a stolen cookie replayed from unfamiliar infrastructure fails the second test.
• Token protection and shorter session lifetimes, so the stolen cookie expires sooner and is bound more tightly to the original device.
• Identity monitoring that watches for the sign-in that follows — the mailbox rule that forwards invoices, the unfamiliar location, the new device — and puts a person in front of it before it becomes a wire transfer.

What to do this month

1. Check which MFA methods your firm actually allows. If SMS or app codes are permitted, they will be used.
2. Roll out passkeys for the accounts that hold client data first — partners, anyone with mailbox access, anyone who can move money.
3. Turn on conditional access. MFA answers "who", conditional access answers "from where and on what".
4. Write down what you did. The WISP is not paperwork for its own sake; it is the document the FTC, the IRS and your insurer will ask for.
5. Decide who watches the sign-ins. A control nobody reviews is a control that tells you what happened after it happened.

The short version

MFA was designed to stop an attacker who has your password. It was not designed to stop an attacker who has your session.

Phishing-resistant factors, conditional access and someone reviewing identity activity are what close the gap — and for a tax or accounting firm, they are also what the Safeguards Rule, your WISP and your insurer are actually asking about.

We watch. We respond. We explain. If you want a look at how your own firm's sign-in controls are configured, that is what the briefing is for.