Federated learning trains a shared machine learning model across many participants — devices or organizations — without ever centralizing their raw data. Each participant computes a model update locally, using its own data, and sends only that update, not the underlying data, to a coordinating server, which aggregates updates from many participants into an improved shared model. It solves a real, common problem: you often cannot or should not move sensitive or regulated data to a central location, but you still want the benefit of training on the combined signal across all of it.
What changed in 2026
- Cross-silo federated learning grew in healthcare and finance, where a small number of institutions each hold large, sensitive datasets and want to collaborate on model quality without pooling raw patient or transaction records into one place. Specific deployments and regulatory clearances vary — verify current status for your sector and jurisdiction.
- Pairing with differential privacy became closer to standard practice, since federated learning by itself does not prevent an attacker or an honest-but-curious server from inferring information about individual participants from the shared updates. See our differential privacy guide for how the combination works.
- Poisoning-attack defenses matured. As federated learning scaled to more open participant pools, more research and tooling addressed the risk of a malicious participant submitting corrupted updates designed to degrade or backdoor the shared model.
- Communication-efficient aggregation techniques kept improving, reducing the bandwidth cost of frequent model-update exchanges, which had been one of the practical bottlenecks for large cross-device deployments.
How federated learning works, step by step
- The server distributes the current shared model to a selected subset of participants (devices or organizations).
- Each participant trains locally on its own data for a limited number of steps, producing an updated set of model weights or gradients.
- Participants send their updates back, not their raw data, typically using secure aggregation so the server cannot inspect any single participant's update in isolation.
- The server aggregates the updates — commonly by averaging, weighted by how much local data each participant used — to produce an improved global model.
- The cycle repeats across many rounds until the shared model converges.
Federated learning vs centralized training vs differential privacy
| Approach |
Where training happens |
Raw data ever centralized |
Formal privacy guarantee |
| Centralized training |
Central server or cluster |
Yes |
None by default |
| Federated learning (alone) |
Locally, on each participant |
No |
None by default — updates can still leak information |
| Federated learning + differential privacy |
Locally, with noised updates |
No |
Yes, bounded by the chosen epsilon |
The table's middle row is the most commonly misunderstood point: federated learning avoids centralizing raw data, which reduces the attack surface, but it does not by itself provide a formal privacy guarantee. Model updates can memorize and leak details about the data used to produce them.
The non-IID data problem
In textbook machine learning, training data is assumed to be independently and identically distributed. In real federated deployments, it rarely is: one hospital's patient population differs from another's, one phone's usage pattern differs from the next. This "non-IID" data means naive averaging of local updates can pull the shared model in conflicting directions, sometimes producing a worse result than simply training on any single participant's data alone. Handling this well — through techniques like weighted aggregation, personalization layers, or clustering similar participants — is one of the harder practical problems in deploying federated learning successfully.
Common pitfalls
- Assuming federated learning is inherently private. It reduces raw-data exposure but needs differential privacy or secure aggregation layered on top for a real guarantee, not just an implicit one.
- Underestimating the non-IID data problem. Pilots run on synthetic, evenly distributed data often look far more successful than real deployments with genuinely skewed participant data.
- Ignoring poisoning risk in open participant pools. Any participant who can submit updates can, in principle, try to corrupt the shared model; open or loosely vetted federated systems need defenses against this.
FAQ
Is federated learning the same as differential privacy?
No, they solve different problems and are often combined. Federated learning keeps raw data decentralized; differential privacy bounds how much any individual's data can influence a shared output, including federated model updates.
Does federated learning work well for small numbers of participants?
It can, particularly in cross-silo setups with a handful of well-resourced organizations, though the statistical and communication tradeoffs differ from large cross-device deployments with thousands of participants.
Can a federated model still memorize sensitive information?
Yes. Without additional protections, individual updates or the final aggregated model can retain patterns traceable back to specific participants' data, which is why differential privacy is frequently layered on top.
Is federated learning slower than centralized training?
Generally yes, per round, due to communication overhead and the need for many rounds of local training and aggregation. It trades some training efficiency for the ability to train on data that could not otherwise be centralized at all.
Where to go next