MSP Liability in Cyber Insurance Attestation: What the Courts Actually Say

MSPs help clients answer cyber insurance questions every week.

Sometimes it is formal and billed. Sometimes it is folded into the managed service. Sometimes it is a five-minute “can you confirm MFA?” email from the broker. Sometimes it becomes a frantic renewal scramble two days before expiration.

What has changed is the legal significance of that help.

The classic MSP mindset was: I am not the insured, I am not the broker, and I am not the lawyer. I am just providing technical facts.

That is still directionally true. The insured’s authorized representative signs the form. Coalition requires an authorized representative to complete the application after reasonable inquiry and states that the application and other underwriting materials can support disclaimer or rescission if materially inaccurate.[1] Travelers’ short-form application says the authorized representative signs after reasonable inquiry and that Travelers may rely on the application as the basis for providing insurance.[2] Hartford requires a senior officer of the applicant to sign and says the application becomes the basis of the contract if a policy is issued.[3]

But the courts and carriers are now showing something equally important:

If technical facts supplied by the MSP are wrong, those facts can become the center of a rescission action, a coverage dispute, or a subrogation lawsuit.

This article is not legal advice. It is a practical reading of the cases and forms that MSPs should understand before they keep treating questionnaire support like low-risk admin work.

The first lesson: the signature belongs to the insured, but the facts often come from the MSP

Most cyber applications are signed by the insured’s authorized representative, not by the MSP. That matters. It means the legal attestation sits with the policyholder.

But it does not mean the MSP is outside the blast radius.

In practice, the technical answers often come from one of three places:

• the MSP’s engineer or vCIO,
• the client’s internal IT lead,
• or a mix of screenshots, exports, and “we should be good” judgment calls.

If the client relies on the MSP’s technical representation when answering the form, the MSP can still become relevant after a loss, even if the MSP never touched the signature line.

That is the legal gray zone: the human who signs the application is not always the human who knows whether the control is real.

Travelers v. International Control Services: the policy can be unwound from the beginning

Travelers v. International Control Services is the cleanest modern warning shot.

According to Travelers’ complaint, ICS submitted a Travelers cyber application signed by its CEO and, at Travelers’ request, also provided a separate Multi-Factor Authentication Attestation.[4] In the application, ICS answered “Yes” to requiring MFA for administrative or privileged access.[4] In the separate MFA attestation, ICS also said “Yes” to a broader set of statements, including:

• MFA is required for all employees accessing email through a website or cloud-based service,
• MFA is required for all remote access to the network for employees, contractors, and third-party service providers,
• and MFA is required for internal and remote admin access to directory services, backup environments, network infrastructure, and endpoints or servers.[4]

Travelers alleged that after a later ransomware event it discovered MFA was not being used to protect the compromised server and that ICS only used MFA to protect its firewall, not its other digital assets.[5]

That distinction matters enormously.

The alleged problem was not that ICS had no MFA anywhere. The alleged problem was that ICS represented a much broader control state than what actually existed.

Travelers then sued for rescission and declaratory relief, alleging material misrepresentations and stating that had it known the true MFA posture, it would not have issued the policy.[5] The matter ultimately ended in a stipulated order rescinding the policy and declaring it void from inception.[6]

That phrase — void from inception — is the nightmare outcome. It means the policy is treated as though it never existed.

Why MSPs should care

Even though the insured signed, the practical question every MSP should ask is: who supplied the technical facts that made those “Yes” answers possible?

If the answer is “our team told the client it was in place,” that is already enough reason to change your workflow.

The real lesson from Travelers v. ICS is not “MFA matters.” Everyone already knows that. The lesson is that a mismatch between the attested control state and the real control state can destroy the policy altogether.

Ace American v. Congruity 360 and Trustwave: carriers may go after service providers after paying the claim

The second case matters for a different reason.

In Ace American v. Congruity 360 and Trustwave, Ace alleged that CoWorx had contracted with Congruity to host and secure the relevant infrastructure and that Congruity was contractually responsible for safeguards including remote access controls such as MFA.[7] Ace alleged that Congruity never established nor enforced MFA to log into the network.[7]

The complaint further alleged that if Congruity had enabled MFA before the unauthorized access, the server would have required acknowledgment of a push notification and the breach would have been thwarted.[7] Ace also alleged that Congruity set up the environment incorrectly, allowing a guest-level actor to gain access into the host network, and that Trustwave failed in its monitoring role.[8]

Most importantly, Ace sued after paying the underlying loss and sought damages in excess of $500,000 from Congruity, including negligence, breach of contract, and breach of implied warranty claims.[8] The docket shows the case was filed in federal court in New Jersey on September 15, 2025.[9]

Why this case is different

Travelers v. ICS was about coverage and rescission between insurer and insured.

Ace v. Congruity/Trustwave shows the next step: the insurer pays the claim, then looks downstream at the technology providers and asks whether they caused or worsened the loss.

That is the subrogation risk MSPs tend to underestimate.

You do not need to be the insured to become a target. You only need to be close enough to the failed control.

The legal gray zone for MSPs

Here is the part many MSPs want to reduce to a slogan: “The client signs, so it’s their problem.”

That is too simple.

It is true that the client or authorized officer signs the application.[1][2][3] It is also true that the broker, not the MSP, should be the one advising on coverage structure, carrier choice, and insurance-specific interpretation.

But the gray zone opens when the MSP does one or more of the following:

• supplies technical answers without preserving evidence,
• interprets a control loosely (“Yes, pretty much everyone has MFA”),
• collapses multiple access paths into one statement,
• fails to disclose known gaps or exceptions,
• or answers beyond the scope of what the MSP actually verified.

In other words, the risk is not only signing the form. The risk is creating the factual record behind the form with inadequate rigor.

The most common dangerous moves

1. Treating MFA as a product decision instead of an enforcement question
Owning Microsoft 365 MFA is not the same as proving email, remote access, and privileged paths are all enforced.

2. Treating policy intent as current truth
“We require BitLocker” or “we rolled out Defender” is not the same as confirming full coverage today.

3. Ignoring access paths outside the main stack
M365 may be solid while the VPN appliance, backup console, or RMM admin portal is not.

4. Using vague language in email
The sentence “everything looks covered” is a terrible artifact to leave behind if there is a later dispute.

What MSPs should actually do to protect themselves

This is the operational part that matters.

1. Separate technical verification from legal attestation

The clean model is:

• the MSP verifies technical facts,
• the broker and insured decide how those facts map to the application,
• the insured signs.

That does not mean the MSP disappears. It means the MSP’s deliverable is an evidence-backed control report, not a casual instruction like “answer Yes to Q6.”

This is why the category is shifting from questionnaire help to attestation defensibility.

2. Document what you checked, when you checked it, and what you did not check

A defensible verification record should include:

• date and time of the review,
• systems queried,
• control scope,
• exceptions found,
• blind spots or unverified systems,
• exported reports or screenshots where appropriate.

Example: “MFA confirmed for Entra-controlled email identities. Standalone VPN appliance not included in this review.”

That one sentence can save enormous pain later because it prevents a Microsoft review from being silently treated as a universal remote-access review.

3. Avoid coverage interpretation

MSPs should be especially careful about statements like:

• “This answer is safe.”
• “You can definitely answer Yes.”
• “This should satisfy the carrier.”

Those are broker- or counsel-adjacent statements, not pure technical statements.

Safer alternatives are:

• “Here is the current control state we verified.”
• “These users are excluded from the MFA policy.”
• “This backup target is connected to production and may not meet an isolation requirement.”
• “Remote access through the firewall appliance was not included in this verification.”

4. Treat exclusions and exceptions as first-class facts

Almost every bad insurance-control story hides an exception:

• one admin without MFA,
• one excluded group,
• one legacy VPN,
• one shared account,
• one site not on the standard stack.

The right workflow is to surface those exceptions explicitly, not bury them in oral context.

5. Make your MSA and SOW language clearer

If you regularly help with cyber-insurance renewals, your contracts should not pretend that this work is generic “IT support.”

At minimum, define whether you are:

• providing technical evidence only,
• preparing draft control summaries,
• excluding insurance/legal advice,
• and requiring the client to review and approve all final answers.

This is not fear-based lawyering. It is scope hygiene.

6. Carry the right insurance yourself

If your business participates in control verification, questionnaire support, or security recommendations, review your own E&O and cyber E&O coverage with counsel and your broker. The more you position your service as security assurance or risk reduction, the more important that becomes.

The evidence standard is rising even outside the courtroom

The court cases matter, but they are not the only sign that the environment is changing.

NAIC’s 2025 Cybersecurity Insurance Report shows that in 2024, cyber claims closed without payment totaled 28,555, while claims closed with payment totaled 9,941.[10] That “closed without payment” category is broader than denials alone — it can include withdrawals, below-deductible claims, and other coverage outcomes — so it should not be oversold. But it is still a strong signal that cyber claims are contested, filtered, and scrutinized.

Coalition’s renewal process shows the same directional change operationally. Coalition says cyber renewals begin 90 days before expiration and can include an updated Cyber Risk Assessment, security findings, and a pre-filled renewal application; appropriate security and risk controls assessed through Coalition’s active scanning affect automatic-renewal eligibility.[11]

This is the key trend:

The market is moving away from annual questionnaire theater and toward continuous, evidence-sensitive underwriting.

That trend is bad for any MSP workflow based on memory, trust, or informal screenshots.

It is good for workflows based on repeatable, timestamped verification.

What a safer MSP posture looks like in 2026

If you support clients with cyber insurance applications or renewals, the safer posture looks like this:

• do not sign,
• do not guess,
• do not compress multiple access paths into one answer,
• do not let the old M365 MFA screen become your source of truth,
• do preserve evidence,
• do define verification scope,
• do let the insured own the attestation,
• do let broker and counsel handle policy interpretation.

That architecture does not eliminate risk. It does reduce unnecessary risk.

The practical bottom line

The question is no longer whether MSPs can be pulled into cyber-insurance disputes.

They already are.

Travelers v. ICS shows that inaccurate MFA-related representations can unwind the policy itself.[4][5][6] Ace v. Congruity/Trustwave shows that carriers may look beyond the insured and try to recover from the technology providers they say failed to implement or monitor the relevant controls.[7][8][9]

The right response is not to refuse all questionnaire help.

The right response is to stop doing it casually.

BindLedger is designed around that separation of roles:

• the platform verifies and records the technical state,
• the report documents scope, evidence, and exceptions,
• the human decision-maker signs the insurance form.

That is a much safer model than “I looked in the portal and it seemed fine.”

Protect the client and protect the MSP

The safest renewal workflow is not “let the engineer answer from memory.” It is “verify first, document scope, preserve evidence, then let the insured sign.”

That is the architecture BindLedger is designed around. The platform records what was verified, when it was verified, what exceptions existed, and which parts of the stack were in scope, so the technical verification can stand on its own without pretending to be legal advice.