Group-member-set is a DAV property that stores the membership list for a group principal. In delegation workflows it determines who inherits access rights from the group. Because it directly affects authorization, updates to this property require strong ownership checks, otherwise an attacker may add themselves and gain unintended access.
Expanded Definition
Group-member-set is the property that records which principals belong to a DAV group principal, and therefore which identities inherit the group’s permissions in a delegation or authorization model. In practice, it functions as the source of truth for membership-driven access, so changes to the property can immediately alter who can read, write, or administer protected resources. Within NHI and IAM operations, this makes the property closer to an authorization control plane artifact than a simple directory field.
Definitions are stable at the protocol level, but implementation patterns vary across vendors and WebDAV deployments. Some systems treat the membership list as directly editable, while others proxy changes through administrative workflows or directory synchronization. For governance purposes, the key distinction is between the membership record itself and the policy outcomes that follow from it. The WebDAV specification defines the property in protocol terms, while enterprise access programs often map it to privileged group management and delegated entitlement review. The most common misapplication is allowing low-trust or self-service processes to update the property directly, which occurs when ownership checks are missing or weak.
Examples and Use Cases
Implementing group-member-set rigorously often introduces administrative friction, requiring organisations to balance fast collaboration against strict membership governance and review.
- A delegated application owner maintains a project access group, and the group-member-set property determines which service accounts inherit deployment permissions.
- An enterprise WebDAV repository uses the property to control who can modify shared documents, with membership changes audited against a central directory.
- A federation bridge syncs membership from an external identity source, but the authoritative write path remains restricted to prevent self-addition or privilege escalation.
- An incident response team reviews group-member-set changes after an anomalous access event, comparing the property history against approved join and leave requests.
- A platform team aligns membership updates with NIST Cybersecurity Framework 2.0 access governance practices and the broader NHI lifecycle guidance in Ultimate Guide to NHIs.
In mature environments, the property is reviewed alongside group ownership, change approval, and downstream entitlement impact rather than treated as an isolated directory attribute.
Why It Matters in NHI Security
Group-member-set matters because it is an authorization leverage point. If attackers can add an NHI, automation token, or compromised service account to a privileged group, they may inherit broad access without ever breaking a password or token directly. That makes the property especially important in systems where machines delegate to machines, where group membership often substitutes for human approval. NHI governance failures frequently begin with poor visibility into who belongs where; NHIMG research notes that only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges, conditions that make unauthorized membership changes especially damaging in practice. The same risk pattern is documented in the Ultimate Guide to NHIs.
Because membership changes can cascade into inherited access, defenders need strong ownership checks, change logging, and periodic recertification tied to actual business need. The control concern is not only who is in the group today, but who can alter the list and under what trust boundary. Organisational exposure usually becomes visible only after an unexpected privilege expansion or lateral movement event, at which point group-member-set review becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Membership-bearing NHI group objects can enable privilege escalation if change control is weak. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access depends on accurate, governed group membership and entitlement assignment. |
| NIST Zero Trust (SP 800-207) | AC-2 | Zero trust relies on continuously validated group and policy assignments for access decisions. |
| NIST SP 800-63 | Identity assurance guidance informs how strongly membership updates should be authenticated and authorized. | |
| OWASP Agentic AI Top 10 | A2 | Autonomous or tool-using agents can abuse group membership paths to gain broader execution authority. |
Require strong authentication and administrative validation before changing protected group membership.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
