What should organisations do first when they still depend on SCP for operational file transfers?

The first move is to switch to SFTP wherever possible, then harden the SSH estate around it. That means tightening server configurations, limiting client-side privileges, and reviewing any automated transfers that were set up and forgotten. Teams should also inspect user-controlled SSH key authorization files, because those are attractive targets when transfer paths are exposed.

Start by replacing SCP with SFTP, then treat the transfer path as an SSH security problem

SCP is usually only a transport choice, but in practice the first step is to move file transfer onto SFTP wherever the business process allows it. That change matters because the control surface shifts to SSH server hardening, client privilege limits, and the credential and key material behind automated transfers. NIST Cybersecurity Framework 2.0 is a useful way to anchor that work in protect, detect, and recover activities.

The most important operational judgement is to avoid treating this as a simple protocol swap. Transfers that were built years ago often carry broad filesystem reach, long-lived keys, and minimal logging, so the first migration pass should map what actually moves, who or what initiates it, and what those credentials can reach. That is where the real exposure sits. NHIMG’s Ultimate Guide to Non-Human Identities is directly relevant here because the transfer mechanism is often owned by service credentials rather than people.

Harden the SSH estate before you trust the new workflow

Once SFTP is the target, harden the SSH servers that will carry it. Tighten authentication settings, restrict which accounts can log in, reduce command and filesystem exposure, and ensure that only the minimum set of hosts and users can initiate transfers. If a transfer account can do more than file transfer, the migration has not actually reduced risk.

This is also where client-side privilege review becomes important. Many file-transfer jobs were created as one-off automations and then left untouched, so teams should confirm which schedulers, scripts, and hosts still use them, then remove unused paths and narrow the remaining ones. That review should include any service accounts, API keys, and workload identities tied to those jobs, because the transfer process is only as safe as the credential behind it.

NHIMG’s 230M AWS environment compromise shows the same pattern from another angle: exposed configuration material and long-lived credentials create an outsized blast radius when automated access is left in place.

Inventory forgotten automations and key files before attackers do

The hidden risk in legacy SCP use is not the protocol itself, but the automation and authorization material around it. Teams should inspect scheduled transfer jobs, scripts, host-based allowlists, and user-controlled SSH key authorization files, then rotate or retire anything that no longer has a clear owner. If a key or script still works but no one can explain why it exists, it is already a control failure.

GitHub Action tj-actions Supply Chain Attack is a good reminder that forgotten automation can become a secrets exposure channel at scale, while Emerald Whale breach shows how exposed configuration can lead straight to stolen secrets and downstream repository compromise. For practitioners, the first cleanup step is usually inventory, not redesign.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC — Access Control	SCP to SFTP migration depends on tighter access boundaries and least privilege.
	PR.PT — Protective Technology	SSH hardening and SFTP replacement are protective technology changes for the transfer path.
	DE.CM — Continuous Monitoring	Forgotten automations and authorization files need ongoing visibility and detection.
Recommendation — Restrict transfer accounts, hosts, and permissions to the minimum required for file movement. Harden SSH and transfer services so only approved secure file-transfer flows remain. Monitor transfer jobs, key use, and authorization-file changes for unexpected activity.
CIS Controls v8	6 — Access Control Management	Legacy transfer accounts and keys should be inventoried, limited, and removed when unused.
	4 — Secure Configuration of Enterprise Assets and Software	SSH and SFTP rely on hardened configuration to reduce exposure and misuse.
Recommendation — Inventory and revoke unneeded transfer credentials and access paths. Harden SSH server and client configurations before expanding SFTP use.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	Legacy SCP workflows often depend on long-lived keys and authorization material.
	NHI-04 — Overprivileged Non-Human Identities	Automated file-transfer identities often have broader access than they need.
Recommendation — Rotate, bound, and retire transfer credentials that no longer have a clear operational owner. Reduce transfer identity permissions to the smallest feasible filesystem and host scope.

Practitioner Guidance

What to prioritise: move the highest-risk transfers first, meaning the ones that use long-lived keys, broad filesystem access, or unmanaged automation. Those are the paths most likely to fail a basic privilege review.

What to verify: confirm that each surviving transfer has an owner, a documented purpose, a bounded account or key, and a clear revocation path. If you cannot identify who rotates or retires the credential, the transfer should be treated as legacy risk, not stable infrastructure.

Common mistake: teams often harden the SFTP server but leave the old SCP jobs, client keys, and authorization files untouched. That leaves the same trust relationship in place, only under a different command name.

Practitioner takeaway: the first successful move is not just protocol replacement, it is reducing the blast radius of every transfer identity, script, and key that the old SCP workflow depended on.