Today, we’re donning our coolest black shades, pulling on leather jackets, and proudly proclaiming, “We’ll be back!”—for when our non-human friends need access control.
As we’ve talked about previously, Identity and Access Management (IAM) is important—especially for the identities we don’t interact with directly or even think about much. These accounts fall under the category of non-human identities, like Azure Managed Identities, Service Principals, or Service Accounts. Service Accounts have been in use for years, but as companies leave traditional AD environments for the cloud, non-human workload identities seems to be popping up everywhere.
That’s why managing their access is absolutely critical.
Before we dive in: Policies for non-human identities need extra evaluation because licensing or functionality can vary depending on your environment. Now, let’s get into it!
Table of content:
Workload Identity - What even is that?
Identities come in a few different flavors (don’t worry, they’re calorie-free). We can generally divide them into two main types:
• Human Identities: These are the ones you know—admin accounts, user accounts, partners, etc.
• Non-Human Identities: These cover the likes of automated, system-managed, or machine identities.
In the Microsoft universe, non-human identities are split into Workload Identities and Device Identities. Today, we’ll leave Device Identities in peace and focus on Workload Identities.
Used with permission from Microsoft. Source: Microsoft Learn: Workload identities, other machine identities, and human identities
In Microsoft Entra, workload identities fall into three distinct types:
Service Principals
Applications
Managed Identities
While these names might seem interchangeable, they fulfill their own respective roles, so let’s break them down:
Service Principals
Service Principals are the “parent” identity for all things non-human. They act as a representative object for applications in your Entra tenant. Whether it’s an internal app or a multi-tenant enterprise app, Service Principals are the object containing the permissions and access used during resource authorization.
Applications
The Application identity is the object created for any application within its home Microsoft Entra tenant. It holds basic information that’s used for all subsequent registrations. Whenever an application is registered or consented in another tenant, a Service Principal is created automatically based on the Application object.
Basically, the app identity is the blueprint, and the Service Principal is the copy created using said blueprint.
The Application Identity is a type of Service Principal.
Managed Identities
Managed Identities are a special type of Service Principal, representing either a system-managed (single-use) or user-managed (multi-purpose) identity. Think of it as a Service Account that Microsoft manages for you, sparing you the hassle of handling credentials.
In short, think of this as an upgraded Service Account where Microsoft handles the annoying parts.
You can assign permissions to Managed Identities, but you cannot modify them beyond that.
Dear Boss - As stated in my previous email...
In my last few posts, I dropped a bunch of statistics to help out the C-suite in their endless risk assessments and ROI meetings. While I'd like to continue feeding you numbers, here’s the deal: non-human identities pose the same risks as human identities—and sometimes even more.
These accounts often have privileged access, and we don’t always have the same insights into, or interactivity with, them as we do with human identities. So, when it comes to the risks, it’s basically the same story—just scarier.
I cast "dispel confusion" on Microsoft Licensing
If you’ve ever ventured into the confusing world of Microsoft licensing, you probably felt like you needed a magic spell to find your way. Hopefully, my spellcasting will bring some much-needed lux to the situation!
Microsoft Entra Workload identities come in two tiers:
Standard: This is included with any Microsoft Cloud subscription—whether it’s an Azure subscription or any Microsoft 365 license—and gives you access to service principals, authentication, authorization, and Workload Identity Federation.
Premium: This is where the real fun begins—Conditional Access, Entra ID Protection, and Lifecycle Management are part of this tier.
To use these awesome features, you’ll need the following license:
Pro tip: You don’t assign this license to individual identities. Just having the required number of licenses (based on your setup) makes you compliant.
Workload identity policies - My two cents
As with the essential policies, and the priviliged access policies, these policies are built using the same naming, and logic, built on the Enterprise Access Model and the Persona-based conditional access reasoning, provided by Microsoft, based on Zero Trust principals as the foundation.
Note: these policies will be for Service Principals, as well as human-like identities such as Service Accounts, which uses User Objects, and not Application Objects.
As we’re limited by the lack of interactivity with these accounts, we’ll be blocking access more aggressively than we would for human identities. For instance, where we’d typically require a password or MFA for human users in risk-based policies, these non-human identities will simply be blocked. This approach demands more hands-on management afterward but ensures stronger protection upfront.
Here’s a quick refresher of the naming convention we use:
<CANumber>-<GrantControl>-<PolicyType>-<Persona>-<App>-<Platform>-<OptionalDescription>
And now, the moment you’ve been waiting for…
Non-human Identity CAPs:
CAP 25: Block access from untrusted locations for Workload Identities
CA300-Block-AttackSurfaceReduction-WorkloadIDs-AllApps-AnyPlatform-Block untrusted locations v1.0
Helps reduce the risk of unauthorized access by preventing attacks from untrusted locations.
CAP 26: Block access from untrusted locations for Service Accounts
CA301-Block-AttackSurfaceReduction-ServiceAccounts-AllApps-AnyPlatform-Block untrusted locations v1.0
Mitigates the risk of compromised service accounts being accessed from unauthorized or suspicious locations, reducing potential lateral movement in your environment.
CAP 27: Block access for Medium & High user risk accounts for Workload Identities
CA302-Block-IdentityProtection-WorkloadIDs-AllApps-AnyPlatform-Block Medium & High user risk v1.0
Protects against compromised workload identities by blocking access for accounts that show signs of risky behavior, reducing potential breaches.
CAP 28: Block access for Medium & High user risk accounts for Service Accounts
CA303-Block-IdentityProtection-ServiceAccounts-AllApps-AnyPlatform-Block Medium & High user risk v1.0
Helps prevent malicious activity, and potential compromises, by blocking risky service accounts with suspicious behavior.
CAP 29: Block access for Medium & High sign-in risk for Service Accounts
CA304-Block-IdentityProtection-ServiceAccounts-AllApps-AnyPlatform-Block Medium & High sign-in risk v1.0
Defends against compromised credentials by restricting access to service accounts showing signs of risky sign-ins, such as multiple failed attempts or unusual access patterns.
CAP 30: Block irrelevant application access for Service Accounts
CA305-Block-AttackSurfaceReduction-ServiceAccounts-AllAppsExcludedMSFT-AnyPlatform-Block unneeded applications v1.0
Mitigates risk by preventing service accounts from accessing unnecessary applications, minimizing the potential for misuse or exploitation of privileges.
Note: This policy needs to be reconfigured depending on your need. This is simply blocking anything except for the MSFT admin portals.
CAP 31: Enforce Continuous Access Evaluation strict location policy for Workload Identities
CA306-Block-DataProtection-WorkloadIDs-AllApps-AnyPlatform-Enforce CAE strict location v1.0
Protects against location-based attacks by ensuring workload identities are only accessible from trusted locations, enforcing continuous access evaluations for real-time security.
CAP 32: Enforce Continuous Access Evaluation strict location policy for Service Accounts
CA307-Block-DataProtection-ServiceAccounts-AllApps-AnyPlatform-Enforce CAE strict location v1.0
Protects against location-based attacks by ensuring Service Accounts are only accessible from trusted locations, enforcing continuous access evaluations for real-time security
CAP 33: Require compliant device for Service Accounts
CA800-Compliance-DataProtection-ServiceAccounts-AllApps-AnyPlatform-Require compliant device for untrusted networks for Service Accounts v1.0
Mitigates risks of device-based threats by ensuring service accounts can only be accessed through compliant and secure devices, particularly on untrusted networks, safeguarding against compromised or vulnerable endpoints.
Note: Requires the service account to be used on a shared device, or primary user on a device.
Conditional Access - Mission accomplished: Non-Human. Non-Issue
With your non-human identities locked down and secured, you’re one step closer to a world where workload identities aren’t the weak link. Managing these accounts with Conditional Access ensures that even the bots have to play by the rules.
Keep in mind: security is only as strong as the weakest link. Don’t let non-human identities become that weak link. If you don’t enforce policies now, you might be the one saying, “I’ll be back!”—to clean up the mess.
So, let’s keep things locked down tight. Whether it’s enforcing Conditional Access or using managed identities to their full potential, make sure your robots aren’t running amok.
Now that we can officially say Non-human? Non-issue! some might think this is the end of my Conditional Access series—but we’re not done yet!
There are still a few Conditional Access policies that didn’t quite fit into the previous posts. In the next one, we’ll tie up those loose ends and give you the final pieces to complete your security puzzle.
And, as always, before I go, here’s a little bad joke to keep you smiling:
Why did the Service Principal go to therapy?
It had identity issues! 😎
Until next time, keep your bots in check and your policies tight! Stay tuned for the next post, which will have a focus on risk-base Conditional Access policies.
Comments