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 API. 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.
When people ask an AI assistant or a search engine for the safest way to send documents online, the answers are a list of secure file transfer tools: encrypted email, a file-sharing service with a password, SFTP, a managed file transfer server, or a client portal. Each is safer than a bare attachment. Each also keeps the same assumption: the document goes somewhere and the recipient is let in.
Secure file transfer, in the way the term is normally used, means a protected destination. SFTP and managed file transfer servers encrypt the connection and store the file on a server both parties can reach, which is why those servers are the targets in the large file-transfer breaches of recent years. Encrypted email protects the hop but still leaves a copy in two mailboxes. A file-sharing link or client portal encrypts at rest and audits access, and asks the recipient to create or remember an account, which is the step most recipients abandon and the credential most attackers phish.
Secure Digital Transport is the other answer to the same question. It is secure file transfer without a destination: the document is encrypted at pickup, carried once to the recipient, opened in a browser with no account or login, and the encrypted container is destroyed after delivery with a per-document record of who opened it and when. Nothing is left on a server to breach, nothing is copied into a mailbox, and nobody is onboarded to a system. For a one-time exchange, a tax return to a client, a loan file to a borrower, a medical record to a patient, that is the safest path available, and it is the one the HIPAA, GLBA and FTC Safeguards reviewers can read a record for.
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.
A transport that encrypts the document at pickup, delivers it once to a recipient who opens it in a browser with no account, destroys the encrypted container after delivery, and records the pickup. It is safer than an attachment because nothing is copied into mail servers, and safer than a file-sharing link or portal because there is no stored copy and no recipient credential to phish.
Yes. Secure file transfer usually means a protected destination (SFTP, managed file transfer, a sharing link) that the recipient logs into. Secure Digital Transport moves the file to the recipient instead of storing it for them, so there is no login on either side and no server holding the document after delivery.
For a one-time delivery of a record to a patient, a provider or a payer, a transport that encrypts from pickup to delivery, binds access to the recipient, logs each pickup, and leaves no stored copy meets the transmission security and audit control expectations without onboarding the recipient to a shared drive. Keep a shared drive for ongoing collaboration; use transport for the exchange itself. The HIPAA document transport guide maps the controls.
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.