SFTP credential leaks happen many times a day on the public internet. A contractor pushes a .env file to a personal repository. A developer commits a config sample with the real values still in it. A workstation backup ends up on a shared drive that wasn't meant to be shared. The mechanism varies; the outcome is the same: a credential that should not be in public space is now in public space.
What happens next depends almost entirely on what authentication the SFTP server requires. This is a walkthrough of how the same scenario plays out under two configurations — an SFTP listener accepting passwords alone, and the same listener requiring an additional one-time code. Both timelines start at the same moment: the leak.
The first fifteen minutes — leak to harvesting
Public commits are scanned for credentials within minutes. GitHub itself runs secret-scanning and notifies the contributor; that catches some leaks. But credential scrapers run independently, commercial and otherwise, and they don't wait for cleanup. They index public commits in near real time and pull anything that looks like a secret into their own corpora.
A leaked SFTP password is a juicy target. It typically grants direct access to a business's file exchange channel with its trading partners, which often carries billing records, invoices, healthcare data, EDI documents, or other data that converts cleanly to either ransom leverage or cash on a forum.
By the time the contributor realises the mistake, force-pushes the commit, and makes the repo private, the credential is already in motion in multiple scraper indexes. The window between leak and first attempted use is typically under an hour, often under fifteen minutes.
Path A — password-only SFTP listener
The first attempt comes from an unfamiliar source IP. The SFTP listener prompts for the password. The attacker supplies the leaked password. Authentication succeeds.
From here, the attacker walks the home directory tree, identifies anything that looks valuable, and starts pulling files. Depending on bandwidth and the size of the home, this takes minutes to hours. Inside the audit log there is little to distinguish this session from a legitimate one, because the only thing that's anomalous is the source IP — and source-IP anomaly alerting is rare on SFTP listeners specifically. The log captures a normal-looking session that downloaded a normal-looking set of files.
The leak is typically noticed days or weeks later, when the contents resurface — for sale on a forum, in a ransom note, or in a downstream partner's incident investigation. By that point the business is on a regulator clock: under most modern data-protection regimes, the window to figure out who took what, when, and to notify affected parties is measured in days, not weeks.
The IBM Cost of a Data Breach Report 2024 puts the average breach cost at $4.88 million globally and $9.77 million for the healthcare sector specifically. The actual cost of any individual incident is shaped by customer attrition, partner trust loss, executive distraction, regulator engagement, and legal costs, and tends to be materially higher than the headline. The underlying mistake was a single bad commit by a contractor with good intentions.
Path B — same listener with MFA enabled
The first attempt comes from the same unfamiliar source IP. The SFTP listener prompts for the password. The attacker supplies the leaked password and gets past that prompt. The listener then prompts for a one-time code that only the legitimate account holder's authenticator app can produce. The attacker has the password and nothing else. Authentication fails.
Then it fails again. Then a different source IP tries; then a botnet does. Each attempt is logged. Each is rejected. None reaches the second factor.
If the SFTP server's audit pipeline is wired into a SIEM with even a basic failed-authentication threshold, the cluster of failures generates an alert on the order of minutes after the first attempt — long before the attacker gives up. The security team sees the alert, correlates it with the leaked credential, and the credential gets rotated in the same afternoon. No files leave. No notification window opens. No regulator gets involved. The audit-log entry for the incident reads, roughly: some number of failed authentications, no successful logins, one credential rotation.
What makes the two paths so different
In Path A, the failure mode of a leaked password is data loss. In Path B, the failure mode is an inconvenient afternoon. The same underlying mistake — one bad commit by one contractor — produces wildly different blast radii depending on a single configuration choice on the SFTP listener.
The specifics of how this plays out in any individual incident vary case by case. How fast the attackers move, what they target, what the recovery actually costs — none of that is uniform. What stays constant is the asymmetry: a single factor makes the failure mode silent, and a second factor turns it into a failed-auth spike that alerts immediately.
Why MFA on SFTP isn't standard practice
For a long time, MFA on SFTP wasn't well supported by SFTP servers. SSH had ways to do it — PAM modules, custom subsystems — but they were awkward, and they broke automation accounts that needed to authenticate by key or password alone. The result, across most file-transfer estates we've seen, is that SFTP quietly became the soft underbelly of an otherwise hardened estate: every other service had MFA enforced; the SFTP listener still accepted a single secret.
The design choice that makes MFA on SFTP cheap enough to actually roll out is per-account enforcement. Human-driven accounts get the prompt. Automation accounts continue to authenticate the way they always did, with the IP allow-list, rate limiting, and audit log doing the security work on those. Two policies, same server, applied per account. That's the version of MFA on SFTP that gets enabled and stays enabled, because it doesn't break the automation flows that depend on SFTP behaving like SFTP.
The take-home
A leaked SFTP password is a routine event in modern operations. Whether it becomes a routine inconvenience or a regulatory incident is determined almost entirely by whether the listener accepts a single factor. The math isn't subtle: a credential rotation in an afternoon, or a notification window opening on a clock you can't stop.
If your SFTP listener doesn't support MFA, you're betting the data on the password's secrecy. If it does and you haven't enabled it, you're letting the bet ride out of habit.