What is federated learning and does it protect privacy?

Federated learning trains one shared model across many devices or organizations without collecting their raw data in a central place. Each participant trains locally and sends back model updates, which a server combines. It lowers data exposure, but updates can still leak information, so it is not a privacy guarantee.

Where did the idea come from?

The term was introduced in a 2016 paper by McMahan and colleagues at Google. They proposed leaving training data on mobile devices and learning a shared model by aggregating locally computed updates, using an approach they called federated averaging, based on iterative model averaging. The motivation was that phone data such as typing history is private and large, and moving it all to a server is both risky and costly.

How does one round work?

1. The server sends the current model to a sample of participants.
2. Each participant trains it for a few steps on its own data.
3. Each sends back only the changed weights, not the data.
4. The server averages the updates into a new global model.
5. Repeat for many rounds.

A constructed example: five hospitals want a model that flags a rare condition from scans. No hospital may export patient images. With federated learning, each trains on its own archive and the coordinator only ever sees weight updates.

What does it fix, and what does it leave open?

It fixes the obvious problem, a central pile of raw records that becomes a breach target.

It leaves several others:

• Leakage from updates. Model updates reflect the data they were trained on. Research on privacy attacks against machine learning, summarized in NIST's adversarial machine learning taxonomy, describes how training data can sometimes be inferred from model behavior.
• Poisoning. A malicious or compromised participant can send bad updates to degrade the model or plant a backdoor. NIST's taxonomy covers poisoning attacks. The server cannot see the data to check it.
• Uneven data. Participants rarely hold similar data, which can hurt accuracy and fairness.
• A trusted coordinator. The server still sees every update unless extra protection is added.

What is added on top?

Teams commonly combine federated learning with secure aggregation, so the server only sees the sum of updates, and with differential privacy, which adds calibrated noise to limit what any one record can reveal. Both cost accuracy or compute. Neither is automatic, so ask which is in use and with what parameters.

When is federated learning a good fit?

It fits when data cannot legally or practically be pooled, when many parties each hold a slice, and when the model gains from the combined view. Hospitals, banks and device makers are the usual examples. It fits poorly when one party already holds all the data, when participants are few and untrusted, or when the model is so large that sending updates each round is too costly.

Communication cost is real. Each round sends updates between every participant and the server, so bandwidth and device availability shape the design as much as the security does.

How to check or apply this

1. State the threat you are guarding against: breach of a central store, a curious coordinator, or a curious participant. Federated learning only addresses the first by itself.
2. Check whether secure aggregation or differential privacy is used, and get the settings in writing.
3. Authenticate participants and limit how much any one can influence a round.
4. Monitor global model quality on held out data to catch poisoning.
5. Treat the final model as sensitive. It can still reveal training data.
6. Record the data flows for your privacy review, since regulators ask about model outputs as well as raw data.

Quick check

Sources

• McMahan et al., Communication-Efficient Learning of Deep Networks from Decentralized Data (arXiv 1602.05629)
• NIST AI 100-2 E2025, Adversarial Machine Learning taxonomy

Last reviewed: 18 October 2026.