One-time secrets: send a password, an API key or an account number through a link that destroys itself when it is read. With a read receipt, with a verification code when you need one, and with a signed certificate proving what was shared, who opened it and when it disappeared.
The proof of what happened remains. The data does not.
It is not a people problem: email was never a place to store keys, it was just the only one to hand.
The password you sent two years ago is still in that person's inbox, on their phone, in the chat history and in the mail server backups. In plain text and with no expiry.
One forward, one screenshot into a group chat, one laptop going home. Nobody tells you, and you have no way of knowing how many people hold that key today.
Keys shared by email have no owner and no date. When someone leaves the company or you change supplier, nobody knows which credentials need changing.
On audit day all you have is a sent email. Not who read it, not when, not whether the key is still alive. And a free public service leaves you a screenshot at best.
For the sender it is paste a text and copy a link. For you, it stops being invisible.
Paste the text — up to 20,000 characters — or hit Generate password and the browser builds a 20-character one with no characters that get confused when read out loud. It is encrypted before it touches the database. The label you recognise it by in your list is never sent to anyone.
Copy the link and send it however you like, or let Dokuflex send it: certified email recorded in the audit log, or SMS with a short link on your own domain. You choose the expiry: from 1 hour to 30 days.
Before showing it you can require a passphrase you give them through another channel, a 6-digit code to their email or mobile, or both. You get a notification the moment it is read, with the IP address and the browser.
On being read, on using up the allowed reads, on expiring unopened, or when you destroy it by hand. The content is wiped from the database. The record, the SHA-256 fingerprint and the timeline remain. The data does not.
Without a passphrase, each secret is encrypted with a key derived from the installation master key and a distinct salt per row: a system administrator could, in theory, decrypt it.
If you enable the passphrase — the one you give the recipient over the phone — the encryption key is derived solely from it, with PBKDF2-HMAC-SHA256 and 150,000 iterations. Dokuflex stores neither the phrase, nor a hash of the phrase, nor anything that would let someone attack it from the database. The secret sits there as an opaque block that nobody but the holder of the phrase can open.
And we say it before selling it: if the passphrase is lost, the content is not recoverable. Not by us either. That is exactly the property people buy it for.
| No passphrase | With passphrase | |
|---|---|---|
| Encryption key | Master key + per-row salt | Derived from the phrase alone |
| Admin can read it | In theory, yes | No |
| If the phrase is lost | Not applicable | Content is not recoverable |
| Where the phrase is given | — | Through another channel: phone, in person |
The difference between saying "I did send it to you" and being able to prove it in front of a client, an auditor or a judge.
For every secret you can download a PDF in the same format as the Dokuflex signature report, signed with your organisation's certificate and timestamped by a time-stamping authority (TSA). It carries the record, the SHA-256 fingerprint of the content, the protection mode, the reads consumed and the complete timeline of everything that happened.
It fits what you are already asked for: the encryption and access control of Article 32 of the GDPR, the authentication information management of ISO/IEC 27001 (A.5.17) and the activity logging required by security frameworks such as the Spanish ENS.
See a sample certificateWhat changes is not the convenience, it is what you can prove afterwards.
| Criterion | Email or chat | Free public service | One-time secrets |
|---|---|---|---|
| Where the data lives | Forever in every mailbox and backup it passes through | On a third party's server, outside your contract | In your Dokuflex, encrypted, and wiped on read |
| Who can read it | Anyone with access to the mailbox, the phone or the backup | The provider, unless you trust that they do not | With a passphrase, nobody: not even Dokuflex can decrypt it |
| Do previews and mail antivirus burn the link? | Not applicable | Yes: they follow the link on their own and the secret is consumed before arrival | No. Revealing requires a POST: opening the URL shows nothing |
| Verifying who opens it | Nothing | Nothing | 6-digit code to email or mobile, even if the link is forwarded |
| What you show in an audit | A sent email. Nothing about who read it | A screenshot at best | Custody certificate in PDF, signed and timestamped |
| Traceability | None | Minimal, and at the provider's premises | Creation, sending, opening, code, failures, lockout and destruction |
| Fit with what you already have | — | Separate account, separate users, separate invoice | Same user, same permissions, same audit trail and REST API |
An auditor does not ask whether you have a tool. They ask how credentials are handed over in your company, who has seen them and what happened to them afterwards. An encrypted, single-use channel with a certificate answers those three questions with data.
References link to their official source. This page is not legal advice: compliance also depends on your own policies and on how you use the tool.
Requires technical and organisational measures appropriate to the risk, and expressly names encryption and the ability to ensure confidentiality on an ongoing basis. A plain-text password sitting in an email nobody deletes is hard to defend against that yardstick.
"Authentication information": it covers precisely how it is allocated and distributed, including the obligation to hand it over through a secure channel and to avoid transmitting it in the clear. This is literally that operation, and one of the easier controls to fail in a certification audit.
The 2025 revision of the US digital identity guidelines raised the minimum length for single-factor passwords to 15 characters, banned composition rules and dropped periodic rotation. Longer, randomly generated secrets are exactly what a generator plus a safe delivery channel make practical. See what a modern password policy looks like.
Lists cryptography and encryption policies and the use of secure communications among its risk management measures, alongside multi-factor authentication. See also what NIS2 requires of your company.
The secure way to share a password is never to write it into the channel you send it through. With Dokuflex one-time secrets, the content is encrypted with AES-256-GCM before it is stored, travels as a link carrying a 24-byte random token, and is wiped from the database the moment it is read. You can require a passphrase handed over through a different channel, a 6-digit verification code to the recipient's email or mobile, or both, and set an expiry between 1 hour and 30 days so the link dies even if nobody opens it.
Compared with a free service on the internet, the difference is control and proof: the data stays inside your own Dokuflex instead of a third party's server you have no contract with; revealing the secret requires a POST request, so mail previews and antivirus scanners do not consume it before it arrives; and for every secret you can download a custody certificate in PDF, signed and timestamped. All of it with the users, permissions and audit trail you already have. We cover it in detail in the guide on why you should not send passwords by email.
Sharing credentials is an explicit ISO/IEC 27001 control (A.5.17), a technical measure under Article 32 of the GDPR and part of access control in public-sector security frameworks. The custody certificate records the SHA-256 fingerprint of the content, the protection mode, the reads consumed and the full timeline: creation, sending, opening, verification, failed attempts, lockout and destruction. If what you need to hand over is files rather than text, the companion is secure file transfer; if your goal is to use fewer passwords at all, the route is passkeys and SSO with multi-factor authentication.
Use a one-time link: the content travels encrypted, is shown once and is wiped from the database the moment it is read. What you should never do is type it into the body of an email or a chat message, because there it stays copied in the recipient's mailbox, on their phone, in the conversation history and in the mail server backups, with no expiry and with no way of knowing who has seen it. If you also need to be sure the right person opens it rather than whoever receives a forward, add a verification code sent to their email or mobile.
The content is decrypted, shown on screen, and the encrypted content is set to null in the database. From that moment the link is useless: the secret's record, the SHA-256 fingerprint of what was shared and the timeline of what happened all remain, but the data itself is gone. Whoever created it receives a read receipt with the date, the IP address and the browser.
It depends on the mode. Without a passphrase, each secret is encrypted with a key derived from the installation master key and a distinct salt per row, so a system administrator could in theory decrypt it. If you enable the passphrase, the encryption key is derived solely from that phrase with PBKDF2-HMAC-SHA256 and 150,000 iterations: the phrase is not stored, nor a hash of it, nor anything that would let someone attack it from the database. In that mode nobody, ourselves included, can open the secret. The trade-off is that if the passphrase is lost, the content cannot be recovered.
No. That is the classic failure of public secret services: anti-malware filters and mail client link previews follow URLs on their own and the secret is consumed before the recipient ever sees it. Here, opening the URL reveals nothing: showing the content requires an explicit user action through a POST request, so automated crawling cannot burn the secret.
In three ways. Where the data lives: here it sits inside your own Dokuflex, not on a third party's server you have no contract with. What you can prove afterwards: you can download a custody certificate in PDF, signed by your organisation and timestamped, rather than a screenshot. And what it fits with: the same users, the same permissions, the same audit trail and a REST API, with no separate account and no separate invoice.
No, it complements one. A password manager is built to store and use credentials over time; one-time secrets are built for the moment of handover, which is precisely the gap where managers leave people reaching for email or chat. The usual setup is both: the manager holds, the one-time secret delivers.
It proves that that exact content was shared, through its SHA-256 fingerprint; when it was created, when it was sent and through which channel; that someone opened it, from which IP address and with which browser; that it was verified with a code, if you required one; and that the content was destroyed, when and for what reason. It does not prove what the content said, because the certificate deliberately leaves it out; nor that whoever opened the link is who they claim to be, unless you required a verification code; nor that the recipient has not forwarded it to someone else; nor anything about what happens to the data after it is read.
Article 32 of the GDPR requires technical measures appropriate to the risk and expressly names encryption and access control. Control A.5.17 of ISO/IEC 27001:2022 deals specifically with the allocation and distribution of authentication information, which is exactly this operation. The NIS2 Directive lists cryptography policies among its risk management measures. And NIST SP 800-63B-4 sets out how passwords should be handled on the verifier side. Overall compliance also depends on your own policies and on how you use the tool.
There is nothing to install and no second account to open: it is one more Dokuflex module, with the users and permissions you already have. Ask for a ten-minute demo and send yourself a secret.