Cybersecurity Technology and Innovation
Azure Workload Identities Without Client Secrets: A Practical Migration and Audit Plan
Applications, scripts, automation, deployment pipelines, and services need identities to reach cloud resources. Many environments still provide that access through client secrets, certificates, account keys, or credentials embedded in configuration. Those credentials can be copied, exposed, forgotten, over-permissioned, or allowed to expire during production use.
Microsoft Entra managed identities and workload identity federation can remove many stored application credentials. The change is valuable, but “secretless” is not the same as “riskless.” A workload can still hold excessive permissions, trust the wrong issuer or subject, lack an owner, evade review, or access sensitive data without adequate monitoring.
This guide explains where the identity patterns fit, how to migrate without an outage, what licensing and product limitations to check, and what evidence an auditor should expect after deployment.
Executive summary
Use the simplest identity pattern that removes reusable credentials while preserving tight authorization:
- System-assigned managed identity: best when one Azure resource needs an identity whose lifecycle should end with that resource.
- User-assigned managed identity: useful when an identity needs an independent lifecycle, pre-authorization, or controlled reuse across multiple Azure resources.
- Workload identity federation: useful when a trusted external workload—such as a CI/CD workflow, Kubernetes service account, or workload on another supported platform—must exchange its own short-lived identity token for a Microsoft Entra access token.
- App registration with a certificate or secret: retain only when a supported credential-free pattern does not fit, and manage it through a documented credential lifecycle.
The migration should include inventory, dependency tracing, minimum role design, test deployment, parallel validation, credential removal, monitoring, and rollback. Do not delete a production credential before the new path has been observed and tested.
Understand the identity objects
The terms are related but not interchangeable.
Workload identity
A workload identity represents software rather than a person. Microsoft Entra workload identities include applications, service principals, and managed identities.
Application registration and service principal
An application registration defines an application identity. A service principal is the tenant-local representation through which the application receives permissions and signs in. One application can have service principals in more than one tenant, depending on its design.
Managed identity
A managed identity is a workload identity whose underlying credentials are managed by Azure. According to Microsoft’s managed-identities overview, applications can obtain Microsoft Entra tokens without developers handling a secret or certificate.
Federated identity credential
A federated identity credential defines a trust relationship between a Microsoft Entra application or user-assigned managed identity and a token issued by a trusted external identity provider. The external workload presents its short-lived token; Microsoft Entra validates the configured issuer, subject, and audience before issuing an access token.
Federation replaces stored cross-platform credentials with a controlled token exchange. It does not grant access by itself—the Microsoft Entra identity still requires authorization to the target resource.
Choose the right pattern
| Situation | Preferred starting pattern | Main design question |
|---|---|---|
| One Azure VM or App Service needs Azure resource access | System-assigned managed identity | Should the identity and permissions disappear when the resource is deleted? |
| Several Azure resources need the same pre-authorized identity | User-assigned managed identity | Is shared identity necessary, or would separate identities reduce blast radius? |
| GitHub Actions or another supported external pipeline deploys to Azure | Workload identity federation | Can issuer, repository, branch, environment, and subject claims be constrained precisely? |
| Kubernetes workload needs Microsoft Entra resource access | Workload identity federation | Is the trust bound to the intended cluster, namespace, and service account? |
| Workload runs outside Azure on a supported identity platform | Workload identity federation | Is the external issuer secure, stable, monitored, and able to mint short-lived tokens? |
| Legacy application cannot use modern token libraries | Temporary managed credential | How will storage, rotation, expiry, monitoring, exception approval, and retirement be controlled? |
The table is an architecture guide, not a substitute for testing service support.
System-assigned versus user-assigned managed identity
Microsoft documents two managed-identity types.
System-assigned
A system-assigned identity is enabled on an Azure resource and shares its lifecycle. Deleting the resource deletes the identity. Only that resource can use the identity to request tokens.
Advantages
- strong one-resource ownership;
- automatic lifecycle relationship;
- reduced identity sharing; and
- straightforward attribution.
Limitations
- replacement or recreation can produce a new identity;
- pre-authorizing before resource creation can be harder; and
- it cannot be shared across resources.
User-assigned
A user-assigned identity is a separate Azure resource and can be associated with more than one compute resource.
Advantages
- independent lifecycle;
- pre-authorization during deployment;
- stable identity across resource replacement; and
- reuse where genuinely required.
Limitations
- it must be deleted explicitly;
- shared use can widen the blast radius;
- attribution may be harder when several resources use it; and
- ownership can become unclear without governance.
Microsoft currently recommends user-assigned managed identities for Microsoft-service scenarios in its overview, but the local design still needs to consider isolation, lifecycle, and attribution.
How workload identity federation changes the risk
Traditional application credentials are bearer material: anyone who obtains the secret or usable certificate may be able to authenticate until it expires, is revoked, or is otherwise constrained.
Federation changes the model:
- the external workload authenticates to its own platform;
- that platform issues a short-lived token;
- Microsoft Entra validates the configured issuer, subject, and audience;
- Microsoft Entra issues an access token to the mapped workload identity; and
- the workload uses that token within the permissions granted to the Microsoft Entra identity.
The primary benefit is removal of a long-lived cross-platform credential. The primary new dependency is the integrity of the external issuer and the precision of the trust relationship.
Microsoft states that issuer, subject, and audience values must match case-sensitively. A trust that is too broad can authorize more workflows, repositories, branches, namespaces, or service accounts than intended.
A seven-phase migration plan
Phase 1: inventory credentials and dependencies
Build a workload identity register containing:
- application or automation name;
- business and technical owner;
- environment;
- current credential type and location;
- credential expiration;
- source workload;
- target resources and data;
- Microsoft Entra application, service principal, or managed identity object IDs;
- current role assignments and scopes;
- sign-in and audit-log locations;
- deployment and rollback owner; and
- decommission date for the old credential.
Search code repositories, pipeline variables, application settings, automation accounts, secret stores, configuration databases, deployment systems, service connections, and documentation. Do not copy secret values into the inventory.
Phase 2: confirm service support
Verify that both the source compute and target service support Microsoft Entra token authentication and the selected pattern. A managed identity can exist even when the downstream service or application library cannot use it.
Identify:
- required SDK or authentication-library updates;
- token audience and resource;
- private-network or endpoint requirements;
- tenant and cloud limitations;
- retry and token-refresh behavior; and
- observability for failed authentication.
Phase 3: redesign authorization
Do not transfer a broad legacy permission unchanged. Determine the exact data-plane and management-plane actions the workload requires.
Prefer:
- a purpose-specific role when built-in roles are too broad;
- the narrowest practical resource scope;
- separate identities for production and non-production;
- separate identities for materially different functions; and
- explicit ownership and review frequency.
Avoid assigning Owner or broad Contributor merely to simplify deployment.
Phase 4: create the identity and trust
Create the selected managed identity or application trust through infrastructure as code where practical. Record:
- tenant;
- object and application identifiers;
- issuer, subject, and audience for federation;
- resource associations;
- role assignments;
- administrators able to change the trust;
- diagnostic settings; and
- change approval.
For federation, bind the trust to the narrowest supported subject. A deployment environment with approval controls can be safer than a trust that accepts every branch or workflow.
Phase 5: test in parallel
Update the application to request tokens through an approved library or platform integration. Test:
- successful access to required operations;
- denied access to unnecessary operations;
- token renewal;
- service restart;
- scale-out;
- resource replacement;
- network failover;
- issuer or subject mismatch;
- role removal;
- logging and alerting; and
- rollback to the known-good path.
Run the new identity alongside the old credential only for the minimum controlled validation period.
Phase 6: remove the old credential
After evidence shows stable use:
- disable or remove the old secret, certificate, key, or service connection;
- delete stale copies from deployment systems and configuration;
- rotate any credential that may have been exposed during migration;
- verify that no workload still attempts to use it;
- update runbooks and recovery procedures; and
- close the change with sign-in and access evidence.
Do not leave the credential “just in case” without an exception owner and expiration date.
Phase 7: govern the identity as a production asset
Review:
- sign-in activity;
- unused or inactive identities;
- permissions and scope;
- shared user-assigned identity associations;
- federated trust changes;
- owner validity;
- access to sensitive data;
- failed-token patterns;
- risk detections; and
- decommission triggers.
A non-human identity needs lifecycle management even though it does not have a password.
Logging and detection
At minimum, retain and correlate:
- service-principal sign-ins;
- managed-identity sign-ins where available;
- Microsoft Entra audit events;
- Azure Activity Log;
- role-assignment changes;
- managed-identity creation, association, and deletion;
- federated credential changes;
- target-resource data and diagnostic logs;
- application authentication failures; and
- pipeline or external-issuer audit logs.
High-value alerts include:
- a new federated credential on a privileged application;
- a broader subject or issuer change;
- role assignment at a wider scope;
- an unused identity becoming active;
- sign-in from an unexpected external workload;
- unusual access volume;
- identity use after the owning application was retired; and
- deletion of diagnostic settings.
Conditional Access, risk, and current limitations
Microsoft documents Conditional Access for organization-owned, single-tenant service principals. It can apply location- or risk-based blocking in supported scenarios. Important limitations in Microsoft’s current documentation include:
- managed identities are not covered by workload-identity Conditional Access;
- Microsoft and third-party multitenant applications are not covered by those service-principal policies;
- service principals must be assigned directly rather than relying on a group assignment;
- only block is available as the grant action in the documented workload-identity policy flow; and
- Workload Identities Premium licensing is required to create or modify these policies.
Microsoft also documents continuous access evaluation for certain workload-identity scenarios, currently with resource, tenant, identity-type, and client-behavior constraints. Application code may need to handle claims challenges and request a new token.
Verify these limits against the current product documentation before design. Do not assume that a user-focused Conditional Access policy protects a workload identity.
Cost and operational considerations
Managed identities and federation can reduce secret-storage, rotation, and expiration work. Microsoft states that core managed-identity and federation capabilities are available without an additional Workload ID Premium charge in supported subscriptions.
Premium features—such as certain workload-identity Conditional Access, risk detection, health recommendations, and privileged service-principal access reviews—have separate licensing. Microsoft’s public FAQ listed Workload ID Premium at $3 per eligible workload identity per month when fact-checked. Pricing, packaging, eligibility, cloud availability, and license-count rules can change, so obtain a current quote and test entitlement before budgeting.
Other costs can include:
- application refactoring;
- SDK and platform updates;
- infrastructure-as-code changes;
- logging ingestion and retention;
- premium identity governance;
- engineering and test time;
- operational training; and
- parallel-run and rollback support.
The business case should compare these costs with credential rotation, expiration outages, secret exposure, audit effort, and incident scope.
Audit evidence to retain
A defensible workload-identity record should show:
- approved architecture and identity pattern;
- owner and business purpose;
- source workload and trusted issuer;
- target resource and permitted actions;
- role definition and scope;
- federation issuer, subject, and audience without sensitive token material;
- resource associations;
- test of required and denied operations;
- sign-in and audit-log evidence;
- old credential removal;
- rollback test;
- exception record;
- periodic access review; and
- retirement or ownership-transfer process.
This evidence demonstrates both design and operation.
Common migration failures
- Replacing a secret but keeping excessive privilege. Authentication improved; authorization did not.
- Sharing one user-assigned identity too broadly. One compromised workload can inherit access intended for several.
- Using a broad federated subject. Unintended workflows or environments can exchange tokens.
- Deleting the credential before testing renewal and failover. The application works once, then fails later.
- Leaving old credentials enabled indefinitely. The legacy path remains available to an attacker.
- Ignoring non-production identities. Test pipelines often hold production-capable permissions.
- Assuming user Conditional Access covers workloads. Identity types and product coverage differ.
- Missing owner and retirement events. Orphaned service principals keep access after the application changes.
Review both authentication and authorization
OC Security Audit can independently assess Microsoft Entra workload identities, Azure role assignments, managed identities, federated trusts, application credentials, logging, and lifecycle governance. Contact OC Security Audit for a focused Azure security review.
Analysis prepared and reviewed by Ali Hassani, CISO.
Review related identity paths in the Storm-2949 Azure attack-path analysis, coordinate workforce authentication with the Microsoft Entra passkey deployment plan, and apply the same least-privilege discipline to AI-agent identities, permissions, and monitoring.
Sources
- Microsoft Learn — Managed identities for Azure resources
- Microsoft Learn — Workload identity federation concepts
- Microsoft Learn — Conditional Access for workload identities
- Microsoft Learn — Continuous access evaluation for workload identities
- Microsoft Learn — Microsoft Entra Workload ID FAQ and licensing
- Microsoft Learn — Azure role-based access control
- Microsoft Learn — Azure Activity Log
For source selection, technology-version reviews, and corrections, see OC Security Audit’s editorial standards.
Last fact-checked July 2026. Product support, licensing, feature coverage, limitations, and pricing can change; verify the current Microsoft documentation and subscription before implementation.