A sent password never leaves
It stays in both mailboxes, in the backups of both mail servers and in every search index along the way, long after the work it was sent for is finished.
Secure Send
Send one credential to someone outside the vault
A link that expires, counts its views and then stops working — so a client or a contractor gets the one password they need, without an account, and without that password sitting in a mailbox for years.
Every team sends passwords to outsiders. Usually by e-mail.
A supplier needs the router password, an auditor needs a read-only login, a freelancer needs the staging credentials for a week. The vault cannot reach them, so the password leaves it the quickest way available — and stays wherever it landed.
An account is too much for one password
Creating a vault account for an outsider means standing access, folder rights to get right, and an offboarding step that someone has to remember once the job is done.
Scanners open one-time links first
Mail security gateways and chat previews follow links as soon as they arrive. A link that reveals its content on first opening is consumed before the person it was meant for ever sees it.
Nothing is revealed until the recipient asks for it
A Secure Send link is not a page that displays a password. It is a request the recipient has to confirm, checked against every limit at the moment they do.
-
Step 1
Choose what to share
From the item, set how many days the link lives and how many views it allows, within the limits your administrator set. Add a passphrase, and the current TOTP code if the recipient needs it.
-
Step 2
Send the link
Copy the link and send it as usual. Send the passphrase through a different channel — a phone call, a chat — so that intercepting one message is not enough.
-
Step 3
The recipient confirms
Opening the link shows the expiry date, the remaining views and, when configured, the sender's organisation. Nothing is decrypted and nothing is counted until the recipient confirms.
-
Step 4
Revealed, counted, gone
The view is reserved before the content is shown. When the last view is used or the expiry date passes, the link stops working for good.
The sender's access is checked again at every opening. A link created by someone who has since been disabled, or who lost access to the item, stops working — even if it has not expired yet. Deleting the item stops its links too.
Two clicks from the item you already have open
- Secure Send sits in the item's toolbar, next to Share and Notify
- The dialog shows what the recipient will see about you before the link exists
- A badge on the item row counts its active links
- My secure sends lists your active links, and revokes any of them
- An item set to delete itself after a number of views, or at a date, does so through a link exactly as through the item viewer
A page that says who is asking, before it shows anything
The recipient has never seen your Teampass. The page they land on has to earn their trust — and give them a reason to check the address before typing a passphrase.
- Your organisation name and your logo, when it is an image stored on the server
- The sender's first and last name, only if the administrator enables it — never a login or an e-mail address
- The expiry date and the remaining views, before anything is revealed
- A reminder to check that the page address belongs to the sender's organisation
- Light and dark mode, in the visitor's language or the instance's default one
No third party learns that a link was opened. A logo given as an external URL stays on the login page only: the recipient page uses a logo stored on your server, or none, so opening a link never contacts another host.
A link to a password has to fail closed
Every limit is enforced by the server, at the moment the link is used — not by the page, and not only when the link is created.
Confirmation before reveal
Only an explicit confirmation reveals the content and uses a view. Link previews and scanners open the page and consume nothing.
Limits that hold under load
Views and failed attempts are reserved in a single database transaction, so concurrent requests cannot exceed a link's limits. Five wrong attempts revoke it.
Access checked at every opening
The sender's current right to the item is verified when the link is created, again before anything is decrypted for the recipient, and when the sender lists their links.
A copy, frozen at creation
The link carries an encrypted copy of the item as it was. A description too long for it is shortened and both sides are told; the credentials themselves are never cut.
TOTP codes, never the seed
When the sender chooses to share it, the recipient gets server-generated codes. The TOTP secret is never sent to a browser.
Nothing for the browser to keep
The recipient page forbids caching, framing and referrers, and runs under a restrictive Content Security Policy.
Senders choose within limits you set
The settings live under Settings → Options, in the Collaboration group, except the organisation name, which is in General Info. The names below are the ones the settings page shows.
| Setting | New installation | What it controls |
|---|---|---|
| User can propose One-Time-View links | Off | Turns Secure Send on |
| One-time-view (OTV) links expire after XX days | 7 | The longest validity a sender may choose, also proposed by default |
| Secure Send maximum number of views per link | 5 | The most views a sender may allow; the form proposes 1 |
| Force a passphrase on every Secure Send link | Off | Makes the passphrase mandatory; links already sent without one stop working |
| Allow sending ad-hoc notes/secrets (not only items) | Off | Lets users share a standalone note instead of an item |
| Show the sender's profile name to Secure Send recipients | On | Shows the sender's first and last name; off after an upgrade until enabled |
| Public entity name | Empty | The organisation name shown to recipients |
| Public sharing address | Empty | A separate address senders may choose for links meant for the Internet |
Publishing links
Reachable from the Internet, with the vault still private
Recipients are outside your network, your vault should not be. A public sharing address puts the recipient page on a dedicated hostname, and the sender picks it link by link — the internal address stays the default, and the dialog always shows which one a link will use.
- Apache and Nginx allowlists that accept the exact requests of the recipient page and refuse everything else
- Reverse-proxy and Docker setups, TLS, and sessions on several nodes
- Logging without the link credentials, and a validation matrix to test the result
Since 3.2.2.7 the official Docker image logs requests without their
query string and without the Referer header, so the
credentials carried by a link never reach the container's access log.
What a Secure Send link does not carry
Custom fields, tags and attachments
The shared copy holds the label, login, URL, description and password, plus the TOTP code when the sender chooses to include it. Files and custom fields stay in the vault.
Ongoing access
A link is for handing over a credential once, or a few times. Someone who needs the item for months belongs in Teampass, with an account and folder rights you can review.
From switched off to a first link
-
Set the policy
In Settings → Options → Collaboration, turn on User can propose One-Time-View links, then set the longest validity, the view limit and whether a passphrase is mandatory.
-
Decide where links point
Internal recipients only? Nothing more to do. Outsiders? Declare a public sharing address and publish it by following the deployment guide, then set your organisation name.
-
Send the first one
Open an item, choose Secure Send, generate the link and copy it. Send the passphrase separately, and watch the link in My secure sends.
Recipient confirmation, frozen copies, TOTP sharing and the public sharing address arrived in 3.2.2.6, the branded recipient page in 3.2.2.7 — see What's new. Every setting and limit is described in the Secure Send documentation.
Straight answers
Does the recipient need a Teampass account?
No. They open the link in a browser, on a page served by your own Teampass server. There is nothing to install and no account to create — and therefore nothing to offboard afterwards.
Can a mail scanner or a link preview use up the link?
No. Opening the link only shows a confirmation page, with the expiry date and the remaining views. The content is revealed, and a view counted, only when the recipient confirms. Security gateways and chat previews that follow links consume nothing.
What if I change the item after sending the link?
The link shares a copy of the label, login, URL, description and password as they were when it was created, so later edits do not reach the recipient. Deleting the item, or losing your own access to it, still blocks the link.
Can I share a TOTP code?
Yes, explicitly: tick Include the current TOTP code when you create the link. The recipient receives a code generated by the server, and the next one when the current code is about to expire — never the TOTP secret. The option is unchecked by default and is not offered to read-only accounts.
What stops someone from guessing the passphrase?
Five wrong key or passphrase attempts revoke the link. Failed attempts are counted in the same database transaction as the views, so parallel requests cannot get around the limit.
What does the recipient learn about me?
The organisation name your administrator sets, and — only if the administrator enables Show the sender’s profile name — your first and last name. Never your login, never your e-mail address. You see in the Secure Send dialog what the recipient will be shown.
Can I cancel a link I already sent?
Yes. My secure sends lists your active links, and each one can be revoked. A link also stops working on its own when it expires, when its last view is used, or when you lose access to the item.
Can the links be reachable from the Internet while the vault stays internal?
Yes. The administrator can declare a public sharing address, and the sender chooses it per link — the internal address stays the default. The Secure Send deployment guide explains how to publish that address so it exposes the recipient page and nothing else.
Is it enabled by default?
No. An administrator turns it on with User can propose One-Time-View links, in the Collaboration settings, and sets the limits that every link must respect.
Can I send something that is not an item?
Yes, when the administrator enables Allow sending ad-hoc notes/secrets: a standalone note gets its own link, with the same limits. It is off by default.
Stop e-mailing passwords.
Install Teampass, turn Secure Send on and send the next credential as a link that expires on its own.