A few years ago, many SMB cyber applications could be summarized as “Do you have MFA, backups, and antivirus?”
That is no longer where the market is.
Current ransomware supplementals now ask some version of a much sharper question:
Who can get remote access into this environment, how, and under what controls?
That is not academic. It tracks exactly what current threat intelligence is showing.
In March 2026, Microsoft documented tax-themed phishing and malware campaigns that used believable lures to deliver or abuse legitimate remote monitoring and management tools after the user interacted with fake tax content.[1] In March 2026, a major remote-access vendor also published an important security hardening bulletin after researchers observed attempts to abuse disclosed cryptographic material for session authentication, warning that earlier versions could allow unauthorized actions and elevated access under some conditions.[2] And in 2025, CISA warned that ransomware actors likely leveraged an unpatched remote monitoring and management product to reach downstream customers in double-extortion operations.[3]
That abuse path is exactly why Tax Season Is Phishing Season is not just an email article. It is also a remote-access article.
That is the new underwriting context.
Remote access is not just a support convenience anymore. It is a trust chain. And insurers are increasingly asking whether you can defend that chain.
The most important underwriting shift is not “Do you use a remote tool?”
Public forms do not ask whether a company uses remote support software in the abstract. They ask how remote access is controlled.
The Hartford’s ransomware supplemental is one of the clearest examples. It asks:
- how users access the network remotely,
- how remote access to the network is controlled,
- how RDP is protected,
- how access is controlled across the network,
- how privileged access is controlled,
- how MSP access to the applicant’s network is controlled,
- what best describes patch management,
- and how open-port hygiene is maintained.[4]
That is not a checkbox exercise. It is effectively an underwriting model for session trust.
Coalition’s current application also points in the same direction. Form CYUSP-00NA-1022-01 asks whether MFA is enforced for VPN, RDP/remote access, and privileged accounts, not just email.[5]
Travelers’ short form folds remote access into Question 3i, asking whether MFA exists for remote access to email and systems holding sensitive data.[6]
If you need the carrier-form companion on the Travelers side, pair this with the Travelers CyberRisk Short Form Guide.
So the question for an MSP is not whether remote access exists. It is whether remote access can be explained and evidenced as a controlled, limited, logged, and verifiable path.
The threat side now looks exactly like the form language
This is what makes the topic hot.
Microsoft’s March 2026 tax-season research documented campaigns that delivered legitimate remote access software after the victim engaged with fake tax forms or IRS-themed content.[1] Microsoft explicitly notes that attackers abuse real remote monitoring and management tools to maintain persistence, create an alternative command-and-control method, or conduct interactive hands-on-keyboard activity on the compromised machine.[1]
That is the bridge most renewal conversations still miss.
A fake tax document is not just an email threat. It can become a session-control problem.
If the attacker gets a remote foothold through a legitimate tool, the risk stops looking like commodity phishing and starts looking like:
- remote access without trustworthy operator identity,
- session approval that can be bypassed or spoofed,
- weak technician scoping,
- poor logging,
- unmanaged unattended access,
- or stale cryptographic/session material.
Those are exactly the issues an underwriter is trying to sniff out when a supplemental asks about MSP access and remote access controls.
The unique angle: this is really a session-trust problem
Most cyber-insurance conversations still treat remote access as a binary control.
- Is RDP exposed?
- Is MFA turned on?
- Is the MSP account protected?
Those are necessary questions. But the more useful 2026 frame is session trust.
Session trust asks whether the entire remote access event is defensible:
- Who initiated it?
- How was that identity verified?
- What device did it come from?
- Was the session approved?
- Was the user or client context limited?
- Was privilege elevated only when needed?
- Was the session logged?
- Can you show what happened later?
That is a much better way to understand why the current forms are getting more specific.
The insurer is not really asking whether your remote support software has a logo and a settings page. It is asking whether a high-consequence remote session into a client environment would be explainable after the fact.
Why remote access is now in the blast radius of MSP liability
This topic is especially relevant for managed service providers because the MSP is not just describing the environment. The MSP is often part of the environment the insurer is evaluating.
The Hartford’s supplemental literally asks how MSP access is controlled.[4]
That means the provider’s own operating model has underwriting relevance:
- technician account hygiene,
- approval workflows,
- segmentation between clients,
- emergency access design,
- patching of the MSP’s tooling,
- logging and retention,
- and how shared secrets or old session material are handled.
This is one reason why the remote-access question is more sensitive than, say, a backup-frequency question. The answer may describe both the insured and a third-party operator with privileged access into the insured’s environment.
The 2026 wake-up call: legitimate tools can still become attacker infrastructure
The March 17, 2026 security bulletin on ScreenConnect is instructive. It does not say remote-access software is inherently bad. It says earlier versions stored unique machine keys in server configuration files, and that under certain conditions those keys could be extracted and misused for session authentication, potentially enabling unauthorized actions or elevated access.[2]
Separately, CISA’s 2025 advisory on a different remote monitoring product says ransomware actors likely used an unpatched vulnerability to reach downstream customers and disrupt services in double-extortion events.[3]
Those two sources point to the same operational truth:
Even when a remote-access product is legitimate, the trust assumptions around it can fail.
That is why MSPs should stop reading underwriting questions about remote access as generic hygiene theater. The market has watched enough post-compromise abuse of legitimate tooling to know that remote access needs to be described more carefully.
What a defensible remote-access answer actually looks like
If a broker sends you a renewal question that asks how MSP access or remote access is controlled, the weak answer is a tool name.
- “We use remote support software.”
- “We use RMM.”
- “We require MFA.”
The stronger answer describes the control model.
1. Identity
- Every technician has a unique identity.
- Shared support accounts are prohibited or tightly exceptional.
- Break-glass access is segregated and monitored.
- Privileged roles are limited and reviewed.
2. Authentication strength
- MFA is enforced for all technician accounts.
- Higher-risk roles or admin paths use phishing-resistant methods where feasible.
- Exceptions are documented and time-bound.
3. Approval path
- Unattended access is restricted to documented scenarios.
- Ad hoc sessions require approval or documented policy authorization.
- Sensitive users and privileged systems have tighter approval requirements.
4. Device and source trust
- Technician access is limited to managed devices.
- Client connections are restricted by policy where possible.
- Public exposure is minimized.
5. Session control
- Session recording or equivalent logging exists for sensitive access.
- File transfer, clipboard, and elevation settings are constrained where appropriate.
- Idle sessions are terminated.
6. Exposure management
- Open-port hygiene is maintained.
- RDP is not left exposed casually.
- Remote tooling is patched promptly.
- Cryptographic material and secrets are rotated and protected.
7. Evidence retention
- Admin, access, and session logs are retained long enough to support renewal, incident review, and claims defense.
That is what “controlled” should mean in practice.
The part most MSPs still miss: cross-client blast radius
Underwriters may not always spell this out, but it sits under the surface of every MSP-access question.
If a technician account or management plane is compromised, what prevents the event from spreading across clients?
This is where remote access becomes more than an endpoint or identity question. It becomes a portfolio question:
- are client environments segmented,
- can one technician credential pivot broadly,
- are permissions scoped client by client,
- can session approval be centralized but still client-specific,
- are automation secrets isolated,
- and can one vulnerable connector or old server setting become a bridge into multiple insureds?
That is part of why remote-access underwriting is getting sharper. The risk is not always local.
What you should document before the broker asks
A broker-friendly remote-access evidence packet should be boring.
That is a compliment.
It should answer, in plain language:
- which remote access methods are in use,
- whether RDP exists and how it is protected,
- whether remote access requires MFA,
- whether technician accounts are unique,
- how MSP access is approved and logged,
- whether privileged sessions are separated from ordinary support sessions,
- which devices technicians may use,
- what your patch/hardening cadence is for remote-access infrastructure,
- and where session logs are retained.
If the answer currently lives only in tribal knowledge, the renewal risk is already higher than it should be.
How to speak about this without overselling or sounding anti-tool
This article should not read like “remote support products are unsafe.”
That is not the right lesson and it is not supported by the evidence.
The better statement is:
Underwriters increasingly care about the trust model around remote access, because attackers now routinely abuse legitimate remote tooling after social engineering or identity compromise.
That is precise.
It also gives the MSP a practical action plan instead of a vendor blame game.
What BindLedger can and cannot do here
This boundary is important to get right.
BindLedger can help establish parts of the broader attestation baseline today or soon:
- the public email-authentication posture of the client domain,
- MFA and privileged-access evidence from Microsoft 365 / Entra,
- identity-side signals that affect remote access defensibility.
What BindLedger cannot fully infer from outside the environment is the entire remote-access trust chain:
- session approval policy,
- whether a given client allows unattended access,
- clipboard/file-transfer restrictions,
- internal technician workflows,
- and how the MSP structures permissions across clients.
Those need a combination of telemetry, connector support, and documented process.
The honest message is not “we auto-prove everything.” It is:
We verify the parts the platforms can prove, and help you organize the parts your process still has to document.
That is the right architecture for this problem.
The renewal takeaway
The remote-access question is no longer a side note on a ransomware supplement.
It is one of the cleanest examples of where cyber insurance is moving:
- away from broad hygiene claims,
- and toward specific, explainable control narratives.
If your environment depends on remote access — and almost every MSP-led environment does — then the real renewal question is not whether that access exists.
It is whether you can defend the session trust behind it.