Replacing SFTP without breaking your audit trail

Priya Anand · 2024-11-04

SFTP isn't insecure. It's just blind. You know files moved. You know roughly when. You probably know who connected. You don't know much else — and that gap is where most firms' SFTP-based workflows quietly become liabilities.

What SFTP shows you

A well-configured OpenSSH server with sftp-server logging enabled gives you:

Connection events (timestamp, user, source IP)
File-level operations if `LogLevel VERBOSE` is set (open, read, write, close)
Authentication failures

That's the maximum. In practice, most deployments log only connection events and rely on the file system's own audit (auditd, file timestamps) for everything else.

What it doesn't

Who downloaded what, when (file system mtime gets you upload time, not download time)
Whether the recipient ever opened the file
Whether the recipient forwarded the file
How long they viewed it, whether they printed it
Anything happening to the file after it leaves the SFTP server

For compliance regimes that require you to demonstrate downstream control (HIPAA, FINRA, SOC 2 confidentiality), the absence of this information is the problem.

The migration trap

The instinctive move is to lift SFTP-and-shift to a portal. Wrap the same workflow in a web UI. This is a mistake because it changes the transport mechanism without changing the visibility. The portal becomes "SFTP with a logo."

The point of migrating off SFTP isn't the transport. It's the workflow shift from "file delivery" to "controlled disclosure." Those are different things.

A staged migration approach

Migrations that succeed share a pattern:

Catalog every existing flow. Inbound vs outbound, internal vs external counterparty, sensitivity tier.
Group by sensitivity. Tier 1 (regulated, PII/PHI/financial). Tier 2 (confidential, no regulatory category). Tier 3 (operational, low sensitivity).
Migrate Tier 1 first. Counter-intuitive but right — the highest-risk flows benefit most from visibility, and your legal team will champion the project.
Run dual-write for one quarter. The new system and SFTP both receive the file. Catch workflow gaps without breaking production.
Deprecate SFTP per flow. Communicate to counterparties, set a sunset date, follow through.
Decommission only after a quarter of stable operation. Keep the SFTP server in read-only mode for a quarter past sunset so historical data is still accessible while you complete archival.

SFTP got many firms here. It does not get them further. The replacement should be measured not by feature parity but by audit-trail capability that the original transport never offered.

Written by Priya Anand. Have feedback? Reach out at hello@verifypg.com.