MFA on the Firewall, Not the Servers: The Case That Shows How UK Cyber Claims Really Die
Friday 10 April 2026
I’m Lucy Harper, and every Friday I take one case and work through what actually happened, what it tells us about the broader pattern, and what UK small businesses need to take away from it.
This week, the case is one that cyber insurance professionals and incident response firms reference regularly, though, as I will explain, the specific details are not publicly identified in the way that some data breach cases are. That confidentiality is itself part of the story.
The account I am working from appears in secondary sources including analysis from UK IT and security professionals who have seen this pattern play out in their own client base. It describes a UK business that said yes to MFA on their cyber insurance proposal form, had a ransomware attack, and had their policy voided when the insurer’s forensic team found that MFA existed on the firewall VPN but not on the servers, which was where the attack originated.
I will walk through what happened, why the insurer was able to act as they did, and what any business with remote access services needs to check.
Transparency note: The specific company in this case has not been publicly identified, which is common in insurance disputes that are resolved without litigation. The pattern, and the legal basis for the insurer’s response, is well-documented and consistent across multiple industry sources. I have flagged where I am working from secondary accounts and where verification is limited. For specific advice on your own coverage position, speak with a qualified, FCA-authorised broker.
What Happened
The business in question: a UK SMB, the precise sector is not identified in the accounts I have reviewed, that purchased cyber insurance and completed the standard proposal form.
One of the questions on that form asked whether the business had multi-factor authentication in place for remote access. The answer given was yes.
That answer was accurate, to a point. The business operated a firewall with a VPN service. That VPN required MFA. The answer reflected the IT team’s understanding of their remote access security.
What the IT team did not account for was a separate remote desktop service running directly on certain servers. This service had been set up to allow specific users to access those servers remotely for operational reasons. It was not part of the main VPN architecture. It did not have MFA configured. And, crucially, it was internet-facing.
When the ransomware attack occurred, the attackers did not come through the VPN. They came through the unprotected remote desktop service. They gained access to the servers directly, without needing to pass through the MFA-protected VPN at all.
What the Insurer Did and Why They Could
After the breach, the insurer appointed a forensic investigation team. That team’s job was twofold: help contain and understand the incident, and reconstruct the state of the business’s IT environment at the time of the attack, comparing it against the proposal form answers.
The investigation found what I described above. MFA on the VPN. No MFA on the remote desktop service. The attack came through the remote desktop service.
The insurer’s position, applied through the framework of the Insurance Act 2015, was that this constituted a misrepresentation on the proposal form. Specifically, the answer “yes, we have MFA on remote access” was not fully accurate, because not all remote access paths were protected.
Under the Act, misrepresentation falls into three categories: innocent (answered honestly based on what was reasonably known at the time), negligent (should have known better and checked), and deliberate or reckless (knew it was wrong or did not care). The distinction matters because it determines what remedy the insurer can apply.
In this case, the insurer’s position appears to have been that the business should have known that other remote access services existed, and should have checked that the proposal form answer reflected their entire remote access footprint, not just the primary VPN. That argument positions the misrepresentation as negligent, at minimum.
The FCA’s ICOBS 8.1 guidance requires that any breach a business relies on to deny a claim must be connected to the loss. In this case, the connection was direct: the specific control that was misrepresented (MFA on remote access) was the specific control whose absence allowed the attack to succeed. That connection was difficult to dispute.
The reported outcome: the policy was voided. The accounts I have reviewed describe the policy as being treated as if it never existed, rather than simply having the payout reduced. That outcome is consistent with a finding of at minimum negligent misrepresentation on a condition that was central to the risk.
Why This Is Not a Rare Edge Case
The reason cyber insurance professionals reference this pattern repeatedly is that it is not unusual. It is, in fact, one of the most common scenarios they encounter.
Coalition’s 2024 cyber claims data found that 82% of denied claims involved organisations without MFA fully implemented. The word “fully” is doing enormous work in that sentence. “Fully” means every user, every account, every remote access path, every service, with no exceptions that have not been explicitly disclosed and agreed with the insurer.
The typical failure mode is not an IT team that decided not to bother with MFA. It is an IT team that implemented MFA on the primary services and considered the job done, without auditing whether there were other services operating in parallel. Remote desktop services are a particularly common gap, precisely because they are often set up for specific operational reasons and are less visible than the primary VPN.
The DSIT Cyber Security Breaches Survey 2025 found that only around 40% of UK businesses have two-factor authentication enabled across all the services they use. If that figure is accurate for the SMB market, then the majority of UK businesses that have answered yes to the MFA question on their cyber insurance forms are in a position where a forensic investigation could find discrepancies.
The Attribution and Evidence Problem
One of the things that makes cyber insurance claim disputes difficult to track and report on is that most of them are resolved confidentially. Unlike ICO enforcement actions or court judgments, insurance claim disputes between an insurer and a policyholder are rarely public. The parties have strong incentives to settle rather than litigate: the insurer avoids legal costs and adverse publicity, and the business avoids the cost and stress of formal proceedings, even if the settlement is unfavourable.
This means the documented evidence base is largely confined to secondary accounts from professionals involved in the claims process, academic analysis, and the handful of cases that do reach formal legal proceedings. The US has more public case law in this area than the UK, partly because the US insurance litigation culture is more adversarial and partly because some US disputes involved large enough sums to make litigation worthwhile.
The Travelers Property Casualty Company of America versus International Control Services case in the United States, for example, involved an insurer seeking to rescind a policy after discovering that the insured had misrepresented its use of MFA during the application process. That case produced a public court record. The equivalent UK cases are largely invisible because they settle.
What this means for the small business trying to understand their exposure: the absence of visible UK case law does not mean these disputes are not happening. It means they are happening quietly.
The Lesson for Any Business with Remote Access
If you run any form of remote access to your business systems, the question to ask is not “do we have MFA?” The question is: “does every path into our network, from the internet, require MFA before anything else happens?”
That means:
Audit your remote access footprint. List every service that allows external access to your internal network or systems. VPNs, yes. But also remote desktop services, remote management tools, web-based administration interfaces, cloud-hosted applications with single sign-on that is not MFA-protected.
Check MFA status on all of them. Not the primary VPN. All of them.
Check who has exemptions. Many IT environments have accounts or services with MFA disabled for operational reasons. Every one of those exemptions is a potential policy condition failure.
Document what you find. If everything is covered, document that it is covered and when you checked. If there are gaps, document the gaps and your plan to close them.
Tell your broker if there are gaps you cannot immediately close. A disclosed limitation is infinitely better than an undisclosed one. Your broker can advise on whether an exception needs to be declared, and whether it affects your coverage terms.
What This Week’s Episode Covers
Episode 15 of The Small Business Cyber Security Guy, with Noel Bradford, Graham Falkner, and Mauven MacLeod, goes through the full picture: how UK cyber policies work legally, what the proposal form is actually testing, what the forensic investigation looks for, and what you need to do before and after a breach to protect your claim.
The case I have described above is one data point in a broader pattern that the episode covers in depth.
How to Turn This Into a Competitive Advantage
Suppliers who can demonstrate that their remote access infrastructure is audited, fully MFA-protected, and documented are increasingly valued by larger buyers, particularly in regulated sectors. The ability to say “we have checked every remote access path and MFA is enforced without exceptions” is not a common claim. Making it credibly, with evidence, is a competitive differentiator.
How to Sell This to Your Board
The case I have described is not about a business that was negligent in a general sense. It is about a business where a technical gap existed in a less visible part of the infrastructure, was not caught during the proposal form process, and was exploited by attackers who specifically look for exactly these kinds of partial implementations.
The board-level lesson: the question is not “do we have cyber insurance and the main security controls?” The question is “have we audited the completeness of our controls against what our policy requires, and do we have evidence to prove it?” Those are different questions. The second one is the one that matters when a claim is disputed.
Related Posts:
- The Proposal Form That’s Building a Landmine Under Your Business
- Six Controls That Stand Between You and a Denied Cyber Claim
- You Bought Cyber Insurance. Congratulations. Now Read the Bloody Small Print.