How to Set Up an SFTP Server to Receive Files From External Partners

Setting up a server to receive files from partners is a different job from pulling files from somewhere else. You are building something that sits and waits for outside parties to drop data on you, safely, on a schedule, and without babysitting.

This is a different job from sending files out, and it fails in different ways. When you send, you control the timing and the destination. When you receive, you're handing a door to people outside your network and trusting that what comes through it lands where it should, gets processed, and doesn't let anyone wander into anything they shouldn't see.

What follows is how to build the receiving side properly, based on what comes up when organizations run inbound SFTP in production.

The short version

An inbound SFTP server has four jobs, and the first is the one people think of:

Accept the connection securely, over SFTP, with each partner isolated to their own folder.
Catch each file once it has finished uploading, so you never pick one up while it is still being written.
Move it out and process it, so the drop folder stays empty and the data reaches the system that needs it.
Tell you when a file doesn't show up, because a missing file is silent and a silent failure is the expensive kind.

Setting up the server is the easy part; the other three are where most of the work is, and they make up the rest of this guide. Where one of them has a dedicated guide in this series, such as automating what happens after a file lands, this guide links to it.

What "receiving files from partners" actually looks like

The pattern is boring and constant. One organization we work with described their entire setup in a single sentence:

"We have a simple Windows server running CompleteFTP that receives daily files from our clients via SFTP."

a US organization (EnterpriseDT support archive)

The shape is consistent: a server, a set of partners, and files arriving on a rhythm that is sometimes daily and sometimes far more frequent:

"A partner company sends a message every 5-10 mins and messages are fine."

a Canadian energy organization (EnterpriseDT support archive)

And it rarely stops once it starts. Even organizations winding a system down still have the drops running:

"We still have incoming drops of data coming in."

a US sports organization (EnterpriseDT support archive)

The point of these three quotes: receiving is a long-lived, always-on responsibility. You're not building a one-time import. You're building something that has to keep working, unattended, possibly for years, while partners you don't control push data at it on their own schedule, more often automated systems than a person at a keyboard. That is why the rest of this guide weights reliability and isolation over convenience.

Before you start: OpenSSH will get you a connection, not a system

The fastest way to accept an SFTP connection on Windows is to enable OpenSSH. It works. A lot of the inbound setups that show up in forums start exactly there, on a spare Windows box with OpenSSH switched on.

The trouble is that a raw SSH daemon gives you a login, and that's all it gives you. It has no concept of a partner, no per-account drop folder that's easy to manage, no "do something when a file lands" hook, no arrival monitoring, and no audit view you can hand an auditor. You end up scripting all of that yourself in PowerShell, and then maintaining those scripts, and then explaining them to whoever inherits the server after you.

A purpose-built SFTP server treats "an outside party drops a file and something happens next" as the thing it exists to do. The difference between the two is whether anything happens after the file lands. The rest of this guide assumes you want the system, because the four jobs above are the actual requirement, not just the login.

CompleteFTP runs as a Windows service and handles SFTP, FTPS, and HTTPS on the same server, so if a partner later asks for a different protocol you're not standing up a second thing. It's one of several production-grade options; the design principles below apply whichever you choose.

Step 1: Give every partner their own isolated drop folder

This is the control that matters most, so it goes first.

Each external partner gets their own user account. That account's home folder is their drop folder, and they cannot navigate above it or across into anyone else's. Partner A writes to Partner A's folder. Partner B cannot see that Partner A exists. On a server that outside parties connect to, per-partner folder isolation is not optional.

Set each partner account to write-only or write-plus-list where you can. They need to put files in. They almost never need to read anything back, and they never need to delete. Narrow the permissions to the job.

If you already run Active Directory, you can back these accounts with AD groups instead of managing a separate credential list, which keeps offboarding clean: when a partner contact leaves, the same directory change that cuts their other access cuts this too. Our guide on SFTP with Active Directory group-based access covers that arrangement in more depth.

Step 2: Lock down how they authenticate

Passwords work, but for machine-to-machine partner transfers, SSH public-key authentication is the better default. The partner generates a key pair, sends you the public half, and there's no shared secret sitting in a config file somewhere waiting to leak. Keys also survive password-rotation policies that would otherwise break an automated transfer at the worst possible moment.

Layer on what else you can:

Restrict source IPs. If a partner always connects from a known address or range, allow only that. It turns a stolen credential into a much smaller problem.
Log every session. You want a record of who connected, when, and what they transferred, both for troubleshooting and for the audit you'll eventually be asked for. If compliance reporting is in your future, a dedicated SFTP audit-logs guide covers what auditors actually ask for.
Prefer keys over passwords for anything automated, as above.

SFTP itself encrypts the credentials and the file contents in transit, so the protocol is not your weak point. Your configuration is. Spend the effort there.

Step 3: Decide where the files actually go (hint: not the drop folder)

The drop folder is a landing pad, not a home. Leaving received files sitting in it is how you end up unable to tell what's been processed and what hasn't.

The move that keeps things sane: on arrival, move the file out of the drop folder to wherever your downstream systems already read. That might be a network share, a database-backed workflow, or a cloud storage bucket. The drop folder stays empty between deliveries, which means "is there a file in here?" becomes a meaningful question with a useful answer.

One healthcare organization described the receive-then-forward version of this exactly:

"We have the CompleteFTP server installed and running well for the SFTP inbound transfers. We need to transfer out newly received files to another SFTP server."

a US healthcare organization (EnterpriseDT support archive)

Receive, then hand off. The inbound server is a checkpoint, not a warehouse. If your downstream target is cloud storage, CompleteFTP can present an S3, Azure, or SharePoint back end as if it were a local folder, so the file a partner drops writes straight through to where it needs to live.

Step 4: Automate the pickup so you're not the trigger

The steps below are what separate an inbound system from a folder someone checks manually.

You want the server to react the instant a file finishes uploading. Not on a person noticing. Not on someone running a script by hand. The event is the upload completing, and the response is automatic.

The trap is acting too early. If your trigger fires the moment bytes start arriving, you'll grab a half-written file and hand a truncated mess to the next system. The fix is to wait for the file to be complete and stable before doing anything with it. One of our customers described the pattern precisely:

"This functionality, known as the FTP Monitor, operates by polling the FTP server at user-defined intervals and triggering an event once the specified file(s) are detected and have remained stable for a configurable duration."

a US IT modernization organization (EnterpriseDT support archive)

Detected, and stable for a configurable duration. That "stable" check is what stops you from processing an upload that's still in flight.

Once the file is confirmed complete, chain the steps you need. A common shape, described by a financial services customer running exactly this:

"script 1, fires on an hourly schedule, and iterates a network folder (Folder1). And for each file in the folder it moves that file to Folder2. script 2 fires from that file move that happens in script 1, and sends the file to a remote server in Folder2 via an FTP script."

a US financial services organization (EnterpriseDT support archive)

Notice the composition: one action's output is the next action's trigger. Move on arrival, then forward on move. You can insert a virus scan, a checksum verification, or a rename into that chain. The server orchestrates it. Nobody watches it.

CompleteFTP handles this with on-upload event triggers and process automation built in, so the "wait until stable, then do these things" logic is configuration rather than a pile of scripts you maintain forever. The SFTP automation guide covers that side in depth.

Step 5: Get told when a file doesn't arrive

Everything above handles files that show up. The failure mode nobody plans for is the file that doesn't.

A corrupt file errors out and gets your attention. A missing file makes no sound at all. The partner's cron job failed, or their contact left, or their side changed a path, and your drop folder simply stays empty. Downstream, a process runs with yesterday's data or runs short, and by the time anyone notices, you're reconstructing a timeline.

Set up a scheduled arrival check: "expect a file in this folder by this time; if the window passes empty, alert someone." A missing file is silent, so without this check the first sign of trouble is usually a downstream process running short of data.

Where inbound transfers go wrong

A few failure patterns show up again and again. Worth knowing before they bite.

The network-share permission gotcha. When received files move to a network share, the SFTP service account needs the right permissions on that share, and the symptom when it doesn't is maddeningly specific. One customer hit it:

"We are experiencing an issue with client receiving an error which states the ZIP file can not be read. The file path is to a network share and the permissions appear to be correct. Other file types transfer correctly."

an Australian equipment rental organization (EnterpriseDT support archive)

"Permissions appear to be correct" and "other file types work" is the classic shape of a service-account or path-length issue that only some files trip. If you're moving files to a share, verify the service account's access to that exact path under load, not just from your own logged-in session.

Staging files where they're exposed. Older designs drop partner files onto an internet-facing machine and stage them there before pulling them inward. That means partner data sits, however briefly, on the most exposed box you own. A gateway design avoids it: the internet-facing component holds no files and no credentials, and the real data never touches the edge. More on that in the FAQ below.

Treating it as fire-and-forget. It isn't. Partners change keys, rotate contacts, and adjust their own schedules without telling you. Build the monitoring in Step 5 and review your audit logs periodically, and these become minor events instead of outages.

Frequently asked questions

How do external partners connect to my SFTP server?

You give each partner a username, a credential (an SSH key is safer than a password), and the server's hostname and port. They connect with any standard SFTP client and land in a folder you control. They never see the rest of your file system or any other partner's folder.

Do I need to put the SFTP server in a DMZ?

Not necessarily. The reason DMZ designs exist is to avoid storing partner files on an internet-facing machine. A gateway or reverse-proxy design lets the internet-facing component hold no files and no credentials, while the real server and the data stay inside your network. That gets you the DMZ security posture without the operational overhead of running and syncing two full servers.

How do I automatically process files after a partner uploads them?

Use an on-upload event trigger. When a file finishes uploading, the server fires an action: move it out of the drop folder, scan it, and hand it to the next system. The key detail is waiting until the file is complete and stable before acting, so you never grab a half-written upload.

Is SFTP secure enough for receiving files from outside my network?

Yes. SFTP runs over SSH and encrypts both the credentials and the file contents in transit. The security work that matters is on your side: isolate each partner to their own folder, prefer key-based authentication, restrict source IPs where you can, and log every session for audit.

Can I give each partner their own isolated folder?

Yes, and you should. Each partner gets a user account whose home folder is their drop folder. They can write to it but cannot navigate up or sideways into another partner's data. This is the single most important control on an inbound server that multiple outside parties connect to.

What happens if a partner's file doesn't arrive?

Set up a scheduled check that expects a file within a window and alerts you when the window passes empty. A missing daily file is often a bigger problem than a corrupt one, because nothing errors out and nobody notices until a downstream process runs short of data.

Where should the received files actually be stored?

Not in the drop folder. Move files out on arrival to a location your downstream systems already read, whether that's a network share, a database-backed process, or a cloud storage bucket. Keeping the drop folder empty makes it obvious what has and hasn't been processed.

Build it once, let it run

Receiving files from partners is one of those jobs that looks trivial on day one and reveals its depth on day ninety, the first time a file goes missing quietly or a half-written upload reaches production. Build the four jobs properly from the start (isolate each partner, catch files only when they're stable, move them out and process them, and alert on the ones that never come) and you get a server that does its job unattended for years.

CompleteFTP runs the inbound pattern described here on Windows and Linux, with per-partner isolation, on-upload automation, arrival monitoring, and full audit logging in one server. It's the same feature set discussed throughout our SFTP server guide. Download the 30-day free trial, point a test partner at it, and watch a file drop, move, and forward on its own.