How to Share Credentials with Contractors and Vendors (Without Email or Slack)
TL;DR: Contractors and vendors sit outside your organization. You can’t add them to your password vault, and you shouldn’t email them credentials. Ephemeral, self-destructing links solve the outbound problem — the credential disappears after retrieval, nothing persists in anyone’s inbox. For the other direction (collecting credentials from contractors), a secure request link lets them submit credentials to you without email or chat. No accounts needed on either side.
The Problem with External Parties
Internal credential sharing has good solutions. Your team probably uses a password manager — 1Password, Bitwarden, Keeper — and sharing within the org is straightforward.
Contractors and vendors are a different problem. They’re not in your directory. They don’t have access to your vault. They’re working with you for six weeks or six months, and during that time they need database credentials, API keys, staging environment logins, service account passwords.
The typical path is the fastest one available: a Slack DM, an email, a Teams message, a text. It takes ten seconds and works immediately.
It also means that credential is now sitting in a message history that will outlive the engagement by years. When the contractor is gone, the credential isn’t.
What Typically Goes Wrong
| Method | Why it fails |
|---|---|
| Searchable forever. Forwarded unknowingly. Compromised in a breach and every credential ever sent through it is exposed. | |
| Slack / Teams DM | Persists in message history. Discoverable by workspace admins and anyone who compromises an account. |
| Shared Google Doc | Accessible to anyone with the link. No access logging. Forgotten about and left open indefinitely. |
| Text message | Unencrypted in transit on most carriers. Stored on the device. Backed up to iCloud or Google. |
The issue isn’t that people are careless. It’s that none of these tools were designed for credential sharing, and they all default to persistence.
How Ephemeral Sharing Works
The concept is straightforward. Instead of sending the credential itself, you send a link. The recipient opens the link, retrieves the credential, and the link self-destructs.
With Password Pusher, the workflow looks like this:
- Paste the credential and set an expiration — after one view, after 24 hours, or whatever makes sense
- Optionally add a passphrase (communicated separately — a phone call works)
- Send the generated link to the contractor through whatever channel you normally use
- The contractor opens the link, copies the credential, and the link is permanently destroyed
- You get a full audit trail — who accessed it, when, how many times
The contractor doesn’t need an account. No signup, no login, no app to install. They click a link, get the credential, and the link is gone.
If a link scanner (Microsoft 365 and Google Workspace both do this) opens the link before the contractor does, the retrieval step catches it — the link requires a deliberate click to reveal the payload, so automated scanners don’t consume the view.
The Other Direction: Collecting Credentials from Contractors
This is the part most guides skip. Sharing credentials with contractors is half the problem. The other half is collecting credentials from them.
A contractor sets up a staging server and needs to hand you the admin credentials. A vendor provisions an API key and needs to get it to your team. An MSP rotates a client’s service account password and needs to deliver it securely.
Password Pusher’s Requests feature handles this. You create a request link and send it to the contractor. They open it, paste the credential, and submit. You receive it as a self-destructing push with the same audit trail and automatic expiration.
The contractor still doesn’t need an account. They just fill in a form and submit.
What About Password Managers?
Password managers are the right tool for ongoing, internal credential management. If a contractor needs persistent access to shared credentials over the life of an engagement, adding them as a guest in your vault (1Password, Bitwarden, Keeper) may be the better answer.
Where ephemeral sharing makes more sense:
- One-time handoffs — a credential the contractor needs once during onboarding, not ongoing
- Contractors who won’t create an account — some won’t, especially for a short engagement
- Compliance-sensitive environments — you need a record that the credential was accessed exactly once and then destroyed
- The other direction — most password managers don’t have a mechanism for external parties to submit credentials to you
These approaches aren’t mutually exclusive. Plenty of organizations use a password manager for their team and ephemeral links for external handoffs.
Where This Might Not Be the Right Fit
Ephemeral sharing solves the ad-hoc credential handoff. It doesn’t solve:
- Ongoing access management — if a contractor needs persistent access to a system, provision them a proper account with scoped permissions and an expiration date
- Application-level access — if you can grant access via SSO or OAuth instead of sharing a password, do that
- Credential rotation — if a credential is shared frequently with many parties, the underlying problem is probably that the system needs better access controls, not a better sharing mechanism
Getting Started
Password Pusher is free for basic sharing — no account required. Premium adds file attachments, auto-dispatch email delivery, and custom branding so contractors see your domain and logo instead of pwpush.com.
The open source edition can be self-hosted on your own infrastructure if your security policy requires it. The security-critical code — encryption, data handling, expiry, audit logging — is fully auditable on GitHub.
For API-driven workflows (onboarding automation, CI/CD credential delivery), the JSON API supports everything the web interface does.
Peter Giacomo Lombardo Founder & Principal, Apnotic · Creators of Password Pusher