How should we handle vendors that cannot use PGP encryption subkeys?

I’d first confirm who actually requires the extra PGP layer. SFTP and HTTPS already protect data in transit, so PGP mainly adds protection if files are stored or relayed by an intermediary, plus signing and end-to-end verification. If payroll or compliance requires PGP, document the supported key format and test procedure for every vendor; otherwise, simplifying the key setup may be more practical than trying to work around broken vendor software.

The primary certification key is not supposed to be used for encryption. A normal OpenPGP key generally has an encryption subkey by default, while signing and authentication subkeys are optional. If a vendor is trying to encrypt directly to a certification-only primary key, its software is mishandling the key or importing it incorrectly. Check that they imported the complete public key and that the encryption subkey is marked with the encryption capability.

This is probably a limitation of the vendors’ managed-transfer products rather than a problem with subkeys. Many of those tools support only a narrow subset of OpenPGP and assume a simple, default key layout. Ask each vendor exactly which OpenPGP implementations and key capabilities they support, and confirm that their software can select an encryption-capable subkey.

A useful test is to have each vendor show the key details from the exact product they use. Compare the key IDs, capabilities, and OpenPGP version with a known-good vendor. Older or limited implementations may not automatically choose the encryption subkey, and some may only support a primary key with encryption capability. If their product cannot handle a standard encryption subkey, the realistic options are a vendor-side upgrade, a separate compatible key, or dropping PGP for that integration if the business requirements allow it.