Files.com encrypts your files in transit and at rest by default. A partner or compliance requirement may also call for GPG or PGP encryption of the file itself. Files.com can encrypt a delivery, decrypt an incoming file, or recrypt it for a different recipient.

An encrypted connection protects a file while it travels between systems. GPG protects the file contents independently of that connection, so the delivered file remains unreadable until its recipient decrypts it with the matching private key. Agreeing to use an encrypted transfer protocol does not establish whether a partner also expects a GPG-encrypted file.

An encrypted TLS or SSH connection protects the transfer of invoice.csv, which is readable at the recipient. When invoice.gpg also has GPG file encryption, the connection protects its transfer and the file remains encrypted at the recipient until decrypted with the required key. File encryption is separate from Files.com storage encryption.

About GPG

GPG stands for GNU Privacy Guard; PGP stands for Pretty Good Privacy. Both names are used for file encryption in partner exchanges.

How GPG Encryption Works

GPG uses a recipient's public key to encrypt file contents. Only the corresponding private key can decrypt them. You can give a public key to senders without giving them the ability to open files encrypted with it.

Files.com can use a recipient's public key to prepare encrypted deliveries without holding their private key. To decrypt incoming files in Files.com, provide the matching private key through the GPG Key Manager. Decide which system should recover the readable contents before choosing where to process the file.

Choosing How GPG Runs

Choose whether processing belongs to a person handling one file, a step in an Automation, or the folder receiving files. These are independent ways to use GPG; manual actions and Automations v2 steps do not require a GPG folder setting.

Approach	Where you configure or start it	What determines the files processed
Manual encryption or decryption	Choose the action in the File Manager or GPG Key Manager.	The one file you select. No Automation or GPG folder setting is needed.
Automations v2	Add an Encrypt With GPG or Decrypt With GPG step.	The files routed to that step in the workflow.
GPG folder processing	Enable encryption, decryption, or recryption in the receiving folder's settings.	Incoming files within the setting's scope, whether or not an Automation delivered them.

GPG in Automations v1 and v2

In Automations v2, GPG is an explicit workflow step. Its key and output destination are configured on the node, and the next node receives the processed file.

You can place encryption after a transformation and before delivery, or decryption before a step that reads the contents, without moving files through a folder configured for GPG. The source file remains unchanged; each GPG node writes its result as a new file.

Automations v1 has no GPG action. To include GPG in a v1 workflow, configure the receiving folder's GPG setting and arrange for the Automation to deliver files into it.

For example, a Copy Files Automation can copy a report into a folder configured to encrypt it. A native-storage Move Files action does not trigger GPG processing. Review the Automation's source and destination together with the folder's operation, keys, and inheritance: the Automation configuration alone does not describe the processing, and other files arriving in that folder follow the same rule.

A folder setting also works without an Automation. For example, a partner can upload encrypted files over SFTP to a folder that automatically decrypts incoming deliveries. Use it when processing is a rule of that receiving location, regardless of who or what supplies the files.

When a v2 GPG node owns the processing, choose its output folder deliberately. Folder settings still apply to files written there; avoid an additional GPG folder rule unless that extra processing is intended. Use the v2 action settings to configure the node's key, destination, and error handling. For processing governed by a receiving folder, see GPG Folder Processing.

File Size Constraints

Files.com supports GPG encryption, decryption, and recryption on files up to 10 GB. GPG processing is CPU-intensive, so the file-size ceiling controls the processing capacity required for an individual job. The same per-file limit applies to manual actions, Automations v2 GPG steps, and folder processing, including buffered uploads to Remote Server Mounts.

GPG operations consume Transformation and AI Credits based on file size. If your workflow needs larger files, we welcome a conversation about raising the limit. Contact us with your expected file sizes, transfer volume, and processing schedule so we can assess and provision enough capacity for the workload.

Signing Constraints

Files that are both encrypted and signed are decrypted successfully, but no signature verification is performed.

Decryption uses the recipient's private key to recover the file contents. Verifying the sender's signature is a separate operation that requires the sender's trusted public key. Successful decryption therefore does not authenticate the sender. If your workflow requires that assurance, verify the signed file separately.

Folder Processing and Remote Storage

A GPG folder setting processes files after they arrive. Its output becomes a new file that can trigger notifications and Automations. Uploads and copies trigger processing in native storage; moving or renaming an existing native file does not. GPG Folder Processing explains the file lifecycle, output names, and processing results.

A GPG folder setting on a Remote Server Mount requires temporary storage on Files.com before remote delivery, even when the Remote Server's Buffered Upload setting is Never. Consider that requirement if you chose a mount to keep file data off Files.com infrastructure. See GPG on Remote Server Mounts for the processing and storage behavior.

GPG (PGP)