Why break-glass credentials need a different design from team passwords
Break-glass credentials are the emergency admin accounts, root passwords and recovery codes that must still work when single sign-on, the identity provider or the directory is down. Regulated organizations commonly keep them for that reason, and examiners and auditors tend to ask how they are stored, who can reach them and how their use is detected. A self-hosted vault can hold these secrets with split access, use alerts and rotation after each use, but it should not be the only thing that makes them work. If the vault depends on the same SSO or directory it is meant to back up, a failed identity service can lock you out of both the systems and the vault that holds their keys.
In practice the choice between platforms turns on the features you need. Passbolt Pro offers finer sharing and audit controls, including account recovery, MFA policies, syslog activity logs and password expiry policies, which are listed as Pro features rather than Community Edition features. Vaultwarden gives a lightweight organization vault with collections, member roles, event logs and emergency access, and it is an alternative server implementation of the Bitwarden Client API rather than an official Bitwarden product. Confirm with each vendor whether the specific control you need, such as per-item approval or alerting on retrieval, is available in your edition, because a vault feature list does not prove that an alert fires on use.
Before you choose, decide who may open each break-glass secret, who must be notified when it is opened, and which system resets the password afterward. Run a test in which the identity provider is switched off and an authorized person retrieves the emergency credentials and logs into a target system. Record the result, the time taken and any gap in the runbook. This test tells you more about the design than any feature comparison, and it should be repeated after every change to the SSO, directory or vault configuration.
Which regulatory requirements shape break-glass design
This table maps two US obligations, the HIPAA Security Rule and the FTC Safeguards Rule, to concrete break-glass build requirements and the evidence an assessor may ask for. Read it as a starting point for discussion with counsel and auditors, since interpretation depends on your entity type and environment. The main takeaway is that a shared emergency credential still needs named accountability, logged retrieval, and a documented way to reach it when the identity provider fails.
| Requirement | Build requirement | Evidence to prepare |
|---|---|---|
| Unique user identification (45 CFR 164.312, access control) | Each retrieval of a shared emergency credential is tied to a named person, even when the account itself is shared | Vault event logs showing the user who opened the item, plus the approval record for that access |
| Person or entity authentication (45 CFR 164.312) | Confirm the requester's identity before the break-glass secret is revealed, using the vault's own login and MFA | Vault policy export, MFA enrollment list, and a sample login trail for break-glass users |
| Audit controls (45 CFR 164.312) | Log every retrieval, copy and change, and send those events to a system someone reviews | Log forwarding configuration, review cadence records, and examples of follow-up on unexpected access |
| Multi-factor authentication for any individual (16 CFR 314.4) | Require MFA to open the vault and to reach any emergency credential stored inside it | MFA policy settings in the vault, identity provider configuration, and exception records |
| Monitoring of authorized user activity (16 CFR 314.4) | Alert on break-glass use and route alerts to people who can act on them | Alert rules, sample alert tickets, and responder sign-off on each event |
| Tension: MFA versus access when the identity provider is down | MFA on the vault depends on an identity provider that the break-glass process may need to bypass. Design a sealed, separately MFA-protected path for a small number of named holders, and document when it applies | Written break-glass procedure, holder list, and records of each activation and rotation afterward |
| Documented testing (both rules expect controls that work in practice) | Test the emergency access path on a schedule and after changes, including the MFA fallback and rotation after use | Test plans, dated results, defects found, and remediation tickets |
Which platforms fit break-glass storage and why
Break-glass credentials need access splitting, activity records and recovery paths that still work when SSO is down. The platforms below differ mainly in which of those controls sit in the free edition and which need a paid tier or a separate tool.
Passbolt Community edition limits
The Community edition is free and self-hosted with unlimited users, which makes it tempting for emergency accounts. Several controls you would rely on during an incident sit in the paid Pro tier, including account recovery, SSO, MFA policies, syslog activity logs and password expiry. Before you store root or recovery credentials there, confirm with Passbolt which features your chosen edition provides and test each one you depend on.
Passbolt Pro recovery and logging
Pro adds account recovery, syslog activity logs and MFA policies, which matter for break-glass use because you need to know who opened a root secret and be able to restore access to the vault when a key holder is unavailable. Check how recovery is authorized, whether it requires another administrator, and whether syslog output reaches the SIEM you already run. Pro pricing is published per user with a minimum, so ask for a quote based on the number of break-glass holders, not total staff.
Vaultwarden organizations and collections
Vaultwarden implements organizations with collections, member roles, groups and event logs, so a break-glass collection can be restricted to a small set of named custodians. It also supports emergency access and admin password reset, but these are personal-vault features, and their behavior inside an organization must be tested. Note that the project is maintained separately from Bitwarden, and bugs go to the Vaultwarden project. Confirm that event logs capture view events on break-glass items before you rely on them for review.
Vaultwarden SSO and two-factor login
Vaultwarden added single sign-on with OpenID Connect in version 1.35.0, and later releases through 1.37.3 added fixes and settings such as SSO_SIGNUPS_ALLOWED. This matters because a break-glass vault is usually reached through SSO, so you must decide what happens when the identity provider fails. Plan for a local master password and a second factor that does not depend on SSO, and confirm which two-factor methods (authenticator app, email, FIDO2 WebAuthn, YubiKey or Duo) your custodians will use.
Self-hosted Bitwarden for break-glass
The official self-hosted Bitwarden server offers organizations and collections as well, but it is a different deployment with its own resource needs and support terms than Vaultwarden. Choose it when your procurement or support requirements call for the vendor's own server, and confirm which organization features, event logging and SSO options your plan includes. Do not assume feature parity with Vaultwarden. Ask the vendor how emergency access behaves when the server is unreachable.
Where a password manager stops and PAM starts
A password manager controls who can retrieve a secret and records that retrieval. It does not record what an administrator does after logging in to a server or database. If auditors expect session recording, command capture or approval workflows for privileged access, a separate privileged access management tool is usually needed alongside the vault. Decide early which records must come from the vault and which must come from session tooling, and check that both feed the same review process.
How to roll out break-glass vaulting in phases
This sequence moves emergency accounts from scattered notes and memory into a self-hosted vault with named custodians, logged access, rotation after use, and proof that recovery works when SSO is down. Each phase produces a record that the next phase depends on. The length of the rollout depends on the scope agreed in writing, and your own change process applies to every phase.
Inventory emergency accounts and recovery codes
Start by listing every break-glass credential: local administrator and root accounts on servers, network device enable passwords, firewall and hypervisor admin logins, directory recovery accounts, and the recovery codes for MFA, cloud tenants and domain registrars. For each item, record the system it protects, the owner, where it is stored today, and what breaks if it is unavailable. The output is a reviewed inventory signed off by the security owner. Confirm with your IAM and infrastructure leads that nothing critical is missing, because the inventory defines the scope of every later phase.
Decide the sharing model and named-user design
Decide how the vault will represent emergency access. Choose whether each break-glass credential is a shared resource granted to a defined group of custodians, and whether individual custodians sign in with their own named accounts before they reach it. Confirm in the vendor documentation which sharing, group and recovery features your chosen edition includes, since some Passbolt Pro features are not in the Community Edition. The output is a written access model that names who can view, who can reveal, and who can administer the vault itself.
Build hosting, backup and HTTPS
Deploy the vault on infrastructure that stays inside your control, with HTTPS in front of it through a reverse proxy, since the Vaultwarden web vault requires HTTPS for the Web Crypto API. Put the vault on a separate network path from the systems it protects, so that a compromise of those systems does not also remove access to the vault. Configure database backups and file backups, and test one restore into a clean environment. The output is a running instance, a documented restore procedure, and a restore test record. Ask the platform owner which hosting, database and backup options your edition supports.
Split access between custodians
Assign at least two custodians to each critical credential so that no single person can use it alone, and keep the vault administrator role separate from custodian access. Load the credentials into the vault in the order of the inventory, using the approved import path and avoiding cleartext exports. Remove the old copies from wikis, spreadsheets and shared documents once the vault copy is verified. The output is a custodian matrix showing each credential, its custodians, and its administrators, plus evidence that the old copies were removed.
Alert on use and export logs to the SIEM
Configure the vault's activity logging and forward those logs to your SIEM, so that every view, reveal, copy, share change and password change on a break-glass item generates an alert routed to the security team. Confirm which events your edition logs and whether syslog export is available in your edition before you design the alert rules. Test the alert by performing a controlled access and confirming it arrives. The output is a documented alert list with a tested example for each event type.
Rotate the credential after each use
Write a procedure that requires a custodian to record the reason for use and the ticket or incident reference, then rotate the password or recovery code before the emergency session ends or as soon as the system is back under normal control. The new value is stored in the vault and the old value is retired, so the next custodian never receives a credential that has already been exposed. Confirm with the system owner whether the target system can rotate the credential without breaking dependent services. The output is a rotation runbook and a log showing each use matched to a rotation.
Test the full recovery path and keep evidence
Schedule a test in which SSO is deliberately made unavailable in a controlled window, and a custodian retrieves a break-glass credential from the vault, signs in to the protected system, and completes a defined administrative task. Record the start and end times, the custodians involved, any failures, and the corrective actions. Repeat the test on a schedule you define in your own change process. The output is a dated evidence record for each test that can be shown to auditors or assessors as proof that the procedure works end to end.
How identity, logging and the vault connect in the break-glass path
A break-glass credential is only useful if the path to it survives the failure it was created for. The integrations below decide whether the vault, the identity provider, the logging pipeline and the privileged session tools fail together or independently, and each one needs an explicit owner and check.
SSO provider and fallback login
The vault normally signs users in through the workforce identity provider. If that provider is down, locked out or misconfigured, staff need a login path that does not depend on it, such as a local vault account with MFA held by a named custodian. Decide whether the vault is hosted inside or outside the failure domain of the SSO provider, and document that choice as an accepted risk where it is outside. Test the fallback login before any incident.
SIEM receiving vault activity logs
Every retrieval, share change and break-glass checkout should reach the security monitoring platform, so an alert fires on use rather than on a quarterly review. In Passbolt, syslog activity logs are a Pro feature, so confirm the edition before designing the pipeline. For Vaultwarden, event logs live in the server, so plan how they are exported and retained. Validate that a test checkout produces a visible alert.
Backup of database and attachments
Vaultwarden keeps vault data in SQLite by default and can use MySQL or PostgreSQL through DATABASE_URL, and its maintainers strongly recommend regular backups of files and the database. Attachments, such as recovery code files, must be covered by the same backup set. Store at least one copy outside the primary host, and test a restore into a separate environment. Passbolt backup scope should be confirmed against its installation guide for your chosen platform.
Offline copies of recovery material
Some recovery material must not depend on any running system, including the vault itself. Examples include the root password for the hypervisor, the recovery keys for the SSO provider and the key material needed to decrypt a backup. Keep sealed, dated copies in a physical location controlled by two or more people, and record each time a copy is opened. Reconcile these copies against the vault after every rotation so they do not drift.
PAM or secrets tool for sessions and injection
Some break-glass access should not hand over a password at all. Where administrator sessions must be recorded, or where a service needs a secret injected at runtime, a privileged access tool or a secrets manager such as OpenBao is the better fit than a shared vault entry. Decide per credential which path it uses, and confirm that the chosen PAM product records the sessions your framework expects before retiring a shared root login.
What auditors and examiners ask to see for emergency credentials
This table lists the records an assessor or examiner typically asks for when emergency credentials sit in a self-hosted vault, and which component produces each one. Read each row as a question to answer with a retrievable record, then confirm retention periods and file formats with your own auditor before you design the logging pipeline.
| Evidence item | Component that produces it | What to confirm before the audit |
|---|---|---|
| Access list per emergency credential | Passbolt sharing and group membership, or Vaultwarden organization collections and member roles | Named custodians per credential, with a dated export of who could decrypt or view each entry |
| Vault activity or event logs | Passbolt activity logs (Pro edition, syslog export), or Vaultwarden event logs | Which log entries exist for view, copy and edit actions, and how long your deployment keeps them |
| Alert record for each use | SIEM rule fed by vault logs, such as Wazuh, with ticket linkage | Alert latency, who acknowledges alerts, and whether alerts survive a SIEM outage |
| Rotation record after each use | Ticketing system entry linked to the password change in the vault or target system | Proof that the new value was set on the target system, not only stored in the vault |
| Test records with outcomes and remediation | Ticketing or GRC tool entries for scheduled break-glass drills | Test cadence your auditor expects, plus the findings and fixes from each drill |
| Backup and restore test records | Backup job logs and restore test reports for the vault database and attachments | Restore success evidence on a separate host, and whether the vault can decrypt the restored data |
| Custodian change records | HR or identity lifecycle records, plus vault membership change history | Timing of removals against leaver dates, and how re-keying or recovery was handled for departing custodians |
What do buyers ask before setting up break-glass vaulting?
What does break-glass vaulting cost and what drives the price?
The cost depends on the written scope: how many systems and emergency accounts are in it, which edition you run, where the vault is hosted, and how far it integrates with your SSO and SIEM. Passbolt Community and Vaultwarden have no license fee for the software itself, so the main costs are people and infrastructure: the implementation work, the hosting and backup design, and ongoing support. Passbolt publishes Pro pricing at $4.9 per user per month billed annually with a 10-user minimum, which the vendor lists on its pricing page. Ask any partner for a quote that separates one-time work (design, import, runbook, first test) from recurring work (patching, upgrades, rotation evidence, test exercises).
How long does a break-glass vault setup take?
Timing follows the written scope, not a standard duration. The schedule depends on how many emergency accounts need to be inventoried, how many systems and owners are involved, whether SSO and log forwarding are in scope, and how many test windows your change process requires. Most engagements are fixed-scope, so the agreed deliverables and timeline are written down before work starts. Ask for a milestone plan that includes the first full restore and emergency access test, since those tend to take longer than the install itself.
What must our team provide before a break-glass project starts?
You need to supply a complete inventory of break-glass credentials, including root passwords, emergency admin accounts and recovery codes for each system. For each item, name an owner, a custodian group and the systems it unlocks. You also need an approval policy that states who may retrieve a credential, under what conditions, and who is notified. Finally, identify test windows with operations and change management, and confirm who can approve a rotation. Without these inputs, a vault becomes a copy of the problem rather than a control.
Can our own team run a break-glass vault without a partner?
A small team can usually run a simple vault, meaning one shared folder, a few named custodians and a documented retrieval step. Harder parts are split custodianship, where no single person can open a credential alone, alerting on each retrieval, and rotation after every use. Testing is often the gap, because an untested emergency procedure rarely works under pressure. Passbolt and Vaultwarden both give administrators the tools to configure sharing, but you must confirm which activity logs, policies and recovery features your chosen edition includes before deciding who can operate it.
Is Vaultwarden or Passbolt Community enough without SSO or activity logs?
It can be enough for a small, lower-risk group, but you should confirm the gaps before committing. Passbolt's comparison lists LDAP provisioning, account recovery, SSO, MFA policies, syslog activity logs, password expiry and SCIM as Pro features that are not in Community Edition. Vaultwarden includes organizations, collections, event logs, emergency access and SSO with OpenID Connect since version 1.35.0, but its README says the maintainers focus on individuals, families and small organizations, and that bug reports go to the Vaultwarden project. If an auditor or SIEM team needs centralized logs for every retrieval, plan that integration explicitly and test it.
How often should break-glass credentials be rotated and tested, and who signs off?
Rotate a break-glass credential after every use, and also on a schedule your policy sets. Test the full procedure on a fixed cadence, covering retrieval, login, the approval path and rotation, and record the results. The policy should name a sign-off owner, typically the security lead for the control and the system owner for the account. Confirm the frequency with your auditors and your own risk owners, since no external standard in this context fixes a single interval for every organization. Keep dated test records because they are the evidence an assessor will ask for.
What happens if the vault itself is lost or corrupted?
Losing the vault can lock you out of every break-glass account, so backup and restore planning must be part of the design from the start. Plan regular backups of the server files and the database, plus separate backups of the encryption material each user holds. Vaultwarden's README highly recommends regular backups of files and the database and states that the maintainers cannot be held liable for data loss. Passbolt users hold their own OpenPGP keys, so account recovery and key escrow policy need to be decided in advance. Test a full restore to a separate host and document how custodians regain access if the primary system is unavailable.
What to ask an implementation partner about break-glass design
Start by asking how the partner will prove the recovery path works without waiting for a real SSO outage. Ask for a written test plan that disables SSO for a named test account, retrieves a break-glass entry from Passbolt or Vaultwarden, and records who approved the test and how long the retrieval took. Ask whether they will rotate the credential after each drill as well as after each real use, and how they will show the drill record to your auditors. Also ask how custodian splits are designed: which roles can reveal a secret, whether two custodians must be present, and which alert fires when a shared resource is opened outside a change window. Confirm that the alert path reaches your security operations team, not only the vault administrator.
Next, ask how backups and offline recovery material are handled. Backups of the database and attachments matter as much as the vault itself, because the Vaultwarden README highly recommends regular backups of files and the database and states that maintainers cannot be held liable for data loss. For Passbolt, ask how the OpenPGP private keys of custodians are backed up and where printed or sealed recovery material is stored. Ask for the restore procedure to be tested on a separate host. Ask who will write the runbook and whether you will own the final version, with its change history, review date and named owners. Finally, ask which features need a paid edition: the Passbolt comparison lists account recovery, MFA policies and syslog activity logs as Pro features, and you should confirm which of these your break-glass design depends on before you choose the edition. Clarify whether support is a fixed-scope handover or a retainer covering upgrades, vault patches and drills after go-live.
