Fidelity Moves Vendor PGP Processing Off Windows Server and Into Files.com Folders

Fidelity Building Services Group is a building services contracting group serving commercial clients across the United States.

The group is built differently from most contractors its size. Rather than a single operating entity, Fidelity is a partnership of roughly 22 regionally branded companies, each trading as “A Fidelity Company,” with 2,600 employees across more than 70 locations.

That structure has a consequence for IT. HR runs group-wide, and the outside benefits and services vendors that work from the employee roster serve all of those companies at once. Data about 2,600 employees has to leave the company on a recurring schedule, and it is exactly the kind of data that cannot travel in the clear. Every file in the exchange moves PGP-encrypted, in both directions.

Fidelity moved bidirectional PGP processing out of its Windows Server workflow and into Files.com folder behaviors, turning additional vendor connections into configuration rather than more manual cryptographic work.

The Encryption Lived on a Windows Server

The cost of the encryption requirement landed on Fidelity’s IT team. Outbound roster files had to be encrypted with the right counterparty’s key before delivery. Inbound vendor files arrived encrypted and sat until someone downloaded them to a Windows Server 2016 file share and ran GPG decryption locally. The inbound side of a pipeline carrying employee data for 2,600 people worked only when a person or a local script worked.

The workflow spanned systems with distinct roles. The roster originated in Okta on the identity side. Downstream processes expected plaintext files on on-premise Windows shares. Each of the four vendors ran its own SFTP endpoint. PGP had to be applied or removed at exactly the right hop between them, and Fidelity wanted to stop maintaining that cryptographic work on its Windows servers.

What the fix had to do was clear. Encryption and decryption had to happen inside the transfer path itself, so no key or crypto tool lived on a Fidelity server. Delivery had to run on schedule over SFTP, which the vendors already spoke. The HR side had to be able to feed the pipeline and clean up after it programmatically, and the whole path had to be restricted to known networks.

Fidelity selected Files.com to be that path.

PGP Became a Property of the Folder

Files.com became the encryption and delivery layer between Okta, the vendors, and the on-premise estate. Instead of encrypting files and then transferring them, Fidelity made encryption something the transfer point did on its own: its Files.com folders carried the crypto as paired encrypt and decrypt behaviors.

Outbound, Okta Workflows uploaded roster files over SFTP into a Files.com folder configured with a GPG encryption behavior. The moment a file arrived, Files.com encrypted it with the counterparty’s public key. Scheduled remote server syncs then pushed the encrypted files over SFTP to each of the four vendor endpoints. No person was in that path.

Inbound files from vendors landed in the paired decryption folder, where Files.com decrypted them automatically with Fidelity’s private key. The Files.com CLI then pulled the decrypted files down to the Windows Server 2016 shares where downstream processes expected them. The keys are attached to the folders rather than to machines, so there is no keyring to maintain on a server and no wrapper script to break.

Two more pieces closed the loop. When a run completed, Okta Workflows called the Files.com REST API to delete the files, so sensitive rosters never accumulated at the transfer point. And IP allowlisting restricted which networks could reach the pipeline at all.

Drop, Encrypt, Push: The Exchange Runs Itself

With the folder behaviors in production, Fidelity replaced a vendor exchange built around local GPG handling with an unattended pipeline.

• Roster distribution runs with nobody in it. Okta drops the file, Files.com encrypts it on arrival, and the scheduled sync delivers it to the vendor. No one runs a script or touches a key.
• Nobody decrypts a file by hand anymore. Inbound vendor files decrypt automatically on arrival, and the CLI pulls them to the on-premise shares in usable form.
• The crypto work left Fidelity’s server estate entirely. Encryption, decryption, and the keys behind them now live in Files.com folders, not on Windows servers.
• Onboarding the next vendor is configuration, not development: a folder, a key, and a scheduled sync. The same pattern already serves four vendor endpoints.

Encryption Stopped Being Anyone’s Job

Today, data about 2,600 employees crosses company lines on a schedule, and no one at Fidelity handles it on the way. For a group built across roughly 22 companies and adding vendors, the exchange now grows by configuration instead of by manual work.