Sheet 00 Cover opened

Public Sector · NIS2 & OZG

SubjectSecurity of administrative IT: testing and evidence

One breach at your IT provider can take down dozens of towns at once

The NIS2 Directive covers public administration as a sector of its own; in Germany, section 29 BSIG governs the federal administration, while state and municipal bodies fall under the respective state law. For online services delivered under Germany's Online Access Act (OZG), the Portal Network Security Ordinance (ITSiV-PV) issued by the Federal Ministry of the Interior additionally requires web checks and penetration tests before connection and at least every three years after that, carried out by the BSI, a state information security authority or BSI-certified providers. One risk stands out: many municipalities don't run their own IT, they rely on a shared municipal IT provider, so a single successful breach can take down dozens of towns at once. Citizen portals, specialized administrative software, and the connection to the shared provider: those are the three places we focus on.

Get your admin IT tested See the Südwestfalen-IT case
  • Test reports following the BSI specifications for penetration tests and web checks
  • Experience with municipal IT & legacy systems
  • Free initial consultation

This page is laid out like an administrative file: ten sheets, each with its own number. The tabs along the edge show where you are.

Sheet 01 Responsibility for review

Responsibility grid

Three levels, three legal regimes, three sets of responsibilities

There is no such thing as one single addressee called the public administration. Federal, state, and municipal bodies run different systems, answer to different law, and own different parts of the infrastructure. The grid walks through the three levels on its own and shows, for each one, what is actually operated there and where a penetration test applies.

Three levels, three legal regimes, three sets of responsibilities
Level Citizen services online Administrative software Network & remote access Buildings & entry Staff
Portal network, federal user account Registers and departmental software Government networks, departmental remote access Premises, plant and server rooms Staff in federal authorities
State portals, state service accounts State-wide administrative software State network, links to subordinate authorities Ministries, state agencies, data centres Staff of the state administration
Citizen portals, online application workflows Registration, social services, building authority Connection to the municipal IT provider Town hall, citizen office, server room Caseworkers in direct contact with citizens

The grid moves through the levels by itself. A click or a key press stops it as soon as you pick a level yourself.

Federal Federal authorities and subordinate bodies

Who answers for it

Bodies of the federal administration are covered separately by section 29 BSIG: they count as particularly important entities, but without management liability, without a supervisory regime, and without fines. That does not lower the technical bar for the measures themselves.

Where a pentest applies

We test the externally reachable services, the separation between specialist networks and office IT, the remote access paths, and physical entry to plant rooms. The report is structured to fit an existing BSI IT-Grundschutz process.

What we tend to find

Systems built for a closed network that are now reachable through a web front end, without anyone having revisited the assumptions behind them.

NIS2 pentest in detail

State Ministries, state agencies, state data centres

Who answers for it

The federal BSI Act does not, as a rule, cover state administration; state law applies there instead. Anyone offering administrative services through the portal network still falls under the ITSiV-PV for those services.

Where a pentest applies

We test the portal connection, the interfaces to subordinate authorities, and the segmentation of the state network. Web checks and penetration test are documented separately, because the ITSiV-PV asks for both separately.

What we tend to find

A state network that treats subordinate authorities as one house: standing in a small branch office effectively means standing inside the ministry's network.

See infrastructure pentest

Municipal Cities, towns, districts and their IT provider

Who answers for it

Municipalities are governed by state law too, not directly by the federal BSIG. For services delivered through the OZG portal network, the ITSiV-PV requires web checks and penetration tests before connection and at least every three years, by the BSI, a state authority or BSI-certified providers. Sourcing IT from a shared provider means sharing its attack surface with everyone else connected to it.

Where a pentest applies

We test citizen portals and application workflows, the administrative software caseworkers use, the connection to the provider, and entry to town hall and server room. During scoping we separate what is your responsibility from what belongs to the provider.

What we tend to find

A boundary of responsibility nobody has in writing: the municipality assumes the provider owns it, the provider assumes the municipality does, and the remote access in between belongs to no one.

See web app pentest

Nobody classifies an authority on your behalf, and neither do we. We deliver the penetration test and the technical report, not the legal assessment and not the registration with the BSI.

Sheet 02 Incident noted

Real-world incident

What the Südwestfalen-IT breach teaches every municipality

On the night of October 29 to 30, 2023, a ransomware attack hit Südwestfalen-IT, the shared municipal IT provider for a large part of the Südwestfalen region. What happened next is a textbook example of what a single point of failure means for municipal IT.

Südwestfalen-IT · Night of October 29-30, 2023 · Group Akira (per media reports)

  1. Compromised VPN access

    According to media reports, the attackers got in through a compromised VPN access, the classic entry point for externally reachable remote-access systems.

    What a pentest checks at this point

    Which remote access paths are visible from outside at all, whether a second factor applies everywhere, and whether the deployed version is current. This is the cheapest part of the test and the one with the most leverage.

  2. Spread into the provider's network

    From that single access point, the attackers moved through the provider's internal network, the same network dozens of municipalities had connected their own administrative IT to.

    What a pentest checks at this point

    Whether the link to the provider is a real boundary or just a line. We deliberately start from a point an attacker would have reached after the first step.

  3. Ransomware encryption

    The group Akira then encrypted core systems at Südwestfalen-IT. Because so many municipalities were tied into the same infrastructure, the encryption didn't hit one administration, it hit an entire region at once.

    What a pentest checks at this point

    How far a single captured account actually reaches: permissions, administration paths, and whether the backups are reachable from the same network as the systems they protect.

  4. Weeks of emergency operations for more than 100 municipalities

    According to heise online, more than 100 municipalities had to run in emergency mode for weeks, with limited access to citizen portals, administrative software, and internal systems.

    What a pentest checks at this point

    Which citizen services keep running without the provider and which stop. That list comes out of the test as a by-product and is often worth more for contingency planning than the finding itself.

What this means

The lesson for your municipality

The Südwestfalen-IT case didn't hit a big city with its own IT department, it hit the exact setup most common across Germany: small and mid-sized municipalities sourcing IT from a shared provider. The target wasn't any single municipality, it was the shared infrastructure they were all plugged into.

Similar incidents also affected the town of Mössingen (November 17, 2023) and, in August 2026, two Berlin Senate administrations, attributed to the group Rhysida.

Based on public reporting (including heise online). Access Granted was not involved in this incident.

More cases in our case studies

Sheet 03 Annex A enclosed

Dependency map

One provider, many municipalities, one shared attack surface

Public administration combines publicly reachable citizen services with legacy administrative software and constant foot traffic. When many municipalities also hang off the same central infrastructure, a single compromised access is enough for an incident to travel along those connections to every administration attached to it.

01 VPN access 02 · 03 Municipal IT provider 04 Municipality Municipality Municipality Municipality Municipality Municipality Municipality
The drawing is schematic and does not depict any particular provider. What matters is the shape: one access, one shared point, many houses attached to it.
  • Entry point: one compromised remote access
  • Shared infrastructure: the joint municipal IT provider
  • Connected municipalities: all affected at the same time

Where we start

Four areas come up again and again at municipalities. The letters reappear in the report so every finding can be placed without searching.

  1. Citizen portals

    Online application workflows for ID cards, vehicle registration, or housing benefits are publicly reachable and a direct target for attackers after citizen data or a foothold into backend systems.

    Learn more

  2. Legacy administrative software

    Specialized software for registration offices, social services, or building authorities has often grown over decades, was rarely designed for today's threats, and is hard to replace quickly.

    Learn more

  3. Shared IT provider

    When many municipalities run on the same central infrastructure, one successful attack becomes an incident for dozens of administrations at once, exactly what happened at Südwestfalen-IT.

    Learn more

  4. Public foot traffic at town halls & citizen offices

    Open service counters, many separate locations, and direct contact with citizens make pretexting and unauthorized entry easier in an environment built for accessibility rather than security.

    Learn more

Sheet 04 Legal basis noted

Regulatory framework

Two obligations, one underlying question

Public administration is regulated from two directions at once: NIS2 across the board, and the OZG specifically for digital citizen services. Both come down to the same question: is your IT actually as secure as it needs to be?

NIS2 / BSIG

Public administration under NIS2

The NIS2 Directive lists public administration as a sector of its own, Annex 1 of the German BSIG does not: the German act deals with it separately. Which obligations follow for your organisation depends on the level: federal bodies are covered by Sec. 29 BSIG, while state and municipal administration follow state law. The technical yardstick the measures are held to is the same at every level.

Annex 1 BSIG · Sec. 29 BSIG · Art. 21 NIS2 / Sec. 30 BSIG

OZG / ITSiV-PV

Mandatory testing for online administrative services

For services delivered through the OZG portal network, the ITSiV-PV requires web checks and penetration tests before connection and at least every three years, by the BSI, a state authority or BSI-certified providers. BSI IT-Grundschutz remains the general reference framework, and GDPR applies on top for all citizen data.

ITSiV-PV (Federal Ministry of the Interior) · BSI IT-Grundschutz · GDPR

Registration and reporting obligations apply regardless of whether a municipality runs its own IT or sources it from a shared provider.

Sheet 05 Sign-off circulating

Who this matters to

Who decides in local government, and what usually gets in the way

A pentest for a municipality rarely has a single decision-maker. In practice you'll find the IT director or head of the IT department, the municipal IT provider itself, an information security officer or CISO, the mayor or treasurer controlling the budget, and the data protection officer at the table, each with different priorities.

In circulation

IT director, head of IT
Findings by priority, cleanly separated into your own responsibility and the provider's.
Municipal IT provider
A clear scope boundary and agreed test windows before anything is touched.
Information security officer, CISO
A report usable as a basis for ITSiV-PV and NIS2 evidence without rework.
Mayor, treasurer
A fixed price and a scope of work that survives budget and procurement review.
Data protection officer
A written arrangement on how citizen data is handled during the test, before day one.

The most common objections

We hear these four sentences in almost every first conversation with a municipality. They are fair, which is why they sit here with our answer rather than in a drawer.

  • Tight budgets

    Municipal budgets are planned tightly and security competes with many other mandatory tasks. A clearly scoped, fixed-price engagement keeps the cost predictable from the start.

  • Procurement law complicates the process

    Public buyers have to follow tender and procurement rules, security services included. We structure our offers so they work equally well for direct awards below the relevant thresholds and as the basis for a formal tender.

  • Unclear responsibility: municipality or IT provider?

    It's often unclear who owns which part of the infrastructure, the individual municipality or the shared IT provider. We clarify this during scoping so the test targets what's actually within your responsibility.

  • We're too small to be a target

    That was exactly the assumption in the Südwestfalen-IT case, and it was wrong. The target wasn't the small individual municipality, it was the shared infrastructure it was plugged into. Size doesn't protect you when the attack surface is shared.

How to compare pentest offers is covered in detail in our buyer's guide. To the buyer's guide

Sheet 06 Procurement note for signature

Procurement-ready approach

Five points that are part of every offer we make to a municipality

Administrative processes and procurement law run differently than in the private sector. So instead of a step-by-step timeline, here is what you can hold us to, from the first conversation to the final report.

No. Commitment What that means in practice
01

Fixed-price offer with a defined scope of work

 You get an offer with a clear scope of work, a fixed price, and a traceable cost breakdown. We define the scope together beforehand: which systems fall under your own responsibility and which run through the municipal IT provider.
02

Direct-award thresholds respected

 Direct awards are subject to value thresholds that vary by state and municipality. We tailor scope and offer so they can stay below those thresholds, or we prepare the documents so they hold up as the basis for a formal tender.
03

Report following BSI specifications, with management summary

 Every finding is rated by severity, exploitability, and impact on citizen services and administrative operations. The final report documents web checks and penetration test following the BSI specifications, as a basis for your ITSiV-PV and NIS2 evidence, with a management summary for IT leadership, department heads, and administrative leadership.
04

Named emergency contact

 For the duration of the test, a named contact is available on both sides. If a critical risk surfaces during testing, we tell you immediately rather than waiting for the final report.
05

No interruption of citizen services

 Citizen portals, administrative software, and network are tested manually and within the agreed scope. Test windows are agreed in advance, destructive tests are excluded, and live citizen services keep running.

These five points appear in the offer itself, not only on this page. If you need them inside a scope of work, you get them as text to copy across.

Sheet 07 List of annexes enclosed

Relevant modules

These tests bring your admin IT up to standard

Citizen portals, specialized software, and the town hall itself can't be ticked off with one test. These are the modules we typically bring together for municipalities, and each remains bookable on its own.

  • CoversSheet 03 · D

    Physical Pentest

    Simulated entry attempts at citizen offices, town halls, and server rooms. Covers the physical attack surface that matters most where public foot traffic is high.

    Learn more

  • CoversSheet 03 · D

    Social Engineering

    Phishing and pretexting simulations tailored to direct citizen contact and how caseworkers actually operate.

    Learn more

  • CoversSheet 03 · C

    Infrastructure Pentest

    Focused on network segmentation, VPN access, and the connection to the municipal IT provider, exactly where the Südwestfalen-IT breach started.

    Learn more

  • CoversSheet 03 · A

    Web App Pentest

    Citizen portals and online application workflows checked for authorization flaws, authentication weaknesses, and configuration issues, following the BSI specifications for the ITSiV-PV web check.

    Learn more

Sheet 08 Queries open

Queries on this file

Pentesting for municipalities: your questions

For online services delivered through the OZG portal network, the ITSiV-PV requires web checks and penetration tests before connection and at least every three years, by the BSI, a state authority or BSI-certified providers. NIS2 applies on top: to the federal administration via section 29 BSIG, to state administrations via the respective state law; whether municipalities are covered as well is up to each state. The ITSiV-PV explicitly requires the penetration test; under NIS2 it is a common way to demonstrate that the measures are effective.

The NIS2 Directive treats public administration as a sector of its own; the BSIG does not implement this via Annex 1. Which duties follow from that depends on the level, however: federal authorities are governed separately by section 29 BSIG, while state and municipal administration follows state law, which fills in the framework differently from one federal state to the next. Registration, reporting channels and oversight therefore do not read the same everywhere. The technical yardstick does: adequate measures, demonstrably in place. Which level is addressed by which law is laid out on sheet 01 of this page.

Not directly. Bodies of the federal administration are covered separately by Sec. 29 BSIG: they count as particularly important entities, but without management liability, supervisory regime, or fines. State and municipal administration, by contrast, are generally not covered by the federal BSIG; state law applies there. For services delivered through the OZG portal network, the ITSiV-PV applies regardless. Classifying your own organisation is your call, together with your legal team if needed; we supply the test and the report.

We structure our offers from the outset to work both for direct awards below the relevant thresholds and as the basis for a formal tender: a clear scope of work, a fixed price, and a traceable cost breakdown.

Yes. Citizen portals and online application workflows are part of a municipality's core attack surface. We test them for authorization flaws, authentication weaknesses, and configuration issues without putting live citizen services at risk.

Yes, as part of our Physical Pentest module we simulate realistic entry attempts, for example posing as a technician or visitor, and check whether reception, access controls, and server rooms hold up. Scope and approach are agreed in advance with a defined group on your side.

It depends on scope: number of locations and administrative systems, whether the municipal IT provider is included, whether physical and social engineering testing are part of it. After a free initial consultation we know your needs and you get a transparent, procurement-ready fixed-price quote.

The Südwestfalen-IT case shows the opposite. The target wasn't a single small municipality, it was the shared IT provider that more than 100 municipalities were connected to. If you run on shared infrastructure, you share its attack surface too, regardless of your own size.

We clarify that during scoping. In practice, part of the infrastructure sits with the individual municipality (administrative software, endpoints, citizen office) and part with the central provider (network, server operations, VPN). We adapt the scope to your actual area of responsibility, coordinating with your IT provider where needed.

Yes, and with a shared provider that is often the most sensible option: a test covering both sides hits exactly the handover points where each side otherwise assumes the other is responsible. Who commissions and who signs is settled before the offer, so the procurement stays clean on one side.

Sheet 09 Closing to file

Ready to test your municipality's IT security?

In 30 minutes we'll talk through your scope, clarify what matters for NIS2 and ITSiV-PV, and you'll get a no-obligation, procurement-ready fixed-price quote.

No sales follow-up, no newsletter. If the fit isn't right, we say so in the call.

Book your free consultation Send us a message
hello@access-granted.de

Contact

Address
Albert-Einstein-Straße 1, 95028 Hof
E-Mail
hello@access-granted.de
Phone
+49 9281 5918506

AccessGranted X GmbH · HRB 7266 · Hof (Saale)

Company

Services

Regulatory pentests

Industries

Networks & trust seals
Trust Seal of the IT Security Association Germany (TeleTrusT)
Participant in the Alliance for Cyber Security
© AccessGranted X GmbH Last updated: September 23, 2026