Credential vault

The credential vault keeps the shared secrets a team needs — service-account passwords, API keys, Wi-Fi keys, license keys, connection strings — out of chats and spreadsheets and under one governed, audited roof.

Encrypted, never in the clear

Every secret is sealed with AES-256-GCM and stored encrypted at rest. ITOps360 staff and the database never see plaintext. Lists show secrets masked; the real value leaves the server only on a verified reveal.

Reveal is a deliberate, audited act

• Permission. Seeing that a secret exists needs Vault.Read; revealing its value needs Vault.Reveal.
• Step-up. A reveal prompts for a code from your authenticator app before the value is shown or copied.
• Audit. Every reveal — and every denied attempt — is written to the hash-chained audit trail, so who saw what, and when, is never in doubt.

Roles with read-only access see that a credential exists and who owns it, but never its value.

Built for good hygiene

• Rotation dates. Set a rotation-due date; the vault flags secrets that are overdue or due soon, so a leak’s blast radius stays small.
• Strong generation. A built-in generator creates strong random secrets when you add or rotate one.
• Context. Tag secrets, link them to the devices or assets they belong to, and note where they are used.

Set it up

Open People → Vault, add a secret with its type and (optionally) a rotation date, and share access by role. Reveal or copy a value when you need it — you’ll be asked to verify first.