Differential Privacy vs Federated Learning Compared

Differential privacy and federated learning are often presented as alternative ways to train models on personal data, but they protect different things: federated learning changes where raw data sits, differential privacy limits what any output reveals about one person, and a system that uses only one of them usually leaves the other door open. This guide compares the two through their threat models: the curious or malicious server, gradient inversion, membership inference and extraction from the finished model. It covers what stays on the device and what leaks through updates, the controls that close each gap (secure aggregation, DP-SGD and user-level differential privacy), the accuracy and communication costs, and how to decide on a combined architecture. It is for privacy engineers, ML platform teams and data protection officers who must sign off a training design.

Key takeaways

They protect different assets. Federated learning keeps raw records on devices or in each organisation's silo; differential privacy bounds how much the trained model or any released statistic can reveal about one contributor. NIST calls these input privacy and output privacy.
Federated learning alone leaks. NIST notes it is "often possible to extract raw training data from model updates", and the ICO says local models "can still contain personal information" and that organisations "should combine FL with other PETs".
Differential privacy alone centralises. Central DP-SGD gives a strong guarantee about the model, but the trainer still collects all the raw data, so breach, insider and purpose risks remain.
The common production pattern is both plus secure aggregation. Federated averaging with user-level differential privacy, with secure aggregation so the server sees only sums, is the design used for Gboard language models.
Costs are real but manageable at scale. Differential privacy needs many contributors to keep accuracy; secure aggregation roughly doubles upload size in the published protocol; federated learning trades data movement for many communication rounds.

The short answer

Choose federated learning when the problem is that the data cannot or should not move: it is on millions of phones, or it sits in hospitals or banks that cannot pool records. Choose differential privacy when the problem is what the output reveals: a model, dashboard or dataset will be released or queried by people who should not learn about individuals. If both are true, which is the normal case for training on personal data across many parties, use both, and add secure aggregation so the coordinator cannot inspect individual updates.

The mechanics of each are covered in the Differential Privacy Guide and the Federated Learning Privacy guide. This page is about the choice between them and the combination.

Side-by-side comparison

Dimension	Federated learning	Differential privacy
What it is	A training architecture: participants train locally and share updates that a coordinator combines	A mathematical guarantee that an output changes only slightly whether or not one person's data is included
Protects	Raw data location (data minimisation in transit and at the centre)	Outputs: model parameters, predictions, statistics
Does not protect	Information carried in updates or memorised by the final model	Raw data held by whoever adds the noise, in the central model
Trust assumption	Participants trust the coordinator with their updates unless input privacy is added	Central DP trusts the curator; local or distributed DP reduces that trust
Measurable guarantee	None by itself	Yes: epsilon and delta at a defined unit of privacy
Main cost	Communication rounds, device heterogeneity, non-IID data, orchestration	Accuracy loss, need for large populations, privacy budget management
Typical scale	Cross-device (many phones) or cross-silo (a few organisations)	Any, but utility improves with more contributors
Standards and guidance	ICO PETs guidance; NIST privacy-preserving federated learning series	NIST SP 800-226; ICO PETs guidance

Threat model: federated learning on its own

Federated learning was introduced by McMahan and colleagues in 2016 as learning "a shared model by aggregating locally-computed updates", leaving training data on devices. The architecture removes the central pool of raw records, which removes a whole class of breach. It does not remove information flow, because each update is a function of the participant's data.

Architecture in words: a coordinator sends the current model to selected participants; each trains on local data and returns an update (new weights or gradients); the coordinator averages the updates into the next global model and repeats. The adversaries to consider are the coordinator itself, other participants, an observer of the channel, and anyone who later receives the trained model.

Threat	Who mounts it	What leaks	Does FL alone stop it?
Gradient inversion	Curious coordinator seeing individual updates	Approximate training examples; Zhu et al. reported pixel-wise accurate images and token-wise matching text	No
Membership inference	Coordinator, participant or model recipient	Whether a specific person's record was used	No
Memorisation and extraction	Anyone with the final model or its API	Verbatim training content	No
Change over time	Observer of successive global models	Contributions of participants who joined or left a round	No; the ICO flags this as a factor raising risk
Malicious coordinator	Operator who manipulates the model sent out or the participants selected	Targeted reconstruction of one participant's data	No
Poisoning	Malicious participant	Integrity rather than privacy: a corrupted or backdoored model	No, and input privacy can make it harder to spot
Raw data breach at the centre	External attacker or insider	All records	Yes: there is no central pool

NIST's privacy-preserving federated learning series puts it directly: attacks on model updates can recover training data, and attacks on trained models can do so without any access to the training process. For a fuller treatment of the attack families, see Model Extraction vs Inversion vs Membership Inference and AML.T0137 Training Data Information from AI Models.

Threat model: differential privacy on its own

Differential privacy limits how much an output depends on any one contributor. NIST SP 800-226, Guidelines for Evaluating Differential Privacy Guarantees (final, March 2025), frames it as a way to measure privacy loss and lists privacy hazards that undermine real deployments. In model training the usual mechanism is differentially private stochastic gradient descent (DP-SGD): clip each example's gradient to a fixed norm, add calibrated noise, and track cumulative privacy loss. Abadi and colleagues showed in 2016 that deep networks could be trained this way with a modest privacy budget and manageable cost in quality.

Architecture in words (central DP): raw data is collected into one training environment; the trainer runs DP-SGD; the released model carries an epsilon and delta guarantee. The adversaries the guarantee addresses are those who see the output: model users, API callers and anyone the model is shared with.

What it stops: membership inference and reconstruction from the released model, to the degree set by epsilon, at the chosen unit of privacy (example-level or user-level).
What it does not stop: a breach of the central training store, insiders with access to raw data, or reuse of the collected data for another purpose. The guarantee covers the output, not the pipeline.
Weak parameters: a large epsilon, example-level protection when one user contributes many examples, or unaccounted repeated training runs can make the guarantee nominal. NIST SP 800-226 treats these as hazards to evaluate.
Utility loss: noise hurts most for small populations and rare classes, which are often the people the model must serve fairly.

Local differential privacy, where each user adds noise before sending anything, removes the trusted curator but costs far more accuracy for the same epsilon. Distributed differential privacy, described below, sits between the two.

What stays on the device and what leaks

Item	Plain FL	FL + secure aggregation	FL + secure aggregation + DP
Raw records	Stay local	Stay local	Stay local
Individual update	Visible to coordinator	Hidden; coordinator sees only the sum	Hidden, and the sum carries noise
Aggregate update per round	Visible	Visible	Visible but differentially private
Final model	May memorise individuals	May memorise individuals	Bounded leakage at the stated epsilon
Participation in training	Inferable	Inferable from the model	Bounded at user level if user-level DP is used
Ability to inspect updates for poisoning	Full	Limited	Limited

The middle column is the one teams most often stop at. Secure aggregation hides each contribution from the server, which defeats the curious-coordinator gradient inversion attack. It does nothing about what the final model memorises, which is why the ICO recommends differential privacy "to hide the participation of a user in a training task" in addition to secure aggregation.

The controls: secure aggregation, DP-SGD and user-level DP

Secure aggregation: Bonawitz and colleagues' protocol lets a server compute the sum of high-dimensional vectors from mobile devices "without learning any individual user's contribution", tolerates arbitrary dropouts, and is proven secure in honest-but-curious and malicious settings. They report communication expansion of 1.73 times for 2¹⁰ users with 2²⁰-dimensional vectors and 1.98 times for 2¹⁴ users with 2²⁴-dimensional vectors, relative to sending data in the clear.
Other input privacy options: NIST describes homomorphic encryption, where updates are encrypted and summed as ciphertexts and a separate non-colluding key holder (or a threshold scheme) decrypts only the total, and trusted execution environments, which avoid heavy cryptography but require trusting the CPU maker. See the Homomorphic Encryption Guide and the Confidential AI and GPU Enclaves Guide.
DP-SGD (example-level): per-example clipping and noise in each local or central training step. Suits cross-silo settings where each silo holds many people's records.
User-level DP with federated averaging (DP-FedAvg): McMahan, Ramage, Talwar and Zhang added user-level privacy to federated averaging by clipping each user's whole update and adding noise to the aggregate, reporting "only a negligible cost in predictive accuracy" for large language models when enough users take part, with the cost paid mainly in computation.
Distributed DP: each device adds a small amount of discrete noise before secure aggregation, so the server only ever sees a noisy sum. Kairouz, Liu and Steinke's distributed discrete Gaussian mechanism was reported as essentially matching central DP accuracy with fewer than 16 bits per value. This removes the need to trust the server to add noise honestly.
Transport security: TLS on every channel, which the ICO lists alongside the PETs; it protects against eavesdroppers, not the coordinator.

Accuracy and communication cost

Cost	Source	What drives it	Mitigation
Communication rounds	Federated learning	Model size, number of rounds, slow or offline devices	Federated averaging (McMahan et al. reported 10 to 100 times fewer rounds than synchronised SGD), compression, client sampling
Non-IID data	Federated learning	Each participant's data reflects one user or institution	Careful client selection, more rounds, personalisation layers
Upload expansion	Secure aggregation	Masking and key exchange between participants	Efficient protocol variants; NIST notes newer research has reduced overhead
Accuracy loss	Differential privacy	Noise relative to population size; small epsilon	More participants per round, public-data pretraining, adaptive clipping
Hyperparameter tuning	Differential privacy	Clip norm, noise multiplier, rounds; tuning runs also spend privacy budget	Adaptive clipping, tuning on public or proxy data
Robustness	Secure aggregation	Individual updates cannot be inspected for poisoning	Norm bounding, robust aggregation, participant vetting; see the AI Data Poisoning and Backdoors Guide

Production evidence exists. Xu and colleagues reported in 2023 that more than twenty Gboard language models were trained with federated learning and differential privacy (using DP-FTRL, with formal guarantees stated as rho-zCDP between 0.2 and 2), that two were also trained with secure aggregation, and that all next-word prediction neural language models in Gboard then carried DP guarantees. Public-data pretraining and adaptive clip estimation were part of reaching good utility.

Decision criteria for a combined architecture

Can the raw data be pooled lawfully and safely? If yes, central training with DP-SGD is simpler and usually more accurate than federated learning. If no, federated learning is the starting point.
Who might see individual updates? If the coordinator is a separate organisation or a cloud operator you do not fully trust, add secure aggregation or distributed DP. A single organisation training across its own devices still benefits, because it shrinks insider and breach exposure.
Will the model leave a trusted boundary? A model shipped to devices, shared with partners or exposed through an API needs output privacy: add differential privacy.
What is the unit of privacy? Cross-device training on personal phones needs user-level DP; cross-silo training where each record is a patient needs record-level DP within each silo, and possibly silo-level protection for commercial secrecy.
How many contributors? Thousands or more per round make DP cheap; a handful of silos make strong DP costly. Small cross-silo consortia often lean on input privacy plus contractual controls and accept weaker output guarantees, which should be stated explicitly.
Is poisoning a material risk? Open participation (consumer devices) needs robust aggregation and update bounding designed alongside secure aggregation.
Horizontal or vertical data? NIST notes vertical partitioning, where parties hold different fields about the same people, makes aggregation "much more complex" and needs different input-privacy techniques; budget for specialist design.

Worked scenarios

Mobile keyboard prediction (cross-device). Typed text is highly sensitive and spread across millions of phones. Federated learning keeps text on devices; secure aggregation hides each phone's update; user-level DP with clipping bounds what the shipped model can reveal about any one person. The model is pretrained on public text to protect accuracy. The privacy notice states the epsilon or equivalent guarantee and the unit of privacy.

Hospital imaging consortium (cross-silo). Five hospitals want a shared model and cannot pool scans. Federated learning addresses data location. With only five participants, a sum of updates hides each hospital far less than a sum of thousands, and collusion between the coordinator and a participant matters more, so the consortium adds a trusted execution environment for aggregation, record-level DP-SGD within each hospital, and memorisation testing before release. A data sharing agreement and joint DPIA cover controller roles.

Retail analytics on centrally held data. The data is already in one warehouse under a lawful basis. Federated learning adds nothing; central DP on the released model or dashboard addresses the real risk. See Differential Privacy vs Anonymisation for AI Training Data for that choice.

How to implement

Write the threat model first: list each party (coordinator, participants, channel, model recipients), what each can see, and what you must prevent each from learning.
Run the DPIA: record the lawful basis, controller roles across participants, the unit of privacy, the target epsilon and delta, and why the combination is proportionate. See the DPIA Guide.
Prototype centrally on public or synthetic data: establish baseline accuracy without privacy, then with DP at the target budget, to measure the cost before building federation.
Add federation and secure aggregation in a simulation: simulate dropouts, non-IID splits and participant counts to confirm the protocol holds and accuracy survives.
Pilot with a small participant group in shadow mode: train but do not ship; run membership inference and memorisation tests on the result.
Release in rings: ship to a small share of users first, monitor quality and complaints, and keep the previous model to roll back.
Account the budget over the model's life: every retraining spends privacy budget; set a ceiling and a review point before it is reached.

Detection and measurement

Log per round the participants selected, dropouts, clipping rates, noise parameters and cumulative privacy spend; log secure aggregation failures and any fallback to unprotected aggregation.

Cumulative epsilon and delta per model and unit of privacy, against the approved ceiling.
Membership inference advantage on held-out tests before each release.
Memorisation or canary exposure: whether planted test sequences can be extracted.
Accuracy gap between private and non-private baselines, overall and for minority groups.
Clipping fraction: share of updates clipped; very high or very low values signal mis-tuning.
Secure aggregation completion rate: rounds completed with protection, and any rounds that fell back.

Framework mapping

Framework	Reference	Federated learning	Differential privacy
GDPR	Art. 25 data protection by design; Art. 35 DPIA	Data minimisation of raw records	Limits identifiability of outputs
NIST SP 800-53 Rev 5	SA-8 Security and Privacy Engineering Principles	Architecture choice	Mechanism choice
NIST SP 800-53 Rev 5	PT-2 Authority to Process; PT-3 Processing Purposes; RA-8 Privacy Impact Assessments	Controller roles across participants	Release purpose and budget
NIST SP 800-53 Rev 5	SC-8 Transmission Confidentiality and Integrity; SC-13 Cryptographic Protection	TLS and secure aggregation	Not applicable
NIST CSF 2.0	GV.OC-03; PR.DS-02	Data in transit	Privacy obligations
NIST SP 800-226	Evaluating DP guarantees	Applies to DP added to FL	Primary guidance
MITRE ATLAS	Training data information from AI models; poison training data	Both apply	Mitigates the first

See AML.T0020 Training Data Poisoning for the integrity side.

Common failure patterns

"The data never left the device" as the privacy case: updates and models carry information; the claim is true and insufficient.
Secure aggregation without output privacy: the server cannot see updates, but the shipped model can still be probed for memorised content.
Example-level DP on user data: one heavy user contributes thousands of examples, so the per-example guarantee badly understates per-person risk.
Unaccounted retraining: each new version spends budget, and nobody tracks the total.
Small consortia with no collusion analysis: with three to five silos, a coordinator plus one participant can learn a great deal.
Forgetting integrity: hiding updates without bounding them invites poisoning that no one can attribute.

Practitioner checklist

Write a threat model naming every party and what each may learn.
Decide input privacy (secure aggregation, HE or enclave) and output privacy (DP) separately.
Set the unit of privacy to match how people contribute data.
Agree a target epsilon and delta and a lifetime budget ceiling in the DPIA.
Measure the accuracy cost centrally before building federation.
Test released models for membership inference and memorisation.
Bound and monitor updates for poisoning alongside secure aggregation.
Log privacy spend, clipping and protected-round completion per round.
Define controller roles and agreements across participants.

Differential Privacy vs Federated Learning: What Each Protects and Why You Often Need Both