entra id group ownership governance: Owners and expiry

What Is Entra ID Group Ownership Governance?

Entra ID group ownership governance starts with an access question: who can change the people admitted through a group, and who remains accountable when its purpose changes? Microsoft distinguishes object ownership from directory roles. A group owner can manage their own group's properties, owners and membership; manual member additions and removals apply to Assigned membership. Ownership does not give that person management rights over every group. Microsoft Learn: default user permissions.

That authority matters when a group controls a real resource. Microsoft documents enterprise application assignments through groups, with access for users in the assigned group and no cascade to nested groups. Group-based application assignment requires Entra ID P1 or P2. The operational inference is straightforward: someone able to change that group's membership can change the population receiving its assigned application access. First establish the actual application assignment; ownership of an unrelated group proves no such access. Microsoft Learn: assign users and groups to applications.

For a Microsoft 365 group connected to a SharePoint team site, owners become site owners and members become site members. SharePoint can also hold permissions separately from the connected group. Your review should therefore record both the group relationship and the site's other grants. Removing a group member is insufficient evidence that every independent route into a site has disappeared. Microsoft Learn: SharePoint sharing and permissions.

This guide separates six review signals: a guest owner, no owner, no members and no parent, Public visibility, missing tenant-wide expiration coverage, and a large collected membership. They answer different questions. None establishes a compromise, a tenant-wide administrative role, or a business decision to delete a group. The precise EtcSec predicates appear below with their source locations.

How Ownership, Guest Settings and Expiration Work

Guest ownership is conditional

For Microsoft 365 groups, the Group.Unified setting AllowGuestsToBeGroupOwner controls whether a guest can be an owner. AllowGuestsToAccessGroups concerns access to groups and their data; AllowToAddGuests concerns guest membership. Treat these as separate decisions rather than reading one setting as permission for all three operations. The settings overview identifies the Microsoft 365 scope and the P1 licensing requirement for the ownership setting. Microsoft Learn: group settings.

Microsoft's configuration reference gives AllowGuestsToBeGroupOwner a default of False. A tenant is not automatically open to Microsoft 365 guest owners simply because it supports collaboration. Inspect the effective configuration and the actual ownership assignment together. When there is no customized settings object, consult the template defaults rather than interpreting an absent object as permission. Microsoft Learn: configure group settings.

Do not extrapolate this Group.Unified control into a blanket rule for all security groups. Graph separately documents adding users or service principals as owners of Microsoft 365 or security groups. For a Teams-backed group, owner synchronization can take up to two hours, and some team changes also require the owner to be a member. Microsoft Learn: add group owners.

Guest restrictions also affect the available management experience. Under restricted guest permissions, My Apps does not expose the list of groups a guest owns or belongs to. SharePoint and Teams retain their own guest controls. An observed owner relationship is therefore a review signal, not proof that every management action succeeds through every interface. Validate the specific operation and service in an authorized test environment. Microsoft Learn: restrict guest permissions.

Consider an illustrative exposure: an Assigned group grants access to a project application, and a guest is an authorized owner. A membership change could alter access to that application if the relevant operation is allowed. This is an inference from documented ownership and application assignment, not an observed incident or a demonstrated escalation to Global Administrator. Document the resource and applicable restrictions before treating the scenario as an actionable access path. Ownership permissions, application assignment.

Ownerless, empty and unused are different states

A group can have members without an owner. Another can have an owner without members. A third may be empty but still needed for a planned workflow. Keep ownership, membership, parent relationships and business purpose in separate review fields. The collector's group-no-owner.go:37 examines owners; group-orphaned.go:39 examines members and parents. Neither function measures business need.

Microsoft's ownerless policy applies to Microsoft 365 groups and is available only in public clouds. It sends actionable invitations to eligible members to accept ownership, with configurable notification duration and eligibility through security groups. It is a recovery workflow requiring member acceptance, not an automatic assignment of accountability. Microsoft Learn: ownerlessGroupPolicy resource.

If nobody accepts during the notification period, notifications stop and administrators must find and assign an owner. Microsoft's admin guide also documents licensing and mailbox prerequisites for notifications. Include that unresolved queue in the operating procedure; enabling the policy alone is not evidence that all ownerless groups have acquired responsible owners. Microsoft Learn: manage ownerless groups and teams.

Expiration covers Microsoft 365 groups

An expiration policy applies to Microsoft 365 groups, not every security group. Active groups can renew automatically near expiry through documented Outlook, SharePoint, Teams or Viva Engage activity. Groups that are not renewed are deleted, with a 30-day restoration period. A long-lived group might therefore be repeatedly renewed under a valid policy. Its age alone does not prove missing expiration coverage. Microsoft Learn: Microsoft 365 group expiration.

The groupLifecyclePolicy resource separates lifetime from coverage: groupLifetimeInDays defines the renewable interval, while managedGroupTypes is All, Selected or None. Selected requires checking the particular group's inclusion. alternateNotificationEmails supplies notification addresses for groups without owners. Treat a renewed expiration date as lifecycle evidence, not as a business attestation. Microsoft Learn: lifecycle policy resource.

Public visibility deserves a resource review

Microsoft describes Public as allowing users to join without owner permission, while Private requires it. Private membership is not automatically hidden; HiddenMembership is a separate value. Public group visibility should trigger a review of intended admission and connected resources. It is not, by itself, proof of anonymous Internet access or successful data retrieval. Microsoft Learn: group visibility options.

Detection: Measure the Directory Before Interpreting Findings

The following blocks copy request syntax or examples from Microsoft Learn. Relative paths belong to the Graph v1.0 documentation. Braced identifiers must be resolved to actual objects; the fixed identifier in the count example is Microsoft's sample. No request here was executed against a tenant. Preserve request scope, collection failures and pagination alongside the resulting inventory.

1. Establish group type and collection scope

Microsoft's List groups page provides this Microsoft 365 filter verbatim:

GET https://graph.microsoft.com/v1.0/groups?$filter=groupTypes/any(c:c+eq+'Unified')

Use it for the Microsoft 365 inventory, not as the entire security-group review. The same page documents default and maximum page sizes of 100 and 999, plus replication delays after changes. Follow every returned @odata.nextLink; a single page or a recently stale result should not close a finding. Microsoft Learn: list groups.

For each selected group, the documented Get group syntax is:

GET /groups/{id}

The API supports $select for specific properties. Preserve group ID, membership type and synchronization state in the review record, and retain the raw response so missing attributes remain distinguishable from negative answers. Microsoft Learn: get group.

The current v1.0 group resource documents groupTypes containing Unified for Microsoft 365 groups and expirationDateTime as their policy-defined expiry timestamp. That date is null for security groups. Do not report a security group's null date as an uncovered Microsoft 365 lifecycle finding. Microsoft Learn: group properties.

2. Inspect owners and resolve their identity type

Read the owner relationship using Learn's syntax:

GET /groups/{id}/owners

The relationship can contain users or service principals. Graph does not expose owners for groups created in Exchange, distribution groups or groups synchronized from on-premises. The v1.0 page also documents missing service principal owners and limited-information objects when the caller cannot read a resource type. In those objects, attributes can be null while the ID and type remain available. Follow pagination and retain unresolved identities; missing attributes cannot establish that a group lacks owners or that an owner is a guest. Microsoft Learn: list owners.

Resolve user owners explicitly and inspect the collected userType. Microsoft's Get user API supports selecting non-default properties; the default-permissions reference distinguishes Member and Guest users. Do not substitute email domains or #EXT# strings for the identity attribute, and do not infer compromise from a Guest classification. Microsoft Learn: get user, user types.

If you use an advanced owner-count filter during investigation, apply the documented ConsistencyLevel: eventual and count requirements. Advanced queries use a separate index and do not support combining these relationship filters with $expand. Keep an ownerless candidate list separate from confirmed per-group owner reads. Microsoft Learn: advanced query capabilities.

3. Verify members, size and direct parents separately

Learn supplies the direct-members request:

GET /groups/{id}/members

Its count example is:

GET https://graph.microsoft.com/v1.0/groups/02bd9fd6-8f93-4758-87c3-1fb73740a315/members/$count
ConsistencyLevel: eventual

These are direct directory objects, not a transitive count of distinct people. The members API documents a v1.0 service principal omission, and hidden membership requires Member.Read.Hidden. For validation, enumerate all pages and deduplicate IDs; record restrictions rather than presenting an incomplete list as a complete membership total. Microsoft Learn: list members.

Read the parent relationship in a separate request:

GET /groups/{id}/memberOf

The API returns direct memberships rather than a transitive graph. Its response can include groups, administrative units or administrative roles depending on the group type. Identify the returned object types when confirming parent groups. An unsuccessful relationship read is not a successful zero result. Microsoft Learn: list memberOf.

4. Read the lifecycle and ownership policies

Copy the lifecycle-list example:

GET https://graph.microsoft.com/v1.0/groupLifecyclePolicies

The API documents Directory.Read.All for delegated or application access. Retain the returned coverage mode and compare it with the intended policy. A Selected response calls for checking the selected group set; a policy object's existence alone does not establish coverage of every group. Microsoft Learn: list lifecycle policies, coverage properties.

Read tenant-level settings using the documented example:

GET https://graph.microsoft.com/v1.0/groupSettings

Inspect Group.Unified and its values rather than treating the whole response as a Boolean. Learn lists GroupSettings.Read.All as the least privileged read permission and explains the additional user-role requirements for delegated calls, including the different behavior with delegated directory-wide read permissions. Microsoft Learn: list group settings.

When customized settings are absent, the settings overview provides this template request:

GET https://graph.microsoft.com/v1.0/groupSettingTemplates

Use the documented template defaults to interpret the absent custom object. Do not read absence as guest ownership being enabled. Microsoft Learn: group setting templates and defaults.

Finally, read the ownerless policy with its Learn example:

GET https://graph.microsoft.com/v1.0/policies/ownerlessGroupPolicy

This endpoint supports delegated Group.Read.All, with a calling user assigned Groups Administrator or Exchange Administrator. Application permission is not supported. A documented 404 indicates that the policy does not exist; an authorization failure needs a different interpretation. Do not promise that an application-only collector can inspect this policy through the same endpoint. Microsoft Learn: get ownerlessGroupPolicy.

How EtcSec Detects This

The following descriptions come from static inspection of etc-collector commit b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c. File locations are relative to public/internal/audit/detectors/. These are implementation criteria, not tenant measurements.

Collection limits change the next validation step

For NO_EXPIRY, unprobed configuration returns an Info finding labeled not determinable, with Count=1. That value is not one uncovered group. The function does not inspect activity, expirationDateTime or a lifetime threshold. A Selected policy can be legitimate even while this implementation flags its Unified groups; confirm actual coverage before describing those groups as never expiring. Source: unified-group-no-expiry.go:43 and :56.

The current Azure provider assigns the same member-ID list to both Members and Member. LARGE then adds both lengths. On that successful path, with complete collection and no duplicate IDs, 2 × n > 500 becomes n > 250: 250 does not pass, 251 does. This is arithmetic from code, not a tenant or Go test result. 500 is the detector's written threshold, not a Microsoft group-size limit. Sources: public/internal/providers/azure/client.go:1115, group-large-membership.go:29.

The provider does populate MemberOf, despite an obsolete comment in ORPHANED claiming otherwise. It stores IDs from the direct memberOf response without filtering their object type, so a recorded parent is not necessarily another group. Microsoft Learn: memberOf object types.

Member and parent failures lack the owner probe marker's explicit success/failure distinction. That marker does not guarantee complete owner data: owner enrichment stores UPN or display name and drops an object when both are absent, even after a successful response. It has a five-minute budget and does not follow owner pagination in this code path. A group limit can also return before enrichment. Review collection warnings and raw relationships before trusting zero counts. Sources: public/internal/providers/azure/client.go:1142, :1158, :1170, :1184, :1235, :1253, :1264, :1345.

Remediation: Restore Accountability and Verify Access

1. Attest ownership before changing grants

Our recommended starting point is a resource-based review: record purpose, accountable internal sponsor, assigned apps or connected sites, current owners, approved exceptions and the authority responsible for membership. Ask the resource owner to confirm whether the group is still needed. For continuing groups, assign responsible owners before removing obsolete ownership.

Microsoft documents the admin-center path Entra ID → Groups → All groups → select group → Owners → Add, and removal through the Owners list. Use the documented role requirements and preserve before/after relationships. For Teams-backed groups, include the membership and synchronization requirements described earlier in acceptance checks. Microsoft Learn: manage owners, Graph owner addition.

2. Restrict guest ownership deliberately

For Microsoft 365 groups whose policy requires internal ownership, retain or restore AllowGuestsToBeGroupOwner=False in Group.Unified. Review existing guest ownership separately instead of assuming a configuration change proves every existing relationship has disappeared. Preserve other settings when updating the object; Microsoft's configuration guide specifically instructs reading current values to avoid overwriting unrelated configuration. Re-read both settings and owners after the change. Microsoft Learn: configure group settings.

Document exceptions with a sponsor and a review date. Review the guest identity's invitation, authentication and lifecycle separately using the guest account attack-surface guide, which covers invitation permissions, MFA and stale accounts. Those identity controls complement ownership review; they do not replace group lifecycle policy.

3. Operate the ownerless recovery queue

In the Microsoft 365 admin center, enable the ownerless workflow under Settings → Org settings → Microsoft 365 Groups, then configure eligible recipients, sender, notification period and target groups. Verify supported licenses and Exchange Online mailboxes: the sender needs a user or group mailbox, shared sender mailboxes are unsupported, and recipients need user mailboxes. Track accepted ownership and escalate groups still unresolved when notifications end. The documented workflow leaves final manual assignment to administrators when nobody accepts. Microsoft Learn: ownerless policy configuration.

4. Configure expiration against real dependencies

Choose lifetime and All or Selected coverage after reviewing application and collaboration dependencies. Entra's expiration settings also support an alternative notification address for ownerless groups. Licensing requires possession of P1 or P2 licenses for members of the groups to which expiration applies. Confirm renewal handling before treating deletion as an intended outcome. Microsoft Learn: expiration configuration.

Re-read lifecycle policy and per-group expiry evidence. For Selected coverage, maintain evidence of which groups are included. Keep group expiry, content retention and guest-account offboarding as separate decisions; a lifecycle policy describes a renewable group lifetime, not all three outcomes. Microsoft Learn: lifecycle policy definition.

5. Review admission and large membership

For Public groups, ask whether admission without owner permission matches the resource's audience. Where approval is required, review Private visibility and verify effective service permissions separately. For LARGE findings, first obtain a deduplicated direct-member inventory, then review why each population needs access. Split responsibilities or access groups where the business review supports it; do not remove members merely to clear the implementation's numeric predicate.

Keep privileged group structure as a separate investigation. The nested privileged and role-assignable group article addresses that topic. Follow its subject boundary without importing a role-elevation claim into this ownership review.

6. Make membership reviews produce a decision

Create reviews with named reviewers, fallback reviewers where group owners are selected, an explicit non-response outcome, and a decision about automatic application of results. Learn documents fallback handling for ownerless groups and warns that non-response removal with automatic application can revoke resource access. An ownerless group's members do not inevitably retain access after a review: their outcome depends on these settings and application of decisions. Verify the current Governance or Suite licensing requirements for the chosen review. Microsoft Learn: create access reviews.