# Security: confidentiality levels, master password and vault 2FA

{/* AUTO-SYNCED SOURCE: this page lives in apps/app/src/modules/credentials/docs/ and is mirrored into the docs app by `bun sync:module-docs`. Edit it in the module, not in apps/docs. */}
<Lead>
The credentials vault (Zugangsdaten-Tresor) encrypts every secret, but not every secret equally strictly. This page explains what the three confidentiality levels mean technically, when you need a master password, how vault 2FA works and which policies your team can define.
</Lead>

## The three confidentiality levels in detail

<DefinitionList>
  <DefItem term="Standard">
    The secret is stored encrypted on the server with AES-256-GCM. Anyone allowed to see the entry can reveal the secret without an extra step. Every reveal is logged.
  </DefItem>
  <DefItem term="Sensitive (Sensibel)">
    Same encryption as standard. In addition, the reveal dialog requires the mandatory field **Grund für den Zugriff (Pflicht)** (reason for access, required), for example "login for property handover". The reason is logged and can be looked up in the audit log later.
  </DefItem>
  <DefItem term="Hyper-sensitive (Zero-knowledge)">
    The secret is encrypted directly in your browser before it ever reaches the platform. A key is derived from your personal master password using Argon2id, and encryption uses AES-256-GCM. The server never sees the plaintext or the key at any point.
  </DefItem>
</DefinitionList>

Two special rules apply to hyper-sensitive entries:

- They can **not be shared externally via link**.
- If you change an entry's confidentiality level, you must re-enter the secret and the notes. That is not a bug: the data has to be re-encrypted for the new level.

## The master password (hyper-sensitive only)

The master password applies exclusively to entries on the **hyper-sensitive** level. Standard and sensitive entries do not need one, and it does not lock the vault as a whole.

When you set it up, the dialog warns you in no uncertain terms: this password is NOT your login. Without it, nobody, not even us, can decrypt your hyper-sensitive entries. There is no recovery. Your team's policy defines how long and how strong the master password has to be (default: 12 characters, medium strength); the dialog tells you during setup if it falls short.

From then on:

- To reveal a hyper-sensitive entry you unlock with **Gib dein Master-Passwort ein** (enter your master password). A wrong entry shows **Falsches Master-Passwort.** (wrong master password).
- If vault 2FA is set up, the extra step **Zweiter Faktor** (second factor) follows, asking for the code from your authenticator app.
- The decrypted key stays **only in the current browser tab**. Reloading the page or closing the tab means unlocking again.

<Danger title="No recovery, really">
There is no "forgot password" path for the master password: no recovery codes, no admin reset, no operator backdoor. That is the essence of zero-knowledge. Keep the master password in a safe place that only you know.
</Danger>

### Unlocking with your fingerprint instead of the password

Nobody types a long master password on a phone several times a day. Anyone who tries picks a short one, and then the strongest level is the weakest. So you can **enrol each device once** and unlock with fingerprint, face recognition or the device PIN afterwards.

<Steps>
  <Step title="Unlock once with the master password">
    Right after that the vault asks: **Auf diesem Gerät merken?** (remember on this device).
  </Step>
  <Step title="Confirm">
    Your device asks for your fingerprint or face. Done.
  </Step>
  <Step title="From now on">
    The unlock dialog shows **Mit diesem Gerät entsperren** (unlock with this device) at the top. The master password stays below it and keeps working.
  </Step>
</Steps>

**Your master password is not stored.** The key is wrapped in a value that only this device hands out, and only after it has verified you. Our servers hold nothing but the wrapped package. Without the device it is worthless, to us as well. The promise of the highest level does not change.

You can enrol several devices (phone and computer) and remove individual ones. The list sits in the unlock dialog, which is exactly where you look for it when a device has gone missing.

<Callout tone="info">
If vault 2FA is mandatory in the workspace, the fingerprint route asks for **no** additional code. That is deliberate: an enrolled device that verifies you is already possession plus inherence, which is precisely what a second factor is meant to establish. The password route still asks for the code.
</Callout>

<Callout tone="warning">
Older browsers cannot do this (it needs the PRF extension for passkeys, available in Chrome and Android and in Safari and iOS from version 18). There the master password remains the way in, and the vault says so rather than quietly doing something weaker.
</Callout>


## Vault 2FA

**Tresor-2FA** (vault 2FA) is a second factor specifically for the vault, using TOTP codes from an authenticator app: when unlocking hyper-sensitive entries, and, if your team requires 2FA, additionally as a confirmation for sensitive entries, external links and imports (see below). It is **separate from the two-factor login of your platform account**: you set it up yourself inside the vault via the header button **Tresor-2FA**.

<Steps>
  <Step title="Connect your app">
    The dialog shows a setup key (Base32) and an otpauth link for common apps such as Google Authenticator, 1Password or Aegis. Use **Schlüssel kopieren** (copy key) to transfer the key into your app.
  </Step>
  <Step title="Confirm with a code">
    Enter the current 6-digit code under **Code aus der App zur Bestätigung** (code from the app to confirm). Vault 2FA only becomes active with a valid code.
  </Step>
  <Step title="Done">
    From now on, unlocking requires a code from your authenticator app in addition to the master password.
  </Step>
</Steps>

To **deactivate**, open the same dialog and enter a valid code under **Zum Deaktivieren aktuellen Code eingeben** (enter current code to deactivate). If a code is rejected, the message reads: **Der Code stimmt nicht. Prüfe die Uhrzeit deiner Authenticator-App.** (the code does not match, check your authenticator app's clock). TOTP codes depend on the time; a drifting device clock is the most common cause.

### Confirmation when 2FA is required

If your admin has switched on the **2FA requirement**, the vault checks the second factor not only in the browser but on the server. Specifically:

- When opening a **sensitive** or **hyper-sensitive** entry, when fetching a one-time code for it, when creating an **external link** and when **importing**, the vault asks once for the code from your authenticator app. The confirmation then lasts as long as a vault session according to the policy (at most twelve hours with **Bis Browser schließt**), not again for every entry.
- Standard entries still open without a code.
- If you have not set up vault 2FA yet, exactly these steps are blocked until you do. The dialog takes you straight there.
- The fingerprint route for unlocking stays without an additional code, as described above. The server still asks for the confirmation for sensitive entries once per session, because only the code from the app is verifiable for it.

<Warning title="Keep the setup key safe">
There are no recovery codes and no admin reset for vault 2FA. If you lose the device with your authenticator app, you can only get back to hyper-sensitive entries if you kept the setup key and reconnect an app with it. Copy the key during setup and store it somewhere safe.
</Warning>

## Team policies

At `/settings/tools/credentials` (section **Sicherheit & Standardwerte**, security and defaults) your admin defines the vault policies for the whole workspace. Note: **Nur Admins dürfen speichern.** (only admins may save).

<Info title="Policies: an honest classification">
Every setting on this page has an effect. The 2FA requirement is checked by the server for sensitive and hyper-sensitive entries, external links and imports (see **Confirmation when 2FA is required** above); members without vault 2FA additionally see the banner **Dein Team verlangt einen zweiten Faktor für den Tresor. Richte die Tresor-2FA jetzt ein, um voll geschützt zu sein.** (your team requires a second factor for the vault, set up vault 2FA now). Standard entries stay readable for them.
</Info>

Tab **Sicherheit** (security):

<DefinitionList>
  <DefItem term="Tresor-Sitzung läuft ab nach (vault session expires after)">
    How long an unlocked vault session should last: **15 Minuten**, **30 Minuten (empfohlen)** (recommended), **4 Stunden** (hours) or **Bis Browser schließt** (until the browser closes).
  </DefItem>
  <DefItem term="Automatische Sperre bei Inaktivität (auto-lock on inactivity)">
    After how much idle time the vault should lock: **Aus** (off), **5 Minuten**, **10 Minuten (empfohlen)** or **30 Minuten**.
  </DefItem>
  <DefItem term="Tresor-2FA (TOTP) für alle erzwingen (require vault 2FA for everyone)">
    Requires a second vault factor from every member. Sensitive and hyper-sensitive entries, external links and imports then ask once per session for the code from the authenticator app; without vault 2FA set up, these steps are blocked.
  </DefItem>
  <DefItem term="Mindestlänge (minimum length)">
    The required minimum length for master passwords, adjustable from 8 to 20 characters. Applies when a master password is set up; existing passwords stay valid.
  </DefItem>
  <DefItem term="Mindeststärke (minimum strength)">
    The required strength for master passwords, including the option **Keine Mindeststärke** (no minimum strength). Also applies at setup.
  </DefItem>
</DefinitionList>

The former setting **Export nur mit Grund** (export requires a reason) has left the panel: the vault has no export it could govern. It returns once there is one.

Tab **Allgemein** (general):

<DefinitionList>
  <DefItem term="Sichtbarkeit neuer Einträge (visibility of new entries)">
    The default suggestion for new entries: **Privat** (private), **Team** or **Benutzerdefiniert** (custom).
  </DefItem>
  <DefItem term="Papierkorb-Aufbewahrung (trash retention)">
    How long deleted entries remain restorable: 30 to 365 days.
  </DefItem>
</DefinitionList>

## Further reading

How revealing with a mandatory reason works in practice is shown in [Managing entries](/tools/zugangsdaten-tresor/eintraege#revealing-a-secret-safely). Who may do what in the vault is covered in [Audit and permissions](/tools/zugangsdaten-tresor/audit-und-berechtigungen). Back to the overview: [Credentials vault](/tools/zugangsdaten-tresor).