Vault Overview

The Vault is concorbit's built-in encrypted password manager. It provides a secure, centralized place for your team to store and share sensitive credentials, passwords, API keys, SSH keys, payment card details, server credentials, certificates, and secure notes, all protected by AES-256-GCM encryption using your tenant's unique encryption key.

Requirements

• Plan tier: concorbit or above.

• Access: All team members with Vault access can view secrets in folders matching their access tier. Administrators always have full (Director-level) access.

Key Concepts

Secrets

A secret is a single encrypted credential stored in the Vault. Every secret has a name, a type, and an encrypted value. Secrets can also carry optional metadata such as a username, URL, notes, and a TOTP seed for two-factor authentication codes.

concorbit supports the following secret types:

Folders

Secrets are organized into folders. Folders can be nested (a folder can contain subfolders), giving you a flexible hierarchy for organizing credentials by client, project, service, or any other scheme that suits your workflow.

There are three kinds of folder scopes:

• Tenant folders: Shared across your team, subject to access tier restrictions (see below).

• Company folders: Attached to a specific CRM company record, useful for storing client-specific credentials alongside the client's account.

• Personal folders: Private to the individual user who created them. Other team members cannot see or access personal folders.

Access Tiers

Every tenant folder is assigned an access tier that controls which team members can see the folder and its secrets. The three tiers form a hierarchy:

A user's effective tier is determined in this order of priority:

1. A per-user override set on their account (if configured).

2. Role-based permissions (vault.tier.director, vault.tier.management).

3. Default: Staff.

Administrators always receive Director-level access regardless of role configuration.

Encryption Model

All secret values are encrypted at rest using AES-256-GCM with your tenant's unique encryption key. The encrypted data is stored in the database and is only decrypted on demand when you explicitly reveal a secret. Decrypted values are never cached, stored in session data, or written to log files.

Usernames are stored with a blind index (a one-way hash derived from the username and your tenant key) that enables search without exposing the plaintext username at rest.

Sharing

Secrets can be shared externally via time-limited, token-based links. Shared links can be configured with an expiry window and an optional view limit. See Secret Sharing for details.

Audit Trail

Every significant action in the Vault is logged: revealing a secret, creating or deleting secrets and folders, sharing secrets, and exporting the vault. The audit log records who performed the action, when, and from which IP address. See Access Control & Tiers for more on the audit trail.

Navigating the Vault

When you open the Vault from the main navigation, you see two tabs:

• Tenant Vault: The shared team vault. Shows all tenant-scoped folders you have access to based on your tier.

• Personal Vault: Your private vault. Shows only folders you own. Other team members cannot see this tab's contents.

The left sidebar displays the folder tree. Click a folder to view the secrets it contains in the main area. From there you can create, reveal, edit, share, and delete secrets.

Company Vault

In addition to the main Vault page, each company record in the CRM has its own vault section. Company vault folders are scoped to that company and are also subject to the access tier system. This lets you keep client credentials organized alongside the rest of the client's account information.

Rotation Reminders

Secrets can be configured with a rotation interval, a number of days after which the secret should be updated. This is a reminder system that helps enforce good credential hygiene.

When a secret's rotation interval has elapsed:

• The secret appears in the secrets list with a visual indicator that rotation is due.

• The number of days overdue (or remaining until rotation) is displayed alongside the secret.

concorbit does not automatically change passwords or keys. The rotation reminder alerts you that it is time to update the credential at its source and then update the stored value in the Vault.

Common rotation intervals:

See Managing Secrets for details on configuring rotation intervals and updating secrets.

Search

The Vault includes a search feature that lets you quickly find secrets across all folders:

• Name search: Type at least 2 characters in the search bar to search secrets by name. Results include the secret name, type, folder name, and URL. The search is case-insensitive and supports partial matches.

• Username blind index search: Search by username using an exact-match blind index. This finds secrets by their associated username without exposing plaintext usernames in the database.

Search results link directly to the secret's folder, so you can navigate to and reveal the secret from the search results.

Export

Users with the vault.reveal permission can export the vault as an encrypted JSON file. The export is scoped to the folders the user can see (their personal folders plus shared folders at or below their access tier), and includes those folders and their secrets with encrypted values intact, values are not decrypted during export. The export file follows the concorbit-vault-export-v1 format and can be used for backup or migration purposes.

To export:

1. Navigate to the Vault from the main navigation.

2. Click the Export action in the toolbar.

3. The file downloads immediately.

The download is named vault-export-YYYY-MM-DD-HHMMSS.json. The export includes:

• Export timestamp and tenant name.

• All folders with their names, access tiers, and company associations.

• All secrets within each folder, including their encrypted values, encrypted notes, URLs, metadata, and rotation interval settings.

The export action is logged in the vault audit trail.

Security Notes

• Encryption at rest: All secret values and notes are encrypted with AES-256-GCM using your tenant's unique key. The encryption key never leaves the server.

• No caching: Decrypted values are never stored in cache, session storage, or browser local storage by the application. They exist in memory only for the duration of the reveal request.

• No logging: Secret values are excluded from application logs, error reports, and debug output. The $hidden property on the VaultSecret model prevents accidental serialization.

• Separate reveal endpoint: Secret values are fetched via a dedicated JSON endpoint, not included in page loads. This means encrypted values are never accidentally exposed through Inertia page props or HTML source.

• Impersonation lockout: The Vault is disabled for impersonation sessions and partner tenant switches. Parent administrators cannot reveal, share, or export sub-tenant vault secrets.

• Audit everything: Every reveal, share, and export action is logged with the user identity, IP address, and timestamp.

• Blind index search: Username search uses a one-way blind index derived from your tenant key, allowing search without storing plaintext usernames.

• Soft deletion: Deleted secrets are soft-deleted, providing a recovery window before permanent purge.

Next Steps

• Managing Secrets. Create, edit, reveal, and organize secrets.

• Access Control & Tiers. Configure who can access what.

• Secret Sharing. Share secrets via time-limited links.

• Vault in Client Portal. How clients access vault secrets.