> 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/entra-id/security-groups.md). # Security Groups A Security group is the other Entra ID group type Augmentt manages under **Secure > Entra ID**. Unlike an M365 group, it has no mailbox, calendar, SharePoint site, or Team attached — it exists purely as an access-control and policy-scoping container. Security groups are what Conditional Access, Intune, Defender, and Entra ID role assignments are typically scoped against. {% hint style="info" %} If the group needs its own mailbox or to act as a collaboration surface (shared inbox, Teams, SharePoint site), use an [M365 group](/modules/secure/entra-id/m365-groups.md) instead. Reach for a Security group whenever the group's only job is to be a membership list you point policies or role assignments at. {% endhint %} ## When to use Security vs. M365 | | Security group | M365 group | | ---------------------------------------------------- | -------------------------------------------------- | --------------------------------------------------------- | | Has a mailbox / group email | No | Yes | | Can be nested inside another group as a member/owner | Yes | No | | Typical use | Policy/access scoping (CA, Intune, Defender, RBAC) | Collaboration surface (shared mailbox, Teams, SharePoint) | | Can be role-assignable | Yes | Yes | ## Configuration surface Everything below is set on **Secure > Entra ID > Groups > Add Group(s) > Create New**, with **Security** selected as the type. It's the same form as M365 groups minus the email/domain fields, plus one extra capability: * **Name** (required, up to 120 characters) — the group's display name. * **Description** (optional, up to 1024 characters). * **Role assignment** — a toggle that makes the group role-assignable, so it can later be granted a Microsoft Entra ID directory role. **This can't be changed after the group is created.** Security groups are already security-enabled by definition, so this toggle doesn't change any other underlying property the way it does for M365 groups. * **Owners** and **Members** — picked from the tenant's users, **or another Security group**. This is the one capability M365 groups don't have: a Security group can nest another Security group as a member or owner, letting you build layered access groups (e.g. a regional group nested inside a company-wide group). This nesting option is not offered for M365 groups. * **Roles** — appears only if role assignment is on; pick which Entra ID directory roles the group is assigned. No group email or domain fields appear for Security groups — Augmentt's backend generates an internal mail nickname behind the scenes for Graph API purposes, but there's nothing to configure or review for it, and it isn't shown to you. Membership type is always **Assigned** — Augmentt doesn't create Security groups with dynamic membership rules. (An existing dynamic-membership Security group created outside Augmentt, or by a specific compliance check — see below — still shows up in the Groups list with its membership type labeled accordingly; you just can't create new dynamic groups, or convert one to dynamic, from this page.) ### Editing **Edit** on a Security group lets you change its name, description, owners, and members (including nested groups). There's no email/domain to edit. Group type, membership type, and role-assignment status are fixed after creation. ### Deleting **Delete** removes the group from the tenant. If you were a member yourself, you lose your own access as part of the same action — Augmentt asks you to confirm before deleting. If other groups are nested inside it, they're unaffected; only the membership relationship is removed. ## Templates and baselines Security group templates work the same as M365: capture one from an existing group (**Templates > Create New > Template**, pick tenant → Security type → the specific group). Only structural settings are captured — security-enabled flag, membership rule, and the role-assignable flag; owners, members, and any nested-group relationships are **not** part of the template and are picked fresh on every deployment. {% hint style="info" %} **Augmentt does not ship any built-in/default Security group templates** for the ordinary Create New > Template / From Template flow — every template in your library comes from a group you (or a teammate) captured from a real tenant. The one notable exception: Augmentt's CIS M365 (V6) compliance content ships a specific, pre-built **dynamic-membership Security group template** — "Ensure a dynamic group for guest users is created" — used to remediate that CIS control. It's a `DynamicMembership` group (guest users only, `membershipRule: (user.userType -eq "Guest")`), applied through the posture/compliance workflow when you action that CIS setting, not picked from the regular Groups > Templates gallery. It's the one case where Augmentt does provide a canned group definition out of the box, and it's specifically a Security group. {% endhint %} ## Downstream capabilities unique to Security groups * **Nesting** — a Security group can contain another Security group as a member (or owner). M365 groups can't be nested into, or nest, anything. * **Role assignability** — both types support it, but because role-assignable groups must be security-enabled, a role-assignable M365 group is quietly promoted to security-enabled behind the scenes at creation; a Security group already satisfies that requirement natively. * **Policy/RBAC scoping** — Conditional Access, Intune, and Defender policies, along with Entra ID directory role assignments, are conventionally scoped to Security groups. This is why the product's own guidance treats Security groups as "the" group type for making CA/Intune/Defender consistent across clients. ## Posture-check / compliance mapping Entra ID Groups has **no dedicated posture check of its own** — there's no "are your Security groups well-formed" item in Secure Score. Where Security groups do surface in posture/compliance is indirect, as the object a check needs you to designate or verify, not as something the check evaluates on its own terms. Two concrete examples found in the product: * **CIS M365 (V6) — 5.1.3.1, dynamic guest group**: the CIS L1 posture template's remediation for "ensure a dynamic group for guest users is created" deploys the dynamic Security group template described above. The posture setting here is really "did you apply this group," not a property of groups in general. * **CIS M365 (V6) — 5.1.3.2, restrict who can create security groups**: a separate CIS L1 setting ("Users can create security groups in Azure portals, API or PowerShell" → should be **No**) checks a *tenant-level* Entra ID setting about who is allowed to create Security groups — it doesn't inspect any Security group Augmentt itself creates. * **SharePoint external sharing restricted by security group** (check key `sharepointexternalsharingsecuritygroup`, used in CIS M365 V6 and CIS v8 assessments): this check passes only when SharePoint/OneDrive external sharing is limited to specific, named Security groups you designate in its configuration — it directly depends on you having a Security group (created however you like, including via Entra ID > Groups) to point the setting at. In short: Entra ID Groups isn't itself scored, but plenty of Conditional Access, Intune, Defender, and compliance-assessment settings elsewhere in Secure assume you have the right Security group(s) already built to scope them against — that's the main reason to keep Security groups standardized across clients via templates and baselines. --- # 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/entra-id/security-groups.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.