Workload identity: system-assigned vs user-assigned managed identity vs service principal vs federation
Verdict: Managed identity removes stored credentials entirely; use system-assigned for a single non-shared resource, user-assigned when several resources must share one identity lifecycle, and workload identity federation for external or cross-cloud workloads. Never store a client secret.
| Criterion | System-assigned managed identity | User-assigned managed identity | Service principal with client secret | Workload identity federation |
|---|---|---|---|---|
| Lifecycle | Created and deleted with its single parent resource | Independent lifecycle; attach to multiple resources | Independent of any resource; manually managed | Independent; trust relationship, not a stored identity |
| Stored secret | None | None | Client secret stored in app settings or config | None; external token exchanged for short-lived Entra token |
| Best fit | Single, non-shared workload (one App Service instance) | Fleet of resources sharing one identity, e.g. five Function apps | Avoid; replace with a managed identity | External or other-cloud workload calling an Entra-secured API |
| External or cross-cloud use | Not usable outside Azure | Not usable outside Azure | Usable but leaves a long-lived credential outside Azure | Exchanges the external platform's own token; no long-lived Azure credential stored outside Azure |
| Least privilege | Scope RBAC narrowly to the specific resources needed | Scope RBAC narrowly; grant once, applies to all attached resources | Risk of over-broad grants (e.g. Owner) for convenience | Dedicated least-privilege identity, reviewed periodically |
Rules
- Use a system-assigned managed identity for a single, non-shared workload: its lifecycle is created and deleted with that one resource.
- Use a user-assigned managed identity when multiple resources (e.g. a fleet of Function apps) must share one identity with an independent lifecycle.
- Replace a stored service principal client secret in app settings with a managed identity plus least-privilege RBAC scoped to only the resources needed.
- Use Microsoft Entra ID workload identity federation for external or other-cloud workloads: it exchanges the platform's own token for a short-lived Entra token, storing no long-lived Azure credential outside Azure.
- Grant an automation identity a dedicated, least-privilege scope for only the permission its action needs, and review that scope periodically to remove unused grants.
Traps
- Automated rotation of a service principal client secret still leaves a long-lived stored credential; it reduces exposure but does not eliminate it.
- Granting Owner or Global Administrator to an identity for convenience is a severe least-privilege violation, not a valid shortcut.
- Reusing a human admin's credentials, or sharing one service principal across automation, removes accountability and grants excess standing privilege.
- Distributing a long-lived token through configuration to an external workload is still a stored secret with the same exposure risk federation is meant to remove.