What’s New in CyberArk Trust Protection Foundation

CyberArk Certificate Manager - Self-Hosted version 26.1 introduces some significant enhancements across all product lines. In the list below, features related to ideas posted and voted on in the Product Ideas Community are marked with a double caret: ^^ followed by the idea number.

IMPORTANT! Before upgrading to version 26.1, carefully review Important Considerations Before Upgrading.

CyberArk Trust Protection Foundation 26.1

  • JWT authentication: Custom OIDC discovery endpoint for JWKS - You can now configure a custom OIDC discovery endpoint in JWT mapping properties. Trust Protection Foundation uses this endpoint to retrieve the OpenID configuration and its jwks_uri, allowing JWT authentication to succeed even when:

    • Standard OIDC discovery is not available, or

    • The JWT issuer URI and the JWKS host differ (for example, Kubernetes or microservices environments where tokens use an internal issuer and keys are published externally, such as on S3).

    This optional field lets you point Trust Protection Foundation directly at the correct discovery URL while still enforcing issuer validation and requiring secure HTTPS for key retrieval. See About JWT mappings.

  • SCIM 2.0 support for modern identity providers - Trust Protection Foundation now supports SCIM 2.0 (System for Cross-domain Identity Management), enabling native integration with modern identity providers (IdPs). The IdP pushes user and group changes directly to Trust Protection Foundation, reducing dependency on traditional Active Directory or LDAP infrastructure.

    Benefits include improved performance (no on-demand queries to third-party systems), better resilience (Trust Protection Foundation stays available even when connectivity to AD is lost), and richer offboarding workflows where audit and approver context remains accurate after employees leave. Existing customers can migrate from LDAP/AD without losing identity policies, attributes, permissions, or local group membership. Learn more.

  • OIDC and SAML single sign-on for the web console - The web console login screen now signs users in through your identity provider. A user enters their username and Trust Protection Foundation looks up the identity connector that owns that account; if the connector is configured to delegate authentication, the user is redirected to your IdP to authenticate over OpenID Connect (OIDC) or SAML. The login screen also shows a button for each configured SSO connector, so users can choose their provider directly. End users no longer need to know which directory they belong to, and users provisioned via SCIM, who may have no local password, can sign in to the console. Learn more.

  • OIDC authentication for MMC snap-ins - The MMC snap-ins now support authentication using OpenID Connect (OIDC), allowing administrators to sign in through their IdP rather than entering local credentials. OIDC authentication is required for users provisioned via SCIM (who may not have a local password) and is also available for any environment that prefers OIDC-based SSO. Learn more.

  • Expanded post-quantum signing algorithm support - Trust Protection Foundation 26.1 documentation updated to list two additional quantum-resistant composite signing algorithms: Composite ML-DSA87 / PSS3072 and Composite ML-DSA87 / ECP521. These pair the ML-DSA87 lattice-based signature scheme with classical RSA-PSS 3072 and ECDSA P-521 respectively, giving you more options when designing a hybrid post-quantum/classical signing strategy for high-assurance certificates. Note: These algorithms were released previously; in 26.1 we’ve updated the documentation to include them. Learn more.

CyberArk Certificate Manager - Self-Hosted

  • License reporting: move to Secured Certificate Instances (SCI) - In 26.1, we simplified license reporting. Instead of separate Trust Authority / Trust Force licenses and different counts for each certificate type, we now use one model: Secured Certificate Instances (SCIs). This makes it easier to understand how many licenses you are using across the whole platform.

    An SCI is one certificate used in one enabled application instance, no matter whether it is a server, client, or device certificate. Certificates now draw from a single SCI pool whenever they are managed or observed by the platform (for example, when they are assigned to an application, issued or renewed, or monitored through inventory). The certificate inventory and licensing report show how many SCIs each certificate consumes, so you see a clear, unified view of license usage.

    SCIs are calculated as: number of active certificates × number of enabled application instances where each certificate is used and validated. Application instances that are disabled do not consume SCIs. See Licensing report.

  • Network Discovery reconciles certificate configuration on rediscovery - Network Discovery jobs can now update an existing certificate object’s configuration when the certificate is changed outside of Trust Protection Foundation — for example, when a Subject Alternative Name (SAN) is added by another tool. When enabled, rediscovery applies the new configuration so that the next renewal preserves the latest values instead of reverting to stale settings.

    Each Discovery job exposes a configuration toggle for this behavior. With the toggle on, the job logs each certificate object it updates; with the toggle off, the job logs the detected change without applying it. A new inventory filter lets you find certificate objects that were reconciled by Discovery. Learn more.

CyberArk Code Sign Manager - Self-Hosted

  • OIDC Device Authentication for Code Sign Client - Code Sign Client now supports authentication using the OIDC device authorization flow (--device option). This enables secure login for users provisioned via SCIM.

    With this update, users authenticate through their browser, eliminating the need to enter credentials in the command line. This method is required for SCIM-provisioned users, while existing username/password authentication remains unchanged for non-SCIM environments. Learn more.

  • Updated Code Sign Client Versioning and Distribution - To improve your organization’s security posture, the Client Distribution page and the client’s --update flag now retrieve the latest client version from a public distribution endpoint, by default. This ensures your organization always has access to the most current client, including the latest security fixes and patches.

    The Code Sign Client now supports both Code Sign Manager - Self-Hosted and Code Sign Manager - SaaS, and is no longer bundled with Certificate Manager installation files.

    If your organization does not want to use the public distribution endpoint, you can disable it after a complete upgrade or install. Note that disabling this option means your organization will not automatically receive the latest client updates, security fixes, or patches. For details on managing client distribution, see Managing Code Sign Client distribution.

    In addition, the Code Sign Client now uses a date-based versioning format (yy.mm.dd.build). Learn more

  • Fully-automated issuance flow for Sectigo CA - Creating an Environment with a Sectigo CA template is now more streamlined. Code Sign Manager - Self-Hosted now automatically handles the key attestation process, eliminating the need to retrieve attestation files from Sectigo and upload them to Code Sign Manager Environments. Learn more.

CyberArk SSH Manager for Machines - Self-Hosted

  • Authorization tracking on the Authorizations > Rules page - SSH authorization events are now tracked on the Authorizations > Rules page. For each connection, the table shows key data points about the authorization attempt.

    From the Rules page, you can revoke an SSH key, and create a Deny rule that blocks future authorizations for a specific connection (for example, a specific account, host, and key combination). See Managing and monitoring SSH Key Authorization Rules.

  • New pages for authorization-based Keys and Hosts - New Authorization-based Keys and Authorization-based Hosts pages show which SSH keys and hosts have been observed through real-time authorization activity. These pages help you see, at a glance, which devices and keys are actively being used. See Managing and monitoring SSH Key Authorization Rules.

  • Usability improvements for day‑to‑day operations - Several usability enhancements make SSH Manager for Machines easier and faster to use, including:

    • Click‑to‑copy for key details,
    • Quick search by fingerprint, and
    • Other small UI refinements that make navigation and filtering more fluid.

    See Managing and monitoring SSH Key Authorization Rules.

Driver Integrations

  • Remote and Central ECDSA Key Generation for AWS Certificates - Trust Protection Foundation now supports generating both central and remote certificates for Amazon Web Services (AWS) applications using ECDSA key algorithms. AWS service-specific restrictions for key algorithms and certificate storage locations (ACM or IAM) are validated during provisioning. Learn more.

  • Dual Account support for CyberArk-managed credentials - You can now enable Dual Account when using the CyberArk Username Password or CyberArk Password credential types. This enhancement ensures the active account managed by CyberArk Privilege Access Manager is used during password rotation, helping maintain uninterrupted authentication. Learn more.

  • Azure Key Vault Driver Alignment with Microsoft Access Control Changes – The Azure Key Vault driver has been updated to support Microsoft’s new access control defaults (enforced February 2027) and Azure SDK requirements. To prevent service disruptions with Azure RBAC Key Vaults, customers on Trust Protection Foundation 24.3 or earlier must upgrade to a supported version. After upgrading, you must complete two migration steps. First, re-run Onboard Discovery so the driver can correctly identify the access control model (RBAC vs. Access Policy) for each vault and maintain visibility. Second, for manually created Azure App Registrations, provision a specific Tenant ID per application to ensure correct SDK authentication. Learn more.

  • Zero Touch PKI (ZTPKI) CA Integration - Trust Protection Foundation now supports enrolling and provisioning User, Device, and Server certificates using the new Zero Touch PKI (ZTPKI) CA driver. To ensure policy compliance, the ZTPKI CA automatically enforces template constraints and may override requested certificate values during issuance. Learn more.

  • Expanded DigiCert Certificate Capabilities - Trust Protection Foundation introduces a suite of powerful enhancements for the DigiCert CA driver. You can now issue and manage S/MIME (Secure Email) and X9 PKI for TLS certificates directly from the platform. Additionally, you can now map custom fields to pass important metadata to DigiCert during enrollment, and easily issue duplicate certificates without requiring full revalidation. Learn more.