Secure Copy Protocol is a file transfer method that moves data between systems over an encrypted SSH channel. It is commonly used by administrators and developers who need to copy files to or from remote servers while preserving confidentiality and transport integrity during the transfer.
Expanded Definition
Secure Copy Protocol, usually written as SCP, is a command-line file transfer method that uses an SSH session to encrypt data in transit and authenticate the remote endpoint. In NHI and infrastructure operations, it is typically used for moving configuration files, build artifacts, keys, and deployment assets between trusted systems.
SCP is often discussed alongside SFTP and rsync, but the security model is narrower: it inherits the trust and access scope of SSH rather than introducing a separate file-transfer trust layer. That makes SCP simple to automate, but also means the operational security of the transfer depends on SSH key management, host verification, and the privileges attached to the service account or operator identity. The NIST Cybersecurity Framework 2.0 treats this kind of secure transport as part of broader identity and access hygiene, not as a substitute for it.
Definitions vary across vendors and tools because some environments call any SSH-backed copy workflow “SCP” even when the implementation behaves more like an SFTP or remote shell transfer. The most common misapplication is treating SCP as a complete control for sensitive data movement, which occurs when teams copy files securely in transit but leave secrets, key material, and account permissions unmanaged at either endpoint.
Examples and Use Cases
Implementing SCP rigorously often introduces operational friction, because teams must balance fast admin workflows against stronger identity controls, tighter endpoint trust, and more explicit file handling rules.
- Deploying a signed application bundle from a build server to a production host over an SSH-controlled path, where access is limited to a dedicated automation identity.
- Copying an SSH public key, configuration file, or certificate bundle between Linux systems during controlled maintenance windows.
- Pulling logs or exports from a remote system for incident response, where confidentiality during transfer matters but the destination still needs file-access restrictions.
- Moving infrastructure artifacts in a CI/CD pipeline, where the pipeline service account must be monitored as an NHI and its SSH key rotated routinely.
- Using SCP for one-off administration tasks, while documenting host fingerprints and transfer permissions to reduce accidental overreach.
For a breach-focused lens on why transport security is not enough, see the Schneider Electric credentials breach, which illustrates how identity and credential exposure can outlast a single transfer event. In practice, SCP should be evaluated alongside SSH key governance, not as a standalone safeguard.
Why It Matters in NHI Security
SCP matters because file transfer is often the moment when privileged automation identities touch sensitive material, including credentials, certificates, deployment packages, and system configurations. If the associated SSH keys are overprivileged, reused, or poorly rotated, the transfer path becomes a durable access path rather than a temporary transport channel. That is why NHI governance has to cover the identities behind the transfer, not only the network encryption that SCP provides.
NHI Mgmt Group research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. In that context, SCP can be part of a secure workflow, but only when the source and destination identities are governed with least privilege, key rotation, and offboarding discipline. For broader identity-risk context, the Ultimate Guide to NHI is the clearest NHIMG reference point for lifecycle and exposure patterns.
Organisations typically encounter the operational risk of SCP only after a key is stolen, a server is rebuilt, or a pipeline starts moving data without clear ownership, at which point the transfer mechanism becomes operationally unavoidable to address.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret handling and exposure paths tied to SCP-based transfers. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is essential for SSH-backed file transfer identities. |
| NIST Zero Trust (SP 800-207) | SC-7 | SCP relies on authenticated, segmented trust boundaries for remote file movement. |
| NIST SP 800-63 | AAL2 | SSH key strength and identity assurance influence the trustworthiness of SCP use. |
| CSA MAESTRO | Agentic workflows often use file transfer channels that must be governed as tool access. |
Treat SCP endpoints as NHI-controlled paths and verify that no secrets are copied into unmanaged locations.
