User view
Why the Panel asks you to unlock, what happens to your encrypted history if you forget your password, and what an administrator can see.
Event and approval details are stored encrypted in the database. Only your sign-in can decrypt them. This page explains what that means for you day to day.
Why does the Panel ask me to unlock?#
Signing in proves who you are. After your password reaches the server it is checked against the stored hash and then forgotten. Imunify does not keep your password in memory or on disk after sign-in.
But your event and approval content — the paths your sensor saw, the system call arguments, the reasons rules matched — is stored encrypted with a key only your password can derive. So the first time you open Events or Approvals after signing in, the Panel prompts you to unlock by entering your password again. The server uses that password to decrypt your private key and keeps the unwrapped key briefly in memory, tied to your current sign-in session. While you stay unlocked, the Panel can show you the decrypted paths, arguments, and reasons on each card.
When your sign-in session expires (or you sign out), the unwrapped key is dropped from memory and you unlock again on the next sign-in. There is no setting to disable this — the unlock prompt is the only way the server can see your event content.
What if I forget my password?#
If you completely forget your password, an administrator can reset it for you. The reset is destructive for your encrypted history.
Here is what happens:
- A password reset destroys your old key generation. The wrapped private key for that generation is wiped from the database.
- All events and approvals encrypted with that old key are now permanently unreadable. The rows themselves stay in the audit trail — your operations team can still see that an event happened, when, on which sensor, and what decision was made — but the content fields (path, arguments, reason) read back as “Unreadable after key reset” in the Panel.
- After the reset, a new key generation is created and all new events and approvals are encrypted under it. From that point on, unlocking with your new password lets you read everything going forward.
If you still know your current password and just want to change it, use the Change password action in Settings instead. That path unwraps your private key with the old password, re-wraps it with the new one, and saves the same key — your encrypted history stays readable.
There is a related action on the same Settings page called Reset encryption key. It is the same destructive reset described above and is guarded by a confirmation where you must type your username to proceed. Use it only when you have already lost access to your historical data and want to start clean.
Does an administrator see my data?#
No. An administrator looking at your events and approvals sees only the operational metadata — sensor, timestamp, decision, container name, rule that matched — and the content fields appear as “Redacted”. Your workload content (paths, arguments, reasons) is not readable by an administrator without your password.
What an administrator can still do:
- See that an event happened, on which sensor, at which time, in which container, under which rule.
- Resolve approvals on your behalf if the rule allows it (the operational metadata is enough to make a decision on simple rules).
- Reset your password, which destroys your encrypted history per the section above. The reset is destructive by design — it is the only way to recover from a forgotten password, but it cannot be used as a back door because the act of resetting also irreversibly drops the data the admin might have wanted to read.
What an administrator cannot do, even with full database access:
- Read paths, arguments, or reasons from your events and approvals. Those fields are stored encrypted with your key.
What a database leak would expose#
If someone walked off with a dump of the database — and nothing else — they would have your encrypted event and approval rows and your encrypted private key. They would not have your password, and your password is what unlocks the chain. The plaintext content is not in the dump and the wrapped private key cannot be unwrapped without the password.
The protection is against database dumps, backup leaks, and casual operational inspection. It is not a defense against a live attacker who controls the running Panel server, can modify its code, attach a debugger to the running process, or capture a future unlock as you type your password. That class of attacker can see plaintext content the moment any user unlocks — keep your Panel server access tight.