Documentation: Secure Messages
Use cases
Secure Messages replaces the habit of putting passwords and other secrets in plain e-mail. Some scenarios it was built for:
Sending credentials to a client
You finished a website and need to hand over the hosting or CMS login. Create a message in the backend with burn after reading enabled and a short expiry, e-mail the link straight from the result screen, and tell the client to store the credentials in their password manager. The message destroys itself after they open it - and if the link ever leaks later, there is nothing left to open.
Receiving sensitive information from clients
Put the public send form on your site (menu item or module) and point clients to it whenever they are about to e-mail you a password, an API key or personal data. Whatever they submit is encrypted in their own browser and reaches you as a one-time link - instead of sitting readable in both mailboxes forever.
Temporary access for suppliers
A photographer, developer or auditor needs access for a week? Send the credentials with a 7-day expiry and no burn flag: they can re-open the link while working, and the message evaporates by itself when the job is done.
Two-channel secrets
For the truly sensitive cases, enable password protection: send the link by e-mail and the password via another channel (phone, chat). Even someone with full access to the recipient's mailbox cannot open the message - the password is part of the decryption key itself, not a gate on the server.
An internal drop box
On an intranet or members-only site, restrict the send-form page through normal Joomla access levels and let staff send secrets to the IT department without using chat or e-mail. Logged-in senders are recorded by name in the User Actions Log.