GUIDE
Every secure-document product asks the recipient to do something first: create an account, remember a password, install an app, open a portal. This guide explains why that requirement exists, why it is the reason sensitive documents still travel as email attachments, and what replaces both.
Not because anyone thinks it is safe. Because every alternative asks the other person to log in, and the other person will not.
A loan officer needs a pay stub. A service advisor needs a signed authorization. A clinic needs a referral packet. The secure option is a portal: the customer gets an invitation, creates an account, sets a password, confirms an email, and uploads. Adoption collapses at the first step, the document arrives by email anyway, and the compliance program now owns an attachment it never wanted.
The attachment then does what attachments do. It is copied to every mail server it crosses, it depends on each hop negotiating TLS correctly, it persists in sent folders, inboxes, archives, and backups indefinitely, and it produces no record of who actually opened it. Under GLBA, HIPAA, FERPA, and the FTC Safeguards Rule, each of those is a finding waiting for an examiner.
Over ninety-five percent of the time a sensitive document moves between two parties, nothing needs to be shared. It needs to be dropped off or picked up, once.
Portals, shared drives, and file-sharing links are built for the other five percent: two parties working in the same space over time. Applied to a one-time exchange they add a credential to protect, an onboarding step to abandon, and a stored copy to govern. The login is not a security feature. It is the cost of putting the document in a place instead of moving it to a person.
Asking a customer to create an account to receive one document is asking them to drive to the post office to pick up a letter. Delivery exists so they do not have to.
Secure Digital Transport (SDT) is the category of technology that moves a sensitive document from one party to another without either side logging in. Botdoc invented it and holds seven granted patents across six jurisdictions on it.
1. The sender's system originates the transaction. A person clicks send, or an application calls the SDT Engine. Nothing is uploaded to a shared space; an encrypted, disposable delivery is created for one recipient.
2. The recipient gets a notification, not a credential. Email or text carries a one-time delivery link. There is no account to create, no password to set, no app to install, and the link is bound to that delivery alone.
3. The document opens in the browser. Encrypted from pickup to delivery. Where identity matters, the delivery can require ID capture or verification at the moment it opens, which is stronger than a password that was set once and reused everywhere.
4. The container is destroyed. On delivery the encrypted container and everything in it evaporates. No copy sits on a mail relay, in an archive, or in a backup. Zero residual footprint is the third pillar of SDT, not an optional setting.
5. The record stays. Who received it, when, from where, and whether anyone else has touched it since. That per-document log is what examiners and vendor-risk reviewers ask for, and it is the thing email can never produce.
The same transport runs backward. Instead of sending, the system requests: the customer gets a notification, opens it, drops the document in, and is done. No upload portal, no account, no abandoned onboarding. For a lender, a dealership, or a clinic, the collection side is usually where adoption was failing.
Easy to send, no recipient friction. Leaves copies on every relay and in every mailbox, depends on hop-by-hop TLS that can downgrade silently, and produces no delivery record. Fails encryption-in-transit and retention expectations under every major framework.
Encrypted at rest, auditable, and the right tool for a long-running shared workspace. For a one-time exchange it adds a credential to be phished, an onboarding step most recipients abandon, and a stored copy the sender must govern for as long as it exists.
No login on either side, encryption from pickup to delivery, container destroyed after delivery, per-document access log. Nothing left behind to govern, breach, or subpoena. The trade-off is conceptual: it is a transport, so it does not pretend to be a filing cabinet. Pair it with whatever system of record you already run.
The same transport primitive runs under purpose-built products for regulated industries. Each one exists because a portal failed and an attachment was the alternative.
SecureMFP replaces scan-to-email on multifunction printers so a scanned document never becomes an attachment. SecureMyDealer moves F&I packets and customer documents in auto retail under the FTC Safeguards Rule. Spark and Connect handle outbound and collected documents for banks, credit unions, and lenders. ID Verify adds identity capture at the moment a delivery opens. The full set is at Built on SDT.
If you are building rather than buying, the SDT Engine exposes the same Push and Pull primitives as an API so your own application can send and collect documents without ever provisioning a recipient account.
Use a transport, not a destination. The sender's system issues a one-time encrypted delivery; the recipient gets a notification, opens the document in a browser with no account, password, app, or portal, and the encrypted container is destroyed after pickup. The same model works in reverse to collect documents.
Yes. The signup requirement comes from the portal model, where the file sits in the sender's system and the recipient must be let in. Secure Digital Transport removes the account because the file is delivered to the recipient rather than stored for them, encrypted from pickup to delivery.
An expiring encrypted delivery backed by a transport that destroys the container after pickup and records who opened it, when, and from where. No copies in mail servers, archives, or backups; no dependence on every relay negotiating TLS; a per-document record for auditors.
For a one-time exchange, transport. Portals solve a sharing problem that rarely exists and add a credential, an onboarding step, and a stored copy. Keep a portal for genuinely collaborative, long-running shared workspaces; move everything else.
Those frameworks require encryption in transit and at rest, access control, and evidence. A transport that encrypts from pickup to delivery, destroys the container after delivery, binds access to the recipient, and logs every pickup gives a reviewer what they ask for. Removing the login removes stored credentials, which reduces attack surface rather than creating an exception.