You should not send a password by email because email does not deliver, it copies: the key sits in plain text in the recipient's mailbox, on their phone, in the histories and in the backups, with no expiry and with no way of knowing who has seen it. The right way to share it is a one-time link that shows the content once and deletes it, with recipient verification and a record of the handover.
Where a password sent by email really ends up
Email is designed for the opposite of what you need here: for the message to arrive, be kept, and be retrievable. When you type a key into the body of a message, you are creating copies in places you have no control over. These are the ones people usually forget:
| Where it stays | For how long | Who can end up reading it |
|---|---|---|
| Your Sent folder | Until someone deletes it: nobody does | You, and anyone who reaches your account |
| The recipient's mailbox | Indefinitely | That person and anyone with access to their session |
| Their phone and laptop | As long as the account is configured | Whoever picks up the unlocked device, or steals it |
| Mail server backups | Whatever your retention policy says: months or years | Systems administration and anyone restoring a backup |
| Forwards and reply chains | Forever, and growing | Anyone who joins the thread later |
| Archiving and eDiscovery tools | The statutory retention period | Legal, compliance and external auditors |
On top of that comes what you cannot see. A credential shared this way has no owner, no date and no inventory. The day that person changes jobs, the supplier stops being a supplier, or there is an incident, nobody knows which keys need rotating, because nobody knows how many were handed out or to whom.
And this is not a theoretical risk. The Verizon Data Breach Investigations Report 2026 puts credential abuse in 39% of all analysed breaches at some point in the attack chain: the single most pervasive technique in the report, even though as an initial access vector it fell to 13% from 22% the year before, overtaken by vulnerability exploitation.
Why people keep doing it
Not through carelessness. Through the absence of an alternative at the exact moment one is needed. Someone has to give the engineer arriving this afternoon the FTP password, or pass the client the PIN of a digital certificate, or hand today's new joiner their first-day credentials. What they have to hand is email and chat. What they do not have to hand is anything else.
The pattern repeats with every tool banned without a substitute: the same story we tell about shadow AI and about consumer file-sharing services. Banning without a usable alternative does not change behaviour: it only makes it invisible to you.
The only relevant public measurement of this habit is a few years old by now, but it still illustrates the point: in Keeper's Workplace Password Malpractice Report, a survey of 1,000 US workers conducted in February 2021, 62% said they had shared a work password over text message or email. Take it for what it is — old, and one market only — and compare it with what you find in your own Sent folder if you search for the word "password".
A one-minute test. Search your corporate mailbox for "password", "credentials", "login details" or "access key". Count how many of the results are still valid today. That number is your baseline, and it is usually the one that convinces the board.
What the rules say (and why this fails audits)
No rule says literally "do not send passwords by email". Four of them make it clear without naming it:
Requires technical and organisational measures appropriate to the risk and expressly names encryption and the ability to ensure confidentiality on an ongoing basis. If the credential you hand out gives access to personal data, the channel you hand it out through falls within the scope of that article. Plain text with no expiry is hard to defend there.
This is the control that deals expressly with how authentication information is allocated and distributed, including the obligation to hand it over through a secure channel and not to transmit it in the clear. It is, literally, the operation this article is about, and one of the easiest findings to document in a certification audit: all the auditor has to do is ask for the emails used to set up three users.
The UK National Cyber Security Centre's guidance is blunt about the human side: design systems so that people are not pushed into insecure workarounds, and give them a safe way to do what they need to do. A ban on sharing passwords, with no supported way to hand one over, is exactly the kind of policy that guidance warns against.
Its risk management measures include cryptography and encryption policies, the use of secure communications and multi-factor authentication. For in-scope entities, how credentials move inside and outside the organisation is part of the scope. We cover it in what NIS2 requires of your company.
Put practically: on audit day nobody will ask whether you have a tool. They will ask how you hand credentials over, who has seen them and what happened to them afterwards. With email, all three answers are "I don't know".
The workarounds that do not work
Before getting to the answer, it is worth ruling out the four things everyone tries first. None of them is absurd; all of them leave the problem essentially unchanged.
Both messages land in the same mailbox, on the same phone and in the same backup. It only protects against picking the wrong recipient, and if autocomplete betrayed you once it usually betrays you twice. Permanence, which is the real problem, does not change at all.
End-to-end encryption protects transport, not permanence. The message stays in the history of both phones and in both cloud backups. It is also a personal channel outside the company's control: when that person leaves, the history leaves with them, you cannot delete it, and you cannot prove what was shared.
That moves the problem: now you have to hand over the ZIP password, which is exactly the operation you wanted to solve. If it goes through the same channel, you have gained nothing. And there are side effects: legacy ZIP encryption (ZipCrypto) is weak, many mail filters block encrypted attachments precisely because they cannot scan them, and the file names remain visible.
And you should: it is the piece that holds, generates and fills credentials over time. But it solves shared storage within a group that uses the same tool. The moment you have to hand something to someone who is not in your manager — a supplier, a client, today's engineer — the manager plays no part and people go back to email. The two pieces are complementary: the manager holds, the one-time channel delivers.
What does work: the one-time secret
The idea is simple and more than a decade old: instead of sending the data, you send a reference that expires when used. You type the password into a form; the system encrypts it and returns a URL with a random identifier; you send that URL however you like. When the recipient opens it, the content is shown and the encrypted content is deleted from the database. From then on, what travels through email is a spent link.
The real change is not cryptographic, it is about permanence: you go from leaving an indefinite copy in half a dozen places to leaving a link that is good for nothing. And along the way you gain something email never gave you: knowing it has been read, when, and from where.
- · The key is written down in six places
- · It never expires
- · You do not know if anyone read it
- · You cannot revoke it
- · You cannot prove anything
- · What travels is a consumable link
- · It expires even if nobody opens it
- · Read receipt with IP and browser
- · Destroyed by hand in one click
- · The timeline of what happened remains
There is one well-known trap, and it is worth knowing before picking a tool: mail anti-malware filters and link previews in many clients follow links on their own. If the service reveals the secret simply by visiting the URL, the secret is consumed before it arrives and the recipient gets a dead link. That is why a well-built service requires an explicit human action — normally a POST request — to reveal the content.
The ten requirements the channel must meet
The list works equally well for evaluating a free public service or a module built into your platform. If any of the first five is missing, it is not a credential handover channel, it is a pretty form.
- Encryption at rest with a distinct key per secret. So one compromised row does not compromise the rest.
- Real deletion on read. The content is removed, not flagged as read. Ask about this explicitly.
- Expiry even if nobody opens it. A secret that is never opened has to die on its own, not sit waiting.
- Opening the URL does not consume it. Protection against mail antivirus and link previews.
- Recipient verification. A one-time code to their email or mobile, or a passphrase given through another channel, so a forward is worthless.
- A zero-knowledge mode. The option for not even the provider to be able to decrypt it, deriving the key solely from the passphrase.
- Read receipt. Knowing when it was opened, from which IP and with which browser.
- Exportable audit log. Creation, sending, opening, failed attempts, lockout and destruction.
- Data in the European Union and a processing agreement. If the service is free and personal, there is no agreement to rely on under the GDPR.
- Downloadable evidence. Something better than a screenshot on the day you have to prove the handover.
Several public services meet the first five. In practice, the last five are what separate a consumer tool from a corporate one.
How Dokuflex handles it
One-time secrets are one more module of the platform, with the same users, permissions and audit trail you already have. Paste the text — or generate a 20-character password with no characters that get confused when read out loud — pick an expiry and a protection mode, and copy the link or let Dokuflex send it by certified email or SMS.
Three details that make the difference against a free service:
- Genuine zero knowledge. With a passphrase, the encryption key is derived solely from it with PBKDF2-HMAC-SHA256 and 150,000 iterations. Neither the phrase nor a hash of it is stored. Nobody, ourselves included, can open it. And we say it before selling: if the phrase is lost, the content is not recoverable.
- A custody certificate in PDF. Signed with your organisation's certificate and timestamped. It carries the SHA-256 fingerprint of the content, the protection mode, the reads consumed and the complete timeline. It does not carry the content, on purpose.
- Inside your own house. The data stays in your Dokuflex, under your contract and with your data in the European Union, not on a third party's server your company never signed up for.
If what you need to hand over is files rather than text, the sibling piece is secure file transfer. And if your goal is to reduce the number of passwords in circulation, the deeper route is different: passkeys and SSO with multi-factor authentication, so most logins never need a key to hand out at all.
Frequently asked questions
Is it illegal to send a password by email?+
No rule forbids it by that name. What it can breach is Article 32 of the GDPR, which requires technical measures appropriate to the risk when the credential protects personal data, and control A.5.17 of ISO/IEC 27001, which requires authentication information to be handed over through a secure channel. In a certification audit, an email with the key in the body of the message is an easy non-conformity to document.
Does sending the password in a second, separate email help?+
No. Both emails land in the same mailbox, on the same phone and in the same backup, so whoever reaches one reaches the other. Splitting username and password across two messages only protects against the specific case of sending to the wrong address, and not even reliably: if autocomplete betrayed you once, it usually betrays you twice.
What about WhatsApp, which is encrypted?+
End-to-end encryption solves transport, not permanence. The message stays in the history of both phones, in both cloud backups, and in plain view of anyone who picks up an unlocked handset. It is also a personal channel the company does not control: when that person leaves, the history leaves with them, you cannot delete it and you cannot prove what was shared.
Does a password-protected ZIP solve it?+
It moves the problem. Now you have to hand over the ZIP password, which is exactly the operation you were trying to solve, and if it goes through the same channel you have gained nothing. On top of that, legacy ZIP encryption (ZipCrypto) is weak, many mail filters block encrypted attachments precisely because they cannot scan them, and the file names remain visible.
Isn't a password manager enough?+
It is essential, but it covers something else. A manager holds, generates and fills credentials over time within a group that uses it. The problem appears at the moment of handing something to someone who is not in your manager: an external supplier, a client, the engineer who comes in for one day. That is where people go back to email. The sensible setup is both pieces: the manager to hold, a one-time channel to deliver.
What is a one-time secret?+
It is a link that shows a piece of content once and then deletes it. You type the password into a form, the system encrypts it and returns a URL with a random identifier; you send that URL however you like. When the recipient opens it, the content is shown and the encrypted content is deleted from the database. From then on the link is worthless, and what travels through email is an already spent link.
Can the email antivirus open the link and burn the secret?+
That is the most common failure of free services: anti-malware filters and mail client link previews follow URLs on their own and consume the secret before it reaches the recipient. A well-built service requires an explicit user action to reveal the content, normally a POST request, so following the URL neither reveals nor destroys anything.
What should I require from a one-time secret service?+
Ten things: encryption at rest with a distinct key per secret; real deletion of the content on read, not just a read flag; configurable expiry even if nobody opens it; opening the URL must not consume it; recipient verification through a code or passphrase; a zero-knowledge mode in which not even the provider can decrypt; a read receipt; an exportable audit log; hosting in the European Union with a data processing agreement; and some form of downloadable evidence for the day you have to prove the handover.
Sources
- Regulation (EU) 2016/679 (GDPR): Article 32, security of processing.
- ISO/IEC 27001:2022: control A.5.17, authentication information.
- NCSC: password administration for system owners.
- Directive (EU) 2022/2555 (NIS2): Article 21, cybersecurity risk management measures.
- NIST SP 800-63B-4 (2025): password requirements on the verifier side.
- Verizon Data Breach Investigations Report 2026: credential abuse appears in 39% of breaches somewhere in the chain; as an initial access vector it drops to 13% from 22% the year before, overtaken by vulnerability exploitation (31%).
- Keeper, Workplace Password Malpractice Report (February 2021, 1,000 US workers): 62% shared a work password over text message or email. An old, single-market figure, cited only to illustrate the habit.
Make the easy path the safe path
Book 20 minutes with the three cases where your team hands out credentials today. We will set up the one-time link, the recipient verification and the handover certificate with you. No commitment.