APP-10: Workload Identity Federation Adoption

Overview

Workload identity federation removes the need for stored credentials on an application entirely. Instead of holding a client secret or certificate, an application trusts tokens issued by an external identity provider such as GitHub Actions, Azure DevOps, Kubernetes, or another OpenID Connect provider. The provider proves the workload's identity at runtime, and Microsoft Entra ID exchanges that trusted token for an access token. There is no secret to leak, no certificate to rotate, and no credential to compromise.

This matters most for automated workflows. CI/CD pipelines are a common source of leaked secrets, because they need credentials to deploy but those credentials often end up in pipeline variables, logs, or configuration files. Federation replaces the stored pipeline secret with a short-lived, trusted token that cannot be exported and reused.

This control assesses how broadly your applications have adopted federation. The expected state is:

• Applications use federated credentials where supported.
• CI/CD pipelines use workload identity federation instead of secrets.
• Client secrets are only used where federation is not available.

Control ID: APP-10 Category: Workload Identity & Applications Baseline Level: Level 2 (Enhanced Security) Severity: Medium License Required: None. Workload identity federation is available on any Microsoft Entra ID tier.

This is an advisory, manual control. Migration requires app-specific configuration with each identity provider, so TrueConfig reports adoption but cannot auto-remediate. Where a workload runs (GitHub, Azure DevOps, Kubernetes, another Azure resource) determines exactly how federation is configured, and that setup happens both in Entra ID and in the external system.

Prerequisites

Required Roles

• Application Administrator - Can configure federated credentials on most applications
• Cloud Application Administrator - Can configure federated credentials
• Application Owner - Can configure federated credentials on owned applications
• Global Administrator - Full access, use only when a scoped role is not available

Required Licenses

• Microsoft Entra ID, any tier

Pre-Migration Requirements

1. Identify the external identity provider for each workload (GitHub, Azure DevOps, a Kubernetes cluster, another OpenID Connect issuer).
2. Confirm you can configure the workload side. You need permission to change the pipeline or workload configuration, not just the app registration.
3. Record the provider's issuer URL and the subject claim the workload will present. These bind the federated credential to a specific repository, branch, environment, or service account.

Time Estimate

Step-by-Step Instructions

Step 1: Identify Candidate Workloads

Federation fits automated, non-interactive workloads that run inside a trusted identity provider. Prioritize:

• CI/CD pipelines (GitHub Actions, Azure DevOps, GitLab)
• Kubernetes workloads using service account tokens
• Azure-hosted services that can use managed identity as the federation source

Interactive applications and workloads that cannot present a trusted external token are not candidates. Those should stay on certificate credentials (see APP-09).

Step 2: Add a Federated Credential to the App Registration

1. Navigate to the Microsoft Entra admin center (https://entra.microsoft.com).
2. Go to Identity > Applications > App registrations and select the application.
3. Open Certificates & secrets > Federated credentials.
4. Click Add credential.
5. Choose the scenario that matches the workload, for example:
   • GitHub Actions deploying Azure resources
   • Kubernetes accessing Azure resources
   • Other issuer for a generic OpenID Connect provider
6. Enter the issuer, subject identifier, and a name. The subject must exactly match the token the workload presents (for GitHub, this encodes the organization, repository, and branch or environment).
7. Click Add.

You can also add federated credentials programmatically:

Connect-MgGraph -Scopes "Application.ReadWrite.All"

$params = @{
    Name      = "github-prod-deploy"
    Issuer    = "https://token.actions.githubusercontent.com"
    Subject   = "repo:my-org/my-repo:environment:production"
    Audiences = @("api://AzureADTokenExchange")
}

New-MgApplicationFederatedIdentityCredential -ApplicationId "<app-object-id>" -BodyParameter $params

Step 3: Configure the Workload to Use Federation

On the workload side, switch authentication from a stored secret to the federated flow. For GitHub Actions this means using the OIDC login with the application's client ID and tenant ID, and granting the workflow id-token: write permission so it can request the OIDC token. No secret is stored in the pipeline.

Match the subject you configured in Step 2 exactly. A mismatch between the token subject and the federated credential subject is the most common reason federation fails.

Step 4: Test the Federated Authentication Flow

Run the pipeline or workload and confirm it authenticates without a stored secret. Verify in the Entra sign-in logs (service principal sign-ins) that the authentication succeeded using the federated credential.

Keep any existing secret in place during testing so you can roll back if needed.

Step 5: Remove Legacy Secrets

Once the federated flow is confirmed working in production:

1. Remove the client secret from the pipeline or workload configuration.
2. Delete the client secret from the app registration under Certificates & secrets > Client secrets.
3. Confirm the workload continues to run on federation alone.

Connect-MgGraph -Scopes "Application.ReadWrite.All"
Remove-MgApplicationPassword -ApplicationId "<app-object-id>" -KeyId "<secret-key-id>"

Verification Checklist

• Automated workloads that authenticate with secrets have been inventoried.
• Federation candidates have been separated from workloads that must stay on certificates.
• A federated credential is configured on the app registration for each migrated workload.
• The subject claim matches the token the workload presents.
• The workload authenticates successfully with no stored secret.
• Legacy client secrets have been removed from both the pipeline and the app registration.
• Workloads that cannot use federation are documented with their reason.
• TrueConfig reflects improved federation adoption for APP-10.

Troubleshooting

Issue: Federated authentication fails with a subject mismatch

Cause: The subject in the federated credential does not exactly match the subject in the token the workload presents.

Solution:

1. Capture the actual subject from the workload's OIDC token (for GitHub, the sub claim reflects the repo, ref, and environment).
2. Update the federated credential subject to match it character for character.
3. Remember that branch, tag, and environment produce different subjects. Add a credential for each context that needs access.

Issue: The pipeline cannot request an OIDC token

Cause: The workflow lacks permission to request the token.

Solution:

1. For GitHub Actions, grant id-token: write in the workflow permissions.
2. For Azure DevOps, use a workload identity federation service connection.
3. Confirm the provider's OIDC endpoint is reachable from the runner.

Issue: A workload has no trusted identity provider to federate with

Cause: The workload runs somewhere that cannot issue a trusted OIDC token.

Solution:

1. Fall back to certificate credentials (see APP-09) rather than staying on client secrets.
2. Document why federation is not possible for that workload.

Issue: Too many federated credentials to manage per repository

Cause: Each branch, environment, or tag can require its own subject.

Solution:

1. Standardize on environment-based subjects rather than per-branch where possible.
2. Use flexible federated identity credential matching (claims matching expressions) to reduce the number of individual credentials, where the provider supports it.

Cost Considerations

There is no additional Microsoft licensing cost. Workload identity federation is available on every Microsoft Entra ID tier and removes the operational cost of rotating secrets.

The cost is one-time configuration effort:

• Per-workload setup. Each workload needs configuration on both the Entra side and the provider side. Budget roughly one hour per workload.
• Reduced ongoing cost. Federation eliminates secret rotation, expiry tracking, and the incident risk of leaked pipeline credentials. Over time it lowers operational overhead compared to secret-based authentication.
• APP-10 is a Level 2 control. It builds on the Level 1 certificate migration (APP-09) and represents the stronger end state where credentials are removed entirely for supported workloads.

Related Controls

• APP-09: Workload Identity Federation & Certificate Credentials (Level 1 baseline for moving off secrets)
• APP-05: Service Principal Credential Hygiene (shorten and rotate remaining credentials)
• APP-07: Identify Unused Service Principals (retire dormant workload identities)

Related Resources

• Workload identity federation overview
• Configure a federated identity credential
• GitHub Actions and Azure OpenID Connect