ChipSoft Ransomware: When Your Vendor's VPN Becomes Your Breach

On April 7, 2026, ransomware hit ChipSoft, the company behind HiX — the electronic health record system used by approximately 70 to 80 percent of Dutch hospitals. Eleven hospitals took systems offline immediately. By April 10, Belgian hospitals were affected. By April 15, sources confirmed patient data from the HIX365 platform had likely been stolen. Roughly fifteen hospitals filed data breach reports with the Dutch Data Protection Authority.

Z-CERT, the Dutch healthcare CSIRT, issued an advisory. Its instruction to ChipSoft's clients was specific: disconnect your VPN connections to ChipSoft.

That advisory draws a line that is worth examining carefully. ChipSoft was breached. The VPN was not the initial attack vector. But Z-CERT identified the VPN as the mechanism that was carrying the risk forward — from a compromised vendor into the networks of every connected hospital.

Those are two separate problems. Understanding the difference matters for every organization that gives a software vendor a tunnel into its network.

What happened at ChipSoft

The initial attack vector into ChipSoft has not been publicly disclosed. No ransomware group has claimed responsibility. What is confirmed: ransomware compromised ChipSoft's environment, encrypted or disrupted systems, and the attacker obtained access to patient data from the HIX365 platform.

This is not a story about a misconfigured firewall at a hospital. ChipSoft is the vendor. The hospitals are the clients. The breach happened at ChipSoft.

How the VPN amplified the blast radius

Once ChipSoft's environment was compromised, the VPN connections it maintained to hospital networks became a risk. A compromised environment on one end of a tunnel is a connected environment on the other end.

Z-CERT's advisory to disconnect VPN connections to ChipSoft was not a claim that VPN caused the attack. It was a recognition that an active network path from a compromised party into a hospital's infrastructure is a liability that can be severed. Hospitals that disconnected in time closed that path. Hospitals that did not faced exposure that extended beyond ChipSoft's environment into their own.

The blast radius was not determined by how ChipSoft was compromised. It was determined by what ChipSoft was connected to.

Why healthcare vendors maintain VPN tunnels to their clients

HiX is not a SaaS product. It runs on hospital infrastructure, either on-premises or on servers managed by ChipSoft on behalf of the hospital. For ChipSoft to support, maintain, update, and monitor those deployments, it needs remote access into the hospital's environment.

A VPN tunnel is the standard way software vendors do this. It gives the vendor's support and engineering teams connectivity to the systems they maintain. It enables ChipSoft to push updates, diagnose faults, and respond to incidents without being physically present in each hospital.

This is the same arrangement that exists across healthcare, industrial operations, critical infrastructure, and any sector where enterprise software runs inside the customer's network rather than in a public cloud. The vendor needs access. The VPN provides it. The customer grants it.

That access comes with a condition that is rarely stated explicitly: if the vendor is compromised, the tunnel is now connected to a compromised party. The same connectivity that enables legitimate support also enables an attacker who has taken control of the vendor's environment.

The third-party remote access problem

The ChipSoft incident is not an edge case. It is the default architecture for vendor-managed on-premises software, and it carries a structural risk that the standard VPN model does not solve.

The risk is not that ChipSoft was a careless vendor. The risk is that a full network tunnel, established for legitimate support access, does not distinguish between a legitimate ChipSoft engineer and an attacker who has compromised ChipSoft's environment. Both have the same access. The hospital has no visibility into which one is using the tunnel at a given moment.

This is why Z-CERT's response was to sever the tunnel rather than to trust that ChipSoft could contain the breach in time. Once the vendor environment is compromised, the tunnel is a liability regardless of what the vendor does next.

What hardware isolation removes from the equation

Zeroport Fantom delivers hardware-enforced, non-IP remote access. The connection does not run over IP. What crosses the boundary is pixels outbound and mouse and keyboard commands inbound.

In the ChipSoft architecture, a VPN tunnel from ChipSoft into each hospital is a network path. If ChipSoft is compromised, that path connects a hospital to a compromised environment.

In a Zeroport architecture, ChipSoft's support team sees a pixel stream of the hospital system they are maintaining. They interact with it via keyboard and mouse input. There is no network path from ChipSoft's environment into the hospital's infrastructure. An attacker who has taken full control of ChipSoft's environment has no tunnel to traverse. There is no equivalent to the VPN connection that Z-CERT instructed hospitals to disconnect, because that connection was never established.

ChipSoft would still need to be investigated and recovered. The hospitals it connected to would not need to be.

For security teams evaluating how their software vendors access managed systems, the ChipSoft incident provides a direct test: if your vendor's environment were compromised tonight, what does the attacker have access to through the connection your vendor uses to reach you?

The answer to that question is determined by the architecture, not by how quickly the vendor responds.

Book a live demo to see how Zeroport Fantom delivers hardware-enforced vendor access with no network path into your infrastructure

‍