Power Automate Desktop Gets Native PGP File Encryption: Key Management and Deployment Risks

While the roadmap announcement frames this capability as an effortless way to eliminate custom PGP solutions and reduce manual handling, any seasoned IT practitioner knows that adding a cryptographic action to a workflow is only half the battle. Native actions simplify the mechanics of encryption, yet they leave the hardest operational challenges—key custody, passphrase portability across Windows machines, partner cipher negotiation, and exception handling—squarely on the shoulders of the automation architect. Here is a deep dive into how Power Automate’s PGP actions actually work under the hood, what parameters they expose, and how to deploy them without creating a maintenance nightmare on your Windows automation hosts.

From Workarounds to Native Desktop Flow Actions​

To appreciate why this update matters, it helps to look at what Power Platform makers were forced to do before it arrived. For years, threads on the Microsoft Power Platform Community forums echoed the same question: how do you encrypt or decrypt PGP files in Power Automate? Because neither cloud flows nor desktop flows offered built-in OpenPGP actions, standard community guidance often pointed teams toward invoking an Azure Function to run custom C# or Python cryptography libraries, or installing third-party PGP binaries directly on Windows virtual machines and calling them via command-line actions.

Those workarounds introduced brittle dependencies. If you upgraded a Windows Server or Windows 11 RPA bot machine and forgot to install the exact version of GnuPG—or if the local service account lacked permissions to the local keyring directory—the entire unattended desktop flow would grind to a halt at 2:00 AM.

Listed under Microsoft's AI at Work roadmap item 576786 as reaching General Availability in July 2026 for Worldwide (Standard Multi-Tenant) environments (following an earlier Microsoft 365 Message Center notice, MC1325004, that projected a June 30, 2026 rollout), the PGP Cryptography action group brings native OpenPGP file operations straight into Power Automate for desktop. According to Microsoft's release notes, the feature is available automatically to admins, makers, and marketers in the action picker without requiring separate UI switches or feature toggles, though encryption or decryption only occurs when a maker explicitly drops the actions into a workflow or wraps them in conditional branches.

Section Summary:

• The Legacy Problem: Previously, Power Automate users had to rely on external Azure Functions or command-line scripts to handle OpenPGP file exchanges.
• The Native Solution: Roadmap ID 576786 (2026 release wave 1) introduces built-in PGP actions directly into the Power Automate for desktop action picker.
• Rollout Status: Marked as Launched for Worldwide Standard Multi-Tenant environments, with Microsoft Learn documentation detailing the exact action reference as of July 2026.

Under the Hood: What the PGP Actions Actually Do​

A critical distinction separates the high-level roadmap summary from the technical reality documented in Microsoft Learn’s PGP cryptography reference for Power Automate for desktop. While the roadmap overview mentions encrypting "files or data payloads", the actual desktop flow implementation is strictly file-based. You are not passing arbitrary in-memory JSON strings or raw text variables into an action and receiving an encrypted string variable back. In fact, Microsoft Learn explicitly notes that neither PGP action produces any output variables at all. Instead, both actions read a source file from disk and write the resulting output directly to a specified file path.

The PGP Cryptography group consists of two specific actions: Encrypt file with PGP and Decrypt file with PGP.

1. Encrypt File with PGP​

When your Windows automation bot prepares an outbound file—say, a CSV export from a legacy ERP system—the Encrypt file with PGP action locks it down using the recipient’s public key. Microsoft’s documentation specifies the following required parameters:

• File to encrypt: The full local or network path to the source file.
• Encrypted output file: The full destination path where the encrypted artifact will be written.
• Public key source: Lets you choose between File (the default) or Text.
• Public key file / Public key: If you select File, you provide the path to a .asc, .gpg, or .pgp key file. If you select Text, you supply the ASCII-armored public key block directly (which begins with -----BEGIN PGP PUBLIC KEY BLOCK-----).
• Encryption algorithm: The symmetric cipher used to encrypt the session payload. Supported options are AES-128, AES-192, AES-256 (the default), Triple DES, and CAST5.
• Compression algorithm: Applied to the file before encryption takes place. Options include None, ZIP (the default), ZLIB, and BZIP2.
• ASCII armor: A Boolean toggle that defaults to False. When left disabled, the action writes raw binary data. When enabled (True), it wraps the output in text-based ASCII armor starting with -----BEGIN PGP MESSAGE-----.

2. Decrypt File with PGP​

For inbound workflows—such as decrypting partner files downloaded from an SFTP server—the Decrypt file with PGP action reverses the process using your organization's private key. Its parameters mirror the encryption action:

• Encrypted file: The full path to the incoming PGP-encrypted file.
• Decrypted output file: The full path where the plaintext file should be saved.
• Private key source: Either File (default) or Text.
• Private key file / Private key: A path to a .asc, .gpg, or .pgp private key file, or the ASCII-armored key text. (Curiously, Microsoft Learn's parameter table describes the private key text field as beginning with -----BEGIN PGP PUBLIC KEY BLOCK-----, which is almost certainly a copy-paste documentation typo on Microsoft's part for a private key block—makers should test their specific exported ASCII-armored private key blocks carefully before production deployment.)
• Passphrase: An optional field accepting either a direct encrypted input or a text variable value for the passphrase protecting the private key. If your private key does not use a passphrase, you leave this field empty.

Section Summary:

• File-Centric Design: Both actions operate strictly on file paths and do not generate output variables in the flow.
• Granular Cipher Control: Makers can choose between modern AES ciphers (defaulting to AES-256) and legacy algorithms like Triple DES or CAST5, alongside ZIP, ZLIB, or BZIP2 compression.
• Flexible Key Delivery: Keys can be referenced from .asc, .gpg, or .pgp files on disk or injected as ASCII-armored text.

Real-World Interoperability: Why Cipher and Armor Settings Matter​

Why did Microsoft expose five different symmetric encryption algorithms and four compression settings instead of just hardcoding AES-256 and calling it a day? Anyone who has integrated with banking mainframes or decades-old supply chain EDI gateways already knows the answer: partner systems can be notoriously picky.

While AES-256 with ZIP compression is a sensible modern default, financial institutions and legacy enterprise gateways occasionally run older OpenPGP implementations that reject certain compression headers or expect specific cipher suites. For instance, some automated clearinghouse parsers fail if a file is compressed with BZIP2, while others require ASCII armor (-----BEGIN PGP MESSAGE-----) because their ingestion pipeline transfers the payload through text-only message queues that corrupt raw binary streams. Conversely, high-volume data lakes often demand raw binary output (ASCII armor set to False) to avoid the roughly 33% file-size overhead that Base64 ASCII armoring adds to large datasets.

By surfacing these parameters directly in the action properties, Power Automate for desktop spares makers from having to rewrite command-line flags when a trading partner's IT department sends over a rigid cryptographic specification sheet. Still, native support does not guarantee plug-and-play success on the first run; teams must verify their partner's exact cipher, compression, and armoring requirements during integration testing.

The Operational Catch: Passphrases, Machine Binding, and Key Custody​

Here is where we put on our veteran sysadmin hat and look past the marketing gloss. Adding an action to a flow is easy; managing private keys and passphrases securely across a fleet of Windows RPA machines is where things get tricky.

When configuring the Decrypt file with PGP action, you have to decide how to supply the private key and its passphrase. According to Microsoft Learn's general guidance on using passwords in Power Automate for desktop, password-required fields allow either Direct password input or Password input as variable. Understanding the difference is vital if you run flows across multiple machines or attended/unattended bot pools:

1. The Machine-Binding Trap with Direct Inputs: When you type a password or passphrase directly into a designated secret field in Power Automate for desktop, the client uses machine-based encryption to secure it. As Microsoft Learn warns, a direct password input only works on the specific Windows machine where it was initially entered. If you export that desktop flow, promote it from a Dev VM to a Production Windows Server, or run it on a different unattended machine in a machine group, the flow will show as invalid and fail until someone manually opens the flow on that target machine and re-enters the secret.
2. The Hardcoding Pitfall: To make a flow portable across multiple Windows machines, Microsoft recommends using the variable input option and marking the variable as sensitive. However, Microsoft explicitly cautions against hardcoding secret strings inside a standard Set variable action inside the flow. Even if you mark that variable as sensitive—which masks the value in desktop flow run logs—a hardcoded value inside Set variable remains exposed in both the designer modal and the underlying flow definition stored in Microsoft Dataverse.
3. Key Custody on Disk vs. Text: Similarly, if your flow points to a local .asc or .pgp private key file on the Windows filesystem, every machine capable of running that desktop flow needs read access to that exact file path, and Windows ACLs (Access Control Lists) must be locked down so unauthorized local users cannot copy the key file. Alternatively, if you pass the private key as ASCII-armored text, you need a secure runtime mechanism—such as passing sensitive inputs from a parent cloud flow or retrieving secrets dynamically at runtime—rather than pasting a raw private key directly into the flow definition.

Section Summary:

• Avoid Direct Passphrase Entry in Multi-Bot Setups: Direct password inputs are encrypted to the specific Windows machine where they were typed and break when moved to another host.
• Never Hardcode Secrets in Set variable: Marking a variable sensitive hides it from logs, but hardcoded text inside action properties remains visible in the Dataverse flow definition.
• Plan Key Distribution: Decide early whether private keys will live in ACL-restricted directories on your Windows bot hosts or be injected dynamically as sensitive text variables at runtime.

Building Resilient Workflows: Step-by-Step Implementation and Error Handling​

Because neither Encrypt file with PGP nor Decrypt file with PGP generates output variables, your desktop flow logic must revolve around deterministic file paths and proactive exception handling. Microsoft Learn documents five specific exceptions across the two actions that makers should trap using Power Automate’s On error block or action-level error handling:

• Failed to encrypt file with PGP / Failed to decrypt file with PGP: General cryptographic failure (for example, corrupted ciphertext or incompatible cipher parameters).
• File not found: The source file path does not exist when the action executes.
• Key file not found: The .asc, .gpg, or .pgp key file is missing from the expected directory.
• Invalid PGP key: The supplied key is malformed, corrupted, or cannot be parsed.
• Incorrect passphrase (Decrypt only): The passphrase provided does not unlock the selected private key.

Recommended Implementation Checklist for Windows Admins and Makers:​

1. Stage Files in Dedicated Working Directories: Before invoking the PGP action, use standard file actions to verify that the input file exists and has finished writing (especially important when files arrive via slow SMB shares or SFTP sync folders).
2. Parameterize File and Key Paths: Store your input path, output path, and .asc/.gpg/.pgp key path in flow variables rather than static strings so you can transition smoothly between Development, Test, and Production Windows environments.
3. Confirm Partner Specifications Upfront: Verify whether your external partner requires binary output or ASCII armor (True), and match their required symmetric cipher (AES-256, AES-192, AES-128, Triple DES, or CAST5) and compression method (ZIP, ZLIB, BZIP2, or None).
4. Wrap Cryptographic Actions in Error Blocks: Configure action-level exception handling for Invalid PGP key, Key file not found, and Incorrect passphrase so your flow can alert administrators and move failed files to a quarantine folder rather than silently halting the bot queue.
5. Clean Up Plaintext Artifacts: After encrypting an outbound sensitive file—or after processing a decrypted inbound file—use a file deletion action to securely remove temporary plaintext copies from the local Windows disk so sensitive data does not linger on the automation host.

The Bottom Line for Enterprise Automation​

The arrival of native OpenPGP actions in Power Automate for desktop is a welcome, pragmatic upgrade for Windows-based RPA environments. It strips away one of the most annoying external dependencies in enterprise file automation, allowing makers to retire fragile command-line GnuPG wrappers and unnecessary Azure Function detours for local file processing. Just remember that cryptography is only as strong as the operational hygiene surrounding it: treat your private keys and passphrases with strict Windows access controls, avoid machine-bound password traps when scaling across bot farms, and test your cipher configurations thoroughly with your trading partners before flipping the production switch.