top of page
Writer's pictureSebastian F. Markdanner

Access Denied (Unless You’re Cool): Conditional Access Policies for Non-human Identities

Updated: 2 days ago

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.

Two robots looking at each-other, one of the robots is old and rusty sitting on the floor outside a party with a red "access denied" sign showing on it's chest, the other robot is new and shiny with sunglasses, standing in the door leading into the party with a green "Access Granted" above it's head

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.


Microsoft ecosystem explanatory diagram showing 2 boxes. The first box on the right side shows Human Identities, the box on the left shows Machine Identities. The Machine identities box have two smaller boxes inside it with one showing Workload identities and the other showing device identities

In Microsoft Entra, workload identities fall into three distinct types:

  1. Service Principals

  2. Applications

  3. 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!



  1. 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.

  2. 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

JSON | MITRE ATT&CK Technique ID: T1078 & T1098

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

JSON | MITRE ATT&CK Technique ID: T1078 & T1098

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

JSON | MITRE ATT&CK Technique ID: T1078 & T1098

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

JSON | MITRE ATT&CK Technique ID: T1078 & T1098

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

JSON | MITRE ATT&CK Technique ID: T1078 & T1098

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

JSON | MITRE ATT&CK Technique ID: T1078 & T1098

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

JSON | MITRE ATT&CK Technique ID: T1078 & T1098

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

JSON | MITRE ATT&CK Technique ID: T1078 & T1098

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

JSON | MITRE ATT&CK Technique ID: T1078 & T1098

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

Rated 0 out of 5 stars.
No ratings yet

Add a rating
bottom of page