Federated Learning for Defense, Explained

Last updated: October 19, 2026

Why it matters to your mission. The data that would make a defense AI model strongest is spread across enclaves that cannot be pooled, because classification, compartments, releasability, and disconnected networks all forbid moving it into one place. Federated learning trains a shared model by sending the model to each data holding and bringing back only the model updates, so data that cannot move can still contribute to a model. The outcome is a model that learns from the whole of the enterprise's data without that data ever leaving the enclave that owns it, with a record of which holdings contributed.

Federated learning for defense is a way to train a shared AI model across separate, isolated data holdings by sending the model to the data and exchanging only model updates, so classified, compartmented, or disconnected data can contribute to a model without ever leaving its enclave. The U.S. National Institute of Standards and Technology describes the mechanism plainly: "the central server sends a copy of the partially trained model to each participating organization and collects model updates instead of data," where "Each organization constructs its model update by training the model locally on its own sensitive data - which never leaves the organization" (NIST, The UK-US Blog Series on Privacy-Preserving Federated Learning: Introduction, 2023).

That inversion is the whole idea. Centralized training moves the data to the model; federated learning moves the model to the data. For defense, where the barrier to pooling data is legal and physical rather than technical, that is the difference between a model that can learn from the enterprise and one that cannot.

Key takeaways

• What it is: training one shared model across isolated data holdings by exchanging model updates instead of the underlying data, so the data never has to move.
• Why defense needs it: the richest training data is split across classification levels, compartments, coalition partners, and disconnected networks that cannot be pooled into a single dataset.
• The central caveat: federated learning reduces data movement but is not automatically private, because model updates can leak information about the data that produced them.
• What to require: protection on the updates themselves, classification-aware participation, a documented record of which holdings contributed, and government ownership of the model and the training process.
• The payoff: a model that learns from data it was never allowed to centralize, with an auditable account of what trained it.

What is federated learning?

Federated learning is a method for training a single machine-learning model on data that stays where it lives. Instead of collecting every participant's data into one dataset and training on the pile, a coordinating server distributes the current model to each participant, each participant trains it locally on its own data, and the server collects and combines the resulting updates into an improved model. NIST describes the collected artifacts as "model updates" rather than data, and notes that "The resulting model updates can be aggregated and assembled to construct an improved model" (NIST, 2023).

A single round looks like this:

• Distribute. The server sends the current shared model to each participating enclave or site.
• Train locally. Each site trains the model on its own data, producing an update (a set of changes to the model's parameters) that reflects what that local data taught it.
• Return updates only. Each site returns its model update to the server. The underlying data stays put.
• Aggregate. The server combines the updates into a new shared model and sends it back out for the next round.

Over many rounds the shared model improves as if it had seen all the data, even though no site ever exposed its own. What crosses the network is the model and its updates, not the training records.

Why does defense need federated learning?

The obstacle to fielding military AI is usually the data, not the model, and in defense that data is deliberately kept apart. GAO's review of AI for weapon systems made the data problem concrete: detecting an adversary's submarines "requires gathering many images of various submarines and labeling them so the AI can learn to identify one on its own," and it named "having usable data available to train the AI" among the obstacles the Department of War faces (GAO, Artificial Intelligence: Status of Developing and Acquiring Capabilities for Weapon Systems, GAO-22-104765, 2022). The data that would answer that need is frequently scattered across holdings that cannot legally or physically be merged.

Four mission conditions make the data impossible to centralize, and each is what federated learning is built for:

• Classification and compartments. Data lives at different classification levels and inside compartments with their own need-to-know rules. Pooling it into one training set is often prohibited outright.
• Releasability and coalition boundaries. Partner-nation data may be shareable for a joint model's benefit but not transferable across a national boundary. Federated learning lets a partner contribute an update without surrendering the data.
• Disconnected and degraded networks. Data collected at the tactical edge may never have the bandwidth or the connection to ship back to a central enclave. The model can go forward to it instead.
• Sensitivity of sources and methods. Some holdings are too sensitive to copy or move even within a single organization. Training in place avoids making another copy.

The payoff is reaching training data that a centralized approach cannot touch, so the model learns from the breadth of the enterprise rather than only the fraction that happens to be poolable.

Is federated learning private?

Not by itself, and this is the point most often missed. Keeping the raw data in place removes one obvious exposure, but the model updates that cross the network are computed from that data and can leak information about it. NIST is explicit: "recent work on privacy attacks has shown that it's possible to extract a surprising amount of information about the training data, even when federated learning is used" (NIST, Privacy Attacks in Federated Learning, 2024). The updates "may appear to convey no information" about the underlying records, yet research has shown attackers can reconstruct training data from them.

So federated learning is a data-minimization architecture, not a privacy guarantee. It reduces how much data moves, but to make it protective the updates themselves have to be defended. That means pairing federated learning with privacy-enhancing techniques: adding calibrated noise to the updates (differential privacy) and combining updates under encryption so no single party sees another's contribution in the clear (secure aggregation or secure multiparty computation). For a defense deployment that distinction is load-bearing. A federated design that ships unprotected updates between enclaves has moved the exposure, not removed it.

How is federated learning different from centralized training?

They produce a model the same way in the end, but they differ in what moves, who holds the data, and what you have to defend. Conflating them hides the risks a defense evaluation needs to weigh.

Neither is simply better. Centralized training is straightforward when the data can legally and physically be pooled. Federated learning is the option when it cannot, and it trades the single concentrated data target for a subtler risk in the updates. That is why protecting the updates matters.

How Torch.AI approaches federated learning for defense

Torch.AI builds government-owned reasoning infrastructure that complements existing systems of record rather than replacing them. The same discipline of provenance that governs data inside it governs how a model learns across separate holdings. NEXUS handles semantic representation and vectorization so that data in different enclaves is described consistently, which makes a model's updates comparable across holdings that were never merged. HALO fuses the relationships among resolved entities into a graph an analyst can trace. The principle carried through a federated design is the one at the center of Torch.AI's approach: the organization keeps an auditable account of what contributed to a result, so a model trained across enclaves can still show which holdings informed it.

Because the infrastructure is government-owned, the customer controls the model, the training process, and the record of which holdings contributed, rather than renting them inside a vendor's environment where the provenance is opaque. That control makes a federated approach defensible under oversight: the organization can show how the model was trained, what protected the updates in transit, and why the result can be trusted, without having moved data that was never allowed to move. See how this is packaged as a capability on the Torch.AI software page. Federated learning also depends on getting the underlying data right first, covered in making mission data AI-ready and data labeling for defense AI, because a model is only as good as what each enclave trains it on.

What to require for federated learning in defense

1. Protected model updates. The updates exchanged between enclaves are defended with privacy-enhancing techniques such as differential privacy and secure aggregation, not shipped in the clear.
2. Classification-aware participation. Which holdings train, and at what level updates aggregate, respects classification, compartments, and releasability, rather than assuming a flat training network.
3. Contribution provenance. The training process records which holdings contributed to the model, so an evaluator can account for what trained it.
4. Robustness to bad updates. The aggregation step guards against a compromised or low-quality participant corrupting the shared model.
5. Runs where the data is. The approach works across the enterprise and forward to disconnected or degraded sites, so edge-collected data can contribute without being shipped back.
6. Validated end to end. The federated model is tested against held-out real data, because distributing the training does not remove the need to prove the result.
7. Government-owned. The customer controls the model, the training process, and the contribution record, and can inspect and evolve them independently of any single vendor.

Evaluating a capability? The seven requirements above are the backbone of a federated-learning review you can hold a program to. Bring them to a scoping call and we will walk each one against your enclaves and your accreditation path: request a technical walkthrough.

Sources

• U.S. National Institute of Standards and Technology, The UK-US Blog Series on Privacy-Preserving Federated Learning: Introduction (2023), nist.gov - defines federated learning as sending the model to each organization and collecting model updates instead of data, trained locally on data that never leaves the organization.
• U.S. National Institute of Standards and Technology, Privacy Attacks in Federated Learning (2024), nist.gov - documents that model updates can be attacked to extract information about the training data, so federated learning is not inherently privacy-preserving.
• U.S. Government Accountability Office, Artificial Intelligence: Status of Developing and Acquiring Capabilities for Weapon Systems, GAO-22-104765 (2022), gao.gov - identifies usable, labeled training data as a central obstacle to fielding AI in weapon systems.

What is federated learning?

Federated learning is a method for training one shared AI model across separate data holdings without moving the data. A coordinating server sends the current model to each participant, each participant trains it locally on its own data, and the server collects and combines only the resulting model updates. NIST describes it as a server that sends a copy of the partially trained model to each participating organization and collects model updates instead of data, trained on data that never leaves the organization.

Why does defense need federated learning?

Because the richest training data is deliberately kept apart, split across classification levels, compartments, coalition boundaries, and disconnected networks that cannot be pooled into one dataset. Federated learning lets each holding contribute to a shared model by returning an update instead of the data, so a model can learn from data a centralized approach could never touch.

Is federated learning private?

Not on its own. Keeping the raw data in place removes one exposure, but the model updates that cross the network are computed from the data and can leak information about it. NIST notes that privacy attacks can extract a surprising amount of information about the training data even when federated learning is used. To be protective, federated learning has to be paired with privacy-enhancing techniques such as differential privacy and secure aggregation.

How is federated learning different from centralized training?

In centralized training all the data moves to one place and the trainer sees everything; in federated learning only the model and its updates move, and the data stays in each enclave. Centralized training is simpler when the data can be pooled, while federated learning is the option when classification, releasability, or connectivity make pooling impossible, at the cost of having to protect the model updates.

What are the risks of federated learning?

The main risks are information leakage through model updates, which can be attacked to reconstruct training data; a compromised participant poisoning the shared model with bad updates; and the operational complexity of coordinating training across isolated sites. Each is addressable, but each has to be designed for rather than assumed away.

Can federated learning be used on classified data?

It is well suited to it, because data stays inside its enclave and only updates move, but it is not automatic. A defense deployment has to make participation and aggregation classification-aware, protect the updates in transit, and keep a record of which holdings contributed, so the approach respects the same rules that prevented pooling the data in the first place.