Seed Groups

What Seed Groups Do in Identity Governance

Seed groups are a bootstrap mechanism, not a steady-state access model. They give a small, trusted set of accounts the initial rights needed to establish administration, populate directories, and begin assigning access through nested groups or role mappings before broader governance rules are fully in place.

Because they sit at the start of the access lifecycle, seed groups are usually temporary in intent even when they persist in practice. Their design should make the handoff from initial setup to normal access governance explicit, so the first privileged memberships do not become the default path for long-term entitlement growth.

How Seed Groups Shape Privilege Assignment

In practice, seed groups often determine who can create roles, approve memberships, connect applications, or define entitlement rules. That makes them an early control point for authorization design, because the permissions granted to the seed set influence every downstream group relationship that follows.

This is why seed groups are different from ordinary access groups. They are usually small, tightly controlled, and functionally upstream of the permissions model. If they are too broad, they can become a shortcut that bypasses the intended structure of role-based access or entitlement governance.

Why Seed Groups Matter for Application Authorisation

For applications, seed groups are often the first trustworthy input that allows the authorisation model to come online. They may be used to grant initial admin access, establish approval paths, or map the first users into application-specific roles before automated joiner-mover-leaver processes and steady-state rules are mature.

That early dependency is useful, but it also means the application can inherit whatever mistakes were made during bootstrap. A poorly designed seed group can lock in excessive privilege, create hidden admin paths, or leave the application dependent on manual group maintenance long after go-live.

Seed Groups in a Mature Access Model

A mature access model treats seed groups as a transition state. Once the environment is established, they should no longer be the mechanism that carries normal business access, because ongoing access should flow through governed roles, entitlement rules, and periodic review rather than through a privileged bootstrap set.

The key design question is whether the seed group still has a necessary operational purpose. If it does, its scope should remain narrow and observable. If it does not, the group should be retired or neutralised so it does not remain an unmonitored path into privileged administration.

Risk and Threat Considerations

Seed groups concentrate early privilege, so any weakness in their membership, lifecycle, or review process can create a high-impact access path. They are especially risky when they are left in place after bootstrap, because inherited memberships and nested group relationships can silently expand authority over time.

Failure mechanism: An attacker or careless administrator obtains or retains seed-group membership, then uses that trust to create broader access, approve additional memberships, or alter role mappings before the drift is noticed.

Impact: Excessive or hidden privilege can spread through the directory or application model, making it harder to detect abuse, harder to unwind access, and easier for compromised accounts to reach sensitive systems.

Practitioner Guidance

Why practitioners should care: Seed groups should be treated as a controlled bootstrap mechanism with a clear end state, not as a convenient permanent admin layer. If their purpose is not time-bound, they often become a quiet source of privilege creep and governance debt.

Governance implication: Define who owns each seed group, what authority it grants, when it is allowed to exist, and what event closes it out. In most environments, that means making the transition from bootstrap access to normal entitlement governance a documented control point rather than an informal handoff.

Related resources from NHI Mgmt Group

• What breaks when Azure Entra nested groups are synced through SCIM?
• Why do nested groups complicate enterprise access governance?
• How can security teams tell whether missing access is caused by nested groups or something else?
• What is the best way to handle nested groups in Directory Sync?