Collection

Expanded Definition

In NHI and secrets governance, a collection is a shared access boundary that groups vault items so multiple users can collaborate without individually duplicating records. It is not a credential itself, and it is not the same as delegation, which grants a person authority over an identity or workload. The control value lies in separating item ownership from access management, so an organisation can review membership, apply role-based access control, and revoke visibility without touching the underlying secret or record.

Definitions vary across vendors, but the operational meaning is consistent: a collection should function as an access container with explicit membership rules, auditable change history, and scoped permissions. That makes it useful for shared admin workflows, team-based secret storage, and structured access review. It also fits naturally with the governance expectations described in the NIST Cybersecurity Framework 2.0, where access control and asset protection must remain reviewable over time. The most common misapplication is treating a collection as a substitute for least privilege, which occurs when broad group membership is used to avoid defining item-level access boundaries.

Examples and Use Cases

Implementing collections rigorously often introduces administrative overhead, requiring organisations to balance collaboration speed against the cost of membership governance and periodic review.

• A platform team places production API keys in a collection so on-call engineers can retrieve them during incidents while access remains limited to the team roster.
• A security team uses a collection for shared vendor credentials, then removes a contractor’s membership immediately after offboarding instead of rotating unrelated items.
• A compliance group stores audit-related records in a collection with tightly scoped editors, preserving collaboration without exposing unrelated vault items.
• An IAM team maps each collection to a business function and reviews the membership changes alongside the guidance in the Ultimate Guide to NHIs to reduce accidental over-sharing.
• A DevOps team separates staging and production secrets into different collections so a build engineer can work in one environment without inheriting access to the other.

Collection design is also shaped by the broader identity architecture in NIST Cybersecurity Framework 2.0, especially when organisations need to prove who could access a secret and when that access changed.

Why It Matters in NHI Security

Collections matter because NHI risk often begins with shared access that is too broad, too persistent, or too hard to unwind. When a collection is used as a convenience layer without governance, it can hide excess privilege, mask stale membership, and make revocation incomplete. That is especially dangerous in environments where secrets are already widely exposed: NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, and 96% of organisations store secrets outside secrets managers in vulnerable locations, creating a strong incentive to control how shared containers are structured and reviewed.

The same source, Ultimate Guide to NHIs, also notes that 73% of vaults are misconfigured, which means a collection can become a multiplier for misconfiguration if its permissions are inherited too broadly. Used well, collections support Zero Trust by shrinking default visibility and making access revocation precise; used poorly, they become a convenient path to unauthorized exposure. Organisations typically encounter this consequence only after a secret leak, contractor exit, or incident review, at which point collection governance becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When does just-in-time access help most in DORA evidence collection?
• How can organisations reduce manual effort in access certification and evidence collection?
• Why do tags matter in SOC 2 evidence collection?
• Who should own SOC 2 evidence collection and remediation?