Federated averaging is an aggregation method used to combine model updates from multiple local training sites into one global model. The server receives updates rather than raw data, then averages them into a shared model. It is a core coordination mechanism in federated learning systems.
How Federated Averaging Works
Federated averaging combines model updates produced at multiple participating sites into a single global model, usually by weighting and averaging the local updates on a coordinating server. The key idea is coordination without collecting the raw training data centrally, which makes the aggregation step the operational heart of the system.
Because the server is merging updates from many places, the quality of the result depends on the consistency, trustworthiness, and timing of those updates. Small differences in data distribution, local training rounds, or client participation can materially affect the shared model even when the aggregation math is straightforward.
Why Federated Averaging Matters in Federated Learning
Federated averaging is important because it enables collaborative model training across organisational or device boundaries while keeping data local. That design is often used when privacy, data residency, bandwidth, or governance constraints make centralised training undesirable or impractical.
It also changes the security and trust model. The coordinating system must assume that participating clients may be heterogeneous, intermittently available, or uneven in quality, so the aggregation layer becomes a control point for both model performance and system integrity. The OpenID Foundation’s OpenID Connect Core 1.0 is not about federated learning, but it is a useful reference point for how federation relies on trusted exchange between participants rather than direct central collection.
Security and Integrity Considerations
Federated averaging inherits the core risks of any distributed update process: poisoned or low-quality updates can degrade the model, skew its behaviour, or create hidden backdoors if the aggregation stage accepts malicious contributions. Because the server sees updates rather than raw data, visibility into the underlying cause of a bad result can be limited.
It also introduces trust dependencies around participant identity, update integrity, and orchestration. If an attacker can impersonate a client, reuse credentials, or manipulate the update channel, they may influence the global model without ever touching the original training corpus. For identity-sensitive deployment patterns, NHIMG’s Workforce Identity Security Guide is a useful reminder that federation and session trust are only as strong as the controls around authentication, recovery, and session protection.
Where Federated Averaging Fits Operationally
In practice, federated averaging sits between local training and global model release. It is the coordination mechanism that turns many partial training runs into one shared artifact, so its behaviour affects convergence speed, robustness, and the degree to which a model reflects the participant population.
That makes it a governance as well as a technical choice. Teams need to decide how clients are selected, how much influence each client has, how often aggregation happens, and what acceptance criteria are used for updates. Those choices determine whether the global model is representative, stable, and defensible in production.
Practical Limits of the Approach
Federated averaging is useful, but it is not a guarantee of privacy, trust, or model quality. Local data never leaving the site reduces one exposure, yet the update stream can still leak information, carry bias, or encode unwanted behaviour if the system does not validate contributions carefully.
It is also sensitive to non-IID data, partial participation, and unequal client reliability. In other words, the method is simple to describe but harder to operate well at scale, especially when the participating sites differ materially in data quality, training cadence, or trust level.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service Organization Users) | Federated averaging depends on trustworthy client authentication and update submission. |
| AC-6 — Least Privilege | Aggregation servers and participants should have narrowly scoped access and influence. | |
| Recommendation — Apply IA-9 to authenticate participating clients before accepting model updates. Limit aggregation and client permissions to the minimum needed for training and update exchange. | ||
| MITRE ATT&CK | T1550 — Use Alternate Authentication Material | Compromised credentials or tokens can let an attacker submit fraudulent federated updates. |
| Recommendation — Hunt for stolen authentication material that could be used to impersonate training participants. | ||
Related resources from NHI Mgmt Group
- What is the difference between static secrets and federated workload credentials?
- How should IAM teams govern federated onboarding for applications and servers?
- What is the difference between static trust and federated trust for AI agents?
- What is the difference between federated trust and decentralized trust in wallet ecosystems?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org