Safeguard
Incident Analysis•

Stevens Point says a ransomware attempt was blocked before it ran

The Wisconsin city found unauthorized network access on 23 September 2026 and said on 29 September it believes it was a ransomware attempt. Here is what is confirmed and what is not.

Safeguard Security Team
3 min read

On 23 September 2026, the City of Stevens Point, Wisconsin, saw problems on several servers and found unauthorized access to its network. On 29 September, the mayor said the city now believes it was the target of a ransomware attempt that was stopped before it could run. The city has not published how the attacker got in.

A note on sourcing: we could not retrieve a statement on the city's own website. The city's words below are as quoted by local news outlets, so treat them as relayed official statements, not documents we read at the source.

What is confirmed

  • The city reported unauthorized access to its municipal network on 23 September 2026, and IT staff cut it off.
  • The city activated its Emergency Operations Center that evening.
  • On 29 September, Mayor Mike Wiza said "We now believe that the City was a target of a ransomware attempt." The city said its security tools and staff blocked it before it was able to execute.
  • The city said it had found no evidence that resident or employee data was compromised or captured, and that the investigation is ongoing.
  • Emergency services and critical functions stayed operational. The city said it was working with Wisconsin Emergency Management, UW-Stevens Point, Portage County IT and other agencies.

What is reported

  • Local reporting says phones and email were disrupted while the city restored services cautiously.
  • Early public messages described "intermittent technology issues." Internal staff emails reportedly called it a cyberattack on the first morning. The city later confirmed unauthorized access.
  • Reports said the city estimated about two weeks for full restoration, later hoping for normal operations within days of 29 September.

What is not known

How the attacker gained access, who was behind it, how long they were inside before 23 September, and whether the "no evidence of data compromise" finding will hold after forensics finish.

What to do now

  1. If you run IT for a small public body, write down who can declare an incident and who speaks publicly, so early messages match what technical staff know.
  2. Check that your detection covers the stage before encryption: new admin accounts, remote tools, and mass file access on servers.
  3. Test restoring phones and email without the main network. Those were the visible failures here.
  4. Keep a contact sheet for your state emergency management office and county IT.

How this could have been avoided

The city says its attempt was stopped, so the better question is how to repeat that result. The facts point to monitoring and staff response working. Controls that help the same way: alerting on unusual server behavior, a tested process to isolate servers quickly, and offline backups so a late detection is survivable. The entry point is unknown, so no one can name the control that would have kept the attacker out.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

The city says no data was compromised. Is that a final answer?

No. It is the city's finding so far, and it said the investigation is ongoing.

Why separate confirmed from reported facts?

Early public statements changed within a week. Writing down who said what, and when, keeps your own record accurate.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.