If your organization is deploying federated learning systems, you're already dealing with a core privacy challenge: training models on distributed data without centralizing that data. But protecting the training data at rest isn't enough. The model updates themselves can leak information about the underlying data.
This checklist focuses on input privacy controls for horizontally-partitioned federated learning systems, where multiple parties hold different samples of the same feature set. If you're implementing federated learning for healthcare records, financial transactions, or user behavior analytics, these controls are essential for maintaining your privacy guarantees in real-world deployment.
Prerequisites
Before you start this checklist, ensure:
- You've documented which data protection regulations apply to your federated learning deployment (GDPR, HIPAA, CCPA, etc.)
- You understand the difference between input privacy (protecting raw data and model updates) and output privacy (protecting inference results)
- Your architecture uses horizontally-partitioned data (participants hold different records, not different features)
- You have baseline performance metrics for your federated learning system without privacy controls
Checklist Items
1. Document Your Threat Model for Model Update Exposure
Define what an adversary could learn from observing model updates during aggregation.
Done when: You have a written threat model that specifies: (a) who can observe model updates at what points in the training pipeline, (b) what information could be reconstructed from individual updates (membership inference, attribute inference, or full reconstruction), and (c) which participants or infrastructure components you trust versus those you don't.
What good looks like: Your threat model explicitly states whether you trust the central aggregation server, whether you assume honest-but-curious participants, and whether you're protecting against malicious insiders.
2. Implement Secure Aggregation Using Secret Sharing
Deploy cryptographic protocols that prevent the aggregation server from seeing individual model updates.
Done when: Your federated learning implementation uses secret sharing techniques where each participant splits their model update into shares, distributes those shares to other participants, and the aggregation server only sees the reconstructed aggregate—never individual updates.
What good looks like: You can demonstrate that if fewer than a threshold number of participants collude, no individual model update can be reconstructed. Your implementation handles participant dropout during aggregation rounds without breaking the protocol.
3. Evaluate Homomorphic Encryption for Your Use Case
Determine whether homomorphic encryption's privacy guarantees justify its computational overhead for your specific deployment.
Done when: You've tested homomorphic encryption in your environment and documented: (a) the computational overhead compared to plaintext aggregation, (b) whether you can deploy an additional trusted participant for decryption without violating your threat model, and (c) the impact on training time and convergence.
What good looks like: You have benchmark data showing whether homomorphic encryption is feasible. If you proceed, you've identified which participant holds the decryption key and verified this doesn't create a single point of failure for privacy. If you don't proceed, you've documented why the overhead outweighs the privacy benefit for your use case.
4. Assess Secure Enclave Trust Requirements
If you're considering hardware-based privacy through secure enclaves, verify you can accept the trust assumptions.
Done when: You've documented: (a) which hardware manufacturer you're trusting (Intel SGX, AMD SEV, ARM TrustZone), (b) your process for monitoring security advisories and vulnerabilities affecting that hardware, (c) whether your threat model permits trusting hardware manufacturers, and (d) performance gains compared to software-only approaches.
What good looks like: You have a written policy on acceptable hardware trust boundaries. If you use secure enclaves, you monitor vulnerability databases specific to your chosen technology and have a rollback plan if critical vulnerabilities emerge.
5. Combine Input Privacy with Differential Privacy Controls
Layer input privacy techniques with differential privacy to protect against inference attacks on the final model.
Done when: You've implemented both: (a) input privacy controls from this checklist that protect individual model updates during aggregation, and (b) differential privacy mechanisms (noise injection, gradient clipping) that protect against membership inference on the trained model.
What good looks like: Your privacy documentation explains how these techniques work together—input privacy protects the training process, differential privacy protects the trained artifact. You can explain to auditors why you need both.
6. Test for Privacy Degradation Under Participant Dropout
Verify your input privacy guarantees survive when participants leave mid-training.
Done when: You've tested scenarios where participants drop out during aggregation rounds and confirmed: (a) the protocol still completes without exposing individual updates, (b) you have a minimum threshold of participants for privacy guarantees, and (c) you log dropout events for security monitoring.
What good looks like: Your system gracefully handles dropout without falling back to insecure aggregation. You alert operators when participant count drops below your documented minimum threshold.
7. Document Computational and Communication Overhead
Quantify the cost of your input privacy controls for capacity planning and vendor evaluation.
Done when: You have measurements showing: (a) additional computation time per training round with privacy controls enabled, (b) increased network bandwidth for cryptographic protocols, (c) memory overhead on participant devices, and (d) impact on model convergence speed.
What good looks like: You can present these metrics to leadership when they ask "what does privacy cost us?" You've identified the bottleneck (computation, network, or convergence) and can make informed trade-offs.
Common Mistakes
Assuming secure aggregation alone provides complete privacy. Secure aggregation protects individual updates during transmission and aggregation, but doesn't prevent the final model from leaking information about training data. You need differential privacy for that.
Treating all participants as equally trusted. Your threat model must specify which participants you trust. If you assume all participants are honest-but-curious, your privacy controls differ from scenarios where you assume some participants are malicious.
Ignoring the decryption participant in homomorphic encryption. Homomorphic encryption requires someone to decrypt the aggregated result. If that participant can collude with the aggregation server, you've gained nothing over plaintext aggregation.
Failing to test privacy controls under failure conditions. Your input privacy guarantees must survive network partitions, participant crashes, and Byzantine behavior. Test these scenarios explicitly.
Next Steps
After completing this checklist:
- Map your input privacy controls to specific compliance requirements (NIST Privacy Framework categories, ISO 27001 controls for cryptographic techniques, SOC 2 criteria for data protection)
- Create runbooks for responding to privacy control failures—what happens when secure aggregation breaks or an enclave vulnerability is disclosed
- Establish metrics for monitoring privacy control performance in production (aggregation latency, dropout rates, protocol completion rates)
Your input privacy controls are only as strong as your weakest link. If you implement secure aggregation but run it on infrastructure where the aggregation server can inspect memory, you've wasted the cryptographic overhead. Test your controls against your documented threat model, not against abstract privacy definitions.
