Microsoft Entra Workload Identities: Securing Non-Human Identities for Small Businesses in Berlin

Microsoft Entra Workload Identities provides identity and access management for non-human identities: applications, services, scripts, and automation processes that need to access Azure resources, Microsoft 365 APIs, or other protected services. For small businesses in Berlin, the challenge is the same as for large enterprises but often less visible: every service principal, app registration, and managed identity that accesses your tenant represents a security boundary that must be managed with the same rigor as human identities.

The Non-Human Identity Problem

When a developer builds a script that pulls data from SharePoint, a third-party SaaS integration that reads calendar data, or an Azure Function that writes to Azure Storage, that code needs a credential to authenticate. Without proper workload identity management, organizations typically fall into one of two anti-patterns: using a shared service account (a human user account with a password used by automation) or embedding app secrets as plaintext in code or environment variables. Both patterns create serious security exposure.

Shared service accounts tie automation to a human account that must have a password that doesn’t expire, that someone must remember, and that grants a human-level set of permissions rather than the minimal permissions needed for the specific task. When that account is involved in an incident or the employee who “owns” it leaves, the entire automation chain breaks or poses a deprovisioning risk. Embedded secrets in code routinely end up in source control repositories, deployment artifacts, and log files, where they are discovered by attackers scanning public repositories for exposed credentials.

App Registrations and Service Principals

An Entra ID App Registration creates an identity for an application within your tenant. The app registration defines what the application is, what permissions it has, and how it can authenticate. The corresponding Service Principal is the instantiation of that app registration within your tenant (or another tenant’s directory when using multi-tenant apps). Service principals authenticate using either client secrets (time-limited passwords) or certificates. Certificates are significantly more secure than client secrets because they require possession of the private key, not just knowledge of a string, and because they can be stored in Azure Key Vault with controlled access.

Permission scoping for service principals follows the principle of least privilege: rather than granting a service principal Global Administrator or broad Graph API permissions, grant only the specific Microsoft Graph permission scopes required for the specific operation. A service principal that reads Teams membership should have TeamMember.Read.All, not Directory.ReadWrite.All. Entra ID Workload Identities provides tools to review and audit permission scopes assigned to service principals across your tenant, identifying over-privileged app identities that represent unnecessary attack surface.

Managed Identities: Eliminating Credential Management

Managed Identities are the most secure approach to authenticating Azure workloads to Azure resources because they eliminate credential management entirely. When you enable a Managed Identity on an Azure resource (a VM, App Service, Azure Function, Logic App, etc.), Azure automatically creates a service principal for that resource and manages the credential rotation transparently. The application code authenticates using the managed identity — it calls the Azure Instance Metadata Service (IMDS) to obtain a token, and that token is used to authenticate to the target resource.

System-Assigned Managed Identities are tied to the lifecycle of the specific Azure resource — when the resource is deleted, the identity is deleted automatically. User-Assigned Managed Identities are standalone identity resources that can be assigned to multiple Azure resources, enabling a shared identity for a group of related services. For a small Berlin business running Azure App Services or Azure Functions that need to access Key Vault, Azure Storage, or Azure SQL, enabling the Managed Identity on the compute resource and granting that identity the minimum required role on the target resource is the recommended pattern, eliminating the need to manage any application credentials at all.

Workload Identity Federation

Workload Identity Federation extends the managed identity concept to non-Azure environments: GitHub Actions pipelines, GitLab CI/CD, Kubernetes clusters (both Azure Kubernetes Service and external), and other identity providers that support OIDC tokens. Instead of creating a client secret for a service principal and storing it as a GitHub Actions secret, you configure a federated identity credential that trusts tokens issued by GitHub’s OIDC provider for your specific repository and workflow.

For a Berlin development team using GitHub Actions to deploy Azure infrastructure, workload identity federation means the CI/CD pipeline authenticates to Azure using a short-lived OIDC token rather than a long-lived client secret stored in GitHub Secrets. There is no secret to rotate, no secret to accidentally expose in logs, and no secret to discover in repository history. The federation trust is scoped to specific repositories and branches, so a token from a forked repository cannot impersonate your deployment pipeline. This pattern significantly reduces the risk of credential compromise in DevOps workflows, which have become a primary target for supply chain attacks.

Entra Workload Identities Premium

The Workload Identities Premium add-on extends Conditional Access and Identity Protection capabilities to non-human identities. Conditional Access for workload identities allows policies that restrict which networks or IP ranges a service principal can authenticate from, blocking authentication attempts from unexpected locations. Identity Protection for workload identities applies risk-based signals to service principal sign-ins — detecting leaked credentials, anomalous authentication patterns, and impossible travel for service accounts.

For small Berlin businesses handling sensitive client data, the ability to alert on a service principal authenticating from an unexpected IP or at an unusual time provides early warning of compromised application credentials. Without workload identity monitoring, a compromised service principal can silently exfiltrate data for extended periods without triggering any alert, because traditional User and Entity Behavior Analytics (UEBA) systems focus on human accounts. The Workload Identities Premium tier brings the same behavioral detection that has long protected human identities to the growing attack surface of non-human identities.

Governance: App Registration Lifecycle Management

App registrations accumulate in Entra ID tenants over time: developers create registrations for testing, integrations are set up and abandoned, and third-party apps are authorized by users through OAuth consent grants. Each abandoned registration with active credentials or permissions represents residual attack surface. Regular governance reviews — identifying app registrations with no recent sign-in activity, credentials approaching expiry, or overly broad permissions — are a maintenance requirement for workload identity security.

Microsoft Entra’s Application Management Policies allow administrators to restrict which users can create app registrations, require admin consent for application permission scopes (preventing users from granting third-party apps access to organizational data without approval), and apply credential expiration policies to ensure client secrets are rotated regularly. For Berlin businesses with Microsoft 365 E3 or E5 licensing, these governance controls are available natively in Entra ID without premium add-ons.