Spring is not just renewal season. It is also one of the cleanest annual stress tests of your cyber controls.
In its March 19, 2026 threat-intelligence writeup, Microsoft described a wave of tax-themed phishing and malware campaigns that used CPA lures, fake W-2 documents, QR codes, Microsoft 365 credential theft pages, and even abuse of legitimate remote monitoring and management tools.[1] One campaign alone hit more than 29,000 users across 10,000 organizations, almost all in the United States.[1]
That matters for BindLedger’s audience for a simple reason: the exact controls insurers care about at renewal are the same controls attackers are testing right now.
When a carrier asks whether MFA is enforced for email, whether remote access is controlled, whether anti-phishing protections are in place, or whether staff are trained against social-engineering lures, it is not asking in the abstract. It is asking because the market keeps seeing the same failure pattern:
- a time-sensitive email arrives,
- a user trusts the context,
- a sign-in or document flow is spoofed,
- credentials or session access are taken,
- an attacker pivots into email, remote access, payroll, or finance.
The tax-season campaigns Microsoft documented in early 2026 make that sequence unusually concrete.
This article is not a generic awareness post. It is a guide to what MSPs, brokers, and M365-heavy clients should read out of these campaigns through an underwriting and attestation lens.
The 2026 tax-season pattern is broader than “watch out for phishing”
The IRS’s 2026 Dirty Dozen warning says scammers are using IRS impersonation by email, text, direct messages, and QR codes that direct targets to fake sites to “verify” accounts, enter personal data, or claim refunds.[2] It also warns that spear-phishing and malware campaigns continue to target tax professionals and businesses, often using “new client” or “document request” lures.[2]
Microsoft’s March 2026 research adds the technical detail behind that warning.[1]
The campaigns it documented were not copies of one another. They used different file types, delivery chains, and post-compromise objectives:
- A CPA-themed campaign used an Excel file, then a OneNote file on OneDrive, then a phishing page to steal Microsoft 365 credentials.[1]
- A W-2-themed campaign sent tax-doc attachments with a QR code that led to a Microsoft 365 credential theft page, with each document customized to the recipient.[1]
- A Form 1099-themed campaign delivered a legitimate remote access tool after the user clicked a fake tax-forms link.[1]
- A separate IRS- and cryptocurrency-themed campaign instructed users to copy and paste a URL instead of clicking, then delivered legitimate remote monitoring software depending on the day of the campaign.[1]
- Other campaigns targeted accounting professionals with document-review stories that ended in remote-access malware delivery.[1]
That variety is the point.
If you need the Microsoft-tenant version of the MFA proof problem behind these campaigns, start with The M365 MFA Reporting Gap. If you want the DNS and sender-authentication side of the same story, DMARC, SPF, and DKIM for Cyber Insurance is the practical companion.
Attackers are not relying on one control failure. They are chaining together the gaps between your controls:
- email trust,
- user urgency,
- QR-code flows,
- MFA weakness,
- browser trust,
- help-desk reset paths,
- and remote access discipline.
If your renewal packet still says “Yes, MFA is enforced” but you cannot explain what happens when a user scans a malicious QR code on their phone and then approves a sign-in, your answer may be technically accurate and still operationally weak.
Why M365 tenants are a natural target in this pattern
Most SMB and lower mid-market environments sit on Microsoft 365 for email, identity, collaboration, or all three. That makes M365 the obvious place where tax-season lures and insurance questions collide.
Microsoft’s W-2 QR-code example is especially revealing. The attachment looked like a tax document. It was personalized to the recipient. The QR code’s URL contained the recipient’s email address. The phishing page mimicked the Microsoft 365 sign-in experience and harvested credentials and 2FA for later use.[1]
The underwriting lesson is not just “have MFA.” It is:
Can you defend the entire path into email and admin access under pressure?
Tax lures are effective because they exploit legitimate business context:
- payroll teams expect W-2 and tax-document traffic,
- CPAs expect unsolicited intake requests,
- finance teams expect urgency in filing season,
- and employees are already primed to treat tax notices as important.
This is why generic awareness language underperforms. It is too broad for the real decision the user faces.
The better question is:
- Would a payroll administrator know that the IRS does not initiate contact by email, text, or social media to request personal or financial information?[3]
- Would a user know that a QR code in a Word document can be just as dangerous as a clickable link?[1][2]
- Would your environment block or at least strongly challenge sign-ins triggered by an obviously suspicious flow?
- Would the download of remote-control software into a finance or payroll workstation stand out immediately?
If the answer is unclear, the renewal answer should probably feel less casual too.
The underwriter’s view: tax-season attacks test the exact questions on real forms
One reason BindLedger’s wedge works is that public cyber applications are still mostly short, attestational, and deceptively simple.
The Hartford’s 2025 CyberChoice underwriting application asks whether MFA is required for all remote access to the business network and whether MFA is required for access to email. It also asks whether applicants use a dual-authentication protocol for funds-transfer requests or account-information changes through a secondary method of communication.[4]
The Hartford’s ransomware supplemental goes further. It asks:
- what type of email filtering is used to prevent phishing,
- how malicious-code emails are managed,
- which protocols authenticate sender and content of emails,
- how remote access is controlled,
- how RDP is protected,
- how often anti-phishing training is conducted,
- how MSP access is controlled,
- and what best describes patch management procedure.[5]
Coalition’s current agency application does not ask about SEG configuration or QR-code defenses by name, but it does ask whether MFA is enforced for email, VPN, RDP/remote access, and privileged accounts on form CYUSP-00NA-1022-01, Question 6a–d.[6]
Travelers’ current short-form renewal application asks whether the applicant has MFA for remote access to email and other systems and programs that contain private or sensitive data in bulk on form CYB-14203 Rev. 03-19, Question 3i.[7]
Those are not hypothetical controls. They are the exact seams Microsoft’s March 2026 tax-season campaigns pressed on.
The unique 2026 twist: phishing now blends into legitimate remote access
The most interesting part of Microsoft’s writeup is not the phishing itself. It is what happened after phishing.[1]
Several campaigns ended in delivery of legitimate remote monitoring and management software. Microsoft notes that attackers increasingly abuse real remote-access tools to maintain persistence, create a secondary command-and-control path, or conduct hands-on-keyboard actions on compromised systems.[1]
That is a very different problem from a simple bad link.
A weak tax-season posture is no longer just:
- “user clicked a fake login page.”
It is increasingly:
- “user clicked a believable tax lure,”
- “the environment allowed a suspicious remote-control foothold,”
- “the attacker moved from identity theft into device control.”
This is why carriers keep asking about remote access, RDP, privileged access, and MSP access. Not because those are separate from phishing, but because they are often the next move after phishing.
Microsoft’s mitigation section reinforces that reading. It recommends enforcing MFA on all accounts, removing users excluded from MFA, strictly requiring MFA from all devices in all locations, enabling post-delivery email controls, and detecting suspicious installation or usage of remote management software.[1]
That is not an awareness campaign. It is a control stack.
Where most MSPs still answer too casually
The common trap is to answer the renewal question at the technology-name level.
Examples:
- “Yes, we use Microsoft 365.”
- “Yes, we have MFA.”
- “Yes, we have endpoint protection.”
- “Yes, we train users.”
None of those statements are wrong. They are also not enough.
The better way to think about tax-season phishing from an attestation standpoint is by control class.
1. Public email-authentication posture
Can your domain show a defensible baseline on SPF, DKIM, and DMARC?
This does not stop every credential-theft flow, but it reduces spoofing opportunities and creates a cleaner external security signal. It is also the part BindLedger can help verify today through a fast domain scan.
2. Mailbox-access enforcement
Is MFA actually enforced for the users who matter, especially payroll, finance, HR, and administrators?
That means not “available,” not “registered,” and not “configured somewhere.” It means enforced on the real access paths in use.
3. Email-layer detection and inbox controls
Can you show link scanning, malicious-attachment handling, and external-sender visibility?
A DNS scan cannot prove that. A renewal answer still needs the internal control story.
4. Remote-access trust
Would suspicious remote-control installation or use stand out quickly? Would ad hoc remote access into sensitive users’ devices be obvious, logged, and challenge-protected?
This is where phishing and device control meet.
5. Payment and payroll verification
Could a user who lost mailbox access cause a fraudulent W-2 disclosure, payroll diversion, or account-change event without a second, independent validation step?
This is not purely a technical control. It is partly operational. But insurers care deeply about it because that is where email compromise becomes money loss.
That is also why BEC and Funds Transfer Fraud Coverage belongs in the same renewal packet discussion.
A better way to explain the risk to clients
Do not explain this as “there are scary phishing emails this time of year.”
Explain it this way instead:
Tax season compresses urgency, trust, and financial sensitivity into a few weeks. That makes it one of the best annual predictors of whether your email, MFA, remote access, and verification controls are actually defensible.
That sentence does three useful things:
- it frames the threat in business language,
- it ties directly to renewal questions,
- and it avoids generic security hand-waving.
What you should document before the renewal arrives
If you support M365-heavy clients, your evidence packet for spring should answer at least these questions:
- What is the domain’s visible SPF/DKIM/DMARC posture?
- Is MFA enforced for email access for all users or only some?
- Are any users excluded from Conditional Access MFA requirements?
- Is MFA enforced for privileged roles and remote access paths?
- What email-layer protections are in place for links, attachments, and external sender visibility?
- What is the escalation path when payroll, HR, or finance receives suspicious tax-related requests?
- What remote-access tools are permitted, and how are they monitored?
- What secondary verification process exists before payroll or banking data changes are actioned?
That is a stronger control story than “we use Microsoft 365 with MFA.”
What BindLedger can verify today — and what still needs human process
This boundary matters.
BindLedger can help verify the public side of the story right now:
- SPF
- DKIM
- DMARC
- domain-level email-authentication posture
BindLedger’s upcoming tenant-side workflows are the natural place to verify the next layer:
- mailbox MFA enforcement,
- privileged-account exposure,
- exclusions and exceptions,
- admin sprawl.
What no scanner can fully prove on its own is the operational side:
- whether payroll staff actually follow a callback rule,
- whether a finance exception was approved out of band,
- whether a help-desk reset process is strong under pressure.
That does not make those controls unimportant. It makes them document controls, not pure telemetry controls.
The real lesson from March 2026
The current tax-season spike is not interesting because it is seasonal.
It is interesting because it reveals the exact gap BindLedger is built around:
- insurers ask short questions,
- attackers exploit messy reality,
- and MSPs are left trying to convert a living environment into a defensible answer.
If you read Microsoft’s March 2026 research next to current carrier forms, the conclusion is hard to miss:
email security, MFA, remote access, and payment verification are not separate topics. They are one loss chain.
That is why a tax-phishing article belongs on a cyber-insurance site.
What to do right now
You do not need to wait for a renewal application to start tightening the easiest part of this story.