Federated Learning IoT: FedAvg, FedProx & Privacy Design

Most failed pilots of federated learning IoT FedAvg FedProx privacy architecture designs fail for a boring reason: the team picked an optimizer first and discovered the fleet second. They benchmarked FedAvg on a tidy simulation, then met real devices that sleep, drop off the network mid-round, run three firmware generations, and each see a different slice of reality. The algorithm was never the binding constraint. Participation, trust boundaries, and the privacy accounting were.

That matters in 2026 because the tooling has matured. Flower, NVIDIA FLARE and Opacus all ship production-grade releases, regulators are rewriting timelines for high-risk AI, and edge hardware can finally run a few epochs of training. What is still missing in most write-ups is an honest end-to-end design.

This post gives you one. You will learn how FedAvg and FedProx actually differ, when the other algorithm families earn their complexity, how secure aggregation and differential privacy compose (and where they fight each other), and how to size bandwidth for a real fleet.

What this covers: the fit between IoT and federated learning, the algorithm family and a selection method, the privacy stack, a worked bandwidth and privacy budget, topologies, failure modes, and a deployment checklist.

Context and Background

Federated learning (FL) trains a shared model by sending the model to the data instead of the data to the model. The founding paper, McMahan et al. (2016, published at AISTATS 2017), introduced Federated Averaging and reported that iterative model averaging reduced the number of communication rounds by 10 to 100 times compared with synchronized SGD, across five architectures and four datasets, including unbalanced and non-IID partitions (arXiv 1602.05629). Google deployed the idea on phones, most visibly in Gboard next-word prediction. The 2019 survey by Kairouz and colleagues, with 59 listed authors, remains the standard map of open problems (arXiv 1912.04977).

IoT inherits the idea but not the conditions. A phone fleet is huge, anonymous and mostly interchangeable. An industrial fleet is smaller, owned by identifiable organizations, and wildly heterogeneous. The literature separates two regimes, and you should decide which one you are in before anything else.

Cross-device FL involves thousands to millions of unreliable, low-power clients that each participate rarely. Think smartphones, wearables, or a consumer sensor line. Clients are stateless: a device may be sampled once and never again.

Cross-silo FL involves a handful to a few hundred reliable participants such as hospitals, plants, or utilities, each with substantial data and compute. Clients are stateful and addressable, which makes stronger cryptography and better scheduling practical.

Most industrial IoT lives in a hybrid: a cross-silo layer of sites or gateways sitting above a cross-device layer of sensors and controllers. That hybrid shape drives the topology we build later.

Why bother with FL at all? Three pressures recur. First, data gravity: a vibration sensor sampling at kilohertz rates produces far more raw data than a metered cellular link will carry, so shipping everything is uneconomic. Second, data sovereignty: contractual and legal limits often forbid exporting machine data, as covered in our guide to edge store-and-forward gateways, where the same connectivity constraints force local buffering. Third, competitive sensitivity: an OEM, its customers and its suppliers may all want a better failure model without handing each other their operating histories.

Regulation adds timing risk: the EU AI Act high-risk dates were being postponed under a provisional “digital omnibus” agreement reported on 6 May 2026 (stand-alone systems to 2 December 2027, products such as machinery to 2 August 2028), subject to formal adoption (Gibson Dunn summary); verify the final text. FL alone does not make a system GDPR compliant.

It is just as important to know when not to use FL. If the data is already centralized, if a few sites hold all the useful signal, or if a trained-once model with periodic offline retraining suffices, a conventional pipeline is cheaper and easier to debug. FL pays off when data cannot or should not move and the model must keep learning from a drifting fleet.

The Reference Architecture for Federated Learning IoT

A production federated learning IoT system has five layers: devices that train locally, gateways that aggregate regionally, a coordinator that selects clients and schedules rounds, a privacy layer spanning secure aggregation and differential privacy, and a model registry that gates what gets pushed back to the fleet. The optimizer (FedAvg, FedProx and relatives) is a small component inside that stack, not the stack itself.

Figure 1: Layered reference architecture for federated learning on an IoT fleet. Raw telemetry never crosses the device or gateway boundary; only masked, clipped model updates move upward.

Figure 1 shows devices at the bottom holding raw telemetry and a local training loop. Gateways in the middle perform regional aggregation and act as a trust and bandwidth boundary. The coordinator at the top owns client selection, round scheduling and the global model. A registry and canary-rollout path closes the loop back to devices. Read the diagram as a statement about trust: each layer sees less than the layer below it.

Layer 1: devices and the local training loop

A device in this architecture does four things per round. It checks eligibility (powered, idle, on an acceptable network, with enough fresh data). It downloads the current global model. It runs a bounded amount of local training, typically a small number of epochs or a fixed number of steps. And it returns a model delta, not weights and certainly not data.

Eligibility gating is not a nicety. Production cross-device systems train only when the device is charging, on unmetered connectivity and idle; this is why participation is never uniform. In an industrial context the equivalent rules are “not during a production run,” “controller CPU below a threshold,” and “maintenance window open.” These rules create systematic bias: the machines that are often idle may be the ones that fail least. A reviewer who skips this point will overestimate model quality.

Hardware sets the ceiling on what “local training” means. A Cortex-A class gateway or industrial PC can train a small convolutional or recurrent model. A Cortex-M class microcontroller usually cannot hold the activations and optimizer state needed for backpropagation, so it performs inference only, with the model distilled or quantized from the federated result. For that tier, see our walkthrough of TinyML on microcontrollers with TFLite Micro and int8 quantization. The pragmatic pattern is a three-tier fleet: microcontrollers consume the model, gateways train it, and a coordinator aggregates it.

Layer 2: gateways as the trust and bandwidth boundary

Industrial sites already have gateways for protocol translation and buffering. Reusing them as FL aggregation points is the single most useful structural decision. A gateway can collect updates from tens to hundreds of local devices over a fast, cheap LAN, aggregate them (securely, if needed), and send a single combined update over the expensive wide-area link.

This changes the economics twice. Wide-area traffic falls roughly in proportion to devices per gateway, and the privacy boundary moves up: the cloud coordinator sees an aggregate of a site, not a single machine. The cost is that intermediate aggregation discards information, and a compromised gateway can poison everything beneath it, a risk we return to under failure modes.

Layer 3: the coordinator and the round state machine

The coordinator runs the federation. In Flower the roles are named SuperLink (the coordinator-side service) and SuperNode (the client-side agent); in NVIDIA FLARE they are the server and client with a job-based workflow. Whatever the framework, a round follows the same state machine, which Figure 2 expands: select clients, broadcast the model, collect updates until a quorum or deadline, aggregate, evaluate on held-out data, and decide whether to promote the new model.

Rounds must tolerate absence, or the flakiest device sets your cadence, and evaluation must stay separate from training: keep a curated central holdout so you notice regressions on a subpopulation.

Layer 4: the privacy layer

Privacy in FL is three distinct tools solving three distinct problems. Secure aggregation hides individual updates from the server. Differential privacy bounds what the final model and the aggregate can reveal about any one participant. Authentication and attestation ensure only genuine devices contribute, which matters because anonymity helps attackers. We treat each in depth below. For hardware-rooted identity of fleet devices, see our piece on TPM 2.0, measured boot and remote attestation for IoT fleets.

Layer 5: registry and canaries

A freshly aggregated model is a candidate, not a release. Evaluate it on a fixed benchmark, shadow it against the incumbent, and canary it; sign model artifacts as you would firmware, using the manifest machinery in our SUIT, Uptane, Mender and RAUC comparison.

Deeper Analysis: Algorithms, Privacy Mechanics and the Numbers

FedAvg: what it really does

In each round the server samples a set of clients, sends them the global parameters, and each client runs several local SGD steps on its own data. The server then forms a weighted average of the returned parameters, weighting by local sample count. Two knobs matter: the fraction of clients sampled per round (often written C) and the amount of local work (epochs E and batch size B). More local work means fewer communication rounds, which is the whole point, but it also lets each client drift toward its own local optimum.

When client data is IID, drift is benign because the local optima roughly coincide. When it is not, the average of locally optimized models is not an optimum of the global objective. This is client drift, and it is the central pathology of FL on IoT. A turbine in a cold, windy site and a turbine in a calm, warm site have different feature distributions (covariate shift), different fault base rates (label shift), and sometimes different physical failure modes (concept shift). Averaging after many local steps lets the cold-site model overfit cold-site features, then the next round pulls back.

FedAvg still works surprisingly often. The McMahan results included non-IID partitions, and a decent default is to try it first with a modest E. Treat poor convergence under FedAvg as a diagnostic signal, not an automatic reason to adopt a heavier method.

FedProx: tethering the clients

FedProx, by Li, Sahu, Zaheer, Sanjabi, Talwalkar and Smith, targets two heterogeneities at once: statistical (non-IID data) and systems (devices that can do different amounts of work). The arXiv abstract describes it as a generalization and re-parameterization of FedAvg with minor changes, provides convergence guarantees under both kinds of heterogeneity, and reports an average absolute test accuracy improvement of 22% in highly heterogeneous settings (arXiv 1812.06127). That 22% is a benchmark-specific figure from the authors’ own datasets; do not expect it on your fleet.

The change is small. Each client minimizes its local loss plus a proximal term:

minimize over w:  F_k(w) + (mu / 2) * || w - w_t ||^2

Here w_t is the global model at the start of the round and mu is a scalar. The extra term penalizes how far the local solution wanders from the starting point, which limits drift without changing the communication pattern. Setting mu to zero recovers FedAvg exactly.

The second contribution is easy to miss: FedProx tolerates partial work. Instead of discarding a straggler that completed only part of its local epochs, the server accepts its inexact solution. That is directly relevant to IoT, where a device may be preempted by a production task halfway through training.

Choosing mu is the practical difficulty. It trades stability against progress: too small and drift returns, too large and clients barely move. The paper tunes it per dataset, and there is no universal value. A workable approach is to sweep mu over a log grid on a simulation that mimics your heterogeneity, then confirm on a small live cohort. Treat any single recommended mu in a blog post, including a rule of thumb, as a starting point only.

The rest of the family, and when each earns its keep

FedAvg and FedProx are the baseline pair, but four other families recur in practice. I cite these from the published literature rather than from fresh benchmark runs, so verify details against the papers before relying on them.

FedOpt (Reddi et al., ICLR 2021) treats the averaged client delta as a pseudo-gradient and applies an adaptive server optimizer such as Adam, Adagrad or Yogi. It helps when convergence is slow or noisy and costs essentially nothing on the client. It adds server-side hyperparameters, and its interaction with differential privacy noise needs care because adaptive optimizers react to noisy gradients.

SCAFFOLD (Karimireddy et al., ICML 2020) corrects client drift using control variates, effectively a running estimate of the difference between each client’s gradient direction and the global one. It can converge in far fewer rounds under heavy heterogeneity. The price is that every client must store and communicate an extra vector the size of the model, and clients must be stateful. That makes it a poor fit for cross-device fleets where a client may be sampled once, and a good fit for cross-silo sites that persist across rounds.

FedNova (Wang et al., NeurIPS 2020) addresses objective inconsistency: when clients perform different numbers of local steps, naive averaging optimizes a skewed objective. FedNova normalizes each client’s update by its number of local steps before averaging. If your fleet has a 10:1 compute spread and you let faster devices do more steps, FedNova (or FedProx’s partial-work handling) is the principled fix.

Personalization (local fine-tuning, per-client heads, clustered FL) accepts that one global model may be the wrong target for fleets with different operating regimes.

Choosing an algorithm: measure, do not guess

A common recipe says “if non-IID, use FedProx.” That is too crude. A more defensible procedure has four steps.

Quantify heterogeneity. Compute per-client label histograms and feature statistics; compare client gradients at the initial model (gradient dissimilarity). Simulate with a Dirichlet partition whose concentration parameter you tune until simulated clients resemble your real ones.
Establish two bounds. Train a centralized model on pooled data (the ceiling) and a purely local model per client (the floor). FL is only worthwhile if it beats the local floor meaningfully and approaches the ceiling.
Run FedAvg with small E first. If it matches the ceiling within your tolerance, stop. You have saved yourself a tuning burden.
Escalate by symptom. Oscillating loss and slow convergence point to FedProx or FedOpt. Wildly unequal local step counts point to FedNova. Persistent drift with stateful silos points to SCAFFOLD. A fleet that is simply different in regime points to personalization.

Symptom in simulation	Likely cause	First thing to try	Cost
Loss oscillates, slow progress	Client drift from non-IID data	FedProx, sweep mu	One extra hyperparameter
Slow but smooth convergence	Weak server step	FedOpt (server Adam or Yogi)	Server tuning
Rounds stall on slow devices	Systems heterogeneity	Deadline plus FedProx partial work or FedNova	Possible bias toward fast devices
Heavy drift, persistent clients	Strong heterogeneity	SCAFFOLD (cross-silo only)	Extra state and traffic per client
One global model underfits subgroups	Regime differences	Personalization head or clusters	More models to manage

Figure 2: Algorithm selection flow for a federated learning IoT fleet, driven by measured heterogeneity and client statefulness rather than by habit.

Figure 2 encodes the procedure as a flow. Notice that statefulness is a gate: SCAFFOLD is only on the menu when clients persist. Notice too that the first stop is always a plain FedAvg baseline with the measured ceiling and floor.

Original thesis: treat participation as a first-class variable

Here is the claim that most tutorials miss. In IoT, who participates in each round is usually a bigger source of error than which optimizer you pick. Eligibility rules, battery states, maintenance windows and connectivity create a participation process that is correlated with the data. If idle machines are healthier machines, then your aggregated model is trained disproportionately on healthy behavior, and its fault recall in production will be worse than any federated benchmark suggests.

The practical consequences are concrete. Log the participation set for every round. Compare the distribution of participating clients to the full fleet along the dimensions you care about (age, site, load, season). Reweight or stratify client selection when you can. And when you evaluate, use a holdout that is not conditioned on eligibility. Optimizer choice is a tuning problem; participation bias is a validity problem.

Secure aggregation: how the server learns only the sum

Even without raw data, a model update can leak. Gradient inversion attacks have shown that, for small batches, training examples can be partially reconstructed from a single client’s gradient. If the server sees each client’s update individually, it can attempt this. Secure aggregation removes that visibility.

The standard construction is Bonawitz et al., “Practical Secure Aggregation for Privacy-Preserving Machine Learning” (ACM CCS 2017; eprint 2017/281). The abstract states that the server computes the sum of large user-held vectors without learning any individual contribution, that security is proven in both the honest-but-curious and malicious settings, and that it holds even when an arbitrarily chosen subset of users drops out (IACR ePrint 2017/281). The reported overhead for 16-bit inputs is a communication expansion of 1.73 times at 2^10 users with 2^20-dimensional vectors, and 1.98 times at 2^14 users with 2^24-dimensional vectors, relative to sending in the clear.

The mechanism works through masking rather than homomorphic encryption. Each pair of clients agrees on a shared secret using key exchange, and each derives a pseudorandom mask from it. Client i adds the mask for each partner j when i is smaller than j and subtracts it otherwise, so all pairwise masks cancel exactly when every update is summed. Each client also adds a private self-mask, and distributes Shamir secret shares of its key material and of that self-mask to the other clients.

Dropouts are the reason for the extra machinery. If a client vanishes after others have already applied masks derived from its key, those masks no longer cancel. In the unmasking phase, surviving clients send shares that let the server reconstruct the pairwise secrets of the dropped clients (so their masks can be removed) and the self-mask seeds of the surviving clients (so theirs can be removed). The server never gets both for the same client, which is the design’s central safety property.

Three engineering consequences follow.

Cost scales with group size. Pairwise key agreement is quadratic in the number of clients in a group. Real deployments therefore run secure aggregation inside bounded groups of hundreds, not across a whole fleet. This aligns with the gateway layer in our architecture: a gateway can be the aggregation group for its devices.

Dense vectors only. Masks are pseudorandom across every coordinate, so each client must send a full-length vector. This collides with top-k sparsification, where clients send only a few coordinates with indices. Sparsification and secure aggregation do not compose directly. Quantization does compose, because the arithmetic runs in a finite ring, but you must pick the bit-width and modulus so the sum cannot overflow.

It protects the server’s view, not the model’s. Secure aggregation tells you nothing about what the aggregate reveals. A sum of many clients is safer than a single update, but with few participants or with outlier-heavy data, the aggregate can still leak. That is the job of differential privacy.

Figure 3: Secure aggregation message flow with pairwise masks and dropout recovery. The server only ever sees masked vectors and the final sum.

Figure 3 shows the order of operations: key advertisement and share distribution, masked uploads, a survivor list, and the unmasking round where shares are returned. The server is the untrusted party throughout.

Differential privacy: bounding what the model reveals

Differential privacy (DP) gives a mathematical bound on how much the output of a computation can change when one participant’s data is added or removed. Two parameters describe it: epsilon, the privacy loss, and delta, a small failure probability. Smaller epsilon means stronger privacy and, almost always, lower utility.

The unit of protection matters enormously in FL. Record-level DP protects one training example. User-level (or client-level) DP protects an entire participant’s contribution, however many examples they hold. For IoT you usually want the client or site level, because a machine’s whole history is the sensitive object. Record-level guarantees can be misleadingly strong-sounding while leaving a device’s overall behavior inferable.

There are two deployment models.

Central DP has clients send clipped updates, and the server (or a secure aggregator) adds calibrated Gaussian noise to the sum. Per round, each client’s update is clipped to an L2 norm bound C, so no single client can move the sum by more than C. Noise with standard deviation proportional to sigma times C is added to the sum, and the noise per client shrinks as more clients are summed. This requires trusting the party that adds noise, or running it inside secure aggregation so that no party sees un-noised individual updates. The Flower documentation describes this design: random client sampling, clipping to a norm bound, and Gaussian noise on the sum, with fixed or adaptive clipping that tracks a quantile of observed update norms (Flower DP explanation).

Local DP has each client add noise before sending anything. It needs no trusted aggregator, but because every client adds its own noise, total noise in the sum is far larger for the same epsilon, and utility drops accordingly. Flower documents both forms: adding noise to local model updates, and DP-SGD with per-step clipping and noise.

Most serious systems take the middle path: distributed DP, where clients add a share of the noise and secure aggregation ensures the server only sees the sum. This is why secure aggregation and DP are partners, not alternatives.

A real data point helps calibrate expectations. Google Research has published formal DP training for a Gboard next-word model for Spanish-language users: a recurrent network of roughly 1.3 million parameters trained with DP-FTRL, with 6,500 devices per round over 2,000 rounds across six days, each device participating at most once every 24 hours. They reported a user-level zCDP guarantee of rho equal to 0.81, and noted that for comparison the 2020 US Census used rho equal to 2.63 (Google Research blog). The takeaway is that a strong guarantee required thousands of participants per round. A fleet of 40 sites cannot buy the same protection with the same recipe.

For a hands-on treatment of clipping, noise multipliers and accounting, see our companion guide to DP-SGD with Opacus and privacy budgets. Opacus 1.6.0 was the latest release on PyPI at the time of writing (5 May 2026).

Privacy accounting: where budgets quietly leak

Epsilon accumulates over rounds. Basic composition adds per-round epsilons linearly, which is loose; modern accountants (Renyi DP, zCDP, privacy loss distributions) give much tighter bounds for the Gaussian mechanism. Two effects reduce the cost per round.

Subsampling amplification: if each client is included in a round with probability gamma, a mechanism that is epsilon-DP for the full population becomes roughly epsilon-prime DP, where epsilon-prime = ln(1 + gamma(e^epsilon – 1)). For epsilon = 2 and gamma = 0.1 this gives about 0.49 per round, a reduction of roughly 4x. Amplification requires genuinely random sampling that the adversary cannot observe. A fleet where eligibility rules decide participation, or where the server can see who responded, weakens this assumption, which is another reason participation matters.

Correlated noise: DP-FTRL, used in the Gboard work, avoids relying on random sampling, which suits fleets that cannot guarantee it.

Keep a privacy ledger as a first-class system component: for each model release record the mechanism, clip bound, noise multiplier, sampling rate, number of rounds, accountant used, and the resulting epsilon and delta. A model is only as private as its ledger says, and every additional training run on the same population consumes budget.

Resist quoting an “acceptable epsilon” from folklore. There is no universal threshold, and bounds in the single digits are common in published work while meaning very different things depending on delta, the unit of privacy, and the accounting method. Pick a target with your privacy officer, document it, and test it empirically with membership-inference or canary-insertion audits.

A worked example: sizing a 20,000-device fleet

The numbers below are an illustrative back-of-envelope design, not a measured deployment. Assume a vibration classifier with 2 million parameters, a fleet of 20,000 devices grouped under 200 gateways of about 100 devices each, and 10% of devices sampled per round.

Dense fp32 update: 2,000,000 x 4 bytes = 8 MB per client. With 2,000 sampled clients per round, naive direct upload to a cloud coordinator is 16 GB per round.
int8 quantized update: 2 MB per client, so 4 GB per round if all clients upload directly.
Top-1% sparsification: 20,000 values at roughly 1 byte for the value and 4 bytes for the index is about 100 KB per client, or 200 MB per round. Compression is large, but this path cannot be combined with standard secure aggregation, as discussed.
Hierarchical aggregation: 200 gateways each aggregate roughly 10 sampled devices (10% of 100). Each gateway forwards a single dense int8 vector of 2 MB, so the wide-area upload is 400 MB per round. Local LAN traffic stays at the site.
With secure aggregation overhead: applying the reported 1.73x to 1.98x expansion band to dense vectors (a rough borrowing from the paper’s 16-bit setting, not a guarantee for your parameters) puts the per-client upload near 3.5 to 4 MB for the int8 vector, which remains small on a site LAN.

The headline is that hierarchy plus quantization gets wide-area traffic down by about 40x versus dense direct upload (16 GB to 400 MB), while preserving a secure-aggregation-compatible dense format. Sparsification buys more, but only if you forgo secure aggregation or accept a design where it runs at the gateway with sparsity applied after aggregation on the wide-area leg.

For privacy, with epsilon = 2 per round and gamma = 0.1, amplification gives about 0.49 per round under idealized random sampling. Basic composition over 100 rounds would suggest about 49, which is useless as a guarantee; a Renyi or zCDP accountant will produce a far smaller figure, but the exact value depends on the noise multiplier and cannot be quoted without running the accountant on your configuration. The right conclusion is not a number but a workflow: set the target, run the accountant, and adjust the noise multiplier, sampling rate and number of rounds until the ledger meets the target.

Topologies: star, hierarchical and peer-to-peer

Figure 4: Three federated learning IoT topologies and how each moves bandwidth, trust and failure domains.

A star topology connects every client directly to one coordinator. It is the simplest to build and reason about, supports secure aggregation naturally, and works for cross-device phone-style fleets and small cross-silo federations. Its weaknesses are wide-area bandwidth that scales linearly with participants and a coordinator that is a single point of failure.

A hierarchical topology inserts regional aggregators, usually site gateways. It cuts wide-area traffic, localizes failures (a site outage removes its devices, not the round), and creates a natural place for secure aggregation groups and local DP accounting. The cost is extra latency per round, a more complex scheduler, and the poisoning-amplification risk of a compromised aggregator.

A peer-to-peer gossip topology removes the coordinator, suits intermittent meshes, but converges slowly, is hard to audit, and fits secure aggregation poorly. Figure 4 sketches all three. For most industrial fleets the answer is hierarchical, with gateways as secure aggregation groups.

Framework landscape in late 2026

You rarely need to write the plumbing yourself. As of the dates I checked:

Flower (flwr) is a framework-agnostic FL library. Version 1.33.0 was released on 5 August 2026, with breaking changes to federation ID format and removal of the experimental REST Fleet transport, per the release announcement (Flower 1.33.0). Flower includes differential privacy strategies and mods as described above.
NVIDIA FLARE (nvflare) lists version 2.9.0 as latest on PyPI, dated 4 September 2026, requiring Python 3.10 or later. The release history also showed 2.8.3 on 13 October 2026 and a 2.9.1 release candidate on 20 October, so confirm the current stable version before you pin (PyPI nvflare). FLARE emphasizes cross-silo, enterprise-style deployments with job-based workflows and federated provisioning.
Opacus 1.6.0 (5 May 2026) is the PyTorch library for DP-SGD and underlies many client-side DP implementations.
TensorFlow Federated, FedML, OpenFL and FATE are also in use. I did not verify their current versions for this update, so check each project’s release page.

Trade-offs, Gotchas, and What Goes Wrong

Non-IID data is the default, not an edge case. Simulations with randomly shuffled data flatter every algorithm. If your simulation does not reproduce your fleet’s heterogeneity, its ranking of algorithms is not evidence.

Compression, secure aggregation and DP interact. Sparsification breaks the dense-vector assumption of masking. Aggressive quantization adds noise that is correlated with the signal and can interact with clipping. DP noise is additive and large relative to small updates, so a fleet that is too small cannot afford both strong privacy and strong utility. Design the stack as a whole and test the combination, not each part alone.

Poisoning and backdoors. FL gives attackers a legitimate channel into training. Byzantine-robust aggregators such as Krum (Blanchard et al., 2017), coordinate-wise median and trimmed mean (Yin et al., 2018) tolerate a bounded fraction of arbitrary updates, but the guarantees weaken sharply under non-IID data because honest clients genuinely disagree. Backdoor attacks (Bagdasaryan et al., 2020) are subtler: a malicious client trains the model to behave normally except on a trigger. Norm clipping, which you already do for DP, is a useful first defense. Secure aggregation makes inspection harder, because the server cannot examine individual updates for outliers, so you must move robustness checks to the gateway or use techniques that verify properties of masked updates. This is a genuine tension with no free resolution.

Stragglers and survivorship. Deadline-based rounds produce predictable latency but silently bias the model toward fast, well-connected devices. Compensate with FedProx partial work or FedNova normalization, and monitor who is dropping out.

Stale models and drift. Seasonal change, sensor recalibration or a new equipment batch can outpace your round cadence. Track input distribution statistics on-device and trigger retraining or rollback when drift exceeds a threshold. A federated model that was good in January can be wrong by July.

Evaluation is harder. Without pooled data you cannot compute a clean global test set. Combine federated evaluation, a curated central benchmark, and per-subgroup reporting so that an average does not hide a failing site.

Practical Recommendations

Start with the question of regime. If you have thousands of anonymous constrained devices, you are in cross-device territory: lean on random sampling, stateless algorithms (FedAvg, FedProx, FedOpt), large cohorts for DP, and secure aggregation groups. If you have tens of identifiable sites, you are in cross-silo territory: stateful methods such as SCAFFOLD become available, personalization is attractive, and cryptographic protections are easier to enforce, but privacy amplification by sampling is weak because the cohort is small.

Build the baseline before the system. Measure the centralized ceiling (if legally possible, on a consented or synthetic subset) and the local floor, then run FedAvg. Escalate to FedProx or FedOpt only for a named symptom. Resist adding SCAFFOLD, DP and secure aggregation simultaneously; add one layer at a time and record the utility cost of each.

Treat the privacy design as a threat-model exercise. Decide who you distrust (the cloud operator, a gateway, other participants, the model consumer) and choose mechanisms accordingly. Use secure aggregation against an honest-but-curious server, DP against inference from the released model, attestation against fake clients, and robust aggregation against malicious ones. Write the ledger down.

A pre-launch checklist:

Heterogeneity measured and simulated realistically (label, feature and quantity skew).
Centralized ceiling and local floor recorded; FedAvg baseline run.
Participation logged per round and compared to the full fleet.
mu, clipping bound, noise multiplier and sampling rate chosen by sweep, not by folklore.
Secure aggregation group size and dropout threshold set; dense format confirmed.
Privacy ledger implemented, target epsilon and delta agreed, empirical audit planned.
Device identity attested; model artifacts signed and rolled out by canary.
Rollback path and drift triggers tested before the first production round.

Frequently Asked Questions

What is the difference between FedAvg and FedProx?

FedAvg has each client run several local SGD steps and the server averages the results by sample count. FedProx keeps that structure but adds a proximal term to each client’s objective, penalizing distance from the global model, and accepts partially completed local work. The result is more stable training when client data is non-IID or devices have unequal compute. With the proximal weight set to zero, FedProx reduces exactly to FedAvg.

Is federated learning private by default?

No. Keeping raw data on the device removes one exposure, but model updates can still leak information, and gradient inversion attacks have reconstructed training examples in some settings. Real privacy comes from adding secure aggregation, so the server sees only a sum, and differential privacy, which bounds what the aggregate and released model reveal. Authentication is a third requirement, so that only genuine devices contribute.

Can microcontrollers run federated learning?

Usually they cannot train, but they can still benefit. Cortex-M class devices rarely have memory for backpropagation activations and optimizer state, so they run inference on a quantized or distilled model produced by the federation. Gateways or industrial PCs do the local training. Research on tiny on-device training exists, but for production fleets the three-tier pattern of microcontroller inference, gateway training, and cloud aggregation is the safer default.

How do secure aggregation and differential privacy work together?

Secure aggregation hides each client’s individual update from the server, revealing only the sum. Differential privacy adds calibrated noise so that the sum and the resulting model reveal little about any single participant. Combined as distributed DP, clients add a share of noise and the server only sees the noised total. Neither alone is sufficient: secure aggregation does not limit what the aggregate leaks, and DP without it exposes individual updates.

How many devices do I need for meaningful differential privacy?

There is no fixed count, but noise per client shrinks as more clients are summed, so larger cohorts give better utility at the same privacy level. Google’s published Gboard training used about 6,500 devices per round to reach a user-level zCDP guarantee of 0.81. A federation of a few dozen sites will struggle to match that, and may need weaker guarantees, fewer rounds, or a different privacy approach.

Which framework should I use for an industrial fleet?

Choose by deployment model. Flower is framework-agnostic and well suited to mixed fleets of heterogeneous clients; NVIDIA FLARE targets cross-silo federations with provisioning and job workflows. Both support the algorithms discussed here. Check current versions before pinning (Flower 1.33.0 and NVFlare 2.9.0 were current in the sources I checked), prototype the privacy stack early, and verify that your framework version supports your chosen secure aggregation and DP mode.

References

McMahan, Moore, Ramage, Hampson, Aguera y Arcas. Communication-Efficient Learning of Deep Networks from Decentralized Data. AISTATS 2017. arXiv 1602.05629.
Li, Sahu, Zaheer, Sanjabi, Talwalkar, Smith. Federated Optimization in Heterogeneous Networks. arXiv 1812.06127.
Bonawitz et al. Practical Secure Aggregation for Privacy-Preserving Machine Learning. ACM CCS 2017; IACR ePrint 2017/281.
Kairouz et al. Advances and Open Problems in Federated Learning. arXiv 1912.04977.
Reddi et al. Adaptive Federated Optimization. ICLR 2021.
Karimireddy et al. SCAFFOLD: Stochastic Controlled Averaging for Federated Learning. ICML 2020.
Wang, Liu, Liang, Joshi, Poor. Tackling the Objective Inconsistency Problem in Heterogeneous Federated Optimization (FedNova). NeurIPS 2020.
Blanchard et al. Machine Learning with Adversaries: Byzantine Tolerant Gradient Descent (Krum). NeurIPS 2017.
Yin et al. Byzantine-Robust Distributed Learning: Towards Optimal Statistical Rates. ICML 2018.
Bagdasaryan et al. How To Backdoor Federated Learning. AISTATS 2020.
Google Research. Federated Learning with Formal Differential Privacy Guarantees (Gboard, DP-FTRL).
Flower 1.33.0 release announcement; PyPI pages for nvflare and opacus (accessed October 2026).
Gibson Dunn. EU AI Act Omnibus Agreement summary (provisional agreement, May 2026).

Last Updated: October 2026

By Riju — about

Federated Learning for IoT: FedAvg, FedProx, and Privacy Architecture