Federated Learning: Securing Decentralized AI

How federated learning works

Training runs in rounds. The server sends the current global model to the parties, called clients. Each client trains the model on its own data. It sends back only the change to the model. The server merges these updates, most often by a weighted average (Federated Averaging). Then the next round starts.

There are two common setups:

• Cross-device: thousands or millions of end devices take part, such as smartphones. One use is better keyboard suggestions. The clients are not reliable, they are anonymous, and hardly anyone controls them.
• Cross-silo: a few organizations train together. Examples are hospitals, banks or the plants of one maker. The clients are known and bound by contract. For mid-sized companies, this is the setup that matters more. Think of joint quality checks or predictive maintenance across several sites.

Well-known frameworks are Flower, TensorFlow Federated, NVIDIA FLARE and PySyft.

Where federated learning can be attacked

A spread-out setup moves risk around. It does not remove it. Each client has a direct effect on the shared model. And the server cannot see which data an update came from.

Leaking training data

Gradients hold traces of the data they were built from. In gradient inversion attacks, a curious server or an eavesdropper rebuilds parts of the training data from single updates. Research has shown this for images and bits of text. Membership inference attacks test whether a given record was part of the training set. The final global model can leak data, too.

Tampering by clients

A hacked or hostile client can send updates that are poisoned on purpose. This is called model poisoning. Backdoor attacks are very hard to spot. The model works as normal in daily use. But it fails when it sees a certain trigger. For example, it might always pass a part with a certain mark as free of defects. Cross-device setups also face Sybil attacks. Here, one attacker runs many fake clients.

Infrastructure and supply chain

The central server is a prime target. Whoever controls it can swap the global model. They can also study the updates of single clients. The classic risks remain as well:

• unprotected links between clients and server
• outdated framework versions
• unsafe file formats for models

How to secure federated learning

1. Define the threat model: decide whom you trust. That can be the server, all clients, or no one. Your answer sets which of the steps below you need.
2. Use secure aggregation: with these crypto protocols, the server only sees the sum of all updates. It never sees what a single client sent.
3. Add differential privacy: you clip the updates and add noise. This makes it harder to learn about single records. The price is most often lower accuracy. So pick the privacy budget with care.
4. Limit outliers when you merge: methods such as median, trimmed mean or Krum cap the weight of outliers. They do not fully stop attacks that are planned together or very subtle.
5. Check who takes part: use mTLS with client certificates and binding contracts. Where you can, add trusted execution environments. They help keep clients intact.
6. Test every model: check each new global model against a test set you trust. Look for odd changes in behavior before release. Keep versions of your models, so you can roll back after tampering.
7. Log and monitor: record which client sent which update and when. Then you can trace odd patterns.

Data protection and law

Federated learning is often sold as the answer to the GDPR. That is too simple. Model updates can reveal facts about people. In that case, you must treat them as personal data. You still need:

• a legal basis (Art. 6 GDPR)
• clear roles between partners (joint controllership or processing on behalf)
• a data protection impact assessment under Art. 35 GDPR, where the criteria are met

The real value of federated learning lies in data minimization and data protection by design (Art. 25 GDPR).

The final system may count as high-risk under the EU AI Act (Regulation (EU) 2024/1689). Then the rules on data governance, robustness and cybersecurity apply. It does not matter if training was central or federated.

Conclusion

Federated learning is a good way to keep data where it is created. But it does not replace cryptography, access control or model testing. SecTepe helps you define the threat model for federated projects. We also help you build the safeguards into your ISMS.

Frequently asked questions

Is federated learning GDPR-compliant by default?

No. It cuts the transfer of raw data. But model updates and the final model can still reveal personal data. The usual data protection duties stay in place.

How can I spot a client that was tampered with?

You can flag odd updates in three ways. Compare their distance to the updates of other clients. Check how they perform on test data. And watch trends over time. Subtle backdoors are hard to find with certainty. That is why you need release steps and a way to roll back.