A Shared University Campus Runs an Audit-Controlled SFTP Hub for Partner Institutions on Files.com

A shared regional university campus hosts degree programs from a group of public universities side by side. Thousands of students take classes there across dozens of degree and certificate programs. But the campus grants no degrees. Every student applies to a home university, follows that university's curriculum, and graduates with that university's diploma. The campus runs the shared facilities around them.

That structure has a consequence for data. Every student on the campus is officially somebody else's student. The systems that create their accounts, issue their ID cards, track the IT assets they use, and support emergency and safety planning all depend on enrollment records held by separate institutions. For the campus to operate, every partner university's student data has to land on one campus, every day.

Partner Registrars, One Morning Deadline

Each morning, servers at the partner institutions connect over SFTP and deposit that day's files into institution-specific folders: enrollment rolls and student contact information, FERPA-scoped data covering the thousands of students on campus. Deliveries typically finish by mid-morning. The campus's own systems then pull the files down and compile them into the central system that provisions accounts, issues ID cards, tracks assets, and feeds safety planning. The campus's operator ranks this exchange among the most important data processes the campus runs, because everything downstream starts from it.

The workload is machine-to-machine, and the campus does not control the servers and network configurations at its partner institutions. The hub therefore had to give each university a reliable SFTP destination while keeping its data separated from every other partner's.

Two Controls Had to Hold in the Cloud

The state university system's security auditors required a two-layer restriction on the exchange: only known endpoint devices could connect, and every connection had to authenticate with an account.

The structure of the exchange raised the bar further. Each partner institution needed to connect through its own network controls, authenticate against the campus's existing directory, and land in a separate folder tree. Their network teams also needed fixed addresses they could whitelist rather than a shifting cloud range.

The campus selected Files.com to carry the hub on those terms.

The Same Two Layers, Rebuilt on Files.com

For the endpoint layer, Files.com's site-wide and per-user IP whitelisting restricts access to approved addresses. The campus controls those lists directly, while campus firewall access controls continue to operate alongside them.

For the account layer, Files.com authenticates connections through the campus's LDAP and Active Directory environment. Group-based permissions map each institution to its own folder tree, and root-directory mappings land each partner's service account in its own directory and nowhere else. One partner cannot see another partner's students.

Dedicated static IP addresses give partner network teams a small, stable set of Files.com addresses to whitelist. The campus also uses a custom domain it controls, preserving a consistent destination for the institutions connecting to the hub.

Event notifications on every institution's folders flag each morning's drop-offs, so a partner that fails to deliver is visible before the compile runs. The FERPA-scoped files are encrypted in transit and at rest on Files.com.

The campus demonstrated the two-layer restriction to the university system's audit office. The audit manager approved the cloud deployment, confirming that the required endpoint and account controls held on Files.com.

The Control Holds Across a Growing Hub

With the partner-facing SFTP hub running on Files.com:

• Only approved endpoints can connect, and each connection must authenticate against the campus directory.
• Dedicated static IP addresses simplify firewall configuration for partner network teams.
• Folder permissions keep each institution's student data isolated, while event notifications make missing daily deliveries visible.
• The hub already extends beyond the core university partners. Two community colleges now feed the same pipeline.

What the Audit Requirement Was Actually For

Today the rhythm of the campus remains the same. By mid-morning each day, the partner universities' enrollment files have landed, and the systems that give thousands of students their accounts and ID cards run from them. Files.com handles the partner-facing SFTP hub, while the campus's local aggregation process pulls down and compiles the daily data.

The audit requirement was never really for a server. It was for two provable controls: known endpoints and authenticated accounts. Once Files.com could demonstrate both to the university system's auditors, the campus could run its multi-institution exchange in the cloud without compromising the restrictions that protect it.