Yes, when the transfer involves sensitive data or credentials. Monitoring can help with detection, but it does not remove plaintext exposure or weak authentication. The better sequence is to identify every FTP dependency, migrate high-risk flows to encrypted alternatives, and then keep monitoring for any residual use that should be retired.
Why This Matters for Security Teams
FTP is not just an outdated transport choice, it is a control gap that can expose credentials, file contents, and operational trust at the same time. Adding monitoring around FTP can improve visibility, but it does not fix plaintext transmission or weak authentication. For security teams, the real question is whether monitoring is being used as a stopgap while a planned migration removes the dependency altogether. NIST SP 800-53 Rev 5 Security and Privacy Controls treats secure transmission and access control as distinct obligations, which is why replacement usually deserves priority when sensitive data is involved.
The practical risk is cumulative. FTP tends to survive in file exchange jobs, batch integrations, vendor workflows, and legacy appliances long after teams believe it has been retired. Once those paths are embedded in business operations, the environment becomes harder to inspect and harder to govern. Monitoring still matters, but it should be used to confirm where FTP persists, not as a substitute for secure transport. In practice, many security teams encounter FTP exposure only after credential harvesting, data interception, or an audit finding has already occurred, rather than through intentional decommissioning.
How It Works in Practice
The safest sequence is to inventory every FTP dependency, assess what data moves through each flow, and rank those flows by sensitivity, business criticality, and exposure. High-risk transfers should move first to encrypted protocols such as SFTP or FTPS, or to managed file transfer services that support stronger authentication, logging, and policy enforcement. For organisations with formal control mapping, this aligns with the intent of secure communication and auditability requirements in NIST SP 800-53 Rev 5, especially where transfers carry regulated data.
Monitoring remains useful, but it should answer specific operational questions: who is still using FTP, from which systems, at what times, and for what payload types. A practical programme often includes:
- Asset and dependency discovery across servers, scripts, vendors, and embedded devices
- Protocol classification so that FTP, FTPS, and SFTP are not treated as interchangeable
- Logging and alerting on any remaining FTP sessions, especially from privileged systems
- Compensating controls for unavoidable legacy cases, such as network segmentation and restrictive allowlists
- Change management to ensure replacements are tested against business workflows before cutover
Where identity is involved, teams should also review whether FTP credentials are shared, static, or reused across systems. That is often where the real control weakness sits, because a monitored but long-lived credential can still be abused even after the transfer path has been observed. These controls tend to break down when FTP is embedded in vendor-managed appliances or air-gapped operational networks because owners cannot easily modify the protocol stack or logging model.
Common Variations and Edge Cases
Tighter replacement timelines often increase operational disruption, requiring organisations to balance reduced exposure against integration risk and change fatigue. That tradeoff is real, especially in manufacturing, healthcare, and franchise-style environments where old systems cannot all be updated at once. Best practice is evolving, but current guidance suggests that temporary monitoring is acceptable only as a bridge to removal, not as a long-term security strategy.
Some environments justify a phased approach. For example, a legacy application may support only FTP, but the surrounding architecture can still reduce risk by isolating the service, limiting source hosts, and enforcing strong external controls around the account used for transfer. Other cases are less defensible. If the transfer carries secrets, customer records, or regulated files, the threshold for replacement should be much lower because monitoring cannot prevent interception on the wire.
Teams should also be careful not to confuse visibility with remediation. Logs can show that FTP is active, yet they do not make plaintext safe. For broader governance and resilience mapping, CISA guidance on prioritising exploited risk supports the wider principle of fixing high-impact exposure before expanding detective coverage. Where FTP remains temporarily unavoidable, OWASP Top 10 risk thinking helps frame the dependency as an exposure management problem, not just a logging problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack surface, NIST CSF 2.0 set the technical controls, and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | FTP replacement reduces weak access paths and credential exposure. |
| MITRE ATT&CK | T1048 | Unencrypted transfer can be used to exfiltrate data over exposed channels. |
| PCI DSS v4.0 | 4.2.1 | Cardholder data must be protected in transit with strong cryptography. |
Replace FTP on sensitive flows and restrict remaining access to explicitly approved hosts only.
Related resources from NHI Mgmt Group
- Should organisations prioritise least privilege before adding more cloud controls?
- Should organisations prioritise identity governance before expanding agentic AI?
- Should organisations prioritise token controls before expanding SaaS access?
- Should organisations prioritise automation before shortening key lifetimes?
