Bitwarden collections show how granular access control scales

At a glance

What this is: Bitwarden describes collections as a way to share sensitive items with granular, non-inherited access controls across teams.

Why it matters: It matters because IAM and security teams need controls that scale across human users, shared credentials, and delegated administration without creating privilege creep or accidental overexposure.

👉 Read Bitwarden's analysis of collection-based access control for shared vault items

Context

Collections are a shared-access model for vault items, but the governance problem is broader than convenience. Once credentials, cards, and other sensitive items are shared across teams, the question becomes who can create, move, delete, and manage access without expanding the blast radius.

That is the same lifecycle issue IAM teams face across human identity, NHI, and delegated administration. The control challenge is not just who can see a secret today, but how access is assigned, reviewed, revoked, and prevented from drifting over time.

Key questions

Q: How should teams prevent privilege creep in shared vault collections?

A: Use separate permissions for viewing, editing, managing membership, and deleting collections. Then recertify those rights on a regular access review cycle so that convenience does not turn into standing authority. The key control is to keep management rights narrow enough that shared access stays intentional, not accumulated by default.

Q: Why do nested collections create governance risk if access is inherited automatically?

A: Automatic inheritance turns a tidy folder structure into an implicit authorisation rule, which can expose more sensitive items than intended. When project teams change or expand, inherited access often survives longer than the business need. Non-inherited access forces explicit approval for each level and reduces accidental overexposure.

Q: How do collection management settings affect delegated administration?

A: They determine whether admins and owners can create, delete, and manage all collections or only the ones they are explicitly assigned to. If those settings are too broad, delegated administration becomes a source of excess privilege. The safest model gives enough authority to operate, but not enough to reshape access without oversight.

Q: Who should own collection access when multiple teams share sensitive items?

A: Ownership should sit with the smallest role that can safely manage the collection, usually a team lead or designated admin rather than every member. That person should be accountable for membership changes, deletion rights, and periodic review. Shared access works best when ownership is clear and bounded.

Technical breakdown

Granular collection permissions and least privilege

Bitwarden’s collections model separates item membership from collection membership, then layers group and individual permissions on top. That structure supports least privilege because access can be scoped to the collection, the item, and the management action independently. In practice, this is the difference between sharing data and delegating control over that data. A team can read a credential without being able to change its membership or delete it. The security value depends on whether permission boundaries remain clear when organisations scale from a few shared vault items to many overlapping teams.

Practical implication: map every collection permission to a business role and verify that manage, edit, and delete rights are not bundled by convenience.

Nested collections and non-inherited access

Nested collections are useful because they prevent access from flowing automatically into subcollections. In governance terms, that means a folder hierarchy does not become an implicit authorisation rule. This matters because inheritance is where accidental overexposure often starts: a project folder may look organisationally tidy while quietly granting more access than intended. Non-inheritance forces explicit access decisions for each subcollection, which is safer when teams share functions but not projects. The model is especially relevant where the same user base participates in multiple initiatives with different sensitivity levels.

Practical implication: require explicit approval for each nested collection instead of assuming parent access should cascade.

Collection management settings and delegated administration

The management toggles described in the article separate who can create, delete, and manage collections from who simply uses them. That is a governance control, not just a product setting, because it determines how much authority can be delegated to admins, owners, and team leads. When organisations allow self-service creation or broad deletion rights, they trade operational speed for greater risk of sprawl and accidental removal. The best use of delegation is bounded administration: enough authority to keep work moving, but not enough to expand the scope of sensitive access unnoticed.

Practical implication: restrict creation, deletion, and membership changes to the smallest set of roles that can operate the programme safely.

NHI Mgmt Group analysis

Collections expose the real governance problem: shared access is easy, but controlled delegation is hard. Bitwarden’s model shows that modern access control is no longer just about granting visibility to a secret. It is about separating use, management, and deletion so that collaboration does not turn into uncontrolled privilege growth. For IAM teams, this is a reminder that the governance surface is the delegation model, not the vault alone.

Non-inherited access is a deliberate control, not a convenience feature. Nested collections that do not inherit permissions force explicit authorisation decisions at each level, which is exactly where many programmes fail. The assumption that hierarchy should imply access creates accidental exposure when project structures change faster than permissions. The practitioner takeaway is simple: if access is inherited by default, review debt accumulates faster than most teams can certify it.

Privilege creep is the named concept hiding inside collaborative sharing. Once users can be added to collections, assigned to groups, and given management rights, access can expand quietly unless lifecycle controls are disciplined. Bitwarden’s model makes the risk visible because it shows how easily operational convenience can become persistent overreach. The implication is that access reviews must examine management rights, not just vault visibility.

Delegated administration needs bounded authority, not open-ended trust. Letting project leads or help desk teams manage collections can reduce central bottlenecks, but only if their authority stops at the right boundary. If they can create, delete, and reshape access without oversight, the organisation has simply moved privileged control into another place. Teams should treat collection management as a PAM-style governance problem, even when the items being protected are not traditional admin accounts.

Collections are most useful when they reflect lifecycle rules, not static sharing habits. The article implicitly points to a broader identity lesson: access that is easy to grant must also be easy to revoke, reassign, and validate over time. That applies to human users and to any shared credentials that live across teams. Practitioners should align collections with joiner, mover, and leaver processes rather than treating them as an informal sharing layer.

From our research:

• 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
• 15% of commit authors have leaked at least one secret in their contribution history, according to The State of Secrets Sprawl 2025.
• For lifecycle and rotation controls, see NHI Lifecycle Management Guide for the governance model that keeps shared credentials from becoming permanent exposure.

What this signals

Privilege creep in shared secret stores is rarely a tooling problem alone. It is usually a governance problem that shows up when management rights, deletion rights, and item visibility are treated as one entitlement. As collaboration layers expand, teams need reviewable boundaries for who can reshape access, not just who can consume it.

The operational signal to watch is whether collection ownership is becoming informal. If too many users can create, delete, or reassign shared items, the programme is drifting toward unbounded delegation, which is exactly where access reviews become noisy and ineffective.

Collections should be aligned to lifecycle, not just convenience. When items move between teams, the access model should make mover events visible and leaver events reversible. That is where lifecycle management becomes a control, not an admin process, and where organisations should anchor their shared-credential governance.

For practitioners

• Separate use from management rights Define who can view items, who can edit items, who can manage collection membership, and who can delete collections. Avoid giving the same role all four permissions unless the business case is explicit and approved.
• Audit nested collection inheritance assumptions Review every subcollection to confirm that access is intentionally assigned rather than copied from a parent structure. Where the business relies on hierarchy, document the exception and recertify it regularly.
• Restrict collection creation and deletion Limit creation and deletion to owners or admins unless there is a clear operational need for self-service. Broad creation rights often become untracked sprawl, while broad deletion rights can remove items from other collections unexpectedly.

Key takeaways

• Bitwarden’s collections model shows that secure sharing depends on explicit control boundaries, not just a shared folder metaphor.
• The main governance risk is privilege creep, especially when management and deletion rights are broader than the business need.
• Organisations should treat collection permissions as lifecycle governance, then recertify access before collaboration turns into standing exposure.

Key terms

• Collection: A collection is a shared access container for vault items such as logins, cards, and other sensitive records. It lets organisations group items for collaboration while controlling who can view, edit, or manage them. In practice, the value comes from separating sharing from delegation so access can be reviewed and revoked cleanly.
• Privilege Creep: Privilege creep is the gradual accumulation of access beyond what a user or role currently needs. It often happens when permissions are added for convenience, then never removed as projects, teams, or responsibilities change. In shared vault systems, it usually shows up as management rights growing faster than governance review.
• Delegated Administration: Delegated administration is the transfer of limited management authority to a non-central role, such as a team lead or help desk user. The goal is to reduce bottlenecks without handing over full control of the environment. Good delegation has clear boundaries, defined accountability, and a reviewable scope.

👉 Bitwarden's full post covers the collection settings, permission boundaries, and delegation options in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.