What is Zero Trust?

Zero-Trust is based around 3 specific Principles: Verify Explicitly, Use Least Privilege and Assume Breach

Each of these principles individually increases your security but when combining them together allows for that security to be enhanced. It does still rely on User Awareness but it provides assistance where needed.

Verify Explicitly

The first principle requires you to verify who you are, the most common function that falls under this area is MFA (multi-factor Authentication) and the use of Conditional Access which can be used to define when you are prompted for verification, such as prompted every time you access an application that contains sensitive information or prompted to verify and change password when your account is detected to be a high risk due to unusual activity.

Use Least Privilege

The second principle requires you to only provide users or admins with the required access to do their job and nothing else. As a silly example, granting a user admin rights to an application, that they only require read only access would be overkill and would introduce a lot of risk and potential harm (especially if they do not know how to use the application).

A proper example would be a user on the IT Helpdesk, who requires access to manage user passwords. If they are only required to change passwords for non-admin users then the least privilege role would be the built-in Password Administrator role, however, an admin user who also requires the ability to change admin user passwords, would require an additional least privilege role to the Password Administrator called "Privileged Authentication Administrator"

Least Privilege also works with a principal called Just in Time (JIT) where you can temporarily elevate your access permissions related to a role for a specific duration. A prime example of this would be if you need to make changes to a Conditional Access Policy, rather than having the Role Permanently assigned to your admin account (where you could potentially accidentally make a change without meaning to) you can make use of an Entra ID P2 feature called Privileged Identity Management, this can also allow you to require Justification for elevation and approval from a set of specific users (for cases where the role is sensitive such as Global Administrator, Conditional Access Administrator or Security Administrator)

A helpful resource is the Entra ID built-in roles and Least Privileged roles by task on the Microsoft Docs page

Assume Breach

The third principle is a change to our thinking where we must now assume we have been breached, so previously, if a user was located at one of our corporate sites, we would mark that anything coming from this location would be marked as trusted explicitly. However, what's to say that the malicious user is able to connect themselves to the network at this trusted site? Then they will be marked as trusted as they are accessing from a defined trusted location.

The assume breach principal is a core of where Zero Trust came from, as the name suggests, we should absolutely not trust anything, including if the user is onsite at one of our "trusted" locations. That is not to say we cannot make use of trusted locations, we just need to ensure that we have some aspects of the verify explicitly principle, such as ensuring we still ask users to verify even when they are located at one of our "trusted" locations.

Additional Reading Resources

Establish the guiding principles and core components of Zero Trust - Microsoft Learn Module

What is Zero Trust? - Microsoft Docs