2026 Major Release - 26.2.1 Notes

October 2026

Keyfactor Command 26.2.1 introduces major enhancements, including new reporting system, orchestrator Keyfactor orchestrators perform a variety of functions, including managing certificate stores and SSH key stores. job pooling, trust bundles, certificate store mirroring, and automatic synchronization of publicly trusted root certificates (see Highlights).

Please refer to Keyfactor Command Upgrading for important information about the upgrade process. For a complete list of the items included in this release, see -*Release Note Details v26.2.1. For gateway and CA Connector Client release notes, see:

• CA Connector Client Release Notes
• Keyfactor Cloud Gateway Release Notes
• Keyfactor Windows Enrollment Gateway Release Notes
• Keyfactor AnyCAGateway DCOM Release Notes
• Keyfactor AnyCA Gateway REST Release Notes

Highlights

• Reports

  A new report definition engine has been introduced in Keyfactor Command version 26.2.1 that replaces the legacy reports provided by the Logi Analytics Platform.

  • The new reports can be accessed via the Management Portal under Reports (see Reports).
  • Reports are user-defined and built from pre-defined, configurable widgets, giving you flexible building blocks for creating custom report layouts.
  • From the Reports > Definitions page you can create, edit, and run reports (see Reports Definitions Operations).
  • Related API An API is a set of functions to allow creation of applications. Keyfactor offers the Keyfactor API, which allows third-party software to integrate with the advanced certificate enrollment and management features of Keyfactor Command. endpoints have been added to support managing reports (see Reports).

  • The legacy reports continue to be available. If installed, they appear on the Management Portal menu under Legacy Reports. The reports only display on the Management Portal menu if the Logi component is selected during Keyfactor Command installation. See Install: Select Components.

    The legacy reports are considered deprecated and will be removed in a future release.

• Orchestrator Job Pooling

  Orchestrators now support job pooling to provide for load balancing and high-availability. Job pools are created in Keyfactor Command and can include one or more orchestrators. Each pool is configured with a set of capabilities, which determines the types of jobs that can be routed to that pool.

  Orchestrators can be added to a pool regardless of the capabilities they individually declare. The jobs executed in a pool are limited to the intersection of the pool’s assigned capabilities and the combined capabilities declared by its orchestrators. Each orchestrator can belong to only one pool.

  On installation, the Keyfactor Universal Orchestrator The Keyfactor Universal Orchestrator, one of Keyfactor's suite of orchestrators, is used to interact with servers and devices for certificate management, run SSL discovery and management tasks, and manage synchronization of certificate authorities in remote forests. With the addition of custom extensions, it can provide certificate management capabilities on a variety of platforms and devices (for example Amazon Web Services (AWS) resources, Citrix\NetScaler devices, F5 devices, IIS stores, JKS keystores, PEM stores, and PKCS #12 stores) and execute tasks outside the standard list of certificate management functions. It runs on either Windows or Linux servers or Linux containers. can specify a pool to join using a parameter A parameter or argument is a value that is passed into a function in an application.. This provides support for auto-registration and auto-approval of the orchestrator.

  Related API endpoints have been added to support managing orchestrator pools.

  Full job-pooling functionality requires Universal Orchestrator version 26.2.1 or later.

  Note:  All orchestrators are associated with an orchestrator pool. Older orchestrators that do not support high availability use auto-generated, one-to-one pools. These pools are created automatically and cannot be managed directly. Universal Orchestrator versions that support high availability can be added to user-managed pools, which can contain multiple orchestrators.

  Due to the introduction of orchestrator pools in this release, Keyfactor Command must be upgraded before any Keyfactor Universal Orchestrators. Universal Orchestrator instances upgraded before Keyfactor Command will be unable to communicate with Keyfactor Command.

• Trust Bundles

  Trust bundles have been introduced to provide a more predictable and controllable foundation for certificate chain building. Administrators can now define trusted root certificates in a central configuration area, and Keyfactor Command will prioritize these trust bundles when constructing certificate chains. This gives organizations clearer trust boundaries, improves chain-building accuracy, and reduces reliance on external AIA The authority information access (AIA) is included in a certificate--if configured--and identifies a location from which the chain certificates for that certificate may be retrieved. locations or server-level certificate stores. Trust bundles are especially useful when decommissioning a CA A certificate authority (CA) is an entity that issues digital certificates. Within Keyfactor Command, a CA may be a Microsoft CA or a Keyfactor gateway to a cloud-based or remote CA. or redirecting a certificate chain to a new issuing CA.

  Related API endpoints have been added to support managing trust bundles, and new security permissions (read and modify) are now available to control access to this functionality.

• Certificate Store Mirroring

  Certificate Store Mirroring extends the value of trust bundles by allowing certificate stores to automatically mirror the contents of a designated trust bundle. When mirroring is turned on, Keyfactor Command uses a periodic task to compare the store’s inventory to the selected trust bundle and automatically add or remove certificates to keep the store aligned with the bundle.

  This allows organizations to centrally manage their roots of trust and push those changes consistently across their environment—making CA onboarding, migration, and decommissioning significantly easier.

  Related API updates and new query capabilities are included to support automation and searching.

• Automated Syncing of Publicly Trusted Root Certificates

  Keyfactor Command now supports automatic synchronization of publicly trusted root certificates from the host operating system. Both Windows and container installations can import new or updated roots published by OS vendors using a periodic task, ensuring that trust bundles stay aligned with the platform’s trusted root store. A scheduled job compares the host’s trusted roots with a designated trust bundle—using the Publicly Trusted Roots bundle by default—and adds or removes certificates as needed. The job is active by default, can be customized or deactivated, and automatically creates the target trust bundle if it does not already exist. This automation eliminates the need for administrators to manually track public trust store updates and helps maintain up-to-date, consistent trust across environments.

Changes and Improvements

• Application Settings

  • The Enrollment > CSR > Allow CSR SAN Entry application setting has been removed. This functionality has been moved to the enrollment Certificate enrollment refers to the process by which a user requests a digital certificate. The user must submit the request to a certificate authority (CA). patterns. See Enrollment Patterns.

  • The Console > General > Use Command Certificates in Chain Building application setting has been removed. Chain building now uses trust bundles, so this setting is no longer needed.

  • The Workflow > General > Workflow Step Run Timeout (seconds) application setting has been added. This sets the number of seconds a workflow A workflow is a series of steps necessary to complete a process. In Keyfactor Command, it refers to the workflow builder, which allows you to automate event-driven tasks such as when a certificate is requested, revoked or found in a certificate store. instance step will be allowed to run before timing out and setting the instance to a status of Failed.

• Auditing and Logging

  • Audit log enhancements have been implemented for operations made to a CA record.

  • The correlation ID generated in Keyfactor Command's logs is now passed to the Keyfactor CA Connector The Keyfactor CA Connector is installed in the customer environment to provide a connection between a CA and Keyfactor Command when a direct connection is not possible. It is supported on both Windows and Linux and has versions for Microsoft (Windows only) or EJBCA CAs.. All relevant logs for the CA Connector Client will now contain the same correlation ID as Keyfactor Command so that users may correlate/aggregate any of the logs output between Keyfactor Command, the CA Connector Client, and the CA Connector API. In addition, the logs will also contain the JobId that is generated for each job. The logs are in the format:

    <datetime> <correlation token> [JobId] <jobId> ........

• Certificate Details, Search, and Operations

  • New certificate query parsers have been added: SANCount, CertStoreType, CertStoreCount, NetBiosRequesterId, SignatureStrengthCategory, and SSLLocationCount. An upgrade script is added to populate the necessary data for existing certificates.

  • Certificate chain building has been updated to prioritize trust bundles (see Trust Bundles) as the authoritative source of root CAs. When a certificate chain is constructed, Keyfactor Command now attempts to build the chain using only the root certificates contained in configured trust bundles. If a chain cannot be built using trust bundles—for example, if no trust bundles are configured, the bundles contain no certificates, or a required root certificate is not found—chain building is done using these methods:

    1. AIA Retrieval: If the chain cannot be build using trust bundles, Keyfactor Command attempts to retrieve issuer certificates using the AIA (Authority Information Access The authority information access (AIA) is included in a certificate--if configured--and identifies a location from which the chain certificates for that certificate may be retrieved.) extension, if present. Only HTTP and HTTPS AIA URLs are supported, and the certificates must be accessible from the Keyfactor Command server.
    2. Trusted Certificate Stores (Windows only): If the AIA retrieval fails, Keyfactor Command attempts to complete the chain using certificates in the server’s local machine Trusted Root Certification Authorities and Intermediate Certification Authorities stores.

    For more information, see Trust Bundles

  • The Get CSV option has been enhanced to include additional columns of information, some optional, that were previously available only in select legacy reports as CSVs.

• Certificate Metadata

  • If a value is removed from a multi-value metadata Metadata provides information about a piece of data. It is used to summarize basic information about data, which can make working with the data easier. In Keyfactor Command, the certificate metadata feature allows you to create custom metadata fields that allow you to tag certificates with tracking information about certificates. field’s value set, certificates that previously used that value will now retain it, and they can continue to be edited and saved successfully as long as that specific metadata field is not changed. The value is no longer available for new assignments but remains on existing certificates. This differs from earlier behavior, where removing a value from the value set also removed it from certificates.

• Certificate Stores

  • The Certificate Chain Root option adds the ability to select one or more root certificate authorities (CAs) when installing a certificate in a certificate store from Certificate Operations, allowing multiple valid trust chains to be included.

  • When defining a certificate store location, the Chain Options setting specifies how the certificate chain is included when installing a certificate in the store.

    • Include Chain (default): Installs the end-entity certificate along with its full chain, including intermediate and root certificates.
    • No Chain: Installs only the end-entity certificate.
    • Include Chain, No Roots: Installs the end-entity certificate and intermediate certificates, but excludes root certificates.

• Certificate Templates

  • For templates coming from a DCOM configuration tenant A logical grouping of certificate authorities (CAs) within Keyfactor Command. The configuration tenant provides a common boundary for managing and organizing CAs in environments where the concept of an Active Directory forest may not apply. For Microsoft CAs, a configuration tenant typically corresponds to an Active Directory forest. For EJBCA, a configuration tenant typically corresponds to a single EJBCA server installation. Configuration tenants cannot be mixed; Microsoft and EJBCA CAs must be managed in separate configuration tenants., the fields for Custom Extensions, Alternative Key Types, and Available CAs are hidden in the Management Portal when using the View on CA option.

  • Templates can now be marked as ephemeral using the Ephemeral setting in the Management Portal or the IsEphemeral parameter for the GET /Templates/{id}, GET /Templates, and PUT /Templates operations. During a CA synchronization, certificates associated with an ephemeral template A certificate template defines the policies and rules that a CA uses when a request for a certificate is received. will be skipped.

  • The View on CA, Create on CA, Edit on CA, Copy on CA, and View Extensions options for templates now can be used when accessing EJBCA instances via a CA Connector.

  • An Extended Key Usages field has been added to the template information on the Details tab in the Key Types and Sizes section.

  • Templates now support querying by Id using the new Id query parser.

• Dashboard and Reports

  • SQL performance enhancements have been implemented for the new dashboard.
  • A new one-click option, Use Pre-Configured Dashboard, provides a starter set of dashboard widgets. When you select this option, you are prompted to choose a certificate collection The certificate search function allows you to query the Keyfactor Command database for certificates from any available source based on any criteria of the certificates and save the results as a collection that will be available in other places in the Management Portal (for example expiration alerts and certain reports).. The dashboard is then populated with two charts—Active Certificates by Template and Active Certificates by Signing Algorithm—and several count tiles: Active Certificates, Expiring in < 48 Hours, Expiring in < 14 Days, Expiring in Last 7 Days, Revoked in Last 7 Days, and Certificates with Weak Keys. Selecting this option replaces any existing widgets on the dashboard. The option is available for both new users and existing users who want to refresh their dashboard layout.
  • Dates in the drilldowns from the Certificates Issued per Week and Certificates Revoked per Week dashboard widgets, as inserted into the certificate search, now use ISO 8601 UTC format (YYYY-MM-DDTHH:mm:ss.000Z).
  • Dashboard widgets are now limited to 20 configured widgets.
  • A new Revocation Monitoring dashboard widget has been added.

• Enrollment

  • The behavior of the Owner Role Name field in PFX A PFX file (personal information exchange format), also known as a PKCS #12 archive, is a single, password-protected certificate archive that contains both the public and matching private key and, optionally, the certificate chain. It is a common format for Windows servers. Enrollment and ODKG has been updated and new hint messages are displayed, depending on the configured policy and defaults:

    • Required: The field is displayed and must have a value before submission, either from a default or user input.

    • Optional: The field is displayed but is not required. If left blank, any configured default (system-wide or from the enrollment pattern) is applied on submission.

    • Hidden: The field is not displayed. If a default owner is defined, that value is automatically applied on submission.

    A tooltip below the Owner Role Name label indicates whether the field is required and whether a default value is configured (at the system-wide or enrollment policy level). If a default is defined, it is included in the tooltip. For example:

    The owner role is required. Leaving the field blank will result in using your default value 'PKI Admins'.
    Note:  The user executing the enrollment does not need to hold the default role for it to be applied to the certificate.

• Enrollment Patterns

  • A new setting—Allow External CSR SAN Policy—has been added to the enrollment pattern. This functionality replaces the enrollment application setting Allow CSR SAN Entry. This field can be used to configure how CSR A CSR or certificate signing request is a block of encoded text that is submitted to a CA when enrolling for a certificate. When you generate a CSR within Keyfactor Command, the matching private key for it is stored in Keyfactor Command in encrypted format and will be married with the certificate once returned from the CA. subject alternative names (SANs) are handled. During enrollment, when submitting a CSR, this option can be configured to either replace the custom subject alternative names (SANs) supplied by CSR, merge with the custom subject alternative names (SANs) supplied by the CSR, or not allow custom subject alternative names (SANs) to be added to the CSR. When this field is off, the Subject Alternative Names section will not appear in the CSR Enrollment page.

    Note:  During upgrade, if the enrollment application setting Allow CSR SAN Entry was set to True, the new global enrollment pattern setting will be set to Replace. If Allow CSR SAN Entry was set to False, the new global enrollment pattern setting will be set to Off.
    Important:  This allows you to select, more directly and clearly, the option that is compatible with the CA you are using, since some CAs do not allow SAN The subject alternative name (SAN) is an extension to the X.509 specification that allows you to specify additional values when enrolling for a digital certificate. A variety of SAN formats are supported, with DNS name being the most common. replacement or merging.

• Installing and Upgrading

  • The command line database upgrade tool check flag has been updated such that if the database is empty (not populated with tables), the tool will continue as though the update flag was provided, since there are no values to check.

  • The ClaimsProxy application has been integrated into the WebConsole application and is no longer installed as a separate web application. Any previous ClaimsProxy configuration is no longer required.

  • Licenses are now upgraded by the database upgrade tool whenever it is run. Previously, it only replaced the license if it was expired. Now, it will always check the license and replace it in the database if the license is valid. Invalid licenses will not stop the upgrade process.

• Keyfactor API

  • Keyfactor API endpoints that previously returned a 500 error in the case where an invalid data exception error was encountered now return a 400 error.

• Security

  • Security roles can now be marked with the Enable Certificate Ownership flag to allow certificate owners to be assigned to the role. Roles with this flag turned off will no longer appear in certificate-owner dropdowns. The flag cannot be turned off for security roles that are already configured as certificate owner on one or more certificates.
  • Permissions for SMTP have been expanded to separate them from the general system settings permissions and to support Test as a separate option. The new permission set is: Read, Test, and Modify. On upgrade, the SMTP Short for simple mail transfer protocol, SMTP is a protocol for sending email messages between servers. permissions will automatically be populated for existing security roles based on configured System Settings permissions. Security roles with the System Settings > Modify permission will be granted the Smtp > Modify permission and roles with the System Settings > Read permission will be granted the Smtp > Read permission.

• SMTP

  • Users with only the Test permission for SMTP will now see a Test Email Notification menu option under System Settings in place of the SMTP Configuration menu option where they can send a test email using the configured SMTP settings. These users cannot see or modify the SMTP configuration.

  • Minor updates were made to the wording used in the SMTP test process and in the test email it generates.

• SSL Discovery & Monitoring

  • The pool configuration on the SSL TLS (Transport Layer Security) and its predecessor SSL (Secure Sockets Layer) are protocols for establishing authenticated and encrypted links between networked computers. Discovery page has been renamed to SSL Pools Definition to avoid confusion with the new orchestrator pool functionality (see Highlights).

  • A new Last Seen query parser has been added for the SSL results.

• Keyfactor Universal Orchestrator

  • On install, if the connection from the orchestrator to Keyfactor Command fails, a more verbose error message is now provided to assist in troubleshooting.
  • On install, the -force parameter to the install script now skips the test-connection functionality to Keyfactor Command.
  • The orchestrator in Kubernetes containers now supports replicas, allowing multiple instances to run concurrently. This can improve availability and distribute workload across orchestrators.
  Important:  Universal Orchestrator version 26.2.1 introduced support for orchestrator pooling. As a result, in-place upgrades from version 25.x or earlier to version 26.2.1 or later are not supported. A clean reinstall is required. For more information, see Upgrading or Migrating the Keyfactor Universal Orchestrator.

• Workflow and Alerts

  • The Require Approval workflow step now supports a customizable alert message for the waiting for approval state. When an enrollment (PFX, CSR, or renewal) requires approval, this message is displayed at the end of the enrollment process.

  • Require Approval workflow steps now appear with a status of waiting for approval rather than suspended when they have reached the point in the workflow when they are waiting for signal input (approvals).

  • The following PowerShell cmdlets have been made available for use with workflow steps of type Set Variable Data:

    • Write-Error
    • Write-Host
    • Write-Information

    • Write-Verbose

    • Write-Warning

    Output is written to the Keyfactor Command API log.

Fixes

• Workflow instances can now be searched using the InitiatingUserName query parser. This issue was introduced in Keyfactor Command 12.3.
• The Universal Orchestrator now uses resource locking during authentication token refresh. When multiple jobs are running and a token expires, the orchestrator requests a single replacement token instead of allowing each job to request a new token independently.
• When the Certificate Owner Role for an enrollment pattern is set to Optional with no default value configured (either system-wide or at the enrollment pattern level), and a user doing a PFX Enrollment does not populate the Certificate Owner Role field, a warning message is no longer generated. The user is able to complete the enrollment. The way in which the Certificate Owner Role field behaves has changed for this release (see Enrollment).
• SMTP configuration using Basic Authentication no longer produces an Invalid authentication mechanism error and now connects successfully. This issue was introduced in Keyfactor Command 25.4.
• The GET /Enrollment/CSR/Context/My and GET /Enrollment/PFX/Context/My Keyfactor API operations now correctly return metadata values configured on the referenced enrollment patterns and templates.

• Release 25.4 introduced a simplified naming convention for EJBCA certificate templates when the certificate profile and end entity profile names match, using <end entity profile name> instead of <end entity profile name>_<certificate profile name>.

  A defect in earlier releases prevented the new naming scheme from being applied correctly for certificates enrolled directly in EJBCA (outside of Keyfactor Command). In these cases, certificates could be associated with an incorrectly constructed template name (for example, CorpTemplateName100_CorpTemplateName100). Because templates are also created during the periodic template import, this could result in duplicate templates (for example, both CorpTemplateName100_CorpTemplateName100 and CorpTemplateName100).

  This issue is resolved in this release.

  On upgrade, incorrect duplicate templates, such as CorpTemplateName100_CorpTemplateName100, are removed where possible. If the shortened template and longer duplicate template no longer match, such as when one template’s settings have been edited, the duplicate template is not removed automatically. The duplicate template is also not removed if it is associated with alerts, workflows, or legacy reports. In these cases, a log message is written indicating that manual cleanup is required.

  Existing certificates associated with the incorrect template name are automatically reassigned to the correct template (with the shortened name) during the next full CA synchronization.

  To avoid reintroducing the issue, upgrade any CA Connector Clients to version 26.2 or later.

Deprecation & Removals

• Support for Microsoft SQL Server 2019 and Windows Server 2019 will be removed in a future release. Upgrade to a supported version before this change takes effect. For upgrade guidance, see:

  • https://learn.microsoft.com/en-us/sql/database-engine/install-windows/upgrade-sql-server
  • https://learn.microsoft.com/en-us/windows-server/get-started/install-upgrade-migrate

Known Issues

• When configuring permissions for a security role using the Select a Profile dropdown, selecting Read Only also grants access to read private keys for certificate stores and certificate collections. These permissions must be cleared manually if not required.

• The V1 Reports endpoints (for the legacy (Logi-based) reporting engine) are deprecated and will be removed in November 2027. They remain functional for backwards compatibility only.

• During Keyfactor Command configuration, in some cases. the service account connection string is used instead of the configuration wizard admin connection string. This can result in a user running the configuration wizard who does not have access to the database, resulting in errors when trying to save the configuration.

• The Add option on the Orchestrator Pool Management tab of the Orchestrator Management page does not add unassigned orchestrators to the selected pool.

  As a workaround, on the Orchestrator Management tab, select orchestrators with a status of New, approve them, and add them to a pool. When you remove an orchestrator from a pool, its status resets to New.

  This issue will be corrected in a future release.

• A change to orchestrator registration in this release introduced an issue that can prevent Universal Orchestrators earlier than 26.2 from running jobs after the upgrade. To avoid this issue, at least 24 hours before upgrading Keyfactor Command, update the Agents > General > Session Length (minutes) application setting to 10.The shorter session length makes orchestrators re-register frequently, which mitigates this issue. Orchestrators don't use the new session length until their current session expires, which can take up to 23 hours with the default setting. This issue will be resolved in a future release.

• On-device key generation (ODKG) jobs do not honor the Agents > General > Number of times a job will retry before reporting failure application setting and will continue to retry beyond this limit. This will be corrected in a future release.

API Endpoint Change Log

Please review the information in the API Change Log for this release carefully if you have implemented any integration using these endpoints: API Change Log v26.2.1.