Bring your own secrets (BYOS)

Enterprise applications connect with external systems, cloud services, and security platforms. These integrations require sensitive values such as client secrets, access keys, private keys, service account credentials, and encryption key identifiers.

Storing these values in Pega Platform creates these challenges:

• Credentials distribute across multiple systems.
• Security teams manage and audit additional storage locations.
• Secret rotation might require application changes or deployments.
• Decentralized storage conflicts with organizational initiatives for centralized secret management.

Under Zero Trust and cloud-native security models, Lead System Architects (LSA) reduce the number of locations that store secrets and limit risks associated with long-lived credentials.

BYOS supports an architecture in which organizations manage secrets in an enterprise secret manager. Pega Platform stores a reference to the secret instead of the secret value and retrieves the value at runtime.

This approach shifts responsibility for storing, rotating, and auditing secret values from the application to enterprise security services.

Design principle: Applications consume secrets; they do not own them.

Deployment considerations: BYOS applies mainly in environments where organizations manage their own cloud accounts, identity federation configuration, and secret stores such as AWS Secrets Manager, Microsoft Azure Key Vault, or Google Secret Manager. In these environments, Pega Platform retrieves secrets at runtime through federated identity instead of storing credential values locally.

The following table compares traditional credential storage with BYOS:

BYOS combines identity federation with external secret stores. Identity federation establishes trust between Pega Platform™ and a cloud provider, enabling Pega Platform to access cloud resources without maintaining long-lived cloud credentials. External secret store references map references in Pega Platform to credentials and secrets maintained in the cloud provider’s secret store, allowing Pega Platform to retrieve them when needed. The following sections explore each capability in more detail.

Identity federation

Identity federation enables Pega Platform to access cloud resources by establishing a trusted relationship with a cloud provider through workload identity federation. Instead of storing long-lived cloud access keys in the application, Pega Platform exchanges a workload identity token for short-lived cloud credentials issued by the cloud provider. This approach reduces credential management overhead and aligns with modern Zero Trust security practices.

The workload identity token originates from one of the following sources:

• Pega Platform acting as an OpenID Connect (OIDC) identity provider
• An external OIDC-compliant identity provider, such as Okta

The cloud provider evaluates the federated identity and grants access based on configured roles, policies, and scopes. The cloud provider's identity and access management service governs access to external secret stores rather than static credentials stored in the application.

To establish identity federation between Pega Platform and the cloud provider, complete the following steps:

• Configure an Identity Federation Rule in Pega Platform.
• Configure the cloud provider's identity and access management service to trust the identity provider.
• Assign the required roles, policies, or scopes that authorize access to the external secret store.
• Record provider-specific federation details in the Identity Federation Rule, such as an AWS role ARN, an Azure tenant identifier, or other configuration values required by the cloud provider.

After establishing federation, Pega Platform uses federated identity to access secrets from the external secret store at runtime, reducing the need to maintain secret values directly in Pega Platform.

External secret stores

An External Secret Store Rule maps reference names in Pega Platform to secret identifiers in an enterprise secret manager.

At runtime, Pega Platform authenticates through the federated identity, resolves the reference, and retrieves the corresponding value. When the security team rotates the secret in the external secret manager, the consuming Rule continues to use the reference.

Supported providers

The following table lists the supported cloud providers and services described in this topic:

The following sequence describes how Pega Platform retrieves a secret for an integration:

1. A consuming Rule, such as an OAuth 2.0 Authentication Profile, requests a secret.
2. Pega Platform presents an OIDC workload identity token to the token service of the cloud provider.
3. The cloud provider validates the token against its trust configuration, including the issuer, audience, subject, and assigned role.
4. The cloud provider issues short-lived credentials.
5. Pega Platform uses the credentials to retrieve the referenced secret from the external store.
6. Pega Platform uses the secret value for the integration call.

When troubleshooting the process, determine whether the failure occurs during:

• Identity federation, which includes trust, role, token, and network configuration
• Secret retrieval, which includes reference mapping and access permissions

Traditional integrations depend on static credentials, long-lived access keys, private key files, and shared service accounts. These credentials create standing privileges until an administrator changes or revokes them.

BYOS supports Zero Trust principles through:

• Federated trust
• Runtime authentication
• Short-lived cloud credentials
• Centrally managed secrets
• Reduced credential distribution

This approach extends Zero Trust principles from human identities to system-to-system interactions.

Check your knowledge with the following interaction: