The LastPass alternative for vendor credentials
If you are moving off LastPass, the question worth asking is not where the passwords live. It is whether you can prove who opened them.
LastPass's own documentation tells admins not to rely on some activity-log events as audit evidence, because they are reported by the client, which it says “is not a trusted source”. Opening a secure note is on that list.
Here, every reveal is recorded server-side, behind an approval, in an append-only log.
Read what LastPass says about its own logs
This is not our characterisation. It is a note in LastPass's own admin documentation, and we have linked it in the table below so you can read the whole thing:
“Some events in the activity log are reported by the LastPass client rather than recorded on the server. Since the client is not a trusted source, these reports can be altered or lost during transmission. The logs can only confirm that the client sent a report, and not that an action actually occurred. ... Use these events only for troubleshooting and diagnostics. Do not rely on them as audit evidence or to meet compliance requirements.”
The events that carry that warning include “Open secure note”, which is to say: the event where somebody looked at a secret.
If the reason you keep credentials in a manager at all is to be able to answer "who opened this, and when", that is a problem, and it is worth knowing before your next audit rather than during it.
Side by side, in their own words
Every claim below about LastPass is a quote from LastPass's own documentation, linked so you can check it.
| LastPass Business | Vendor Access Vault | |
|---|---|---|
| Can the log prove someone opened a secret? | LastPass tells admins not to use these events as audit evidence, because some are reported by the client rather than the server. The affected list includes “Open secure note”. “Do not rely on them as audit evidence or to meet compliance requirements.”Source: their documentation | Yes. Every reveal is recorded server-side in an append-only log with actor, timestamp, IP and user agent, and tied to the approval that authorised it. It is the record, not a hint. |
| The unit of access | A shared folder, and group membership cascades into every folder that group can reach. “Adding a user to a user group automatically gives them access to all shared folders that the group can access.”Source: their documentation | A single credential. Requested, approved, and expiring on its own. |
| How access ends | An admin acts. Offboarding is a set of manual account actions: disable, delete, separate, transfer, or replace the master password. “LastPass admins can disable or delete user accounts, separate them from the company, transfer them to another user, or make the accounts inaccessible for the owners by replacing the master password.”Source: their documentation | The grant expires by itself. Offboarding a vendor also denies every pending request against its credentials in the same transaction, and the audit log tells you exactly which credentials were actually revealed, so the rotation list is short and real. |
| Cost for a team of ten | $7.00 per user per month billed annually on Business, so about $840 a year for a team of ten. Their pricing page offers a 14-day trial. “$7.00 user/month billed annually”Source: their documentation | Free while we build it. Every feature, unlimited team members. |
What a log is actually for
A log exists to answer one question after something has gone wrong: who saw this, and who let them? A log that can only confirm a client said something happened cannot answer it.
Here the credential is only ever decrypted on the server, and only when somebody holding an approved, unexpired grant explicitly asks to reveal it. That act is what gets written down, with the actor, the timestamp, the IP, the user agent, and the approval that authorised it. Export it as CSV whenever you need it.
The security model spells out exactly how, including what we do not claim.
Common questions
- Is the LastPass audit log really not usable as evidence?
- For some events, LastPass says so itself. Its documentation notes that certain activity-log events are reported by the LastPass client rather than recorded on the server, that the client is not a trusted source, and that the logs can only confirm the client sent a report, not that an action actually occurred. It then says plainly: use these events only for troubleshooting and diagnostics, and do not rely on them as audit evidence or to meet compliance requirements. The affected list includes opening a secure note. We have linked the page so you can read it yourself.
- So what do you do differently?
- Every reveal happens on the server, behind an approval. The credential is decrypted server-side only when someone with an approved, unexpired grant explicitly asks for it, and that event is written to an append-only log with the actor, the timestamp, the IP and the user agent, linked to the approval that authorised it. It is not a client telling us what it thinks it did. It is the server recording what it did.
- Do we have to migrate everything off LastPass?
- No. Most teams keep their existing password manager for employees' day-to-day logins. What moves here are the vendor and contractor credentials, the ones where you actually need to prove who opened what, and when.
- Do you have SSO and SOC 2?
- Both are on the roadmap. If your procurement process requires a SOC 2 report today, we are not there yet.
An audit log you can actually stand behind
Free while we build. No credit card, no sales call.