In 2024, the City of Hamilton, Ontario became the victim of one of Canada's most costly municipal ransomware incidents. The attack disrupted city services for weeks and cost the municipality an estimated $18.3 million in recovery and operational impact.[1]

The technical details have been documented by security researchers and the city's own audit reports. But the underwriting implication is sharper: Hamilton had implemented multi-factor authentication on some systems. It did not have MFA enforced universally across all systems and administrative accounts.

Attackers found the gaps.

This is not speculation about what might have happened in a hypothetical. This is what actually happened at scale in a major North American municipality. And it directly mirrors the control question every carrier now asks during cyber insurance renewal.

What Happened: MFA Deployment Was Incomplete

Hamilton's attack was a classic ransomware operation delivered through credential compromise. The attackers gained initial access, moved laterally through systems, and encrypted critical services. The city's response included weeks of disrupted operations and significant recovery costs.

The incident report and security analysis both confirmed that MFA was deployed on some city systems but not all. More importantly, administrative accounts and critical systems did not have universal MFA enforcement.

When carriers ask "Do you require MFA for all remote access?" or "Is MFA enforced for all administrative accounts?", what they are really asking is: "Did the architecture prevent the exact sequence of events that happened to Hamilton?"

The honest answer in Hamilton's case was no.

Why Coverage Was at Risk

This matters not because the city necessarily filed a claim that was denied or rescinded. It matters because the coverage question was always binary: either MFA enforcement was defensible, or it was not.

Let's look at what carriers actually check:

  1. Scope of MFA enforcement — Which systems and account types have MFA?
  2. Enforcement mechanism — Is MFA required or optional?
  3. Exception tracking — Are there exclusions, and if so, are they documented?
  4. Conditional Access policy — Are there gaps in the policy that allow unprotected access?

Hamilton's actual deployment created a situation where an attacker could:

  • Compromise administrative credentials through external reconnaissance or phishing
  • Use those credentials to access systems without MFA challenge
  • Move laterally within the network

From a carrier's perspective, this is the control failure that ransomware attacks exploit. The answer to "Is MFA enforced everywhere?" was no. And that answer changes how a carrier prices the renewal, applies contingencies, or views the claim context.

What Evidence Would Have Changed the Outcome

Evidence doesn't change the past. It changes the conversation before the incident.

A defensible MFA posture requires:

  1. Complete enrollment documentation — Every account type, every system, every administrative user. Not a sample. All.

  2. Conditional Access policy artifacts — The actual policy rules that define who is required to use MFA and from where. Including any exclusions, and the business justification for those exclusions.

  3. Exception tracking log — A maintained record of any accounts or systems where MFA could not be deployed, with timestamps and justification.

  4. Enforcement verification — Sign-in logs or MFA audit data showing that the policy is enforced in practice, not just configured in theory.

  5. Scope review evidence — Documentation that the organization has inventoried all systems and account types and confirmed MFA status for each.

This is the companion evidence piece: "How to prove MFA is everywhere — not just where it's easy."

Because MFA is easy to deploy on cloud systems. It is harder on legacy systems, older hardware, or external service accounts. Carriers know this. They do not penalize partial MFA if it is documented, justified, and scoped precisely.

What they penalize is the confident claim that MFA is universal when it is not. That was Hamilton's position: reasonable controls on many systems, but no defensible claim of universal coverage.

The Control Question at Renewal

This year, when you sit down with your carrier renewal questionnaire, you will see this question in some form:

"Do you require multi-factor authentication for all user remote access?"

Or:

"Is MFA enforced for all administrative accounts?"

Or:

"Are all external-facing systems protected by MFA?"

The question looks simple. The answer is hard because the question collapses "all" into a binary.

Carriers know this. They build in the follow-up:

"If not all, please list the systems or account types where MFA is not enforced and explain why."

That is where the Hamilton case becomes relevant. Because if the answer is "we have some legacy systems without MFA" or "we could not enforce MFA on vendor accounts," the carrier will follow up with: "Show us the documented exception, the business justification, and the compensating controls."

If you cannot show those, you are back to the original problem: a claim to universal coverage that is not defensible.

Practical Steps Before Your Next Renewal

  1. Inventory all systems and account types — Not just cloud, not just end-users. Remote tools, vendor accounts, hardware management interfaces, legacy applications.

  2. Document actual MFA status — For each system/account type, is MFA required, optional, or not available? Use screenshots, policy artifacts, and signed attestation from your security team.

  3. Identify exceptions — Where is MFA not deployed? Write down the reason, the business impact of deploying it, and any compensating controls (IP allowlisting, time-based access, hardware keys).

  4. Preserve conditional access policies — Export your Entra ID or cloud identity platform policies. This is your single source of truth for the renewal conversation.

  5. Test the claim — Before renewal, perform a spot check: pick three administrative accounts at random and confirm that MFA is actually required to access production systems.

This is the work that prevents the Hamilton case from repeating in your environment.

Check your controls now. Run the free readiness check →

Have a carrier questionnaire? Upload it to see what you're missing →