How to Set Up Secure File Drops for Sources (October 2026)

If you take documents from people who could lose their job or their freedom over it, you need a way to receive files that doesn’t become a record of who sent them. That’s the whole job of a secure file drop: a page a source can upload to without making an account, over a connection your newsroom controls, where nothing about the connection is written down.

Setting one up takes an afternoon for the lightweight version and a few weeks of work for a self-hosted system. Most of the effort isn’t software, it’s deciding what you’re protecting against and who on your staff is allowed to touch a submission. Below is the process I would follow, in the order I’d follow it.

What You Need

Before you pick a tool, write down what the drop has to do. Without that, you’ll end up paying for features you don’t need and missing the two you do.

• A drop service or a server. Either a hosted service built for anonymous submissions, or a machine you control running an open-source whistleblower submission system such as SecureDrop.
• Individual staff accounts. Never a shared login. You need to know who downloaded what.
• Two-factor authentication, with hardware keys. SMS codes are the weakest option available and attackers know it. Passkeys or a physical security key are better.
• HTTPS on your own domain. A bare onion address is fine for the source-facing side; your internal review side still needs a normal login page over TLS.
• Role-based access. A reporter who needs a source’s documents has no reason to open someone else’s source file.
• A separate channel for two-way contact. Signal or an equivalent encrypted messenger, so a nervous contributor can check whether you received the file without making another trip.
• A written retention rule. Decide now how long submissions live and who deletes them. Deciding later means keeping everything forever.
• A tested backup, or a deliberate decision to have none. Backups of source material are also a liability. Know where they live.

Step-by-Step

Step 1: Define the security and privacy requirements

Start by sorting your sources into three groups, because each group needs a different answer. A named source handing you a document they already sent you by email doesn’t need an anonymous channel. A source whose name is known internally but not to an adversary needs pseudonymity and stored metadata hygiene. A source facing real consequences needs a system that logs nothing.

For each group, note the expected file types, the largest file you’ll realistically accept, who is authorized to read it, and how long it should exist. If video or photo dumps are part of the plan, a 2 MB limit is going to generate angry phone calls rather than tips.

Step 2: Choose a secure file-drop platform

There are three realistic architectures, and the honest difference between them is who owns the server and who logs what.

Option	Source anonymity	Source needs an account	Server owner	Setup effort	Best for
Self-hosted SecureDrop	Strongest, via Tor and metadata minimisation	No	Your newsroom	High, plus maintenance	Outlets with real legal exposure and technical staff
Hosted secure-drop service	Good, provider-dependent	No	The vendor	Low, an afternoon	Small outlets, freelancers, community partners
Cloud request link	Weak, provider logs IPs and accounts	No	A large platform	Minutes	Public tip lines where anonymity is not promised

SecureDrop is the open-source reference implementation, stewarded by the Freedom of the Press Foundation, and it still ships regular releases. It runs on your own infrastructure so there is no cloud provider sitting on a subpoena response between your source and you.

The honest reason small newsrooms pick a hosted service is staffing, not principle. Self-hosting means someone owns updates, disk failures, and the 2am page. The forum consensus among people who have actually run one is that you need a named person with server admin experience before you start, not after.

Whatever you choose, look for encryption in transit and at rest, a clear statement about whether the provider can read your files, per-user access control, audit logs of who opened what, and a deletion mechanism you can trigger yourself.

Step 3: Configure authentication and staff access

Set up one account per person who needs access, then apply least privilege. Reporters who handle one beat get access to that beat’s submissions only. Nobody but a small group of administrators sees the full queue.

Require hardware-key two-factor authentication on every account, including your own, and set a session timeout so an unattended laptop locks itself. Then log every download. When a lawyer asks six months later who accessed a source’s file, an access log answers the question and a guess does not.

Step 4: Set upload rules and encryption protections

Lock down what the drop accepts: allowed file types, a maximum size, and nothing executable. Turning off indexing on any public-facing upload page matters too, since a cached page is a public page.

Turn on scanning for uploaded archives and documents before anyone opens them, and confirm in writing whether your provider can access file contents or connection logs. “Zero-access” and “encrypted at rest” are different claims. The first means the provider cannot read your data; the second only means disk theft doesn’t expose it.

Step 5: Create the source-facing upload page

This page is written to a frightened person, not to a procurement officer. Short sentences. No product names. No tour of features.

Tell them what to upload, how to protect their identity before they start (a personal device, a network not tied to their employer, Tor Browser at its Safest setting), what metadata the drop collects (ideally: none), and how to reach you afterwards through an encrypted messenger.

One thing I always add: a note about the user’s own device. A source who photographs a document on a work phone and uploads from the same work phone has undone most of the setup, and no amount of server-side security fixes that.

Step 6: Test the workflow before announcing it

Run a full submission yourself, from a device you don’t normally use and ideally on a network you’ve never touched. Time each step and write down anything confusing, because a confused source gives up and that tip never reaches anyone.

Then test the failure paths: an oversized file, a rejected file type, a wrong password, a lost link. Confirm downloads land in the right place, notifications reach the right person, and the audit log recorded the access. Finally, delete the test submission and confirm it actually deleted.

Check that none of your internal pages get indexed by search engines. A discovery panel that says “step two of eight” is a gift to anyone looking for your queue.

Step 7: Publish only the minimum instructions needed

Publish the address, the minimum instructions, and a way to verify you received something. Nothing more.

Publishing the architecture, the security level a source should use, the internal folder structure, and the staff workflow tells an adversary exactly where to aim. Write about your reporting, not your infrastructure. Where a story needs to explain a submission happened, describe the journalism and leave the plumbing out.

Step 8: Maintain, review, and retire the system

Put a recurring calendar item on permission reviews. Quarterly is reasonable, and it should produce deletions, not just confirmations. People leave newsrooms; accounts and their access don’t leave on their own.

Apply software updates on a schedule, review access and download logs, and confirm that your deletion deadlines are being met rather than aspirationally met. Reassess the platform whenever your threat level changes or a big story makes you a more interesting target than you were last quarter.

Common Mistakes

Using a personal cloud account. It’s the most common failure and the easiest to fix. Move the drop to infrastructure your organisation controls, and stop using staff personal accounts for anything a source touched.

Telling sources to email attachments. Email is not a secure file drop. It logs accounts, IP addresses and device details on both ends, and the message sits in inboxes you don’t control. If a source insists on email, give them a one-time encrypted upload link instead.

Publishing the direct upload link in ways that reveal structure. A numbered link sequence or a public directory of internal queues gives away your workflow. Publish an address, not a map.

Granting everyone permanent access. Broad, permanent access turns one compromised account into the entire source list. Use per-user accounts, scoped permissions, and expiring or one-time download links wherever the tool supports it.

Assuming anonymity without testing it. Most anonymity failures happen in the source’s browser or on their network, not on your server. Watch someone else complete a submission end to end before you promise anonymity in print.

Retaining submissions indefinitely. Every file you keep is a file you may be compelled to hand over. Write a retention rule down, automate deletion, and keep the audit trail about who accessed what rather than the content itself.

Skipping metadata hygiene. Document properties, tracked changes, embedded links and printer tracking dots carry authorship. Look at a file’s properties and its revision history before treating it as evidence.

Frequently Asked Questions

Conclusion

Assess the threat first, because a public tip line and a source under investigation need entirely different systems. Pick a controlled platform, hosted if you lack technical staff and self-hosted if you don’t. Then lock down access with individual accounts and hardware-key two-factor, test the whole thing with a dummy file from a device you don’t own, and publish only the minimum instructions a source needs to submit safely.