Administration, Zero-Knowledge and Compliance

This guide is for the administrator who has to operate the vault across an organization, and the reviewer who has to sign off on it. By the end you will know how to tie vault access to identity so offboarding is complete, how multi-factor and device factors are enforced, what the audit trail captures, how the design limits the blast radius of a compromise, and the exact cryptography and compliance posture behind the zero-knowledge claim.

Tie Access to Identity so Offboarding Is Complete

After this section you will close the deprovisioning gap. The classic failure is that disabling someone's sign-in leaves the shared credentials they could see still usable, because a login block is not a credential revocation. Backbuild closes this in two ways. First, removing a person from a vault re-keys it, so their old access cannot open items going forward, immediately (see Sharing Vaults with Your Team). Second, and better at scale, share vaults to a group, department, or role rather than to individuals, so that the same identity lifecycle that removes someone from the group removes their vault access with nothing to clean up by hand.

That identity lifecycle is the platform's single sign-on and directory provisioning: when your directory deprovisions a person, their group memberships fall away and the vault access those memberships carried falls away with them. This is why lifecycle provisioning, not just sign-on, is the control that actually revokes access. See Security and Compliance and SSO and SCIM for how identity and provisioning are configured across the workspace.

Enforce Multi-Factor and Device Factors

After this section you will know how strong authentication is required. Account authentication, including multi-factor requirements, is governed by your organization's security policy across the whole workspace, so the vault inherits the same sign-in assurance you set for everything else. On top of that, the vault applies its own step-up: sensitive actions, such as authorizing a machine, releasing a credential to an integration, or revealing a value from history, require a fresh confirmation even inside an unlocked, signed-in session. Device factors, which let a person reopen the vault with a verifying gesture, are enrolled per device after a master-password unlock and are individually revocable in security settings. See Signing In and Account Security for the account-level factors and Unlocking, Device Factor and Recovery for the vault's own device factor.

The Audit Trail

After this section a compliance owner will know exactly what is recorded. Every security-relevant action on the vault is written to a tamper-evident audit log: creating, editing, and deleting items; sharing a vault and changing a role; re-keying on revocation; unlock attempts; every AI-tool call; and every release of a secret to a machine or an integration. Each record carries the acting identity, the time, and the target, and never the secret value. Tamper-evident is the precise word to carry into your own audit: a change cannot happen without its audit record. The wider audit surface, retention, and how to export the evidence an auditor samples are covered in Security and Compliance and the Security and Compliance API.

Blast Radius and Isolation

After this section you will be able to answer what one compromise reaches. The design keeps a single compromise from cascading. Secrets are encrypted per vault under keys wrapped to individual members, so a compromised account reaches only the vaults that account could already open, not the organization's secrets at large. Vaults are isolated per organization, so one tenant's secrets are never reachable from another. And because the vault is zero-knowledge, a compromise of the server itself yields ciphertext, not readable secrets: there is no server-side key to steal, because none exists. The scenario that has broken other managers in independent testing, a compromised server turning ciphertext into plaintext, has no path here.

A diagram showing containment. In the center, a compromised user account. Around it, boundaries it cannot cross: it reaches only the vaults that account already had access to, not other members' vaults; it cannot cross the organization boundary to another tenant; and a compromised server holds only ciphertext with no key to decrypt it. Each boundary is drawn as a ring with a lock, labelled per-vault keys, per-organization isolation, and no server-side key.
Per-vault keys, per-organization isolation, and no server-side key together bound what any single compromise can reach.

The Cryptography, for Reviewers

After this section you will have the specifics a security reviewer asks for. The vault is zero-knowledge: plaintext and the keys that open it exist only on the user's own devices, and the server holds only ciphertext, wrapped keys, and public keys. The primitives are stated here as posture; the construction details are deliberately not, because they are not useful to you and would be useful to an attacker.

  • Master password stretching: Argon2id, the memory-hard function that won the Password Hashing Competition, derives the master unlock key on the user's device.
  • Key exchange (post-quantum): hybrid, combining X25519 with ML-KEM-768, the key-encapsulation mechanism standardized by NIST as FIPS 203. Hybrid means an attacker must break both the classical and the post-quantum part.
  • Signatures (post-quantum): critical state is signed with a hybrid of Ed25519 and ML-DSA-65, the signature scheme standardized by NIST as FIPS 204, so a signature holds unless both the classical and the post-quantum part are broken.
  • Item encryption: each vault has its own random key that encrypts item contents with XChaCha20-Poly1305 authenticated encryption, and that vault key is wrapped separately to each member's public key.

The post-quantum key exchange is what defends against harvest-now, decrypt-later: an adversary who records today's ciphertext, waiting for a future quantum computer, still cannot open it, because the key material was never protected by classical cryptography alone.

Compliance Posture

After this section you will have the row for your vendor risk register. Backbuild Secrets inherits the platform's compliance posture. The platform is built to meet the requirements of ISO 27001, SOC 2 Type II, HIPAA, and the OWASP Top 10, and billing runs through a PCI-compliant payment processor. This is a statement of the control bar the platform is engineered to; for current attestations and the supporting documentation a procurement or vendor-risk reviewer needs, see the Security and Compliance overview and the Backbuild Trust Center.

Two honest scoping notes for the vault specifically. A stored credit card is encrypted data a user keeps for their own reference and autofill, not a card Backbuild processes, so the vault is not a cardholder-data environment. And a passkey entry is a filed record for reference today, not a working authenticator that answers sign-in challenges.

With single sign-on alone, does access really go away when I offboard someone?
Tie vault access to a group, department, or role, and lifecycle deprovisioning removes the group membership and the vault access it carried. Removing a person from a vault directly also re-keys it immediately. A login block alone is not enough; the vault access has to be revoked, which these do.

How does revocation work, and does a removed user keep access to what they already had?
Removal re-keys the vault so old access cannot open items going forward, immediately. It cannot un-see a value the person already copied, so for a sensitive departure, also rotate the specific secrets they had used.

Is the zero-knowledge claim real under a compromised server?
Yes. The plaintext and the unlocking key exist only on user devices; the server holds ciphertext and public keys and no key that can decrypt them. A server compromise yields ciphertext, which is the exact scenario that has exposed weaker designs in independent testing.

What is your post-quantum stance?
The vault uses a hybrid post-quantum key exchange, X25519 with ML-KEM-768 (NIST FIPS 203), and signs critical state with ML-DSA-65 (FIPS 204), which protects against harvest-now, decrypt-later.

Does administrator-assisted recovery weaken zero-knowledge?
No. It relies on material a member entrusted in advance to an administrator of their own organization and restores access without anyone, administrator or Backbuild, ever seeing a secret value. There is no path by which the provider can open a vault. See Unlocking, Device Factor and Recovery.

Where is the third-party validation?
Current attestations and the security and legal documentation for vendor risk review are in the Backbuild Trust Center.

Next Steps