A Global Digital Agriculture Company Runs the File Layer Behind Seven Business Systems

A global digital agriculture company builds a platform that combines on-farm data, data science, and satellite imagery to help growers decide when to plant, apply inputs, and harvest. It began as a startup and has since passed through two changes of corporate owner.

Underneath that product sits an ordinary enterprise. The company runs on the same commercial systems any software business runs on, exchanges customer data with outside vendors and logistics partners, and has passed from startup to one corporate parent to the next, with each change of owner bringing a new corporate security regime. The files moving between its business systems and its outside partners have to move through something, and that something has to hold up under whichever regime arrives next.

On Files.com, what began as governed exchange for a small set of accounts grew into the file layer behind seven business systems. It withstood three rounds of formal scrutiny and two identity migrations without ever needing a dedicated file transfer team.

Keyed Vendor Access Without a Server to Run and Defend

In 2017, the company’s systems engineering team scoped the requirement, and it was deliberately small: a modest number of accounts for vendors and internal users, a few sets of folders and subfolders, small files purged on a regular schedule, and RSA key exchange for SFTP access.

What makes even a small requirement like that expensive is what it ordinarily takes to meet it. Keyed vendor access means running an SFTP server, and the server brings everything with it: key management, accounts created and removed by hand, patching, and the recurring job of proving to auditors who can reach what. For a systems team inside a corporate security regime, that is infrastructure to build, staff, and defend, for the sake of a modest number of accounts.

The fix had to give each outside party its own keyed, scoped access, keep internal access tied to the corporate directory, expire files on schedule, and produce audit evidence on demand, with nothing for the team to host. The company selected Files.com to provide that governed exchange layer.

A Keyed Account and a Scoped Folder Tree for Every Partner

Files.com became the place where the company’s systems and its outside partners meet, with keys, permissions, and the audit record handled as configuration on a platform rather than software on a server.

Each external partner connects over SFTP with its own account, authenticated by RSA key and confined by folder and subfolder permissions to its own tree. A vendor sees its folders and nothing else. Internal users never received separate file credentials at all. The company connected the site to its corporate identity provider over SAML for single sign-on and turned on SCIM 2.0 provisioning, so Files.com creates, updates, and deactivates accounts as the directory changes. Nobody sets up a file user by hand, and nobody who has left the company keeps access.

For the audit record, the team built a pipeline on the Files.com REST API. It generates History Exports, the site’s own trail of logins and file events, and lands them in a directory on the site for retention and downstream review. The evidence an examiner asks for is produced by the platform, not reconstructed by a person.

From a Small Vendor Exchange to the File Layer Behind Seven Business Systems

With the site in production, the company replaced the question of how to run vendor exchange with a pattern it could repeat: another partner is another keyed account and another folder tree, and another system is another scoped path.

The pattern kept being applied. By January 2020, the company’s own security reviewer, cataloguing the platform for a corporate risk assessment, described it as a SaaS portal holding customer information for processes spanning seven business systems, from Salesforce, Revstream, NetSuite, and SAP to the systems of its agricultural retail and logistics partners. A site scoped as a set of vendor drop folders had become the file layer behind the company’s core commercial systems.

Nothing about how the site is run changed on the way there. The growth was more of the same configuration, applied by the same person.

Three Rounds of Formal Scrutiny

A platform holding customer information behind core business systems draws examiners, and this one drew three: the company’s SOC 2 Type 2 audit, a parent-side internal audit, and a corporate risk assessment. Each put the site’s governance under formal scrutiny.

The deployment withstood all three without a dedicated file transfer team behind it. Its administrators could show that internal access followed the corporate directory, partners stayed within their permission sets, and activity records were already retained through the History Export pipeline.

Two Identity Migrations and a Change of Owner Without Re-Onboarding Users

The company later moved internal logins from Google authentication to Okta, adding SAML single sign-on and SCIM 2.0 provisioning. Then, as part of its integration into the new parent, the same engineer moved the site’s SSO from Okta to Azure while re-basing every username from the company’s own domain to the parent’s domain.

The site absorbed a corporate acquisition’s identity change without re-onboarding a single user, and partner access, authenticated by RSA key rather than through the corporate directory, carried on unchanged.

A Decade of Operation, One Systems Engineer

Today, one systems engineer administers the whole estate on Files.com: the partner accounts and their keys, the SSO and SCIM lifecycle, the folder permissions behind seven business systems, and the History Export pipeline. That has been true across a decade of operation, through the growth from a small vendor exchange, through three formal examinations, and through a change of corporate owner.

What is different about how the company operates is that file transfer never became an operation of its own. When a new partner arrives, the work is a keyed account and a folder tree, done by the person who already runs the site. When an examiner arrives, the record they ask for already exists. And when the company itself changed hands, the file layer behind its business systems moved to the new owner’s identity, domain, and security regime as a configuration change on Files.com, not a rebuild. A partner exchange grew into the file layer behind an enterprise’s core systems and never outgrew its administrative model.