Keith Doolan

Identity is the cornerstone of Zero Trust, and for those who don’t know, identities are not just user accounts, they’re devices and service principles also. For this blog post I will focus on how I apply Zero-trust Principles on clients Entra ID environments. Before I dive into this, let’s have a look at the Zero-trust Principles and where they’re applicable on Entra ID.

Microsoft’s Zero Trust framework is built on three core principles:

---

Assume Breach

Operate as though an attacker already has access to credentials, devices, or sessions.

Applies to Identity Protection, Continuous Access Evaluation, MAA

---

Least Privilege

Provide the minimum access required for the shortest time possible.

Applies to PIM, Administrative Units, Access Reviews, RBAC

---

Alright, now that we understand the core principles and what features of Entra ID they apply to, let’s have a look at how I ‘ZT’ client’s environments. Note, the screenshots you see is my environment, you didn’t really think I’d show you a real live environment, did you?!

Verify Explicitly

Most clients still use passwords, I know, it gives me shivers up my spine too. I thought them days were gone when passwords on sticky notes get stuck to monitors or on scraps of paper hidden in drawers. It’s all about convenience, and security is not convenient to the end-user until they hear about Windows Hello for Business and Passkeys. I’m not going to talk about these features, that’s not the purpose of this blog, plus I’ve wrote about these previously if you want to read up on them.

https://keithdoolan.com/2026/08/09/windows-hello-for-business/

https://keithdoolan.com/2026/01/25/how-to-enable-synced-passkeys-in-entra/

We want to verify the identity using more secure methods, and we have multiple ways to do that. Many organizations still rely on, passwords, SMS MFA, and push notifications which are all vulnerable to phishing attacks, MFA fatigue, session hijacking and forms of MITM attacks. The new way to securely verify identity is to use phishing-resistant MFA methods sprinkled with other verification mechanisms or signals, like named locations, sessions controls or GSA.

So, you’ve probably guessed by now, I use a conditional access policy to achieve this. Before I give an example, understand that I’m trying to apply ZT Principles to a client’s tenant with the least disruption as possible. The CA is not a level 500 policy; it’s a simple practical example on how I achieve a ZT Principle via MFA methods. I also want to apply ZT principles in a manner that the client understands and is not too complicated for me to implement and hand over to the service desk or external IT teams.

Configurations to note:

1. Applied to all users because we don’t want nasties slipping through the cracks.  
2. Network is set to home country trusted named locations with the country lookup method being ‘Determine location by GPS coordinates’, to prevent spoofing.

How do you apply this on a client’s tenant?

Great question, it’s circumstantial but generally this is my approach in order.

1. Run a report to assess authentication methods in use. Note the number using authenticator, these transition easier.
2. Ensure Passkeys and MS Authenticator is enabled for all users.
3. Run an authentication methods campaign which is currently limited to Microsoft Authenticator or passkeys (FIDO2).
4. Come back a week later and run the authentication methods report again.
5. Create the above CA in report only mode and assigned to a pilot group of users.
6. Exclude admin account from the policy
7. Ensure System-preferred authentication state is enabled or Microsoft managed and targeted to all users.
8. Begin transitioning users over to the CA gradually.
9. Run the report again.
10. Put the old MFA policy into report-only mode and turn on the new policy.
11. Assign policy to all users.

The secret to success is to have both CA’s running side by side until you’re happy to switch over from the older less secure MFA policy to the new phishing-resistant method.

Other configurations to achieve the Verify Explicitly Principle:

1. Configure Authentication Strengths
2. Hardware keys (YubiKeys)
3. Cert-based controls
4. Global Secure Access. (GSA)

Essentially we very otherwise you don’t gain access.

Assume Breach

Now onto our next principle, Assume Breach, which for me is difficult to conceptualise and explain to clients why this principle is important. How do I explain to a client to assume all identifies aren’t to be trusted, even those already in use?! Conditional Access Policies also play a big part in applying the Assume Breach Zero-trust Principle. I’m not going to start listing off CA policies, if you’re reading this blog then I assume you understand how a CA policy works and its capabilities, instead I’ll talk about the functionality in Entra ID that facilitate applying this principle.

Identity Protection

This feature is turned on by default, but it plays a limited roll on a client’s tenant unless the tenant is licensed with an Entra ID P2. Let’s assume the client has a P2, doing so will make explaining the functionality easier. When I think of identity protection I immediately think of risky users. Microsoft uses its own threat intelligence engine which consists of hundreds of thousands or millions (I can’t remember) of ‘signals’ to designate a risk score to a user’s identity so you don’t have to. That’s nice of them!

Where does Assume Breach come into this?

Well, with Identify Protection enabled and risky user policies configured, each user account access is assessed based on a ‘combination of user sign-in behaviours, location, machine learning, intelligence engine analysis and other signals’. This is a quote from Microsoft because no one really knows the depth at which Microsoft evaluates and assigns a risk score to an identity, because doing so would give attackers insightful information to work with.

Anyways, to answer the question, Microsoft ‘Assumes Breach’ by evaluating every single sign-in under a magnifying glass and only allows the sign-in to pass if it’s confident the risk is low or medium depending on how it’s configured on the tenant.

Obviously from the screenshot, I don’t have a P2, I deployed the CA to give you an idea of the configuration.

How do you apply this on a client’s tenant?

This CA policy is less impactful on more mature organisations that use modern authentication methods, named locations and device controls. Here’s how I completed the work:

1. Evaluate the Risky Users and Sign-ins portal.
2. Note high and medium risk identities, if any.
3. Create the policy in report-only mode with pilot group assigned.
4. Exclude admin account from assignment.
5. Evaluated the CA for one week.
6. Gradually assign logical user groups to the policy.
7. Set enable policy to on.
8. Assign policy to all users.

I like to populate my pilot group of users as the VIP users as these are generally the most targeted persons in any organisation, so you want them onboard first. Also, they travel a lot which can give immediate results.

Other configurations to achieve the Assume Breach Principle:

1. Impossible Travel: Location-Based Blocking
2. CA Session Controls: Time based, Continuous Access Evaluation (CAE).
3. Conditional Access: Device Compliance, Managed Devices
4. Global Secure Access. (GSA)

Just a note on Continuous Access Evaluation, this is going to be a gamechanger and a much simpler option when it moves out of evaluation mode. Access is currently evaluated on token lifecycles; CAE evaluates the access token based on real-time events, which reduces the attack surface and likelihood of token hijack.

Least Privilege

Finally, onto the last principle, Least Privilege. When I see the word privilege I think of admin accounts, and there are many features in Entra ID to control access for admins with all requiring additional licenses that in my opinion, aren’t worth it, except for PIM. It’s easy to apply the principle of least privilege to a greenfield environment, but in practice it’s very hard to implement on mature environments. To implement least privilege we must evaluate access, justify it, limit it, and ensure the correct people have access. Who has time for that?     

Let’s take a step back and look at the problem holistically from an identity perspective, not just admin identities, all identities. Before we had the functionality that comes with identity governance (PIM, Automatic Access Reviews, Lifecycle workflows) we used to manually review access, which in my opinion is still relevant today.   

When did access reviews become an IT function?! Yes, it’s our responsibility to look after admin accounts and ensure we’re not over-permissive. I suppose what I’m trying to say is, unless the client pays for Identity Governance Access Reviews then applying the principle of least privilege at an org level, is a manual effort and not exclusive to admins.

How do you apply the principle of Least Privilege on a client’s tenant?

I’m only looking at this problem from an admin’s perspective, the privileged accounts. It’s difficult to justify ID Governance: Access Reviews just for admins unless the client has a governance team, compliance administrator or someone who manages governance daily on the client’s behalf. I wouldn’t propose this solution without said person(s).

In this case I propose to the client, recurring manual access reviews monthly or at a cadence acceptable to the client. If the client wants all roles, groups, and service principles reviewed then this would a separate project and not something I’m going to discuss in this blog post.

To achieve the Least Privilege Principle, you can configure:

1. Privileged Identity Management (PIM)
2. Role-Based Access Control (RBAC): Scoped/Custom Roles
3. Multi-Admin Approval (MAA)
4. Access Reviews
5. Lifecycle Workflows

In summary, when proposing a zero-trust deployment plan, the strategy doesn’t always have or require a technical solution.

To learn more about Zero Trust Principles, visit: Zero Trust as a security foundation | Microsoft Learn