Privacy and Security Controls

FL reduces the need to centralise raw data, but it does not remove privacy and security risks. Model updates, intermediate metrics, logs, and trained models may still reveal information if controls are weak. This section explains the practical controls that should be considered in the reference deployment.

5.1 Threat model for the starter deployment

Risk or adversary	Practical control
External network attacker	Use TLS and mTLS; restrict network paths; do not expose client nodes broadly.
Unauthorised participant	Issue per-client certificates; revoke certificates for departed or compromised participants; bind client identity to audit logs.
Honest-but-curious coordinator	Use secure aggregation where individual participant updates should not be visible to the coordinator.
Inference from model updates or final model	Apply DP-SGD where needed; run membership-inference and leakage tests; document residual risk.
Malicious or low-quality participant update	Monitor update statistics; consider robust aggregation; define participation and contribution rules.
Supply-chain compromise	Use signed containers, dependency pinning, software bills of materials, and image scanning.
Operational misuse	Apply least privilege, just-in-time access, change control, and immutable audit logs.

The threat model should explicitly define trust boundaries between participant environments, the coordinator, shared infrastructure, repositories, logs, model artefacts, and any optional privacy-enhancing components. Each boundary should identify what crosses it, who can access it, and which control protects it.

5.2 Mutual TLS and participant authentication

Each client should authenticate to the coordinator using a client certificate or an equivalent strong identity mechanism approved by the deploying organisation. The coordinator should reject unknown or revoked clients. Client identity should appear in logs so that training participation can be audited.

• Use a server certificate for the coordinator endpoint.

• Issue one certificate per participant client node.

• Record certificate ownership, expiry, and revocation status.

• Avoid relying only on IP allow-lists. Network controls are useful, but identity should be cryptographic where possible.

Figure 3. Example mTLS guard pattern: certificate verification, proxy headers, and application-level shared-secret verification.

Certificate lifecycle management should be planned before production use. At minimum, teams should define certificate ownership, expiry, renewal, revocation, audit logging, and the process for offboarding participants. Detailed PKI procedures should be maintained in Appendix D and the repository runbooks.

5.3 Secure aggregation

Secure aggregation protects individual participant updates from being visible to the coordinator. In a typical mask-based secure aggregation protocol, clients mask their updates before sending them to the coordinator. The coordinator can recover only the aggregate once enough participating clients complete the round.

Secure aggregation helps with	Secure aggregation does not solve
Preventing the coordinator from seeing individual participant updates.	Leakage from the final trained model.
Reducing trust in the central coordinator.	Malicious clients submitting poisoned or low-quality updates.
Supporting cross-organisation collaboration where participants do not want their updates individually exposed.	The need for governance, logging, access control, and data protection review.

Figure 5. Example secure aggregation flow. Clients exchange public keys, derive masks, submit masked updates, and the server recovers only the aggregate.

Operational Guidance: Secure aggregation parameters

• Record whether secure aggregation is enabled for the run and why.

• Define the minimum quorum and dropout tolerance for each task.

• Where a mask-based protocol is used, document the key-agreement method, mask derivation approach, and dropout recovery threshold.

• Test the failure path deliberately by dropping a client below quorum during a synthetic-data run.

• Log only protocol state and aggregate outcomes needed for audit; do not log individual unmasked updates.

5.4 Differential privacy

Differential privacy (DP) can reduce the extent to which a model update or trained model reflects any particular individual record. In the reference stack, DP-SGD is applied on the client before the update leaves the participant environment. This means the coordinator receives updates that have already been clipped and noised according to the configured DP budget.

DP settings involve a privacy-utility trade-off. Stronger privacy generally means more noise, which may reduce model performance. This guide does not publish fixed regulatory epsilon thresholds. Instead, each deployment should compute and document the projected privacy budget, explain why it is appropriate for the data sensitivity and threat model, and record the residual-risk decision.

DP decision	What to document
Whether DP is used	Why DP is needed or why alternative controls are sufficient.
Noise multiplier and clipping norm	How the values were selected and tested.
Projected privacy budget	Expected budget at planned number of rounds, batch size, sampling rate, and dataset size.
Impact on model performance	Comparison against local, centralised/proxy, and federated baselines where available.
Residual risk	What inference risks remain and who has accepted them.

Operational Guidance: DP budget accounting

• Compute the privacy budget before the run and record the expected budget in the training manifest.

• Log the realised budget after each run, including round count, batch size, sampling rate, noise multiplier, clipping norm, and dataset-size assumptions.

• Stop or pause training when the privacy budget is exhausted or if the run configuration differs materially from the approved assumptions.

• Compare DP-enabled performance against non-DP baselines using synthetic or approved test data before moving to production data.

5.5 Container and supply-chain security

The FL stack should be treated as production software once it interacts with sensitive or personal data. This includes controls over the container image, dependencies, build process, and deployment approvals.

• Pin dependency versions for repeatability.

• Build images through an approved CI/CD process rather than on an operator laptop for production.

• Generate a software bill of materials where required.

• Scan container images for known vulnerabilities.

• Sign images and verify signatures before deployment.

• Record the model version, code version, configuration, and participating clients for each run.

5.6 Audit logging and monitoring

At minimum, a pilot should log who participated, when each round started and ended, which configuration was used, whether secure aggregation and DP were enabled, whether any clients dropped out, and where model checkpoints were stored. Production deployments should additionally monitor operational health, security events, model performance, and cost.