> 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/default-policy-templates.md). # Default Policy Templates Augmentt ships with a library of ready-made Conditional Access **Templates** — real, deployable policy designs you can hand straight to a client tenant from **Policy Management > Templates**, or fold into a **Baseline** and roll out in one pass. These are the "Out of Box" templates referenced on the main [Conditional Access](/modules/secure/conditional-access.md) page: nothing needs to be imported or authored first, they're seeded into every MSP's Templates list automatically, they're shared globally (not owned by any one client), and — like every Out of Box template — they can't be edited directly; duplicate one first if you want a customized version. {% hint style="info" %} This isn't the same thing as the **Import** flow some other policy-managed modules use to pull an existing tenant configuration in "as-is." Augmentt's default CA templates are pre-authored designs that exist in the product before you ever connect a client tenant — the same way a word processor ships with document templates you didn't write yourself. {% endhint %} There are two tiers to this library: * **Fourteen general-purpose default templates** — Augmentt's own hardening recommendations, independent of any specific compliance framework, covering the highest-impact identity and device controls most tenants should have regardless of which framework they're audited against. * **Compliance-framework template sets** — additional templates authored specifically to satisfy individual controls in the **CIS Microsoft 365 Foundations Benchmark v6.0.0** and **NIST CSF 2.0**, each tagged with its exact control number and grouped into ready-made Baselines (**CIS M365 v6** and **NIST CSF 2.0**) you can deploy in one step. These are what [Compliance Audit](/modules/secure/security-posture/compliance-audit.md) and [All Posture Checks](/modules/secure/security-posture/all-posture-checks.md) are checking for when they report a CIS or NIST control as failing. All of these deploy in **Report-only** status by default, consistent with Augmentt's general safety guidance for Out of Box templates — review sign-in logs before promoting any of them to On. {% hint style="warning" %} Every template below excludes **Service Provider** guest/external users (your own MSP technicians accessing the tenant via GDAP/delegated admin) from its scope by default, in addition to whatever exclusions the template prompts you to add at deployment (typically a break-glass account). This keeps a newly deployed policy from locking your own support staff out of a client tenant. {% endhint %} ## Augmentt Default Templates ### Require MFA for All Users Requires every user in the tenant to complete multi-factor authentication before accessing any cloud app, with the single exception of a break-glass account you exclude at deployment. * **Conditions:** Users: All (Service Provider guests excluded by default) · Applications: All · Client app types: all * **Grant controls:** MFA (operator: OR) * **Default status:** Report-only * **Prompted inputs:** Exclude Users (optional — break-glass account) · Exclude Groups (optional — legacy-app service accounts) * **Resolves posture check(s):** **User MFA** (`usermfa`) and **Admin MFA** (`adminmfa`) — a tenant-wide MFA policy satisfies both checks simultaneously since it covers admins and non-admins alike. ### Block Legacy Authentication Blocks sign-in via legacy protocols (Exchange ActiveSync, POP, IMAP, older Office clients) that can't enforce MFA, closing off the most common way attackers bypass an MFA requirement entirely. * **Conditions:** Users: All (Service Provider guests excluded) · Applications: None selected as include, targeting the client app types below instead · Client app types: Exchange ActiveSync, Other clients * **Grant controls:** Block (operator: OR) * **Default status:** Report-only * **Prompted inputs:** Exclude Groups (optional — service accounts still on legacy protocols) * **Resolves posture check(s):** **Block Legacy Authentication** (`blocklegacyauthentication`). ### Block Device Code Flow Blocks the OAuth device-code sign-in flow (used by CLIs, IoT, and shared-device sign-in) for every user, closing a flow that's become a favored phishing vector — a user is tricked into entering a code on a legitimate Microsoft page, handing the attacker an authenticated session. * **Conditions:** Users: All (Service Provider guests excluded) · Applications: All · Client app types: all · Authentication flows: transfer method = Device code flow * **Grant controls:** Block (operator: OR) * **Default status:** Report-only * **Prompted inputs:** None * **Resolves posture check(s):** *Ensure the device code sign-in flow is blocked* (`AUG.CIS.M365.5.2.2.12`). ### Require Device Compliance Requires a device to be marked compliant by Intune before it can access Microsoft 365, keeping unmanaged or non-conforming devices out entirely. * **Conditions:** Users: All (Service Provider guests excluded) · Platforms: all included · Applications: None selected as include, scoping instead by the platform/client-app conditions * **Grant controls:** Compliant device (operator: OR) * **Default status:** Report-only * **Prompted inputs:** None * **Resolves posture check(s):** **Require Device Compliance** (`MT.1001`). ### Register Security Info Only From Trusted Locations Restricts where users are allowed to register MFA methods or other security info to your defined trusted locations, and excludes Global Administrators and guest/external users from the requirement. Modeled directly on [Microsoft's own recommended policy](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-security-info-registration). * **Conditions:** Users: All, excluding the Global Administrator role and all guest/external user types · Locations: excludes all trusted locations (i.e., applies outside them) · Applications: scoped via the `urn:user:registersecurityinfo` user action, not a normal app list · Client app types: all * **Grant controls:** Authentication strength = Microsoft's built-in **Phishing-resistant MFA** strength (operator: OR) * **Default status:** Report-only * **Prompted inputs:** Exclude Guests or External Users (required) · Include Locations (required — your trusted-location set) * **Resolves posture check(s):** *Require Security Info Registration from a Trusted Location* (`MT.1011`). ### Block High Risk Users and Sign-ins Blocks access outright for any user or sign-in Entra ID Protection has scored as **high risk**, acting as a hard stop rather than a step-up challenge. * **Conditions:** Users: All (Service Provider guests excluded) · Applications: All · Client app types: all · User risk levels: High · Sign-in risk levels: High * **Grant controls:** Block (operator: OR) * **Default status:** Report-only * **Prompted inputs:** Exclude Users (optional — break-glass account) * **Resolves posture check(s):** **Block Risky Sign-ins** (`CISA.MS.AAD.2.3`), and contributes to any user-risk-based check by blocking the highest risk tier outright. Requires Entra ID P2 for risk detection signals. ### Register MFA from Managed Devices Requires a compliant or hybrid-joined device before a user can register MFA/security info, preventing an attacker who's stolen a password from registering their own authenticator on an unmanaged machine. * **Conditions:** Users: All (Service Provider guests excluded) · Platforms: all included · Applications: scoped via the `urn:user:registersecurityinfo` user action · Client app types: all * **Grant controls:** Compliant device OR Domain-joined device (operator: OR) * **Default status:** Report-only * **Prompted inputs:** None * **Resolves posture check(s):** **Register MFA from Managed Devices** (`CISA.MS.AAD.3.8`). ### Enforce Restrictions for Unmanaged Devices Applies Microsoft's application-enforced restrictions (e.g., blocking download/print/sync in Office apps) for sign-ins to Office 365 rather than gating access outright — a session control, not a grant control. * **Conditions:** Users: All (Service Provider guests excluded) · Applications: Office 365 · Client app types: all * **Session controls:** Application-enforced restrictions enabled * **Default status:** Report-only * **Prompted inputs:** Exclude Users (optional — break-glass account) * **Resolves posture check(s):** No dedicated posture check name exists for this control specifically; it closes the general "unmanaged device" exposure gap that the device-compliance and idle-session-timeout checks (below) also address from different angles, per [Microsoft's own recommendation](https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-policy-app-enforced-restriction). ### Block Access for Unknown or Unsupported Device Platforms Blocks sign-in from device platforms other than the ones your fleet actually uses (Android, Windows, macOS by default), so a device Intune can't classify or manage can't authenticate either. * **Conditions:** Users: All (Service Provider guests excluded) · Platforms: all included, with Android/Windows/macOS excluded from the block · Applications: All · Client app types: all * **Grant controls:** Block (operator: OR) * **Default status:** Report-only * **Prompted inputs:** Exclude Users (optional — break-glass account) · Exclude Applications (optional — Augmentt and other hosted-service apps that can appear as Linux/Other platforms and would otherwise be caught by the block) * **Resolves posture check(s):** **Block Access for Unknown or Unsupported Device Platforms** (`MT.1015`). ### Non-persistent Browser Session for Unmanaged Devices Forces re-authentication every hour and disables persistent browser sessions for sign-ins from devices that aren't domain-joined/hybrid-joined or Intune-compliant, limiting how long a stolen session token stays useful on an unmanaged machine. * **Conditions:** Users: All (Service Provider guests excluded) · Devices: filter rule `device.trustType -ne "ServerAD" -or device.isCompliant -ne True` (i.e., matches non-domain, non-compliant devices) · Applications: All · Client app types: all * **Session controls:** Sign-in frequency = every 1 hour · Persistent browser session = never * **Default status:** Report-only * **Prompted inputs:** Exclude Users (optional — break-glass account) * **Resolves posture check(s):** *Enforce Sign-in Frequency for Non-Corporate Devices* (`MT.1018`); the same gap the CIS/NIST idle-session-timeout templates below close via `applicationEnforcedRestrictions` instead of a sign-in-frequency clock. ### Require Compliant or Entra Hybrid Joined Devices for Admins Requires anyone holding one of roughly a dozen privileged Entra roles (Global Administrator, Privileged Role Administrator, Security Administrator, Exchange/SharePoint/Conditional Access/Application/Cloud Application Administrator, Password Administrator, Helpdesk Administrator, and similar) to sign in from a compliant or hybrid-joined device. * **Conditions:** Users: scoped by directory role to Microsoft's standard set of privileged admin role template IDs, Service Provider guests excluded · Applications: All · Client app types: all * **Grant controls:** Compliant device OR Domain-joined device (operator: OR) * **Default status:** Report-only * **Prompted inputs:** Exclude Users (optional — break-glass account) * **Resolves posture check(s):** **Require Compliant or Entra Hybrid Joined Devices for Admins** (`MT.1014`), per [Microsoft's recommendation](https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-policy-compliant-device-admin). ### Require New Password when User Risk Is High Forces a password change (plus MFA to prove it's really the account owner) the moment Entra ID Protection scores a user as high risk, self-remediating a likely-compromised account instead of just alerting on it. * **Conditions:** Users: All (Service Provider guests excluded) · Applications: All · Client app types: all · User risk levels: High * **Grant controls:** Password change AND authentication strength = Microsoft's built-in **Multifactor authentication** strength (operator: AND) * **Default status:** Report-only * **Prompted inputs:** Exclude Users (optional — break-glass account) * **Resolves posture check(s):** *Require New Password When User Risk Is High* (`MT.1013`). Requires Entra ID P2. ### Block Risky Countries or IPs Blocks sign-in from countries or IP ranges you've flagged in a Named Location as risky — typically geographies or ranges the tenant has no legitimate business in. * **Conditions:** Users: All (Service Provider guests excluded) · Applications: All · Client app types: all · Locations: the Named Location(s) you supply at deployment * **Grant controls:** Block (operator: OR) * **Default status:** Report-only * **Prompted inputs:** Exclude Users (optional — break-glass account) · Include Locations (required — the risky-country/IP Named Location to block) * **Resolves posture check(s):** **Risky IP Address Policy** (`riskyips`) and **Risky Country Policy** (`riskycountries`) — this single template covers both checks depending on whether the Named Location you supply is IP-range- or country-based. ### Require Anti-phishing MFA for Admins Requires the same set of privileged admin roles to authenticate with a **phishing-resistant** method (FIDO2 security key, Windows Hello for Business, or certificate-based auth) rather than ordinary MFA, and forces that check on every single sign-in rather than relying on a remembered session. * **Conditions:** Users: scoped by directory role to Microsoft's standard set of privileged admin role template IDs (including Hybrid Identity Administrator, added in a later fix), Service Provider guests excluded · Applications: All · Client app types: all * **Grant controls:** Authentication strength = Microsoft's built-in **Phishing-resistant MFA** strength (operator: OR) * **Session controls:** Sign-in frequency = every time (no remembered session for this control) * **Default status:** Report-only * **Prompted inputs:** Exclude Users (optional — break-glass account) * **Resolves posture check(s):** **Phishing-Resistant MFA for Highly Privileged Roles** (`CISA.MS.AAD.3.6`), per [Microsoft's own admin phishing-resistant MFA guidance](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-admin-phish-resistant-mfa). ## Compliance Baseline Templates Beyond the fourteen general templates above, Augmentt seeds two additional, framework-specific sets of CA templates — one per control in the **CIS M365 v6** and **NIST CSF 2.0** Baselines you'll find already built in **Policy Management > Templates**. Deploying either Baseline deploys every template in its set in one pass; you can also deploy any individual one on its own the same way you would any other template. Where a CIS/NIST template targets the same control as one of the fourteen templates above, treat them as interchangeable — deploy whichever matches the framework you're being audited against, not both. Both sets exclude Service Provider guest/external users the same way the general templates do, and both deploy Report-only by default. ### CIS Microsoft 365 Foundations Benchmark v6.0.0 templates Thirteen templates, one per Conditional Access control in the benchmark, each named and numbered to match its exact section: | Template | Conditions (condensed) | Grant / session controls | Resolves | | --------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | CIS M365 v6 L1 - MFA for Administrative Roles 5.2.2.1 | Privileged admin roles, all apps | MFA | CIS 5.2.2.1 — superseded by 5.2.2.5 at L2 | | CIS M365 v6 L1 - MFA for All Users 5.2.2.2 | All users, all apps | MFA | CIS 5.2.2.2; also **User MFA** / **Admin MFA** | | CIS M365 v6 L1 - Block Legacy Authentication 5.2.2.3 | All users, legacy client app types | Block | CIS 5.2.2.3; also **Block Legacy Authentication** | | CIS M365 v6 L1 - Sign-in Frequency and Non-Persistent Sessions for Admins 5.2.2.4 | Privileged admin roles, all apps | Session: 4-hour sign-in frequency, never-persistent browser | *Ensure Sign-in frequency is enabled and browser sessions are not persistent for Administrative users* (`AUG.CIS.M365.5.2.2.4`) | | CIS M365 v6 L2 - Phishing-Resistant MFA for Administrators 5.2.2.5 | Privileged admin roles, all apps | Authentication strength: phishing-resistant | CIS 5.2.2.5; also **Phishing-Resistant MFA for Highly Privileged Roles** (`CISA.MS.AAD.3.6`). Requires Entra ID P2 | | CIS M365 v6 L1 - Identity Protection User Risk Policy 5.2.2.6 | All users, user risk = High | Password change AND MFA | CIS 5.2.2.6 — superseded by nothing at L2, complements 5.2.2.8. Requires Entra ID P2 | | CIS M365 v6 L1 - Identity Protection Sign-in Risk Policy 5.2.2.7 | All users, sign-in risk = Medium/High | MFA | CIS 5.2.2.7 — superseded by 5.2.2.8 at L2; don't deploy both together. Requires Entra ID P2 | | CIS M365 v6 L2 - Block Sign-in Risk Medium and High 5.2.2.8 | All users, sign-in risk = Medium/High | Block | CIS 5.2.2.8; also **Block Risky Sign-ins** (`CISA.MS.AAD.2.3`). Requires Entra ID P2 | | CIS M365 v6 L1 - Managed Device Required for Authentication 5.2.2.9 | All users, all apps | Compliant device OR domain-joined device | CIS 5.2.2.9. Requires Intune | | CIS M365 v6 L1 - Managed Device Required to Register Security Info 5.2.2.10 | All users, `registersecurityinfo` action | Compliant device OR domain-joined device | CIS 5.2.2.10; also **Register MFA from Managed Devices** (`CISA.MS.AAD.3.8`). Requires Intune | | CIS M365 v6 L1 - Sign-in Frequency for Intune Enrollment 5.2.2.11 | All users, scoped to the Microsoft Intune app | Session: sign-in frequency = every time | CIS 5.2.2.11. Requires Intune | | CIS M365 v6 L1 - Block Device Code Sign-in Flow 5.2.2.12 | All users, all apps, device code transfer method | Block | *Ensure the device code sign-in flow is blocked* (`AUG.CIS.M365.5.2.2.12`) | | CIS M365 v6 L2 - Idle Session Timeout for Unmanaged Devices 1.3.2 | All users, Office 365 app, browser client, excludes compliant/hybrid-joined devices | Session: application-enforced restrictions | CIS 1.3.2 — must be paired with the matching idle-timeout value set separately in the Microsoft 365 admin center | ### NIST CSF 2.0 templates Eighteen templates, each labeled with the NIST CSF 2.0 subcategory it maps to (e.g. `PR.AA-03`, `DE.CM-01`). Several are the same underlying policy design as a CIS or general-default template, re-labeled for a NIST-based Baseline: | Template | Conditions (condensed) | Grant / session controls | Resolves / overlaps | | ------------------------------------------------------------- | ------------------------------------------------------------------------ | ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | MFA for Administrative Roles PR.AA-03 | Privileged admin roles, all apps | MFA | Same design as CIS 5.2.2.1 | | MFA for All Users PR.AA-03 | All users, all apps | MFA | Same design as CIS 5.2.2.2 / **User MFA**, **Admin MFA** | | Block Legacy Authentication PR.PS-04 | All users, legacy client app types | Block | Same design as CIS 5.2.2.3 / **Block Legacy Authentication** | | Block Device Code Sign-in Flow DE.CM-09 | All users, device code transfer method | Block | Same design as CIS 5.2.2.12 / `AUG.CIS.M365.5.2.2.12` | | Block Risky Countries GV.RM-01 | All users, Locations = a "Deny List — Blocked Countries" Named Location | Block | Same intent as **Risky Country Policy** (`riskycountries`) | | Phishing-Resistant MFA for Admins PR.AA-02 | Privileged admin roles, all apps | Authentication strength: phishing-resistant | Same design as CIS 5.2.2.5 / **Phishing-Resistant MFA for Highly Privileged Roles** | | Sign-in Frequency Non-Persistent Sessions for Admins PR.AA-01 | Privileged admin roles, all apps | Session: 4-hour sign-in frequency, never-persistent browser | Same design as CIS 5.2.2.4 / `AUG.CIS.M365.5.2.2.4` | | Sign-in Frequency for Intune Enrollment PR.AA-01 | All users, scoped to the Microsoft Intune app | Session: sign-in frequency = every time | Same design as CIS 5.2.2.11 | | Block Guest Access to Admin Portals PR.AA-05 | Guest/external users (non-Service-Provider), Microsoft Admin Portals app | Block | No CIS/general-default equivalent — a NIST-specific addition | | Idle Session Timeout Unmanaged Devices PR.PS-01 | All users, Office 365, browser, excludes compliant/hybrid-joined devices | Session: application-enforced restrictions | Same design as CIS 1.3.2 | | Identity Protection User Risk Policy DE.CM-01 | All users, user risk = High | Password change AND MFA | Same design as CIS 5.2.2.6 / *Require New Password When User Risk Is High* (`MT.1013`) | | Identity Protection Sign-in Risk Policy DE.CM-01 | All users, sign-in risk = Medium/High | MFA | Same design as CIS 5.2.2.7 | | Block High-Risk Sign-Ins DE.CM-09 | All users, sign-in risk = Medium/High | Block | Same design as CIS 5.2.2.8 / **Block Risky Sign-ins** | | Phishing-Resistant MFA for All Users PR.AA-02 | All users, all apps | Authentication strength: phishing-resistant | No CIS/general-default equivalent — extends phishing-resistant MFA beyond admins | | Managed Device Required for Authentication PR.AA-05 | All users, all apps | Compliant device OR domain-joined device | Same design as CIS 5.2.2.9 | | Managed Device Required to Register Security Info PR.AA-05 | All users, `registersecurityinfo` action | Compliant device OR domain-joined device | Same design as CIS 5.2.2.10 / **Register MFA from Managed Devices** | | Block Unsupported Device Platforms PR.PS-01 | All users, platforms = Linux/Windows Phone | Block | Narrower version of the general-default **Block Access for Unknown or Unsupported Device Platforms** (`MT.1015`), which excludes Android/Windows/macOS instead of listing unsupported platforms directly | | Require Compliant Device for Azure Management PR.PS-02 | All users, scoped to the Azure Management app | Compliant device | No CIS/general-default equivalent — narrows device compliance to the Azure management plane specifically | | Block High-Risk Users DE.CM-01 | All users, user risk = High | Block | Harder-line companion to *Require New Password When User Risk Is High*; blocks outright instead of allowing self-remediation | {% hint style="info" %} Every named admin-role condition above (in both the general and framework-specific templates) is scoped to Microsoft's own privileged-role template IDs — Global Administrator, Privileged Role Administrator, Security Administrator, Conditional Access Administrator, Exchange/SharePoint/Application/Cloud Application Administrator, Password Administrator, Helpdesk Administrator, Privileged Authentication Administrator, and similar — not a client-specific group you have to populate yourself. {% endhint %} ## Building your own template: the full field surface The condition and grant-control fields available when you build or edit a template mirror Entra's own Conditional Access object model field-for-field. This is the same vocabulary summarized on the main [Conditional Access](/modules/secure/conditional-access.md) page, expanded here to the level of detail you'll need while actually filling in the wizard or the JSON editor. ### Conditions * **Users, groups, and roles** * Include/exclude specific users, specific groups, or specific directory roles (e.g., a built-in Entra role like Global Administrator, not a custom Augmentt concept). * A dedicated **guests and external users** include/exclude, further broken down by external-user *type* — internal guest, B2B collaboration guest, B2B collaboration member, B2B direct connect user, other external user, and **service provider** (used to exempt your own MSP's GDAP/delegated-admin technicians) — and by which external tenants count, via a membership-kind filter. * **Applications** * Include/exclude specific cloud apps by application ID, or Microsoft's built-in groupings — **All**, **Office 365**, **Microsoft Admin Portals** — plus specific first-party app IDs such as Microsoft Intune Enrollment, Azure Windows VM Sign-In, and Azure Management. * Instead of an app list, a policy can instead be scoped to a **user action** — Augmentt's default templates use `urn:user:registersecurityinfo` (registering MFA/security info) as the way to target that specific flow rather than a normal application. * **Authentication context** (`includeAuthenticationContextClassReferences`) can further scope a policy to a specific sensitive operation an app has tagged, independent of the app itself. * **Client app types** — Browser, Mobile apps and desktop clients, Exchange ActiveSync clients, Other clients (the legacy-protocol bucket), or **all**. * **Device platforms** — Include/exclude by platform: Android, iOS, Windows, macOS, Windows Phone, Linux, or **all**. * **Devices (filter)** — A device-attribute filter expression (the same rule syntax Entra itself uses, e.g. `device.trustType -ne "ServerAD" -or device.isCompliant -ne True`), evaluated in **include** or **exclude** mode, for scoping by device attributes finer than platform alone. * **Locations** — Include/exclude by [Named Location](/modules/secure/conditional-access.md), plus Microsoft's built-in **All trusted locations** and **unrecognized/unmapped countries**. * **User risk levels** and **sign-in risk levels** — Low, Medium, High, individually selectable (requires Entra ID P2 for the underlying Identity Protection signal). * **Insider risk** — Scoping by a Microsoft Purview Insider Risk Management risk level, where that's licensed. * **Authentication flows / transfer methods** — Currently exposed for the **device code flow**, letting a policy target that specific sign-in method directly. ### Grant controls * **Block access** — the hardest control; overrides everything else when it matches. * **Require multifactor authentication** — Microsoft's standard MFA control. * **Require authentication strength** — instead of plain MFA, require sign-in to satisfy a named authentication strength. Augmentt's templates reference Microsoft's two built-in strengths by ID: **Multifactor authentication** (`00000000-0000-0000-0000-000000000002`) and **Phishing-resistant MFA** (`00000000-0000-0000-0000-000000000004`, i.e. FIDO2, Windows Hello for Business, certificate-based auth) — custom authentication strengths defined in the tenant can be referenced the same way. * **Require device to be marked as compliant** (Intune) and **require Hybrid Azure AD joined device** (domain-joined) — usable individually or together. * **Require password change** — forces a password reset as a grant control, typically combined with an authentication-strength requirement (as in the "New Password When User Risk Is High" templates). * **Operator** — when more than one grant control is selected, **AND** requires all of them, **OR** requires any one of them. ### Session controls Session controls aren't full first-class form fields the way conditions and grant controls are, but the templates above show the shapes Augmentt does support setting directly: * **Sign-in frequency** — a time-based interval (e.g., every 1 hour, every 4 hours) or **every time**, applied to primary-and-secondary authentication. * **Persistent browser session** — set to **never**, preventing the browser from retaining the session after it's closed. * **Application-enforced restrictions** — hands session limits off to the app itself (e.g., Office 365's own reduced-functionality mode for unmanaged devices) rather than Entra enforcing a timer. {% hint style="info" %} Anything beyond these three shapes — continuous access evaluation toggles, Microsoft Defender for Cloud Apps session controls, secure sign-in session, disabling resilience defaults — still isn't a dedicated Augmentt form field. Set it through the raw JSON editor on the Template or Edit screen the same way you would for any other unsupported field; it edits the same policy object Microsoft Graph accepts. {% endhint %} --- # 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/default-policy-templates.md?ask=&goal= ``` `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.