Five threats to a Swiss organisation, and the control that blocks each one

Published 7 August 2026 · updated 25 August 2026

In March 2026 the Swiss Federal Office for Cybersecurity published its report on the second half of 2025: 29,006 voluntary reports, 145 mandatory reports, and fraud behind about 52% of the voluntary reports. Those numbers say what happens most often. They don’t say what stops a company for a week, and that gap is the problem: a budget built on how often something gets reported doesn’t pay for the measures that stop the expensive incidents.

This article takes the threats one at a time. Each section states where the threat comes in, gives a documented Swiss case, and names the control that blocks it. The control deserves the attention, and it is rarely the product on the invoice.

The exposed security appliance

Akira stayed the most active ransomware group in Switzerland in 2025. The NCSC counts around 200 Swiss victims between May 2023 and September 2025 and names unpatched systems and badly secured VPN or RDP access, above all access without a second factor, as the common ways in.

The semi-annual report separately discusses a 2024 SonicWall vulnerability, exploited at companies that had not completed all the vendor’s instructions, including changing the passwords. The published evidence doesn’t tie that particular path to all 200 victims, but the lesson stands: a security appliance facing the internet is itself an attack surface, and an installed patch is not enough when the advisory asks for more.

Three controls close this route:

An inventory of exposed services: every appliance, port and service that answers from the internet, with a named owner for each entry.
A patch calendar for the appliances themselves: the firewall and the VPN gateway get their own schedule, separate from the workstations they protect.
The vendor advisory executed to the last step: when an advisory tells you to change the passwords after updating, it is telling you to assume the passwords already left.

The credential already for sale

The next route exploits no flaw at all: it uses a password that is already circulating. A machine infected by an infostealer hands over the passwords saved in the browser and, above all, the session cookies, the tokens a service issues once you have signed in.

Those cookies defeat a good share of current defences. A six-digit code is a value a human retypes, and a relay sitting between the victim and the real sign-in page retypes it just as well, then collects the session token issued behind it. The second factor worked, and the attacker got in anyway.

The control that holds is phishing-resistant authentication:

Security keys and passkeys: they sign against the site’s origin, so they refuse a lookalike domain.
Endpoint protection and session controls: the key stops the relay, not the infostealer already running on the machine.
A recovery path as strong as the sign-in: an attacker who cannot beat the passkey attacks the reset procedure instead.

Not every service supports passkeys yet, banks included. See identity, directory and access.

Executive fraud and the three payment rules

Executive fraud forces nothing; it prepares. The professional networks, the company website and the commercial register are enough to learn the hierarchy and spot who is away, and the preparation sometimes stretches to the AI-reproduced voice of a business partner. The email that asks for payment can look entirely legitimate: a real domain, a valid signature, even the supplier’s genuinely compromised mailbox. A filter can have nothing to report.

Three written rules protect where filters cannot:

The callback: every time, on a number you held before the request arrived, never the number printed in the message.
Two signatures above a threshold you set: no single mailbox, however senior, releases a large payment alone.
Urgency treated as the signal: stated out loud once a year: a request that forbids you to check is a request to check.

The compromised supplier

The Swiss Confederation lived through this threat twice in a single year: Xplain in 2023, then Concevis a few months later, two software suppliers whose compromise exposed data the administration didn’t host itself. The ransomware struck the provider without reaching the federal systems; the leak concerned the data each provider held for its clients.

Two lists and one clause contain this exposure:

The list of who holds your data: kept current, with the contractual duty to notify you written into the contract.
The list of who can reach your systems: provider identities that are named, least-privileged, limited in time, logged, revocable without delay, dedicated or federated.
No accounts outside the directory: an unmanaged account outside the directory isn’t safer than a well-governed account inside it.

I set out the clauses to get before you sign in the requirements a municipality should put to its IT provider.

Ransomware, the consequence of the routes above

Ransomware is usually not the way in but the consequence: the routes above let the attacker in, and the encryption closes either a fast attack or a much longer stay.

On 12 April 2026 Akira encrypted the town of Vétroz: close to a week without its databases and core software, and the loss of the emails received since 7 April. The attack spilled onto a neighbouring SME, left with no stock management and no invoicing, and so with nothing coming in.

The controls in this section don’t prevent the incident, they decide its cost:

A copy the attacker cannot reach: the backup refuses the production passwords, so the encryption never touches it.
A restore already run and timed: the difference between a day and a week is a number you measure before the incident, never during it.

See backup and recovery and the restore test.

Where to start

None of these measures reduces to a product. Each one is a decision: the services you leave exposed, the people allowed to sign in and how, the person who signs a payment, the place where each copy of the data lives. Write the decisions down and test them at a rhythm that matches the risk. For the company described here, I would start in this order:

The inventory of exposed services: list everything that answers from the internet, patch it, complete every vendor instruction including the password changes, and close the services that don’t need to stay exposed.
Passkeys on the accounts that open everything else: mail and admin accounts first, with a recovery path as strong as the sign-in.
The three payment rules: one page is enough, read out loud once a year.
One copy out of reach, with a timed restore: that copy decides whether an incident costs a day or a week.
The two supplier lists: the holders of your data and the accesses to your systems, with the duty to notify written into the contract.

Denial of service carries no rank here, its priority depending on the service: for a town, a healthcare provider, a platform bound by contract or an online shop, losing availability can be severe and call for protective capacity, a fallback channel and rehearsed crisis communication.

A risk assessment therefore adapts this order to the assets the company holds and the obligations it carries.

Nobody in Vétroz decided to lose five days of correspondence. The backup decided it for them.

The federal report and the other sources

I took the report and its figures on 14 August 2026. The priorities above fit the scenarios in this article; reorder them to match business impact, exposure, dependencies, obligations and the controls already in place.