From a Hand-Managed SFTP Server to Tellabs’ Controlled Manufacturing Partner Exchange

Tellabs makes the fiber-based local area networks that run inside buildings and campuses: Optical LAN hardware, plus the software that manages it, sold through channel partners into government, education, healthcare, and hospitality. The company effectively created the enterprise Optical LAN category, and its equipment carries some of the most sensitive traffic there is. Tellabs Optical LAN has been deployed by every US military service, at every classification level.

Hardware is the operative word. Tellabs ships boards, and those boards are built and tested by a separate company in its manufacturing chain. That relationship runs on files. Tellabs writes the code that runs on the factory's test fixtures, and updates to that code have to reach the factory. In the other direction come manufacturing logs and debug output, arriving when something goes wrong with the manufacturing of the boards. Two independent companies, exchanging files continuously, in both directions.

One Server Between Two Companies

The exchange ran on a single SFTP server that Tellabs had set up specifically for the relationship and managed itself. Access management was handled by hand, and granular control over what each side could see did not exist. A shared server offers no natural boundary between ours, theirs, and shared. Tellabs could not put material on the server without, in effect, deciding to show it to the partner. Every change to what the partner could reach was manual work, performed on infrastructure Tellabs also had to keep patched and online.

The stakes ran higher than inconvenience. Some of the data Tellabs handles originates with Department of Defense end customers, who hold requirements on where that data lives and who can reach it. An exchange where the answer to "who can reach it" depended on someone's manual upkeep of a shared box was a condition Tellabs could not leave standing.

The problem persisted because it was structurally hard to fix. The counterparty is a genuinely separate company, not a business unit: neither side's identity systems or network controls extend to the other. Hardening the exchange meant building and operating per-partner infrastructure. Any replacement also had to keep speaking SFTP, because that was the protocol the factory's workflow already ran on.

That was the specification. Tellabs needed a layer between the two companies that neither had to operate: a place where Tellabs could declare which folders the partner reads and which it writes, where the factory kept connecting over SFTP with the tooling it already had, and where access on the Tellabs side followed the corporate directory instead of a local account list.

Directional Folders, With the Factory Still on SFTP

Tellabs selected Files.com to be that exchange layer.

The structure was a set of folders with a direction. Test-fixture code went into folders the partner could read. Manufacturing logs and debug output landed in folders the partner could write. Files.com's per-folder, role-based permissions enforced the split, so each company saw only the part of the exchange that belonged to the relationship. Tellabs decided what the partner could reach by setting a permission rather than by administering a server.

The factory side did not have to change. Files.com presented an SFTP endpoint, so the partner's existing workflow connected to the new exchange the same way it had connected to the old server. On the Tellabs side, access ran through the company's own identity stack: single sign-on through Microsoft Entra ID with Duo, two-factor authentication enforced, and SCIM provisioning creating and removing Files.com accounts from the directory. Every action on the exchange landed in one platform log.

Partner Access Became a Permission, Not a Server

With the exchange in production, Files.com replaced a hand-managed server and a manual access list with a boundary Tellabs declares in configuration. Tellabs no longer has to patch and keep a dedicated exchange server online or reconcile its employees against a local account list. Access follows the corporate directory: someone added in Entra ID gets access, and someone removed loses it. Activity across the exchange appears in one platform log.

The pattern also compounds. Nothing in the design is specific to one partner: standing up a controlled exchange with another counterparty is a set of folders and a credential, not another server to build and maintain.

A Boundary the Platform Enforces

The larger change is what that makes possible. Tellabs no longer has to choose between cooperating closely with an outside manufacturer and controlling what that manufacturer sees. It put Files.com between the two companies and got both.