# Vault check and access log
{/* 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. */}
A vault is a place where things go in and nobody ever looks again. That is exactly why it has two areas that look for you: the **vault check** and the **access log**.
## The vault check
You find it in the sidebar under **Tresor-Check**. It reviews every entry you are allowed to see and reports what needs attention.
At the top there is a verdict in three steps: **all good**, **a few things to look at**, or **something to do here**. Deliberately not a score from 0 to 100. Such a number implies a precision that does not exist, and it invites people to optimise the number instead of fixing the findings.
### What the check finds
| Finding | What it means |
|---|---|
| **In a known breach** | The password appears in a published collection and must be considered known. Change it now. |
| **Reused** | The same password sits on several entries. If one becomes known, all of them are open. |
| **Too weak** | Short, guessable or built from a recognisable word. The generator in the entry creates a replacement in one click. |
| **Expired** | The stored expiry date is in the past. |
| **Expiring soon** | Less than 30 days. Renew before the access breaks in the middle of a transaction. |
| **Not changed for over a year** | For shared credentials the circle of people who know it grows over time. A change resets it. |
| **Not opened for over a year** | Probably no longer needed. Deleting it reduces the attack surface. |
| **Created by someone who left** | That person is no longer in the workspace. They still know the password. |
| **Only one person has access** | If that person is unavailable, nobody can get in. A second grant or emergency access solves it. |
Every finding links straight into the filtered list. A finding you cannot act on is just nagging.
### Checking against known breaches
The vault can compare your passwords against published collections. **No password leaves the platform**: only the first five characters of a hash are sent, and millions of real passwords match those five characters. The service does not learn which one is yours, or whether yours was among them at all.
Three things are required:
1. You are an owner or administrator of the workspace.
2. The switch **Leck-Prüfung erlauben** is on in the vault settings under **Prüfungen**. It is off by default.
3. The consent for processing outside the EU exists under **Settings, Privacy**.
The switch says "we want this", the consent says "we may do this". Both are needed.
If the service is unreachable, an entry is **not** counted as checked. The difference between "checked and clean" and "could not check" is the difference between an assurance and a guess.
## The access log
In the sidebar under **Zugriffs-Protokoll**. Line by line it shows who opened, copied, opened via a link or exported which entry, and for sensitive entries the reason they gave.
The most recent lines also appear inside the entry itself under **Zuletzt geöffnet**, so nobody has to go looking.
**Viewed and copied are two different events.** A copied password sits in the clipboard, a viewed one only on screen. If something ever has to be reconstructed, that is exactly the distinction people ask about.
Whoever may see an entry may also see who opened it. That is intentional: a shared password where only the manager sees the accesses turns colleagues into the observed. When everyone involved sees it, it is shared oversight.
**The log never contains a secret.** Not even a truncated one.
## The trash
Deleted entries land in **Papierkorb** and can be restored with one click. How long they stay is set in the vault settings under **Allgemein**; after that they are removed automatically.
Permanent deletion is only possible from the trash and only with the **delete entries** permission. A path that removes a live entry irreversibly in one step would be a trap.
Permanent deletion also removes the access log for that entry. If you need the history for an audit, leave the entry in the trash.
## When someone leaves
At the bottom of the vault check there is **Beim Ausscheiden einer Person**. Pick the person and you see which credentials they opened, and which of those have been changed since.
The time window is **90 days** by default and switches to **30 days** next to it. 90 days is the safe choice and also catches the portals someone opened once months ago. 30 days shows what the person used most recently, for when you can only do the most urgent ones.
Anything marked **offen** is still known to that person. Change those at the provider and enter the new value in the vault; the entry then counts as rotated and drops off the open list.
If that is not possible in the vault (because the credential is not kept there at all, for instance), use **Als gewechselt markieren** on the row, or **Alle offenen markieren** for the whole list at once. This changes no password. It only records that you set a new one at the provider.
**Liste exportieren** gives you the credentials as a table to work through. It contains no passwords, only what needs doing.
This area requires the **read all entries** permission, because it is information about a person rather than about an entry. Marking additionally requires the **rotate passwords** permission.
When you reset or delete a seat in member management, the confirmation names how many credentials are affected and links here. Look at the list before you **delete**: afterwards the link between the access log and that person is removed and the list can no longer be retrieved. The counts stay in your workspace audit log.
## Frequently asked questions
At the highest tier the secret is encrypted in your browser before it is stored. The server never sees it and therefore cannot assess it. That is not a gap, it is the whole point of that tier.
No. It sees exactly what you see in the list. A check that reported findings about invisible entries would reveal that they exist.
When a secret is saved, a keyed check value is derived from it. Only those values are compared. They reveal exactly one thing, namely whether two values are the same, and nothing else.
Twelve months. Older lines are then removed automatically, because the log contains personal data and should not grow without limit.