Vaults are containers within a project that store secrets, cryptographic keys, and certificates. They provide an additional layer of organization and access control beyond projects, allowing you to group sensitive resources by purpose, environment, or security level.

Every vault belongs to exactly one project, and all access to secrets, keys, and certificates is evaluated through the vault.

Purpose of Vaults

Vaults exist to:

• group related secrets, keys, and certificates
• separate concerns such as environments or services
• apply tighter access controls when needed
• provide clear audit and access boundaries

A project can contain multiple vaults, each serving a distinct purpose.

What a Vault Contains

Each vault can store:

• Secrets – sensitive values such as API keys and credentials
• Keys – cryptographic material for encryption, signing, or authentication
• Certificates – TLS or identity certificates and their private keys

Secrets are versioned. Keys and certificates are not: replacing one means creating a new resource. Expiration tracking applies to secrets, keys, and certificates. Changes are written to audit logs, which are not tamper-evident.

Vault Access Model

Access to a vault is determined by:

1. user membership in the project
2. user role within the project
3. whether the vault is restricted

By default, users who belong to a project can access all vaults in that project, subject to their role permissions.

Restricted Vaults

A restricted vault is a standard vault with an additional access rule enabled. When a vault is marked as restricted, project membership alone is no longer sufficient to access its contents. Only users explicitly added to the restricted vault can view or manage the resources inside it.

Restricted vaults are useful when certain secrets, keys, or certificates require tighter control than the rest of the project.

When to Use Restricted Vaults

• the vault contains highly sensitive credentials
• access should be limited to a small subset of users
• you need stricter separation than the rest of the project
• you want to isolate production or security-critical resources

Restricted vaults change who can open the vault in the web interface. They do not change storage. The vault access key still reads the whole vault and does not follow the restricted-user list.

Access Evaluation Order

When a person uses the web interface, Secryn evaluates permissions in this order:

1. project membership
2. user role within the project
3. restricted vault membership (if enabled)
4. resource visibility (for public keys and certificates)

A vault access key skips that list. It is one read-only bearer token for the vault. A public resource token skips it for that single key or certificate.

Vault Lifecycle

Vaults are created within a project and persist for the lifetime of that project. Access rules can be modified at any time, and resources within a vault can be added, updated, archived, or restored without affecting the vault itself.

Vaults provide a stable, auditable boundary for managing sensitive data over time.

Vaults are the primary workspace in Secryn. By combining projects, vaults, and restricted access rules, you can design a security model that scales from simple setups to complex, highly controlled environments.