Summary
- An interview published on 16 October documents an earlier 12-week municipal security programme.
- Twenty-seven participants examined settings including SMB signing, LDAP signing and Kerberos hardening.
- The reported results and implementation experience come from participants; the programme was not newly launched this weekend.
An account of a German municipal cybersecurity project has described how 27 local government IT organisations tackled longstanding Windows Server and Active Directory configuration weaknesses through a shared 12-week programme. In an interview published on 16 October, David Fuhr, chief technology officer at intcube, explained how participating teams tested potentially disruptive settings, planned reversals, and assigned responsibility for keeping changes in place.
The project was originally designed for 10 to 15 municipalities, according to Fuhr, but attracted 27. Participants attended weekly sessions, completed practical assignments, and assessed their environments at the beginning and end of the programme. The interview provides fresh detail about the operating model for a project conducted earlier; it is not evidence that a new scheme began in October.
The configuration work covered areas such as SMB signing, LDAP signing, and Kerberos hardening. These settings can reduce opportunities for certain authentication and relay attacks, yet enforcing them may affect applications or equipment that depend on older protocols and behaviour. Organisations have to understand which services will be affected before applying changes that appear straightforward in written hardening guidance.
Smaller municipal IT teams can face a particular capacity problem. An administrator may be responsible for desktop support, servers, identity, networking, and supplier relationships simultaneously. A setting that might be changed after extensive testing in a large organisation can remain untouched for years when the consequences of an outage are difficult to model and specialist staff are limited.
Testing changes before they reach production
Fuhr said the programme used laboratory testing and rollback planning to handle changes that could break systems. Such preparation allows teams to distinguish a technical recommendation from a practicable deployment. If a legacy application relies on weak authentication behaviour, a forced change may interrupt a public service. Keeping that dependency undocumented does not resolve the underlying risk; identifying it creates an opportunity to plan remediation with application owners.
The participating organisations were reportedly divided into smaller groups, giving administrators a route to compare problems and share results. This collaborative model can help teams with limited resources reproduce checks and discuss failure modes, although settings should still be validated in each local environment. One municipality’s successful change does not guarantee the same result where applications, domain trusts, or supplier-managed systems differ.
A recurring challenge is ownership after a time-limited project ends. An environment can become less secure as servers are replaced, systems are restored from old images, or new applications reintroduce weaker settings. Fuhr’s interview addresses who becomes responsible for maintaining the configuration baseline and how participants measured their position at the start and finish. It does not supply an independently audited, comparable improvement percentage for all 27 organisations.
Active Directory continues to be a critical dependency for public services because it underpins authentication and access to shared resources. Technical weaknesses can allow a compromise of one account or device to affect broader systems, depending on network segmentation and privileges. Hardening settings is therefore part of identity risk reduction, but cannot substitute for recovery preparation, privileged-account controls, and management of legacy dependencies.
Baseline and end-of-programme measurements can record individual configuration changes even where no audited aggregate security score is published. Establishing a baseline can identify which controls are absent or inconsistently applied, while an end-of-programme measurement can record what was changed. Neither measurement necessarily demonstrates resistance to a real attack; that would depend on test methods, the scope of the environment, and the durability of the settings. Participating municipalities also have to deal with supplier-managed applications and inherited infrastructure that may sit outside the administrators’ direct control.
The October interview documents a practical structure for testing security changes in small municipal IT teams, with weekly assignments, laboratories, and local rollback plans. The measurable long-term outcome would be whether improvements persist after the coordinated sessions and whether participating municipalities maintain the ability to test and reverse risky configuration changes independently.
