> For the complete documentation index, see [llms.txt](https://helpdesk.augmentt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://helpdesk.augmentt.com/modules/secure/conditional-access.md).

# Conditional Access

Conditional Access is Microsoft Entra ID's if-this-then-that engine for sign-ins: a policy says who or what (a user, a group, an app, a device platform, a network location, a risk level) triggers the policy, and what happens as a result — block access outright, or grant it only if a control like MFA or a compliant device is satisfied first. Augmentt doesn't replace that engine — every policy you manage here is a real Conditional Access policy living in the client's own Entra tenant. What Augmentt adds is a way to build a policy once and roll it out, consistently, across every client tenant you manage, instead of recreating the same rules by hand in each one's Entra admin center.

You manage all of this from **Secure > Policy Management**, which has three areas: **Policies** (what's actually deployed to the currently selected client), **Templates** (your reusable policy designs, not tied to any one client), and **Named Locations** (the network locations a policy can reference).

{% hint style="warning" %}
Everything you deploy from here is a live change to the client's tenant, pushed through Microsoft Graph with the same effect as building the policy directly in the Entra admin center. Augmentt is the authoring and rollout layer — it is not a sandbox, and a deployed policy immediately participates in real sign-ins for that tenant.
{% endhint %}

## Templates, Baselines, and Policies

These three words get used loosely, so it's worth being precise about what each one actually is:

* A **Template** is a single Conditional Access policy design, sanitized of anything specific to the tenant it came from (the exact users, groups, or locations) and turned into a reusable blueprint. It isn't deployed anywhere by itself.
* A **Baseline** is a named group of Templates — nothing more. Deploying a Baseline just deploys every Template in it, one after another, so you don't have to deploy your standard set of policies one at a time for every client.
* A **Policy** is what you get after a Template (or a Baseline's Templates) has actually been deployed to a specific client tenant — a real Conditional Access policy, with real values filled in, that Microsoft now evaluates on every sign-in.

In short: you author Templates, optionally group them into Baselines, and deploying either one produces Policies in the target tenant. There's no fourth concept hiding here — a Baseline is a bundle of Templates and nothing else, and a Policy is a deployed Template and nothing else.

## Building a policy template

Templates come from real, working Conditional Access policies — either the ready-made ones Augmentt ships (its **Out of Box** recommendations) or ones you build yourself from a policy that already exists in one of your clients' tenants.

{% hint style="info" %}
Some support material calls the tenant you copy a policy from a "Golden Tenant." There's nothing special about the tenant itself — it's just whichever client's Entra tenant currently has the policy configured the way you want to standardize on. Augmentt doesn't require a dedicated tenant for this, and you never need to provision one solely to build templates.
{% endhint %}

To create one, go to **Policy Management > Templates**, select **Create New > Policy template**, then:

1. **Select the tenant** you're copying the source policy from, and **select the policy** itself from that tenant's existing Conditional Access policies.
2. Give the template a **Template name** and a **Description**. Microsoft doesn't support descriptions on Conditional Access policies natively, but Augmentt does — this is where you leave a note for whoever deploys it later about what the template is for.
3. Augmentt sanitizes the policy: anything tenant-specific — a particular group, a named location, a specific user or role that only exists in the source tenant — is stripped out and turned into a variable you'll need to (or can choose to) fill in when you deploy. You can inspect the sanitized result either as the normal form view or as raw JSON.
4. On the next screen, the wizard shows you every sanitized element as a prompted input. For each one, mark it **Required** or **Optional**, and add **Notes/Instructions** — this is effectively the deployment SOP for whoever uses the template. You can also add or remove inputs manually here, beyond just the ones Augmentt auto-detected, by picking an input type from the dropdown.
5. Click **Next**, review, and **Create** to save the template.

{% hint style="info" %}
Augmentt's own Out of Box templates are shared globally across your MSP and can't be edited directly — duplicate one first if you want a customized version.
{% endhint %}

## Grouping templates into a baseline

A Baseline is just a saved list of Templates you deploy together. From **Policy Management > Templates**, choose **New baseline** (this opens **New CA Policy Baseline**):

1. Give it a **Baseline name** and **Baseline Description**.
2. Under **Policy Selection**, pick every Template you want included — the panel shows your **Selected policy templates** as you go.
3. Click **Create Baseline**.

The Templates and Baselines you've built both live in the same table on the Templates page — a filter lets you switch between **All**, **My templates**, **Templates**, and **Baselines** — and each can be opened to view its full details or edited later.

## Deploying a template or baseline

Once you have at least one Template (or Baseline), you deploy it to a specific client from **Policy Management > Policies**:

1. Make sure the correct client is selected, then select **Deploy policy**.
2. Choose **Template** or **Baseline** and click **Next**.
3. Review the policy's details, then click **Next**.
4. Fill in the **Required** and **Optional** inputs the template asks for — the group to apply it to, the named location to exclude, whichever tenant-specific values were sanitized out when the template was built — following the notes/instructions the template's author left. You also choose the policy's **Status** here (see below).
5. Review your selections and click **Deploy Policy**.

Deploying calls Microsoft Graph directly to create the policy in the client's tenant (the same `conditionalAccessPolicies` API Entra's own admin center uses), so it takes effect immediately, not after some separate sync step. Deploying a Baseline just repeats this for every Template inside it.

{% hint style="warning" %}
Augmentt's Out of Box templates are authored to deploy in **Report-only** status by default, and that's a deliberate, recommended safety margin — not a hard limit. The status is a normal field you fill in during deployment, so a template can be set up to deploy as **On** or **Off** instead. Unless you have a specific reason not to, start new policies in Report-only and review sign-in logs before switching them on.
{% endhint %}

Right after deploying, a policy shows as **Synchronizing with Microsoft** in the Policies table and its status can't be changed again until that finishes — Augmentt is confirming the change landed and refreshing its own view of the tenant before it lets you act on the policy again.

## Managing deployed policies

**Policy Management > Policies** lists every Conditional Access policy currently deployed to the selected client, with columns for **Status**, **Exclusions** (a quick icon summary of excluded users/groups, locations, device platforms, and cloud apps), **Description**, **Access control**, **Date created**, and who last touched it.

Unlike some of Augmentt's other policy-managed modules, Conditional Access policies aren't locked once deployed — you can act on them directly from this table:

* **Status** is a dropdown right in the table — **Enabled**, **Disabled**, or **Report-only** — so promoting a policy out of Report-only, or turning one off, doesn't require re-deploying anything.
* **Edit** (from the row menu, or by clicking the row) opens the same condition and grant-control editor used when building a template, pre-filled with the policy's live values, plus a raw JSON editor for anything the form doesn't expose. Changes here are pushed back to Microsoft the same way a deployment is.
* **Delete** removes the policy from the tenant entirely.
* Every row also has a **history** you can open from its last-updated timestamp, showing who changed the policy and when.

{% hint style="info" %}
Editing or changing the status of a policy requires **manage** permission on Secure, and a valid Secure posture/baseline subscription — without either, the table is read-only.
{% endhint %}

## Conditions and access controls

The condition and grant-control vocabulary in Augmentt's policy editor matches Entra's own Conditional Access assignment and access-control model directly — nothing is renamed or reinterpreted:

* **Users, groups, and roles** — include/exclude by individual user, group, or directory role, plus a dedicated include/exclude for guest and external users.
* **Locations** — include/exclude by [Named Location](#named-locations) (see below), including Microsoft's built-in "All trusted locations."
* **Applications** — include/exclude specific cloud apps, or the built-in "Office 365" and "Microsoft Admin Portals" groupings, plus a set of known Microsoft first-party apps (Intune Enrollment, Azure Windows VM Sign-In, Azure Management).
* **Client app types**, **device platforms** (include/exclude), **user risk**, **sign-in risk**, **insider risk**, and **transfer methods** round out the remaining conditions.
* **Grant controls** — the access controls a matched sign-in must satisfy: **MFA**, **block**, **compliant device**, custom authentication factors, or an authentication strength, combined with an AND/OR operator when more than one is selected.

{% hint style="info" %}
Session controls (things like sign-in frequency or app-enforced restrictions) aren't exposed as their own form fields in the Augmentt editor the way conditions and grant controls are. If a template or policy needs one, use the JSON editor in the Edit or Template screens — it edits the same underlying policy object Microsoft Graph accepts, so anything a Conditional Access policy supports can be set there even without a dedicated form input.
{% endhint %}

## Named Locations

A Named Location is Microsoft's own Conditional Access object — a named, reusable definition of "this network," used as a Locations condition on a policy. It comes in two forms:

* A **countries location** — a set of countries/regions, evaluated either by the sign-in's IP address or (where available) GPS-based location, with a toggle for whether to include sign-ins from unrecognized/unmapped countries.
* An **IP ranges location** — one or more IP ranges, optionally marked **trusted**.

Manage these from **Policy Management > Named Locations**, or create one inline while building a policy — the **Locations** input on a template or policy has its own **Create Named Locations** action, so you don't have to leave the wizard to add one you're missing. You can also clone an existing named location from one of your other client tenants as a starting point, rather than rebuilding it by hand for every client.

{% hint style="warning" %}
Named Locations are not the same feature as [Safe Locations](/modules/secure/alerts/safe-locations.md), even though both are about "trusted" locations. Named Locations are a Microsoft Entra construct that Conditional Access policies evaluate as a condition — they change what a policy does. Safe Locations is an Augmentt-only alerting concept that suppresses sign-in and security-info alerts; it has no effect on Conditional Access and isn't read by any Conditional Access policy. Configuring one does not configure the other.
{% endhint %}

## In this section

* [Default Policy Templates](/modules/secure/conditional-access/default-policy-templates.md) — every Out of Box Conditional Access template Augmentt ships (general-purpose, CIS M365 v6, and NIST CSF 2.0), with exact conditions/grant controls and the posture check each one resolves.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://helpdesk.augmentt.com/modules/secure/conditional-access.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.