Cases · 2026-10-30 · 3 min read
ConnectWise breach: when you can't prove what the hackers saw
Chinese hackers spent months inside ConnectWise's systems, with potential access to thousands of client companies. The incident shows a gap in breach response: proving what data was accessed or changed.
What happened
In early 2025, ConnectWise, a major provider of IT management software used by thousands of managed service providers, disclosed that Chinese state-sponsored hackers had breached its systems [1]. The attackers maintained access for months, potentially reaching sensitive data from the managed service providers and their own clients.
ConnectWise detected the breach and brought in forensic investigators. It says it has found no evidence that client data was exfiltrated or altered, but proving a negative is harder than proving a positive [1]. The company couldn't say with certainty what the attackers did or didn't see during those months.
For the managed service providers who rely on ConnectWise, and for their clients in turn, that uncertainty is the problem. If you're one of thousands of companies whose data might have been accessed, "we found no evidence" isn't the same as "we can prove it wasn't".
Why logs matter, and why they're hard to trust
Think of access logs like a sign-in sheet at a building's reception. If someone breaks in through a side door, the sheet won't show it. If they sign in under a false name, or if the receptionist quietly erases a line later, the sheet becomes less useful as evidence.
In a breach, logs are what tell you who accessed what, when and from where. But logs are kept by the same people who could change them. That's fine until someone with the right access wants to make a problem disappear.
Under the EU Cybersecurity Act, organisations in essential and important sectors must report significant incidents within 24 hours of becoming aware of them, with a full report within 72 hours and a final one within a month [2]. DORA's technical standards require financial firms to protect logs against tampering, deletion and unauthorised access [3].
The law asks for the logs. Whether they hold up as evidence is another question.
What you need to show
When a breach happens, the questions come quickly. Supervisors, clients, insurers and potentially courts want to know:
- When did the breach start, and when did you become aware of it?
- What systems and data were accessed?
- What was changed or taken?
- Who accessed the logs, and when?
If your logs can be edited by the same people who run the systems, those questions get harder to answer. It isn't that anyone will edit them. It's that someone else can ask whether they might have, and you'll struggle to prove they didn't.
How a digital witness helps
Here, the thing to seal is log segments as they close, at short intervals such as every few minutes. Your system sends a fingerprint of each segment to WitniumChain through the REST API, the SDK or the MCP server, and gets a witness ID back. The content stays with you.
Later, if someone questions a log, anyone you share it with can calculate the fingerprint again and compare it with the sealed one. If it matches, the log hasn't changed since sealing. Change a single character and it won't match.
Internal audit, supervisors and incident responders can check it. That makes a breach debrief shorter and the evidence harder to challenge.
A digital witness doesn't replace access controls, monitoring or backups. It doesn't show that the logs are complete, or that the response was adequate. What it does is make tampering visible, even when it's done by someone with administrator rights.
How it would work
- Log segments are sealed as they close, every few minutes.
- The fingerprint is sealed on a chain where any change would show.
- When questioned, anyone you share the log with can recalculate the fingerprint and check it matches.
What this means for you
If you're responsible for IT systems, client data or incident response, here are three questions worth asking now:
- If we were breached tomorrow, could we show supervisors and clients exactly what was accessed, based on logs nobody can quietly edit?
- Do our incident response plans assume we'll be able to trust our own logs under pressure?
- When we rely on a third-party platform, do we have our own records of what data we gave them access to?
The ConnectWise breach is a reminder that access isn't the same as proof. You may never be breached. But if you are, the side with the stronger evidence starts several steps ahead.
What to watch
The EU Cybersecurity Act's incident reporting rules apply from 15 January 2026 [2]. Financial firms under DORA have been subject to its ICT risk management requirements, including log protection, since 17 January 2025 [3].
For high-risk AI systems under Annex III of the AI Act, the logging requirements in Article 12 apply from 2 December 2027 [4].
Sources
- [1]Chinese hackers breached IT giant ConnectWise in months-long cyber-espionage campaign, TechCrunch, 2025-01-09
- [2]Cybersäkerhetslagen (2025:1506), Riksdagen, 2025
- [3]Commission Delegated Regulation (EU) 2024/1774, Article 12, EUR-Lex, 2024-06-17
- [4]AI Act Article 12: Logging, European Commission AI Act Service Desk, 2024