The 1Password alternative built for vendor access
1Password hands out vaults. You need to hand out one credential, to one person, for four hours, and be able to prove afterwards who opened it and who said yes.
In 1Password, the unit of access is a vault. A guest gets the whole thing, and keeps it until an admin takes it away.
Here, the unit of access is a credential. It is requested, approved, and it expires by itself.
A vault is the wrong unit
Every team ends up here. A contractor needs the ad platform login, so somebody creates a "Vendors" vault and adds them as a guest. It takes ten seconds and it solves today's problem.
But a vault is a container, and you just handed over the container. 1Password is explicit about this: a guest gets “access to a single vault which you choose”. Not the one credential they needed. All of it. And it lasts until a human remembers to go and take it away.
Nobody remembers. That is not carelessness, it is arithmetic: permissions only ever accumulate, because nobody is thanked for removing one and removing the wrong one breaks someone's work.
Side by side, in their own words
Every claim below about 1Password is a quote from 1Password's own documentation, linked so you can check it. Scoped to the job you came here for: giving an outside person access to a credential you own.
| 1Password Business | Vendor Access Vault | |
|---|---|---|
| The unit of access | A whole vault. A guest is given one vault and can open everything inside it. “They don't have their own Employee vaults and only have access to a single vault which you choose.”Source: their documentation | A single credential. Access is granted to one secret, not to a container of them. |
| How access begins and ends | An admin adds the person to the vault. The access lasts until an admin removes them. “After you've confirmed a guest, you can add them to a vault and manage their access to it, like you would a team member.”Source: their documentation | The person requests one credential with a justification and a duration. An admin approves. The grant then expires on its own, with nobody having to remember. |
| Request and approval | A request-and-approve flow does exist, but in SaaS Manager (part of Extended Access Management, priced on request, not included in Business), and what you request is access to an app, not to a stored credential. “Employees can browse available apps, see which are pre-approved for their team, and request access in just a few clicks.”Source: their documentation | Built in, free, and it governs the credential itself. Nothing is revealed until somebody approves that specific request. |
| One-off share links that expire | Yes. 1Password can share an item via a link with an expiry. “Choose when the link expires and who it's available to: anyone with the link or only specific people.”Source: their documentation | Yes, and the ongoing access expires too, not just a one-off link. |
| Logging when someone opens an item | Yes. 1Password Business reports item usage events through its Events API. “sign-in attempts, item usage, and audit events”Source: their documentation | Yes, append-only, with actor, timestamp, IP and user agent, and each reveal is tied to the approval that authorised it. |
| Cost for a team of ten | $8.99 per user per month billed annually, so roughly $1,079 a year for a team of ten. “$8.99 USD per user, per month. Paid annually.”Source: their documentation | Free while we build it. Every feature, unlimited team members. |
What replaces it
- The contractor requests one credential, with a justification and a duration.
- An admin approves or denies. Until then, nothing is visible.
- On approval they can reveal it, and every reveal is written to an append-only audit log with the actor, timestamp, IP and user agent, tied to the approval that authorised it.
- The access expires on its own. No cleanup task, no calendar reminder.
- Offboard the vendor and every pending request against its credentials is denied in the same transaction.
Now "can the agency we fired in March still get into our ad account?" has an answer. See vendor offboarding or the security model.
Common questions
- Do we have to drop 1Password to use this?
- No, and most teams do not. 1Password is where your employees' day-to-day logins belong. What we replace is the shared vault you spun up for vendor and contractor credentials, where the unit of access is the whole vault and it lasts until somebody remembers to take it away.
- What is actually different?
- Scope. In 1Password, the thing you grant is a vault, and the thing their approval workflow governs (in SaaS Manager, sold separately) is an app. With us, the thing you grant is a single credential, the approval governs that credential, and the grant expires by itself. That is the whole difference, and it is the difference that decides whether you can answer 'who opened the Stripe key in March, and who approved it?'
- Does 1Password have an audit log?
- Yes, and be sceptical of any comparison page that tells you otherwise. 1Password Business reports item usage through its Events API. The difference is what the log can prove: because every reveal here happens behind an approval, our log ties the reveal to the person who authorised it, not just to the person who opened it.
- 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.
- What does it cost?
- Nothing. Free while we build it, with every feature and unlimited team members.
Keep reading
- vs LastPassLastPass tells admins, in its own docs, not to use its logs as audit evidence.
- Sharing credentials with contractorsThe workflow that replaces the shared vault, end to end.
- Offboarding a vendorCut off everything a vendor could reach, in one action.
- PricingFree. Every feature, unlimited team members.
Give contractors access that expires on its own
Free while we build. No credit card, no sales call.