Conditional Access Blueprint

The first step in building your access security is defining what security restrictions can be applied to each persona in your environment.

What's a persona, you ask?

A persona can be:

• a group of users/identities: e.g. regular users, ADM users, DEV users, external users, Entra roles, a group of Service Principals, emergency accounts, C-level users, service accounts or non-interactive accounts (like Entra Connect sync accounts, phone service accounts, server service accounts, meeting room service accounts, ...)
• an individual user/identity: e.g. a specific service account, a Tier 0 account, an Entra role, a Service Principal, ...

Begin by listing all existing personas in your environment. To visualize the relationships and structure, create a hierarchy chart. This will help in understanding how different personas interact and what their place is within the organization. Important to understand is that in this hierarchy chart, each node will inherite Conditional Access actions from the nodes above.

An example of personas in a tenant:

For most of the organizations, the hierarchy chart looks something like this. But depending on your organization, it might look a bit different, or different keywords are used. You can and you should go really detailled while defining your personas. Later on in the framework, you can delete what you don't need or what you think is overkill.

What do you do with these personas?

For each persona, you should define what access restrictions or actions can be applied. This can be done by simply following the persona flow from top to bottom (https://jbaes.be/CAF/CA-flow):

Screenshot(s)

Results can be documented in tool #2.

Who needs to be involved?

• Security or IT engineer
• Each persona owner (i.e. the person or team responsible for using the persona)
• CISO (optional)

The second step in building your access security is documenting what security actions can be applied to each persona.

Where do I start?

Download the Excel template here:

In this template, fill in your listed personas horizontally in the prepared cells.

For each security action (listed vertically), mark whether the action can be applied on the specific persona. To correctly do this, use tool #1 Flow Diagram.

For each marking, the template has whitespace for a small note. In the end, this makes it easier to group personas in Conditional Access policies. This small note can contain e.g.:

• which Operating Systems should be blocked
• the device Extention Attribute
• the device property
• IP (ranges)
• the sign-in frequency
• the action on a identity risk
• ...

How will this help (re)creating my Conditional Access policies?

With all security restrictions filled in for each persona, the next step is to group them. This guides you into creating (or adjusting) your Conditional Access policies. For each security restriction, you can horizontally see which personas should be included in the policy that enforces this security action.

The goal is to create Conditional Access policies once and then simply add or remove personas (Entra groups) as needed.

Next, create or adjust your Conditional Access policies in report-only mode. Do this based on the different security restrictions in the template. For example:

By just adding or excluding personas to these Conditional Access policies, your organization will have a strong, clear and well-documented access security setup. A setup based on your organization's personas and organization's use cases.

And here, you’ll need to make a decision: do you prefer a higher level of security and being able to customize more with better exclusion catches, or is having a less complex access setup a higher priority. The answer to this question depends on different factors like the type of organization, core business, the IT team, mentality and so on. It is not a binary decision but rather a balance you need to find.

Who needs to be involved?

• Security or IT engineer
• Each persona owner (for validation)
• CISO (for final approval)

Finally, you should continiously verify both common and malicious access situations. Key here is compliance.

Tools to simulate access:

The need for a Breach and Attack Simulator (BAS)

Conditional Access is one of the most important security components of Entra, but complicated to setup and maintain. It can contain many policies, which can add up or exclude eachother. Also, misconfigurations happen often resulting in security gaps or incidents. Your access setup is partly a translation of the policies business has defined. So you should just be (continuously) checking if your Conditional Access setup meets these business defined policies.

The easiest way to do this is with compliance. For each simulation you define what the expected outcome is (e.g. MFA, company device, password reset, block, ...). If the simulation matches the expected actions, you're good. If not, you have a misconfiguration or wrong configured Conditional Access policy.

You should only create simulations for user accounts you specifically want to test, or a random user from a persona.

Screenshot(s)

Define simulations:

Simulation results:

Best practices:

Maester example:

Who needs to be involved?

• Security or IT engineer
• CISO

The sole purpose of the Conditional Access Blueprint is to guide you towards a more secure access configurations. Here's how you can contribute to that mission:

• Use it: Use the tools and other referenced tools! That's why they were build. Use it in your own organization, or use it with your clients.
• Talk about it: Engage in discussions about this, or invite me to spreak about the framework.
• Feedback or share ideas: Have ideas or suggestions to improve this framework? Message me on LinkedIn (Jasper Baes)
• Contribute: Join efforts to improve the quality, code and usability of the Conditional Access Blueprint.
• Donate: Consider supporting financially to cover costs (domain name, hosting, development costs, time, production costs, professional travel, ...) or future investments: donate on
  ☕ Buy Me A Coffee

The Conditional Access Blueprint was developed entirely on my own time, without any support or involvement from any organization or employer. For tool 4, a free alternative is available.

Please be aware that the Conditional Access Blueprint is intended solely for individual administrators' personal use. It is not licensed for use by organizations seeking financial gain. This restriction is in place to ensure the responsible and fair use of the tools. Admins are encouraged to leverage this code to enhance their own understanding and management within their respective environments, but any commercial or organizational profit-driven usage is strictly prohibited.

Thank you for respecting these usage terms and contributing to a fair and ethical software community.