MSP FAQ: a standing service-principal secret is not workload identity

Automation accounts and integrations often authenticate with a service-principal client secret: a long string, valid for months, that any script or engineer with access to it can use to act as that identity. Adding multi-factor authentication to the human side of an account does not change that; the secret itself remains a standing credential with its own blast radius.

Why client secrets are treated as legacy

Microsoft's own guidance is explicit that service principals with client secrets should be treated as a legacy approach, to be replaced with managed or federated identities wherever the hosting environment supports it. A client secret should only exist when a workload genuinely cannot use a stronger credential. The problem is not that secrets are impossible to secure — it is that they have to be stored somewhere, rotated on a schedule, and revoked manually if they leak, and every one of those steps is a place for a mistake.

What workload identity federation removes

Workload identity federation lets an external workload — a CI/CD pipeline, a Kubernetes cluster, a script running outside Azure — trust tokens from its own identity provider and exchange them for short-lived Microsoft Entra access tokens, without any secret ever being generated, stored or rotated. Microsoft's comparison of the three models is direct: federated service principals and managed identities are secret-free and work across hosted, self-hosted and on-premises environments alike, while secret-based service principals are not secret-free and still carry the operational risk that comes with any long-lived credential.

For an MSP managing many customer tenants

The tenant dimension matters as much as the credential type. A single service principal shared across several customer tenants turns one leaked secret into a cross-customer incident; identity should be bound to a single tenant's scope regardless of which credential model is in use. Where federation is not yet possible, treat the client secret as a standing risk: inventory where it is used, set it to expire within 90 days or less, and calendar its removal once federation is in place.

Sources: Microsoft Learn — Workload identity federation, Microsoft Learn — Service principals and managed identities.