Credential security
Shared password vault with audited reveal and rotation
Store shared account logins encrypted at rest, grant scoped access, and reveal or rotate with a full access log — so shared credentials stop living in spreadsheets and chats.
Running in production today: encrypted credential storage with audited reveal, rotation, and an access log.
- Product proof
- Already live in the product
- Backed by app modules
- Protected app route: /security/shared-vault
Built around real workflows
Highlights below describe capabilities already present in the protected app behind this page.
Encrypted-at-rest shared credentials
Scoped access grants
Audited reveal and rotation
Access log for accountability
How it works
- 01
Store a shared login
Add a credential with its username, password and optional shared TOTP seed. Both secrets are Fernet-encrypted before they are saved and are never returned in plaintext through the API.
- 02
Organise by client and category
Tag each entry with a client name and a category — Google/Google Ads, Shopify, Meta, hosting, domain, social or other — so an agency-style tenant can find the right login fast.
- 03
Grant scoped access
Give individual members a use grant (list and reveal) or a manage grant (also edit and re-grant). Grants can carry an expiry so temporary access lapses on its own; admins implicitly manage everything.
- 04
Reveal under audit
Every reveal, copy or change is written to an immutable access log — who, what and when — so a shared login stops being anonymous.
- 05
Rotate on policy
Set a rotation interval in days; the vault flags a credential as rotation-due once the interval passes, and alerts can fire on overdue rotation or on a reveal from a never-before-seen IP.
A worked example
Say a twelve-person marketing agency shares one Google Ads login across five staff, kept until now in a spreadsheet nobody audits. Moved into the vault, the login is stored encrypted under the client's name, three campaign managers get a use grant, one lead gets manage, and a 90-day rotation interval is set. Months later a contractor rolls off: their grant is revoked in one click, and the access log still shows each time they revealed the password while they had it — the exact trail a client asks for when they wonder who could touch their ad account.
What teams can do here
- Step 1
- Add a shared credential
- Step 2
- Grant scoped access
- Step 3
- Reveal when needed (audited)
- Step 4
- Rotate on a schedule
Frequently asked questions
See also: Access control & conditional access · Mobile device management · Blog: What is endpoint security? · Blog: MDM best practices · Security Trust Center
Shared logins without the anonymous spreadsheet
Encrypted credentials and TOTP seeds, scoped use/manage grants with expiry, and an immutable reveal log — so a shared account always has an answer to "who accessed this, and when?"