MuleSoft - SFTP and PGP Encryption
File-based integrations remain common when systems or external partners exchange batch data outside a synchronous API flow. SFTP protects the transport channel, but some use cases require an additional layer of payload protection so that the file remains encrypted even after it leaves the transport session.
This article demonstrates that layered approach with MuleSoft: use SFTP for secure file transfer and PGP for payload encryption and decryption.
Version context: This implementation was created with Mule 3.x-era SFTP and PGP components. The exact Anypoint Studio screens, component names, Java security configuration, and connector behavior are historical. The architectural pattern—transport security plus file-level encryption—remains relevant.
Why Combine SFTP and PGP?
SFTP protects data while it is moving between endpoints. PGP protects the file itself. Combining them is useful when sensitive files may be stored temporarily, forwarded through multiple systems, or retained in locations where transport encryption alone is insufficient.
The example covers two complementary operations:
- Encrypt an outbound file using the receiving party's public key.
- Decrypt an inbound file using the recipient's private key and passphrase.
Processing Flow
The sample Mule application performs the following sequence:
- Read a plaintext file from an SFTP location.
- Encrypt the payload with PGP.
- Write the encrypted file to another SFTP location.
- Read the encrypted file.
- Decrypt the payload.
- Write the decrypted result to the destination location.
Create the Mule Application
Create a Mule application in Anypoint Studio using the project wizard.

Configure PGP
The original Mule 3.x implementation configured PGP through global elements and Spring beans.


The configuration requires access to the relevant key material and credentials, including:
secretKeyRingFileName— path to the private-key ring.publicKeyRingFileName— path to the public-key ring.secretAliasId— identifier for the private key used by the runtime.secretPassphrase— passphrase protecting the private key.pgpCredentialAccessor— accessor used to supply encryption credentials.
The example also uses a PgpCredentialAccessor class to expose the credentials required by the PGP configuration.

The completed configuration resembles the following:

Encrypt the Inbound File
The first flow reads a file through the SFTP_IN endpoint, encrypts the payload, and writes the encrypted output through the SFTP_ENCRYPTED endpoint.


At a design level, the sequence is:
SFTP input → PGP encryption → SFTP encrypted output
Decrypt the Encrypted File
The second flow reads the encrypted file, applies PGP decryption, and writes the plaintext result through the outbound SFTP endpoint.


Conceptually:
SFTP encrypted input → PGP decryption → SFTP output
Resolve the Private-Key Alias
In the original runtime, an initial placeholder value was used for the secret-key alias. When the application started, the Mule logs exposed candidate key identifiers that could be used to configure the correct alias.

After updating the configuration with the appropriate key identifier, the application started successfully.


With the flows running, a file placed in /IN/ is encrypted into /ENCRYPTED/, and the second flow decrypts it into /OUT/.
Security Considerations
A production implementation should treat private keys and passphrases as secrets rather than embedding them directly in application configuration. Key rotation, access control, auditability, algorithm selection, and failure handling should be designed explicitly.
The historical example also referenced installing Java Unlimited Strength Jurisdiction Policy files. That requirement was specific to older Java distributions and should not be treated as a current universal requirement.
Takeaway
SFTP and PGP solve different layers of the security problem. SFTP protects the connection; PGP protects the payload. Using both can provide defense in depth for file-based integrations, especially when sensitive files are stored or forwarded after transmission.