Most multinational security teams have the same blind spot. One subsidiary sees an attack; the others meet it weeks later, unprepared. The intelligence existed inside the organisation. It just never travelled.
The obvious fix pool all security data into one platform is also the one that keeps stalling. This article walks through an illustrative scenario showing how federated learning solves the problem from the other direction.
The organisation below is hypothetical, built to show how the approach works in practice. It does not describe a specific customer.
The scenario
Meridian Group operates energy infrastructure across six European countries. 14,000 employees. Each country runs its own subsidiary, its own SOC (Security Operations Centre) and its own security stack inherited from successive acquisitions. Roughly 40,000 security events a day across the group, four analysts per SOC.
Their German subsidiary detected a phishing campaign targeting procurement in March. The Italian subsidiary was hit by the same campaign six weeks later.
Why centralising the data failed
Meridian tried twice. Three obstacles killed both attempts.
Security logs contain employee personal data, triggering GDPR (General Data Protection Regulation) obligations that differ by country. Two subsidiaries (silo, nodes, clients)operate critical infrastructure whose national regulator explicitly prohibits certain operational data from leaving the jurisdiction. And contracts with two managed service providers forbid sharing their monitoring data with third parties.
The centralised SIEM (Security Information and Event Management) project has been stalled for two years. Meanwhile every SOC keeps training its detection on what it sees locally a fraction of what the group actually experiences.
How federated threat detection works
Federated learning inverts the usual approach. Instead of moving data to the model, it moves the model to the data.
Each subsidiary runs a node connected to what already exists locally: SIEM, EDR (Endpoint Detection and Response), network logs, identity management. Models train locally on local data. Only learned parameters are aggregated and shared, never the underlying records.
The result is a detection model that has learned from all six subsidiaries without a single log crossing a border. When the phishing campaign hits Germany, the pattern enters the global model. Italy has it before the first email lands.
This is what the centralised SIEM was supposed to deliver. Federated Learning delivers it without solving the regulatory problem, because it never creates it.
Agents in the analyst’s workflow
Detection is half the problem. The other half is that analysts spend most of their day on triage rather than investigation.
Agents operating inside each silo change the shape of the work. A correlation agent groups alerts from different sources into single incidents and filters known noise. A context agent uses federated RAG (Retrieval-Augmented Generation) to query the group’s playbooks, historical incidents and system documentation repositories scattered across subsidiaries answering “have we seen this before?” without copying a single document.
The decision point stays human. Agents observe, correlate and propose ranked options; the analyst decides and signs off. Every action is logged, including the agent’s.
Access control that survives the risk committee
Permissions are governed by attribute-based access control. Access depends not only on the user’s role but on context: who is asking, from which device, from which location, about which data.
In practice, a French analyst can query aggregated group patterns but not German raw data. Policies are explicit, auditable and consistent, with a record of why each access was granted or denied.
For the CISO this is not a technical feature. It is what makes the project survivable at the risk committee.
What Federated Learning does not solve
Leaving this section out is what turns a use case into a brochure.
- Federation does not fix bad data. If a subsidiary logs with gaps, the federated model learns the gaps. Data logs quality work remains a prerequisite.
- Heterogeneous nodes complicate training. When subsidiaries differ sharply in volume and data distribution, the global model can skew toward dominant nodes. It is a known and manageable problem, but it needs deliberate design.
- Agents do not replace analysts. They remove mechanical work. Investigation, judgement and decisions stay human, and the design says so rather than promising full autonomy.
The underlying point
The bottleneck in most multi-site SOCs is not a shortage of data. It is that the data sits where it cannot be brought together.
That is an architecture problem. Architecture problems have solutions.