Google Research has announced a next-generation Federated Learning (FL) system built on Trusted Execution Environments (TEEs). The research team claims externally verifiable central differential privacy (DP) guarantees for FL for the first time.
What Problem Does TEE-Based Federated Learning Solve?
Google introduced Federated Learning FL in 2017. It powers next-word prediction and Smart Compose on Gboard, reply suggestions in Google Messages, and Smart Text Selection in Android.
Earlier systems had a trust gap. Devices uploaded data for immediate aggregation, but outsiders could not verify that data was never logged or inspected. Secure Aggregation added cryptographic protection. However, it was not compatible with state-of-the-art central DP algorithms like matrix factorization DP-FTRL. Google also had to be trusted to add DP noise correctly.
The new design moves client gradient computation to the server. It then makes that server logic attestable, so the operator no longer needs to be trusted.
How Does the System Work?
The system builds on Google’s earlier confidential federated analytics work. It coordinates 4 core components:
- Data upload: Devices encrypt training examples locally and pre-authorize an access policy. The policy lists which TEE computations may process the data. Policies must appear in a public transparency log.
- KMS and policy verification: A Key Management System, built from TEEs running the RAFT consensus protocol, releases keys only to workloads matching the policy.
- Workload execution: A root TEE runs a Python training loop and delegates subtasks to worker TEEs. Orchestration uses Federated Language, derived from TensorFlow Federated. Only DP model weights are released.
- Fault-tolerant recovery: Each round saves a KMS-encrypted recovery state for handling root or worker failures.
Why Is the Privacy Guarantee Verifiable?
Access policies are published to Rekor, Sigstore’s public transparency log. External auditors can track every server workload a device could feed. The KMS and data processing binaries are reproducibly buildable from open source code.
The policies directly describe the Python training program. To protect proprietary model architectures, TEEs support sideloading serialized logic at runtime. All privacy-relevant logic must stay hardcoded in the attested program. Workload operators see only metrics and DP model weights. Encrypted data can be decrypted only for a limited time after upload.
What Did Gboard Gain?
Gboard used the system to launch English and Japanese next-word prediction models with stronger privacy guarantees and improved accuracy. Two design choices drive this:
- First, all uploads are collected before server-side training runs. Diurnal swings in device availability no longer slow training. The program can compute an optimal participation schedule and tune DP parameters. Google’s privacy-utility curves come from training an English model for 5000 rounds with cohorts of 6500 devices on both systems.
- Second, the bottleneck moved to the server. Previous FL models took 1 to 2 months each to train. Training now parallelizes across machines, limited only by TEE resource availability. Google reports substantially faster compute times but does not publish a single speedup figure.
Interactive Explainer: Inside the TEE-Based FL Pipeline
How Google’s TEE-based Federated Learning works
Interactive explainer based on Google Research’s Oct 2, 2026 post and paper (arXiv:2609.31494).
Pick the server workload that asks the KMS for decryption keys. Only code listed in the published access policy gets them.
Approved training programhash = matches policy in Rekor log
Modified program (logs raw data)hash = not in access policy
🔒
Waiting for a request. The KMS verifies the TEE’s remote attestation against the access policy.
How Does It Compare With Other FL Frameworks?
| Feature | Google TEE-based FL | NVIDIA FLARE | Flower | Apple pfl-research |
|---|---|---|---|---|
| Primary use | Production cross-device training (live in Gboard) | Production FL SDK with Docker, Kubernetes and cloud tooling | Framework for building federated AI systems | Simulation only; not intended for third-party deployments |
| Where client updates are computed | Server-side TEEs | At each participating site | On clients | Simulated |
| Hardware TEE support | Yes, built on Project Oak | Yes: AMD SEV-SNP, Intel TDX, NVIDIA GPU confidential computing | Not part of the core framework | No |
| Differential privacy | Central DP, externally verifiable | DP filters, DP-SGD via Opacus | Central and local DP | Local and central DP mechanisms |
| Other privacy tech | KMS-gated decryption; Willow secure aggregation container | Homomorphic encryption, private set intersection | SecAgg and SecAgg+ | Not applicable (simulation) |
| Public transparency log for server code | Yes, Sigstore Rekor | Not documented | Not documented | Not applicable |
| Reproducible TEE builds | Yes (KMS and data processing binaries) | Not documented | Not applicable | Not applicable |
| License | Apache 2.0 | Apache 2.0 | Apache 2.0 | Apache 2.0 |
Sources: Google Research blog, Confidential Federated Compute repo, NVIDIA FLARE docs, FLARE attestation guide, Flower 1.8 release notes, pfl-research repo. Verified October 4, 2026.
Key Takeaways
- Google moved FL gradient computation from phones into attested server-side TEEs.
- Central DP guarantees are now externally verifiable via Rekor and reproducible builds.
- Gboard ships English and Japanese next-word models on the new system.
- Training once took 1 to 2 months per model; TEE capacity is now the limit.
- Core TEE binaries and Federated Language are open source under Apache 2.0.
Check out the Paper, Technical details and GitHub Repo. All credit goes to the researcher of this project. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well.
Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us
