Skip to main content

From Kleopatra to Files.com: Odom Moved PGP Encryption Out of the Data Center

A business systems manager built the encrypted payroll and benefits automations in a browser, with on-platform PGP, audit logs, and event-triggered email notifications.
The Odom CorporationFiles.com

The Odom Corporation has been moving beverages across some of the hardest terrain in America since 1934. A family-owned Coca-Cola bottler and wholesale distributor, and one of the largest privately held companies in the Pacific Northwest, Odom sells soft drinks, beer, wine, and spirits across Alaska, Washington, Idaho, Oregon, Wyoming, and Hawaii, through roughly 20 distribution centers and about 2,300 employees.

A company shaped like that runs on data moving between systems. Its people are spread across six states, and the platforms that pay them and administer their benefits are SaaS products run by other vendors. The hours a field rep punches into the Green Mile application have to reach UKG payroll. COBRA benefits files have to reach the company's benefits administrator, PGP-encrypted. None of those systems talk to each other directly. Files carry the data between them, and for years, the machinery that moved those files lived in Odom's own data center. When Odom prepared to exit that data center, PGP encryption for payroll and benefits still depended on Kleopatra installed on a local Windows machine.

Payroll Hours, a Scheduled Task, and a Desktop Utility

The pipeline that fed UKG showed how these feeds ran. A PowerShell script on an on-premises server, kicked off by a Windows scheduled task, pulled a file of employee punch hours from the Green Mile API. Before that file could go out, it had to be PGP-encrypted, and that job belonged to Kleopatra, a desktop encryption utility installed locally on the machine. The script then placed the encrypted result on UKG's SFTP site. The COBRA benefits feed carried the same requirement: sensitive files, encrypted before delivery.

The cost of that design was a hidden dependency. Payroll data for 2,300 people had one specific Windows machine in its path, and every hop was a point of failure that reported nothing. There was no platform log to check and no alert when a step did not run, so a failure surfaced only when someone downstream went looking for a file that never came. The pipeline was also tribal knowledge: even the team that owned it had to piece together out loud how the encryption leg actually worked.

The encryption was not a property of the workflow. It was a property of one Windows install, and everything downstream inherited that fragility.

The Data Center Exit Left the Encryption Nowhere to Run

None of this felt urgent while it ran, and it did run, daily, for years. A working payroll feed is the last thing an IT team volunteers to rebuild. What changed was structural.

Over the last five years, we've really been re-platforming all of our in-house built applications and all of our on-prem stuff, and transforming them into SaaS apps.
Murray Looper, IT Director, The Odom Corporation

That program eventually reached the data center itself. Odom committed to exiting it, and the on-premises servers hosting the scheduled tasks were being deprecated. The pipelines could not simply be re-pointed at new hardware, because the encryption step was welded to a locally installed desktop application. The encrypt and decrypt function itself had to move somewhere.

The replacement had to encrypt and decrypt files with counterparties' keys inside the transfer, deliver on schedule to the SFTP endpoints those counterparties already ran, keep a record of every run, and send an email when something happened. And it had to be operable by Odom's business systems team, because these are business feeds, not an engineering product.

Odom selected Files.com to carry the encrypted feeds.

Encryption as a Folder Setting, Delivery as an Automation

On Files.com, each feed is a folder and a rule rather than a script and a machine. When a punch-hour file reaches its folder, Files.com's on-platform PGP encrypts it automatically with UKG's public key, and a Files.com Automation delivers it over an outbound SFTP connection to UKG's server. The COBRA feed runs the same way, syncing files out PGP-encrypted to the benefits administrator's endpoint, and inbound encrypted files decrypt on the platform. No desktop utility touches any of it. The Kleopatra install was retired. Staff reach the site through Odom's existing Entra ID sign-in, with MFA enforced.

The IT manager who runs Odom's business systems built these automations herself, in the browser, without an engineering project. She names the logging and the event-triggered email notifications as the capabilities that matter most to her team: every run is recorded, and the platform emails when an event fires.

Encryption With No Desktop in the Path

With the feeds in production on Files.com, Odom replaced a machine-bound encryption step with a workflow the platform runs and records.

  • PGP encryption and decryption for punch hours and COBRA benefits files run with no desktop utility and no particular machine hosting that step. Encryption happens inside the transfer, on every file, the same way every time.
  • Every automation run lands in the log, and event-triggered emails tell the team what moved.
  • The encrypted feeds cleared the data center exit. Encryption and delivery no longer run on servers Odom has to keep alive.
  • The next counterparty that requires PGP is a folder, a key, and an automation, built by the business systems team in the browser rather than scoped as an engineering project.

Encryption That Belongs to the Workflow

Odom did not find a new machine for the encryption step. It stopped being a machine's job at all.