San Luis Obispo County Uses Files.com to Meet the CalSAWS SFTP Mandate Without Building a DMZ Server

The County of San Luis Obispo's Department of Social Services is the safety net for a stretch of California's Central Coast. It runs the programs that put food, health coverage, cash aid, and protection within reach of the county's residents: CalFresh, Medi-Cal, CalWORKs, foster care, and protective services for children and dependent adults. The scale is steady and large. In an average month, the department carries nearly 22,000 active CalFresh cases and more than 38,000 Medi-Cal cases.

Those are not county programs in the ordinary sense. They are state and federal entitlement programs that California delegates to its counties to administer. The county owns the casework. The state owns the systems the casework runs on. So when California mandated a new statewide welfare eligibility system, CalSAWS, San Luis Obispo County did not get to evaluate it. It had to connect to it.

To make that connection, the county selected Files.com as a fixed-IP SFTP landing zone, allowing nightly files to move automatically without building and indefinitely operating an internet-facing server in its DMZ.

CalSAWS Arrived With an SFTP Requirement the County Could Not Meet

The new system required nightly batch transmission of fiscal-interface files: sensitive constituent data, delivered over SFTP, to a publicly reachable endpoint at a static IP address. The state's side of the interface was fixed. The protocol, the schedule, and the shape of the receiving target were all decided for the county, not by it.

The county had no such target. Its legacy welfare system provided no dedicated SFTP channel for this traffic, and the department had no inbound SFTP location of its own behind its DMZ. Until one existed, there was nowhere for the state's files to land, and the mandated interface could not run. The migration timeline belonged to the state, and the department needed an endpoint urgently.

The Default Answer Was a DMZ Server the County Would Own Forever

The requirement could not be negotiated away. A statewide system does not adapt itself to each county. Each county stands up a fixed, reachable target and keeps it standing.

The only in-house way to do that was to build it: acquire static IP addresses, stand up an internet-facing SFTP server in the county's DMZ, harden it, and then own it for as long as the interface exists. That server would carry welfare-program data about county residents, which means it would also carry a class of security exposure the county would have to defend indefinitely. All of it on the state's schedule, in a department whose job is eligibility casework, not running file transfer infrastructure.

What the fix actually had to do was narrower than what a server project would deliver. The county needed an endpoint that was publicly reachable at fixed IP addresses, restricted so only the state's approved senders could deliver, presented under the county's own name, and reachable from inside the county network so internal systems could collect what landed. None of it could require the county to operate a server of its own.

A Static-IP Endpoint Under the County's Own Name, Locked to Known Senders

Files.com gave the department a hosted SFTP endpoint on dedicated static IP addresses, the fixed target the statewide system required. A custom domain under the county's own government domain fronted the site, so the address senders connected to carried the county's name rather than a vendor's. Inbound access was restricted with Files.com's IP allow-listing: only the approved sender addresses could deliver files, and every other source was refused the connection.

On the collection side, nothing connected into the county at all. A provisioned API user was configured to pull each landed batch file from Files.com into the department's application servers through the Files.com API. That connection originated inside the county network and traveled outbound, so the county's firewall never opened an inbound port for this traffic. Files.com held the public face of the interface. The county reached out and took what arrived.

The cutover was self-driven. A single onboarding call with Files.com covered user provisioning and the custom domain setup, and the county then confirmed connections over both the dedicated IP addresses and its own domain.

Nightly Feeds Land, Get Collected, and Run Without Hands

With the endpoint in production, San Luis Obispo County met the CalSAWS interface requirement without adding a single piece of internet-facing infrastructure of its own.

• The state's nightly fiscal-interface feeds land on a controlled ingress point: fixed IP addresses, sender allow-listing, and the county's own name on the domain.
• Sensitive constituent data is received without the county opening its perimeter. There is no DMZ server to acquire, harden, patch, or defend, now or for the life of the interface.
• Collection runs unattended. The API user moves each landed file into the department's application servers with no operator handling files by hand.

A Mandate Met Without Becoming an Infrastructure Operator

When California mandated the interface, the county's obligation was to receive the files, not to run perimeter infrastructure. Files.com let San Luis Obispo County meet the first without ever taking on the second.