Pega supports external key management patterns, but the built-in keystore/documented Data Page approach is oriented around keystore objects such as JKS, PKCS12, JWK, or specific Vault-backed keystore integrations and not arbitrary raw SSH private-key strings loaded ad hoc into the FTP rule at runtime.
Pega’s documentation explicitly mentions HashiCorp Vault keystores and Data Page-based keystore loading, but those patterns are framed around keystore types and master-key/KMS usage rather than a general “fetch raw SSH private key text and inject it into SFTP auth” workflow
So the Data Page + Load Activity pattern is the closest supported extension point if you need dynamic keystore loading.
But for your exact scenario, the better-supported path is to use a Pega keystore integration designed for Vault/keystore material, not to treat raw SSH key material as an arbitrary secret blob and manually couple it into SFTP authentication
The key challenge is that Pega’s keystore APIs and rule forms expect a keystore abstraction, not just any secret. i.e.
- file-based JKS/PKCS12 loaded via KeyStoreUtils or
- JWK from URL or
- Vault-backed keystore definitions for managed cryptographic keys
there is no clear article that I’ve found that says retrieve an SSH private key PEM from Vault and directly attach it to the FTP Server rule’s Client Key at runtime.
So I’d recommend to use a Vault-backed keystore configuration if the key material can be represented in a way Pega’s keystore integration supports. Pega has articles for Configuring a HashiCorp Vault keystore using AppRole authentication. (mentioned above)
However, If your external team insists on raw SSH private key retrieval, implement a custom integration layer that retrieves the key securely from Vault at runtime, keeps it only in memory and is isolated then I would treat that as a custom extension requiring TRA/security review but not as a standard keystore-rule usage pattern.
Also, Pega’s keystore data page supports Node-scoped caching with refresh strategy, which is useful for performance, but with externally managed keys you need to balance cache duration against rotation requirements.
usual best practice:
- short-lived in-memory cache only,
- refresh aligned with Vault rotation policy,
- no persistence in clipboard logs, rule forms, or files,
- strong masking/logging controls
From a security point of view, avoid storing private keys in rule forms, local keystore files, or any long-lived Pega artifacts, if enterprise policy requires Vault control. Pega’s own KMS/custom-source documentation shows the platform expects external key-management integration to be carefully controlled through dedicated APIs/utilities, not casual secret handling in application logic