Entra Workload Identities - Simply Explained

You already know how your own work account works. You sign in with a password or maybe Windows Hello, approve an MFA prompt and if you forget your password, you reset it. But software needs access too and nobody sits at a keyboard to approve a prompt for a running app. So a logic app might need to read a mailbox at two in the morning or an app might need to reach a database or a backup job might need to save files while everyone is asleep. So who is signing in? And that brings us to Microsoft Entra Workload Identities. By the end of this episode, you'll have a plain English map of user identities, workload identities, app registrations, service principles, and managed identities. This matters because old apps often hide passwords in code, config files, or build pipelines. Some have broad access, some have no clear owner at all. And the safer choice often means the developer never handles a password in the first place. Let's start with the identity you already use every day then compare it with the one that software uses. User identities and workload identities. People and software both need access but they prove who they are in very different ways. Your user identity is your digital badge. It connects to your name, your work account, your groups, and the job you do. When you sign into Outlook Teams, SharePoint, or another Work app, Microsoft Entra checks that badge. You might use a password, your phone, a security key, or Windows Hello. Then MFA adds another check. Entra asks, "Is this really Mirko or someone pretending to be Mirko?" That works because there is a person at the other end who can type a code, tap approve, or use a fingerprint, or face. A workload identity is different. It's a digital badge for software. That software could be an app your team built an automation that runs on a schedule, a background service, or even an AI agent that needs access to company data for a defined job. Here's the thing. Think of Microsoft Entra ID as the reception desk in a modern office building. When you enter the building, you show your personal badge so reception can see who you are, which teams you belong to, and which rooms you may enter. A workload enters with a badge assigned to its job, not to a person. The logic app badge might say, "I send an alert when a support request arrives." A virtual machine badge might say, "I can read one secret from the company vault." A backup service badge might say, "I can write backup files to this location." And a GitHub pipeline badge might say, "I can deploy this approved piece of code into this Azure resource group." Each workload needs access for a reason. Giving each one its own identity, let's enter check that reason, recorded silence, and control what it can reach. You've probably seen the older approach, someone creates a normal user account like service account at company. Come gives it a password, maybe a mailbox, maybe brought permissions, and then several apps share it. That creates a mess, which app used the account last night who owns the password, what breaks if you disable it? And if someone copies that password, can they act as every app that shares it? A workload identity fixes that model. It doesn't pretend to be a person, it gets its own permissions and its own sign-in records. That separation gives you a much clearer answer when something goes wrong. Now, there is one limit you need to keep in mind. A workload identity can't complete an MFA prompt because an app can't pull out a phone and tap approve. So you protect it in other ways, like controlling what it can access, how it proves its identity, and where its silence come from. People use personal badges because people work in many places and make choices. Software uses job badges because software should perform a narrow task repeatedly without borrowing a human account. Once you give software its own badge though, Enter starts using several names that sound almost identical. And that's where most beginners get stuck. The three names that confuse everyone. You'll see three names in Enter over and over. Application registration, service principle, and managed identity. They all connect, but they're not the same thing. Let's start with application registration. Think of an application registration as the master record for an app. It's like the design sheet created before the app ever enters a company. It describes the app's name, where it sends people after sign in, and what kind of tokens it can ask to enter to issue. A token is a short-lived digital pass that lets software ask another service for access. The application registration also lists the permissions the app might want. For example, an app can ask to read calendar data, call Microsoft Graph, or access a business API. Microsoft Graph is Microsoft's main doorway for apps that need to work with Microsoft 365 data and services. But here's the key. The registration doesn't mean the app automatically gets every permission it asks for. It only describes the app and its possible requests. Picture a software company building a meeting app. They create one application registration for that app. Then many customer organizations can choose whether they trusted and allowed into their own entry directory. One app design can travel to many companies, but each company still decides what that app can do inside its own walls. That local decision happens through the service principle. A service principle is the app's local identity inside one entry directory. It's the record that receives permissions in your company and signs in as the app when the app works on its own. The filing cabinet comparison helps here. The application registration is the blank form design. It lists the fields and tells you what the form is for. The service principle is the completed folder inside your company's filing cabinet. Your company's details sit in that folder. Whether the app is allowed, which permissions it received, and which roles it can use. So a vendor can create one application registration for its software while your company gets its own service principle for that software. Another company gets a different service principle. Your decision doesn't give the app access in every company that uses it. Each organization controls its own local copy. That's the part people often miss. Say an app needs to read a shared mailbox. In your entry directory, its service principle can receive permission for that task. Or it may need to call Microsoft Graph to read a set of data. Or perhaps it needs an Azure role that lets it read from one storage account. Those permissions attach to the service principle in your organization. The app registration describes the app. The service principle does the work locally. Now let's add the third name, Managed Identity. A Managed Identity is a special type of service principle created and looked after by Azure for an Azure resource. That resource could be a virtual machine, an app service, an Azure Function or a logic app. Instead of your team creating an app registration, creating a secret, storing that secret, rotating it later, and hoping nobody copied it into the wrong place, Azure handles the identity credentials behind the scenes. Your Azure resource still gets an identity in entry. It can still receive permissions. But your developers don't need to carry around a password for it. There are two common Managed Identity patterns. A system assigned Managed Identity belongs to one Azure resource. Turn it on for a logic app, for example. An Azure creates an identity tied to that logic app. Delete the logic app and Azure removes that identity with it. That works well when one resource needs one identity. A user assigned Managed Identity has its own life outside a single resource. You create it, then attach it to the Azure resources that need to use it. For example, several app services might need the same approved access. Rather than setting up a separate identity for each one, you can attach the same user assigned Managed Identity to those chosen services. The difference is simple. System assigned means one resource, one identity linked together. User assigned means one identity that you can attach to more than one chosen Azure resource. So when you hear these names keep this map in your head, the application registration is the app's master design. The service principle is its working identity inside your company. A Managed Identity is a service principle that Azure creates and looks after for an Azure resource. It can sound like harmless naming detail until an app needs a database password. Then these differences decide whether that password ends up in a code file, a pipeline setting, or nowhere at all. Let's follow one normal request from an Azure workload asking for access to the service it needs. What a workload identity does during a request. Imagine a logic app that runs every morning and needs a password stored in Azure Key Vault. That password might belong to a database, a partner system, or an older service that still needs a password. The logic app needs the password to do its job. The old way creates an awkward problem. You put the database password inside the logic app workflow or in a connection setting. But now the workflow needs its own secret protected. Someone has to create it, copy it, store it, rotate it, and make sure it never lands in a code repository or a screenshot. You end up protecting a password with another password. A Managed Identity changes that path. The logic app starts and asks Entra ID for a short-lived access token. It doesn't type a password. It doesn't look up a client secret. Azure recognizes the Managed Identity connected to that logic app and handles the proof behind the scenes. Entra ID then checks two things. First, it checks the identity. Is this request really coming from the Managed Identity attached to this logic app? Second, it checks what that identity may request. Has the logic app received access to Key Vault? If the request passes those checks, Entra issues an access token for Key Vault. Think of that token as a temporary access pass created for a specific destination rather than a general pass that opens everything. The logic app sends that token to Key Vault. Key Vault reads the token and checks its own access rules. It asks a narrower question. May this identity read this specific secret? If the answer is yes, Key Vault returns the secret. If the answer is no, Key Vault blocks the request. That gives us two words that sound technical, but are easy once you separate them. Authentication answers, who is this? In our example, Authentication proves that the request comes from the logic apps managed identity. Authorization answers, what may it do? Authorization decides whether that logic app may read that particular secret from Key Vault. Those are separate checks and they need to stay separate. A workload can prove its identity perfectly and still get denied access. That isn't a fault. It means the boundaries work. This is where beginners often get tripped up. They turn on a managed identity, see that Azure created it, and expect the app to reach every service immediately. But an identity alone doesn't grant access. The logic app still needs a role or permission. Someone must allow that identity to read the required secret, use the required API or reach the required resource. Azure creates the badge, but you still decide which doors that badge opens. Compare that with the older setup. You may have a connection string that contains a server name, database name, user name, and password. You may have a client secret copied into an app setting. You may have a certificate stored somewhere that a build pipeline can reach. You may have the same password copied across several config files because one app talks to another. Each copy becomes another place to lose control. Someone changes the password and an overnight job stops working. Someone leaves a secret in a test file and it reaches source control. Someone finds a credential in an old pipeline and nobody knows whether it still works. With a managed identity, the logic app asks for a token when it needs one. The token expires after a short time. The logic app doesn't need to pose as a user and the developer doesn't need to keep a long-lived password beside the workflow. That doesn't mean the token carries unlimited power. A token only helps the workload reach the service it was issued for, and the service still checks the permissions assigned to that identity. A temporary pass with a narrow purpose is very different from handing out one permanent master password. So the modern flow solves a very practical problem. Software can access the right service without borrowing a human account or keeping a password in its own files, but that same access path can become dangerous when the identity has too much permission or when someone steals the way it proves who it is. Why workload identities need their own security rules? Now, tokens are cleaner than sharing passwords, but a workload identity still needs serious protection. Think of it like a robot that works in your office. It can't tap a proof on a phone or type a code. Some workloads run all day long, calling services, moving files, reading data, and deploying code while nobody watches the screen. In some cases, one app has access to more systems than a single employee ever needs. That creates a different kind of risk. You can ask a person to approve an MFA prompt or use a security key, an app can't do either. So an attacker doesn't try to trick the app into tapping a proof. They look for what the app uses instead that might be a client secret, it might be a certificate, it could be a stolen token or permissions that were far too broad from the start. Picture a developer setting up a new app registration for a small internal tool. They create a client secret, paste it into a config file, and add the same secret to a build pipeline so the app can deploy automatically. The tool works and everyone moves on. Months later, that config file ends up in a source code repository, or someone copies the pipeline settings into another project. Anyone who gets that secret can sign in as the app, not as themselves, until the secret expires or an admin removes it. Entrassies the request as the app. That's why a client secret deserves the same care as a powerful password, and why it should be the last choice when a better sign-in method exists. For a workload that runs inside Azure, start with a managed identity when the service supports it. For code that runs outside Azure like a GitHub actions pipeline, look at workload identity federation. That phrase sounds complicated, but the idea is simple. GitHub can prove which workflow is running, which repository it came from, and under what conditions it started. Entrassed that proof for a defined setup, then issues a short-lived token to the pipeline. No long-lived entry secret needs to sit in GitHub waiting to be copied. If neither managed identity, no federation works for your app, a certificate is usually a better choice than a client secret. Certificates still need safe storage and planned renewal, but they're harder to casually copy and use than a plain-text secret. Client secrets still exist because some older apps need them. Treat them as an exception, not the default. The next control is permission. An identity should receive only what its job requires. If a reporting app needs one SharePoint folder, don't give it access to every site. If a workload needs one secret from Key Vault, don't give it permission to read every secret. If a pipeline deploys to one Azure resource group, don't hand it owner access across the whole subscription. Broad access feels easy during setup, but it also turns one stolen identity into a much larger incident. Microsoft Entra can apply conditional access to workload identities too. These are rules, Entra checks when it issues a token. For example, a policy can limit a workload to expected locations or respond to risk signals. The app won't get an MFA prompt, but Entra can still decide whether the conditions around that request look acceptable. Logs matter just as much. Review workload sign-ins, watch for repeated failures, access from an unexpected location, sudden activity at odd times, or an app calling services it normally never touches. Microsoft Entra ID protection can help surface risky workload activity, but a tool can't decide whether an old app still has a business purpose. A person needs to own that answer. Every workload identity needs a named owner. That owner should know why it exists, what it can access, how it signs in, and when somebody will review it again. When the app disappears, its identity and permissions should disappear too. Many companies treat app security as a one time setup task, create the service principle, grant access, confirm the app works, and forget about it. But old projects don't clean themselves up, an unused service principle can keep permissions for years. A forgotten certificate can remain valid. A former team may leave behind automation that nobody can explain, yet nobody wants to disable because something might break. That uncertainty is the risk, so you don't need to memorize every enter setting. You need a simple way to choose the right pattern then check access before a workload goes live. Picking the right pattern without overthinking it, you don't need to turn this into a big architecture project. Start with one question, where does the workload run? If it runs inside Azure, on a virtual machine app service, function, or logic app, start by checking for a managed identity. Turn it on, then give that identity the smallest role or permission the workload needs. A function that only reads blobs from one storage account should get access to that storage account, not every storage account in the subscription. A logic app that needs one key vault secret should receive access to that secret, not the whole vault. The location of the code tells you a lot. If the code runs outside Azure, perhaps in GitHub Actions or another Cloud Platform, look for workload identity federation. The outside platform proves what it is using its own trusted token. Entra checks that trust, then gives the workload a short-lived enter token. That lets a pipeline deploy without keeping a long-lived secret in the pipeline settings. The third question applies to custom apps. Does the app need to sign in as itself, work across more than one organization, or request app permissions for Microsoft 365, or another Entra protected service? If yes, you'll usually use an application registration and a service principal. The application registration describes the app. The service principal receives access inside each organization, where the app runs. When that app needs a credential, choose a certificate over a client secret where you can. A certificate still needs careful handling, but it gives you a stronger option than a plain text secret copied between people and systems. Think about a simple file scenario. Your personal work files usually begin in one drive. Team files usually live in SharePoint, that tells you where the files belong, but it doesn't give an app access to either place. The app still needs its own Entra identity. Then you decide whether it can read a folder, upload a file, or do nothing at all. File location and app access are separate decisions. Before any workload goes live, ask five plain questions, who owns this identity, what can it access, how does it sign in, where will someone review its logs, and when will its access be removed? Those questions work for a brand new app, but they also expose risk in apps already sitting in your directory. An old service principle with no owner, a client secret nobody remembers, and broad permissions nobody can explain should not stay invisible just because the app still exists. You don't need an admin deep dive to begin, you need an inventory, and a willingness to ask what each workload is doing. So how do you do a workload identity check? Start by listing all your applications, service principles, and managed identities, then attach a real owner to every single one. That's step one. Next, hunt for client secrets hiding in code, config files, and build pipelines. If an Azure workload can use a managed identity, move it in that direction, then review permissions, remove any identities nobody uses, and watch the sign in logs for activity that doesn't fit the job. An unattended app can still open doors across your company, treated with the same care, you'd give a highly privileged account.