The privacy guarantees behind federated learning training data have long rested largely on users trusting the server operator. On October 2, 2026, Google Research announced in an official blog post a next-generation federated learning system: training now runs inside Trusted Execution Environments (TEEs), so data processing can be remotely verified and audited, and exactly which computations may touch the data must first be written into a public transparency log. The Gboard keyboard app has already adopted the new system, starting with its English and Japanese next-word prediction models.
The old system's weakness was not the algorithm — it was invisibility
Google introduced federated learning in 2017, and it powers features such as next-word prediction in Gboard and reply suggestions in Google Messages. In the early design, device data was uploaded and aggregated immediately, but outside observers had no way to verify whether data was ever logged or inspected. Secure Aggregation, added later, protected uploads cryptographically, but it was not compatible with the strongest central differential privacy guarantees. The result: the operator added the noise, and the operator also vouched that the noise had been added. Privacy stayed at the level of a promise.
How the new system replaces "trust" with "verification"
Devices encrypt training examples locally before uploading them, and pre-authorize an access policy: only the TEE computations listed in the policy may process the data, and they may release only anonymized results. Access policies must be published to Rekor, a public transparency log, so external auditors can track the full set of server-side workloads a device might take part in. The key management system is a cluster of TEEs running the RAFT consensus protocol, and it hands decryption keys only to workloads that match the access policy. Training itself runs as a Python program inside TEEs: a root TEE delegates parallelizable subtasks to a cluster of worker TEEs, and all a workload operator can see is metrics and differentially private model weights. The key management and data processing binaries can be reproducibly built from open-source code in the Confidential Federated Compute repository on GitHub.
What has already changed, and where the limits remain
Gboard's migration brought two direct changes. Training one of these models used to take one to two months, throttled by device availability, on-device compute, and multiple training jobs competing for the same devices. The new system collects uploads first and then trains in parallel on the server, moving the bottleneck to TEE resource availability; training time has dropped substantially, and Google says accuracy has improved as well. Moving gradient computation from devices to servers also raises the ceiling on model size for federated learning, and Google is experimenting with running other Python workloads, such as synthetic data generation, on the same infrastructure, alongside work on combining TEEs with accelerators.
The limits deserve equal billing: current-generation TEE hardware has known limitations, side-channel observations remain an open problem, and Google frames this as a step toward provably private learning, not the finish line. For everyday users, the significance is not a slightly faster keyboard — it is that the burden of proof for privacy is starting to flip: from "we say we never looked at your data" to "the list of code that may process your data is published first, and you can check it yourself."
