The cyberattack on Berlin's state network: what is documented so far, and what other public administrations can learn from it

An assessment made with reservations. The incident is only a few days old, the forensic investigation is ongoing, and the attacker's path is unconfirmed. This analysis therefore draws a strict line between what is documented, what is reported, and what we reconstruct. The status date is 18/08/2026, the evidence level of the attack path is reconstructed, and the case remains under observation with a review scheduled for 15/09/2026.

The essentials at a glance

• Two Berlin senate departments have been disconnected from the shared state network as a precaution since 14 August 2026: Urban Development, Building and Housing, and Mobility, Transport, Climate Protection and the Environment.
• Both have been working without internet access and without outbound email since then. Remote work is prohibited, and they can only be reached by telephone.
• There are two accounts of the initial access, neither of them confirmed: a malware attachment in an email, and a vulnerability in a locally operated departmental application that was never migrated to the state's central IT service provider.
• No figure has been put on the damage so far. It shows up in the calendar instead: housing benefit payments to more than 50,000 households and the education and participation benefits are time-critical.
• The lesson for others holds regardless of which account of the initial access is correct. What matters is how far an attacker gets from the first system they take over.

What happened

On Friday, 14 August 2026, forensic investigations establish a compromise of Berlin's state network. On the same day, two senate departments are disconnected from the network as a precaution to prevent further spread. (documented)

On 17 August the Senate Chancellery issues a public statement. It names the two affected departments, confirms the involvement of the State Criminal Police Office, the public prosecutor's office and the Federal Office for Information Security, and sets up an ICT emergency task force led by the state commissioner for information security. It gives no information on the attack path, the scope or a possible data breach, citing the ongoing investigation. (documented)

Over the following days it becomes clear what the disconnection means in daily practice. Staff describe themselves to the press as effectively unable to work. Housing entitlement certificates, misuse-of-housing reviews, land registry information as well as housing benefit and education-and-participation applications are not being processed. (reported)

How the attack unfolded

By our reconstruction, the path consists of three stages. All three carry the evidence level "reconstructed", meaning they are derived from the pattern of the respective attack route and are not confirmed in this case.

01 Delivery. A news agency reports, citing security sources, that a member of staff opened a PDF attachment containing malware. This is unconfirmed. A public broadcaster's report instead names a vulnerability in a locally operated departmental application as the starting point. Both accounts can be true and describe different stages of the same sequence. (reconstructed)

02 Lateral movement. Access extended beyond the first system taken over. That it reached the shared state network is the only statement about the sequence of events that comes from an official source: the Senate Chancellery speaks of an established compromise of the state network. It is consistent with the fact that two departments were isolated, not one. (reconstructed)

03 Data exfiltration. Here the sources clearly contradict each other. The Senate Chancellery states that the data concerned was already freely available through open data. A broadcast report speaks of highly sensitive data. Sources within the administration mention exfiltrated geoinformation data from public databases. As long as the forensic investigation is running, none of these accounts is reliable. (reconstructed)

Each stage has a control that takes effect there. Marked as an assumption, because the path itself is an assumption:

• 01 Delivery, phishing by email. Would have broken it: malware filtering at the email gateway.
• 02 Establishing a foothold, lateral movement in the network. Would have broken it: network separation and segmentation.
• 03 Objective, data exfiltration. Would have broken it: collecting and analysing network flow data.

The metrics for this case are correspondingly thin. The dwell time is unknown. Recovery is open, and the isolation is still in place on 18/08/2026. The visible operational disruption is housing benefit for more than 50,000 households, and it is time-critical.

An opened attachment is an incident in one department; only a network that does not end there turns it into an incident for the entire state.

Two pieces of information are still missing, and both would be decisive for the assessment. No one has said whether 14 August was the day of the attack or merely the day of discovery. And no one has said when the departments will be back on the network.

Where it could have been broken

At this point our analyses normally state which control was missing. That is not permissible here. Outside the forensic investigation, nobody currently knows what was in place in the two departments, and speculation about it would amount to claims about people who are in the middle of recovery.

What can be said is which controls take effect at these stages.

At delivery, malware filtering at the email gateway takes effect, because it intercepts the attachment before anyone can open it. Behind that, endpoint protection with behavioural detection takes effect, noticing the execution if the filter let it through.

At lateral movement, network separation takes effect. It is the most expensive control on this list and the only one that decides whether an incident in one department stays an incident in one department. Alongside it, complete asset management takes effect: a system that appears in no central inventory is not patched, not monitored, and in an emergency not the first place anyone looks. And central analysis of security-relevant events takes effect, because movement across several network zones leaves traces that someone has to see.

At data exfiltration, network flow data takes effect, making an unusual outbound transfer visible. On top of that comes an administrative decision: a planned fallback procedure for time-critical services. It does not prevent the attack, but it decides whether citizens notice it.

What the outage costs

The financial damage has not been quantified, and at present it cannot be credibly estimated either. Something else is visible.

Operationally, two departments are in emergency mode. No internet, no outbound email, no remote work, reachable only by telephone. Several departmental processes are fully suspended.

Financially, the housing benefit payment to more than 50,000 households is time-critical, because it is usually made at the end of the month. The same applies to education and participation benefits.

Legally, investigations are running, and a task force is coordinating. The 72-hour window under Art. 33 GDPR starts as soon as anyone in the department becomes aware of the incident. Anyone who waits until the scope is clear reports too late. That is exactly what happens regularly the first time round.

For a public authority, this chain ends differently than it would for a company. The notification goes to the Berlin Commissioner for Data Protection and Freedom of Information; fines against public bodies of the state are excluded (§ 28 BlnDSG). What remains are a reprimand and an order from the supervisory authority, a report to the state parliament, and compensation claims by affected individuals under Art. 82 GDPR. (documented)

A federal cybersecurity obligation does not apply to the state administration regardless. The NIS2 transposition act covers the federal administration. The states implement it for the critical parts of their own state administrations under their own responsibility, and the municipal level is exempted following a 2023 decision by the IT Planning Council. What applies in Berlin is therefore decided by Berlin. (documented)

Reputationally, the criticism is directed less at the incident than at the structure behind it, namely locally operated IT alongside a central service provider.

It is worth noting who bears the damage. The organisation bears the emergency mode and the working time tied up in it. The visible part is borne by the applicants. Someone waiting for housing benefit has nothing to do with the IT structure of a federal state and still feels the consequences first. In a public administration, this line takes the place of lost revenue.

What other organisations can check today

The case is transferable to any organisation with a shared network and locally operated departmental IT: state and municipal administrations, corporate groups with acquired subsidiaries, any organisation with an ongoing, not yet completed centralisation.

Three questions can be answered today without anyone setting up a project:

1. Which externally connected systems in your organisation are not run by central IT operations, and do you even know which ones those are? This should not be an annual inventory but a continuous query: what is reachable from outside, who operates it, and is it recorded in the inventory?
2. If one of these systems is taken over: where does the access end? And can someone show that boundary rather than assert it?
3. Which of your services can only tolerate a short outage, and at what point does it become expensive or legally sensitive? And how are those services delivered if the network is gone for a week?

The third question is the starting question of business continuity management. It asks how long a service may be unavailable before the damage is no longer tolerable. For the three most important services it can be answered without setting up a full business impact analysis.

A short list of measures follows from the answers. First, asset management covering all operated systems, because it is available immediately and its effect becomes visible in inventory coverage. Then connecting the locally operated systems to central analysis, measurable by log coverage of critical systems. Then network separation. It takes years, and it is the only item on this list whose progress cannot be read off an established metric: coverage is measurable, quality of separation is not. Anyone taking it on should define the success criterion in advance, otherwise the project peters out between two budget years. And finally the fallback procedure for time-critical services. Its effect shows in how many critical processes have a tested emergency mode.

How we arrive at this assessment

We work through every case using the same procedure: source situation, attack path, breaking points, causes, business impact, controls, transferability, limits. Every statement carries an evidence level. Documented means an authority, a court or the affected organisation itself has published it. Reported means several independent media outlets or a forensic service provider. Reconstructed means derived from the pattern and not confirmed in this case.

Because this incident is only a few days old, we work in remote mode. Additional rules apply there. Every assumption gets its own entry with its basis, a counter-assumption, and the observation that would overturn it. Statements about what those affected failed to do are off limits. Controls are addressed to third parties.

Assumption 1. The initial access came through a malware attachment in an email. Falls if a parliamentary answer or a forensic result names a different route. Two controls in this analysis then fall with it; the statement about the spread remains.

Assumption 2. Between the initial access and the state network there was at least one area outside the central operating and patching processes. Falls if an account from the forensic investigation traces the route exclusively through centrally operated systems.

Assumption 3. Data was exfiltrated; the accounts differ on how sensitive it was. Falls if the forensic investigation, a notification to affected individuals under Art. 34 GDPR, or a parliamentary answer names the scope. The Art. 33 notification goes to the supervisory authority and is not published, so it does not work as a falsification condition.

We build the chain this way so that, once an assumption is overturned, it remains readable which part of the analysis falls with it and which part stands.

Limits and open questions

The initial access is not confirmed, and the two available accounts may only appear to contradict each other. On the data exfiltration, three statements stand side by side that cannot be reconciled. The time of the initial access is unknown, and with it the dwell time, meaning the period between intrusion and discovery. And the duration of the isolation is open.

Whether the incident belongs to a larger pattern cannot be judged from the public sources. We looked for it and found nothing that could be substantiated. That is not an all-clear, it is a statement about the source situation.

Sources

1. Senate Chancellery Berlin, press release on the ICT incident in Berlin's state network, 17/08/2026. berlin.de
2. Tagesspiegel, reports on the ability to work and the endangered housing benefit payment, 18/08/2026. tagesspiegel.de
3. Berliner Zeitung, consequences for housing benefit and for education and participation, 18/08/2026. berliner-zeitung.de
4. WirtschaftsWoche with a Reuters report from security sources on the initial access, 18/08/2026. wiwo.de
5. heise online, investigations and isolation from the state network, 18/08/2026. heise.de
6. Berlin Data Protection Act, § 28 BlnDSG on fines. Text retrieved 19/08/2026. dsgvo-gesetz.de
7. BSI, FAQ on NIS-2 for states and municipalities, on the states' responsibility and the IT Planning Council's decision 2023/39. Retrieved 19/08/2026. bsi.bund.de

Status and updates

Status 18/08/2026, state: under observation, review on 15/09/2026. On 19/08/2026 first publication as a remote analysis, all stages at evidence level reconstructed.

19/08/2026, legal framework clarified. Added the exclusion of fines for public bodies and the states' own responsibility for NIS-2, plus two sources. Path and metrics unchanged.

As long as a case is under observation, we check on the review date whether any of the open points has occurred. Here there are three: an answer to a parliamentary question with information on the initial access, a notification to affected individuals under Art. 34 GDPR, and a possible entry for the affected bodies on a leak site. If none of them occurs, the case is closed and stands as it is. If one occurs, we change the article and record in this log what has changed. That applies even if our assessment turns out to be wrong.

This analysis describes the situation as of 18/08/2026. It stays online even as it ages. We update it when new evidence changes the statement.

How we work. KaitoSec analyses cyberattacks using a fixed procedure and derives controls with demonstrable effect from them, for organisations with grown IT estates and regulatory pressure. The procedure is published, and so are the case analyses.

Professional assessment, not legal advice.