/security-posture

name: "Bitwarden Security Posture"
description: >
  Assessing a client's Bitwarden organization posture from the read-only
  Public API: which security policies are enabled and how they are set,
  two-step login coverage across confirmed members, owner and admin sprawl,
  members stuck in Invited or Accepted, and the SSO caveat on the 2FA flag.
  Produces a scored posture summary with remediation steps for the Admin
  Console.
when_to_use: >-
  When reviewing how well a client's Bitwarden organization is locked down,
  preparing a security review or QBR, or checking a compliance control that
  depends on the password manager. Use when: bitwarden policies, bitwarden
  2fa coverage, who lacks two-step login, bitwarden mfa posture, master
  password policy, vault timeout policy, bitwarden owners and admins, or
  password manager compliance check.

Bitwarden Security Posture

Overview

A password manager is only as strong as its policies and its weakest admin. This skill turns three read calls into a posture summary an MSP can act on: the policy set (`bitwarden_policies_list`), the membership with its roles and 2FA flags (`bitwarden_members_list`), and, where needed, a single policy's settings (`bitwarden_policies_get`).

All three tools are read tier in Conduit. None of the posture checks need the admin-gated `bitwarden_events_list`; use it only to answer "when did this policy change?" (see [event-log-review](../event-log-review/SKILL.md)).

This plugin cannot change a policy or a member. Every finding is a recommendation for an owner or admin to carry out in the Admin Console.

Anti-triggers

• **A specific departing user's access** — use

[offboarding-access-review](../offboarding-access-review/SKILL.md).

• **Seat counts and billing** — use

[license-reconciliation](../license-reconciliation/SKILL.md).

Key Concepts

Policies that matter in a review

`bitwarden_policies_list` returns every policy that has ever been configured, each with `type`, `enabled` and a `data` object whose shape depends on the type. A policy missing from the list was never configured; treat it as off. `bitwarden_policies_get` answers 404 for the same case.

| Type | Policy | Why an MSP cares | Expected for a managed client | |---|---|---|---| | 0 | TwoFactorAuthentication | Requires members to use two-step login | On, unless SSO with IdP MFA covers everyone | | 1 | MasterPassword | Minimum length and complexity for master passwords | On; read `data` for the settings | | 3 | SingleOrg | Stops members joining other Bitwarden organizations | On (required by RequireSso) | | 4 | RequireSso | Members log in through the client's identity provider | On where the client has an IdP | | 5 | OrganizationDataOwnership | Items are saved to the organization, not personal vaults | On for most business clients | | 8 | ResetPassword | Account recovery: admins can reset an enrolled member's master password | Deliberate choice; know which way it is set | | 9 | MaximumVaultTimeout | Caps how long a vault stays unlocked | On; read `data` for the limit | | 10 | DisablePersonalVaultExport | Blocks members exporting their individual vault | On where data loss prevention matters | | 6 | DisableSend | Blocks Bitwarden Send | Client choice; note it | | 14 | RemoveUnlockWithPin | Removes PIN unlock | Client choice; note it |

Check Bitwarden's [policies documentation](https://bitwarden.com/help/policies/) for the exact behaviour of each policy, including who it exempts, before telling a client what it enforces.

The 2FA flag and SSO

`twoFactorEnabled` on a member is Bitwarden's own two-step login. When the organization uses RequireSso, members sign in through the identity provider, which may enforce MFA itself. A `false` flag on an SSO organization is therefore not proof of missing MFA: confirm the IdP's MFA rules (for example Entra conditional access) before reporting it as a gap.

Who counts

Only **Confirmed** members (`status` 2) can use organization data. Count 2FA coverage over confirmed members. Report Invited (0) and Accepted (1) members separately; Revoked (-1) members have no access and are excluded.

Common Workflows

Posture review for one client

1. Call `bitwarden_policies_list`. Build the table above with each policy's enabled state. For MasterPassword and MaximumVaultTimeout, read the `data` settings. Call `bitwarden_policies_get` only if you need one policy's detail on its own. 2. Call `bitwarden_members_list`. Check for `truncated: true` first (see [api-patterns](../api-patterns/SKILL.md)); if the list is cut, say the coverage figures are partial. 3. Over confirmed members, compute:

• 2FA coverage: members with `twoFactorEnabled` true, as a count and

a percentage.

• Owners (`type` 0), Admins (1) and Custom (4), each with their 2FA

state. 4. List members stuck in Invited or Accepted. Accepted members are waiting for an admin to confirm them and cannot see shared items yet. 5. Rank the findings (see below) and write the summary.

Ranking findings

1. **Owner or admin without 2FA** (and no SSO-enforced MFA). An owner holds the organization API key and can export everything shared. 2. **TwoFactorAuthentication policy off** with confirmed members lacking 2FA. 3. **No MasterPassword policy**, or one with weak settings. 4. **Too many owners or admins** for the size of the organization. Two owners (a primary and a break-glass account) is a common target; more needs a reason. 5. **SingleOrg or RequireSso off** where the client has an identity provider. 6. **Stale Invited / Accepted members**: access granted on paper, never completed.

Output

A short verdict line, then a table of policies (on / off / not configured, with key settings), the 2FA coverage figure with the denominator, the owner and admin list, and a numbered remediation list. Each remediation names the Admin Console area where an owner or admin makes the change. Never writ