Bitwarden Security: Hardening Policies, SSO, Recovery and Machine Accounts

A Bitwarden organisation concentrates every shared credential a business owns, so the policies, decryption model, recovery rights and machine access tokens around it decide whether one compromised admin or leaked token exposes everything. This guide explains how to run a Bitwarden Teams or Enterprise organisation securely, using Bitwarden's own help documentation as the source for every product detail (checked 8 November 2026). It covers member roles and collection permissions, the 20 enterprise policies, SSO with its three member decryption options, account recovery, the organisation API key, Secrets Manager machine accounts and access tokens, event logs and SIEM export, and a hardening baseline. It is for identity teams, security engineers and IT administrators who own a Bitwarden tenant, cloud or self-hosted. For the wider discipline see the Secrets Management Guide.

This is an independent guide from NHI Mgmt Group, based on Bitwarden's public documentation as of November 2026. It is not sponsored or reviewed by Bitwarden. Product features change, so confirm settings against Bitwarden's current documentation.

Key takeaways

• Single organisation is the keystone policy. Bitwarden documents it as a prerequisite for Require SSO, Account recovery administration, Session timeout, Default URI match detection, Enable fill assist and Automatic user confirmation, so it should be the first policy you switch on.
• Your decryption choice is a security architecture decision. SSO authenticates; decryption still needs a master password, a trusted device or Key Connector, and removing master passwords is described by Bitwarden as effectively irreversible.
• Account recovery is a powerful privilege. Owners, admins and custom roles with Manage account recovery can reset an enrolled member's master password, so the people holding it are as sensitive as the vault itself.
• Machine access tokens default to never expiring. Secrets Manager tokens are shown once and not stored, but expiry defaults to Never and a revoked token can keep retrieving secrets for up to one hour on an already authenticated machine.
• Logs are kept indefinitely but are partly client reported. Event logs can be viewed 367 days at a time and streamed to a SIEM, yet Bitwarden warns they may not be enough on their own for forensic or legal audit.

How identity and access work in Bitwarden

Bitwarden describes its design as zero-knowledge and end-to-end encrypted: vault data is decrypted on the client, and the server stores wrapped keys. That has a practical consequence for administrators. Authentication (proving who you are, possibly through your identity provider) and decryption (obtaining the account encryption key) are separate steps, and every access design choice is really a choice about how the second step happens.

Master password and key derivation

Where members keep a master password, it is stretched with a key derivation function. Bitwarden's KDF page gives PBKDF2-SHA256 with a default and, since release 2026.2.1, a minimum of 600,000 iterations; accounts set lower are prompted or updated at their next unlock or login. Argon2id is the alternative, with defaults of 32 MiB memory, 6 iterations and parallelism 4. Changing the KDF re-encrypts the protected symmetric key and updates the authentication hash but does not rotate the symmetric key, so it does not re-encrypt vault data. The Master password requirements policy then sets minimum length, a zxcvbn strength score from 0 to 4 and required character types.

SSO and member decryption options

SSO is an Enterprise feature supporting SAML 2.0 and OIDC, with just-in-time provisioning at first login. Bitwarden stresses that the identity provider handles authentication only. Decryption then follows one of three models.

Decision guidance: Bitwarden itself recommends trusted device decryption as the alternative that needs neither a master password nor a key server, and recommends Key Connector only for enterprises with a team and infrastructure to run a key server securely (database plus key storage such as an HSM or cloud KMS). Small organisations should stay with master password or trusted devices. Remember that members without a master password who are removed or revoked are locked out of their vault, cannot use the CLI, and must unlock with a PIN or biometrics or be logged out instead of locked.

Admin roles and privileged access

Bitwarden has three default roles and, on Enterprise, custom roles.

Collection permissions

Collections are the access model for shared credentials. Bitwarden's levels are View items (the default), View items with hidden passwords, Edit items, Edit items with hidden passwords and Manage collection. Member-level permissions override group-level ones. Bitwarden notes that hidden passwords limit casual copying but do not block autofill, so treat those credentials as shared with the member. Two organisation settings matter for privileged collections: Restrict collection deletion to owners and admins, and Restrict item deletion to members with Manage collection. The setting Owners and admins can manage all collections and items gives administrators reach into every collection; decide deliberately whether you want that.

Account recovery

The Account recovery administration policy (which requires Single organisation) lets owners, admins and custom roles with Manage account recovery reset an enrolled member's master password or remove their two-step login methods. On enrolment, the member's encryption key is encrypted with the organisation's public key; during recovery, the organisation's private key decrypts it and it is re-encrypted with a new master key, so the administrator never sees the old password. Recovery does not bypass SSO or identity provider MFA, and deleted accounts are not restored. Policy can auto-enrol new members. Because a recovery holder can take over any enrolled vault below their level, restrict the permission, require approval outside Bitwarden for each use, and alert on every recovery event. A master password assigned through recovery to a trusted-device user cannot currently be removed.

For emergency administrator access design, see the Break-Glass Account Guide.

Integrations, API tokens and service accounts

Bitwarden has three families of non-human credential, each with a different blast radius.

Secrets Manager machine accounts

Machine accounts are Bitwarden's identity for applications and pipelines. Each is granted projects with either Can read or Can read, write; write also allows creating secrets and new projects. Members or groups added to a machine account can generate its access tokens, so that membership list is the real list of people who can mint credentials for it. Deleting a machine account is permanent with no trash step, and its secrets survive. The number of machine accounts is set by the subscription. Each machine account has its own event log tab recording secret access and changes.

Operational rules that follow from the documentation:

• Always set an expiry: the default of Never turns every token into a standing credential. Match expiry to a rotation cycle you can sustain.
• One token per consumer: name each token after the pipeline or host that holds it, so revocation is surgical and events are attributable.
• Read-only by default: grant Can read, write only to the workflow that genuinely writes secrets.
• Deliver through a secret store: the CLI reads BWS_ACCESS_TOKEN; Bitwarden recommends the environment variable or a CI/CD secret store over embedding the token in scripts.
• Plan for the one-hour tail: after revoking a leaked token, rotate the secrets it could read, because an attacker already authenticated may keep pulling them for up to an hour.

Pipeline credential design is covered in the CI/CD Pipeline Identity Security Guide.

Logging and detection

Event logs are available to Teams and Enterprise organisations under Admin Console, Reporting, Event logs. They are retained indefinitely, viewable 367 days at a time, and exported as CSV or as JSON through the Public API /events endpoint with a continuation token for paging. Native SIEM integrations exist for Elastic, Microsoft Sentinel, Panther, Rapid7, Sumo Logic and Splunk, with a generic HEC route for others. Server events are recorded immediately, but most client events reach the server about every 60 seconds.

Metrics that show the controls work:

• Percentage of Secrets Manager tokens with an expiry set (target 100%).
• Number of people holding Owner, Admin or Manage account recovery (trend down, reviewed quarterly).
• Account recovery events that match an approved ticket (target 100%).
• Percentage of members signing in through SSO where Require SSO is enforced.
• Time from token leak report to revocation and rotation of the secrets it could read.
• Members reported by the Single organisation and Master password requirements policies as non-compliant.

Because some events are client reported and may arrive late, correlate Bitwarden events with identity provider logs before drawing conclusions in an investigation.

Hardening baseline

A phased rollout limits disruption. Test each policy on a pilot group of members before enforcing it, and remember that several policies do not apply to owners and admins.

1. Foundations: enable Single organisation; set Master password requirements; confirm KDF settings meet the documented 600,000 PBKDF2 minimum or move to Argon2id after testing on slow devices; enable Require two-step login unless SSO or Duo is enforced for all members, where Bitwarden says it should not be used.
2. Ownership and data controls: enable Centralize organization ownership so work credentials live in organisation-owned My Items (transfers cannot be reversed); enable Remove export for members; configure Manage Send and share; consider Remove Unlock with PIN (applies to everyone, mobile enforcement planned) and Session timeout with a lock or log-out action.
3. Identity integration: configure SAML 2.0 or OIDC SSO, test with master password decryption, then enable Require SSO for non-admin members. Claim your domains and enable Block account creation for claimed domains.
4. Recovery and decryption: decide on master password, trusted devices or Key Connector; enable Account recovery administration with auto-enrolment if you choose trusted devices; restrict Manage account recovery to a small group.
5. Least privilege: replace broad Admin grants with custom roles; set collection deletion restrictions; review Owners and admins can manage all collections and items.
6. Machine access: rotate the organisation API key if its holders are unknown; inventory machine accounts, their projects and member lists; reissue tokens with expiry.
7. Monitoring: connect a SIEM integration and build alerts for recovery events, policy changes and secret access from unknown hosts.

Rollback: most policies can be turned off again, but some actions cannot be undone: item transfers under Centralize organization ownership, and master password removal under Key Connector or trusted devices. Pilot those with a small group first. As general good practice rather than a Bitwarden-documented setting, for self-hosted servers keep the server patched, restrict network access to the admin portal and back up the database; the environment-variable settings Bitwarden mentions (covering owners under Require SSO, and the fill assist rule URL) live in server configuration and should be change controlled.

Framework mapping

Common misconfigurations

• Tokens left at Never: Secrets Manager access tokens created with the default expiry become permanent credentials in CI variables and on hosts, and are rarely reissued.
• Revoking without rotating: teams revoke a leaked token and stop, forgetting the documented window of up to one hour in which an authenticated machine can keep retrieving secrets.
• Too many recovery holders: Manage account recovery granted broadly, or to helpdesk staff without approval, gives a path to take over any enrolled member's vault.
• Require SSO without Single organisation thinking: enabling SSO and assuming owners and admins are covered, when the policy applies to non-owner and non-admin members unless a self-hosted environment variable says otherwise.
• Key Connector without the team to run it: adopting Key Connector to avoid master passwords, then running the key server and its key storage with less care than the vault it unlocks.
• Organisation API key in an unknown script: the owner-only key with full management access stored in an integration nobody owns, never rotated.

Practitioner checklist

• Enable Single organisation first, then Master password requirements and two-step login or Require SSO.
• Choose a member decryption option deliberately and record why; pilot any master password removal with a small group.
• Limit Owners to two or three named people and move other administrators to custom roles.
• Restrict Manage account recovery and alert on every recovery event.
• Enable Centralize organization ownership and Remove export for members after a pilot.
• Inventory machine accounts, their projects, members and tokens; reissue every token with an expiry.
• Store the organisation API key in a managed secret store and rotate it when holders change.
• Stream event logs to your SIEM and correlate with identity provider sign-ins.
• Review roles, collection grants and machine account access quarterly.

Standards and references

• Bitwarden: Enterprise Policies
• Bitwarden: Member Roles
• Bitwarden: Trusted Devices
• Bitwarden: About Key Connector
• Bitwarden: Account Recovery
• Bitwarden: Machine Accounts
• Bitwarden: Access Tokens
• Bitwarden: Event Logs

Related NHI Mgmt Group resources: Secrets Management Guide · CI/CD Pipeline Identity Security Guide · Break-Glass Account Guide