Migrate existing service principals to federated credentials
Implementation Effort: High – Inventorying and converting every legacy service principal secret to workload identity federation across many pipelines and applications is a sustained migration effort. User Impact: Low – The migration is performed by administrators on pipeline identities; developers and end users are not prompted or affected. Lifecycle Stage: Build
Overview
Migrate existing CI/CD service principals from stored secrets and certificates to Workload Identity Federation. Most organizations that have been running CI/CD pipelines for any length of time have accumulated service principal credentials—client secrets and certificates—stored in pipeline service connections, GitHub Actions secrets, or Azure DevOps variable groups. These credentials were created before Workload Identity Federation was available, and they typically carry broad permissions with long or indefinite expiration periods. This task focuses on migrating existing long-lived service principal credentials to federated credentials as a follow-on to the task that establishes the workload identity federation pattern for new deployments.
Migrating these existing service principals to federated identity credentials replaces each stored secret with an OIDC-based trust relationship, so the service principal continues to function as the Azure identity but no longer requires a persistent credential to authenticate. In Azure DevOps, existing Azure Resource Manager service connections can be converted to workload identity federation directly from the service connection settings. In GitHub Actions, the migration involves adding a federated credential to the existing Microsoft Entra application registration and updating the workflow to use the OIDC login action.
The risk of leaving legacy service principal secrets in place grows over time. Secrets that were provisioned years ago may have been copied into multiple locations, shared across teams, or included in backup archives, expanding the attack surface far beyond the original pipeline. Threat actors who gain access to a single leaked service principal secret can authenticate as that identity from any location, bypass Conditional Access policies designed for interactive users, and move laterally into Azure resources. Because these credentials are static, the compromise may persist undetected for months.
This activity directly supports Use least privilege access by replacing over-provisioned, long-lived credentials with just-in-time, context-bound authentication. It also reinforces Assume breach by removing the class of static credentials that threat actors most commonly exploit to establish persistent access to cloud environments.