Do not infer Bitwarden collection permissions from the folder-like hierarchy

Nesting organizes the list; it does not copy a parent collection’s access or items.

Source facts

Bitwarden collections group organization-owned items for sharing, and the organization can assign access to users or groups. An organization-owned item must belong to at least one collection, while its ownership stays with the organization rather than an individual user. The documentation makes a specific distinction about nested collections: nesting changes how the collection list appears in the vault filter. It does not cause the child collection to inherit its parent’s items, access, or permissions. Those assignments must be configured independently.

Source: Bitwarden — Collections.

Applicability

This concerns Bitwarden organization collections and their visual nesting. Personal-vault folders, group membership, and organization administrative roles are separate concepts with different effects.

DSE recommendation

DSE recommends maintaining a collection-to-group access table independent of the visual hierarchy. When creating a nested collection, review its explicit permissions and intended items instead of assuming the parent establishes a boundary. Use names that help users find information without implying inheritance that does not exist. During a restructure, check both old and new assignments before moving sensitive items. Keep organization ownership and collection access visible in the change record so a tidy-looking list does not hide unintended sharing.

Verification

Create parent and child test collections with different synthetic items and access groups. Confirm that access to the parent alone does not reveal the child’s items. Add the intended child assignment and retest. Review effective permissions through every relevant group and individual assignment before applying the structure to production data.

Official reference

Bitwarden — Collections. Reviewed October 15, 2026.