By Yair Knijn · February 4, 2025
The shadow SFTP server no director knows about, until the auditor finds it
You sign off on the asset register because the CMDB says it is complete. That signature rests on one assumption: every endpoint moving customer data is in the inventory, owned, classified, and scanned. The assumption is wrong, and it usually fails first at a Linux box running sshd that someone stood up in 2023 to unblock a partner integration and never told you about.
Nobody was being reckless. A team had to exchange files with a downstream partner by Friday, the change to the managed gateway was three weeks out, and an engineer did the obvious thing: spun up a VM, ran apt install openssh-server, opened 22/tcp to one partner IP, and shipped. It worked. Nobody ever went back to close it.
How a 'temporary' SFTP box becomes permanent production
That host has no ticket, no owner field, no monitoring agent, no log forwarding. It is absent from the CMDB because nothing ever pushed it there. The partner comes to depend on it. A second partner gets bolted on because the server already exists. Two years later, invoices, payroll extracts, and claims files have all moved through a machine your register does not list. The credential is a password in a runbook. The host key has never rotated. Patching happened whenever the original engineer remembered, and they left in 2024.
Why your CMDB and your network reality have diverged
A CMDB records what was provisioned through process; your network carries what actually runs. The two drift apart every time someone moves faster than change control, and self-service cloud turned that drift from occasional into structural. ISO 27001:2022 puts the obligation on you under Annex A 5.9, Inventory of information and other associated assets, the control that absorbed the old A.8.1.1. Hold an inventory, assign an owner, keep it accurate. The nonconformity auditors keep writing up is not a missing policy. It is an inventory that is provably incomplete because a live asset processing real data was never in it, and a forgotten SFTP daemon is the textbook case.
The auditor's discovery method: port scans, firewall logs, partner IPs
A competent auditor does not trust your spreadsheet. They triangulate, and the shadow box tends to surface quickly:
- A scan finds
22/tcpopen on a host that does not appear in your register. - Firewall and flow logs show recurring transfers to a partner IP with no matching managed-gateway entry.
- The partner's own audit names a hostname or IP your team cannot account for.
- SIEM gaps expose a production host with no log source, itself a finding against logging.
Once they have the host, the questions are fatal to your access-control posture. Who owns this account? When did the credential last rotate? Where are the access logs for the past twelve months? None of it has an answer, because the system was never managed, and you cannot demonstrate control over a system you did not know existed.
Bringing every transfer endpoint under one managed control plane
Another scanning sweep that catches the box after the fact is not the fix. The fix is removing the reason teams build shadow servers at all: make the managed path faster than the unmanaged one. When provisioning a new SFTP or AS2 endpoint is a self-service action inside a governed control plane, with the account, key rotation, logging, and ownership wired in by default, the engineer under deadline reaches for that instead of apt install. Inventory stops being a quarterly reconciliation and becomes the system of record, because every endpoint was born in it.
xEvolve gives each tenant a single Environment where every SFTP and AS2 endpoint is provisioned, owned, key-rotated, and logged in one place, so your asset register and your network are the same list. There is no shadow box for an auditor to find, because there is nowhere to spin one up. See how the control plane closes the inventory gap on the security page.