Release 26.R3: April 2026

Behavior Changes for this Release

Here are some of the changes in behavior introduced in this release that you might want to be aware of.

Improved API Access Page

The API Access page has been updated. Instead of using a single authentication method, you can now select multiple methods using new checkboxes. The API key has been moved to the Authentication tab, and a new Client Apps tab has been introduced to better organize related settings. (refs PB-120542)

OAuth 2.0 Authentication now set by default

OAuth 2.0 authentication is now automatically enabled for any accounts that were previously configured to use OAuth authentication. If your account was not configured to use OAuth authentication, contact our Support Team to enable it. (refs PB-120612)

Bounced Email Callback Changes

The following changes have been made to the email bounce callback: (refs PB-117208)

• • New Bounce Types: The following changes to email bounce types have been introduced:

    SES Bounce Type	Current Behavior	New Behavior
    Any hard bounce	BOUNCE	BOUNCE
    Complaint	COMPLAINT	COMPLAINT
    Soft bounce - AttachmentRejected	OOTO	ATTACHMENTREJECTED
    Soft bounce - ContentRejected	OOTO	CONTENTREJECTED
    Soft Bounce - General	OOTO	OOTO
    Soft bounce - MailboxFull	OOTO	MAILBOXFULL
    Soft bounce - MessageTooLarge	OOTO	MESSAGETOOLARGE

• Changed class name for bounce callbacks: The class name in the callback has changed from "com.silanis.esl.packages.event.ESLProcessEvent" to "com.silanis.esl.notification.BounceNotificationEvent".

• New callback parameter: A new parameter (diagnosticCode) has been introduced in the callback with the details of the bounce message.

UI and Other Changes

The following changes in UI behavior or appearance have been made:

• Updated supported date formats. We have updated the date formats that can be used by integrators. More specifically, capitalized years are no longer supported (for example, YYYY). Existing integrations will be automatically converted to the new format and will continue to work as expected. (refs PB-119667)

  • The new supported formats are:

    • yyyy-MM-dd"

      “yyyy-dd-MM”

      “MM-dd-yyyy”

      “dd-MM-yyyy”

• Updated header menu icons. Several icons in the sender interface header have been refreshed for clarity and consistency. (refs PB-120976)

• Hidden “esigned by” text for initial selections. The “esigned by” label is no longer displayed on Choose Initials signatures. This was done to enhance clarity and readability. (refs PB-121239)

• Warnings and errors no long auto‑close. Users must now click the “X” to dismiss alerts, which improves accessibility compliance. (refs PB-121406)

• Updated OFAC terminology. To eliminate confusion, multiple labels and event names were rewritten to say “Customer blocked country list”. (refs PB-122329)

• Fast Track link changes: Fast Track links can now only be generated from templates. You can no longer generate these links for transactions. (refs PB-122512)

• Default In-App Documentation. The in-app documentation widget introduced in Release 25.R4 is now enabled by default for all non-white labelled accounts (accounts that have not overridden the default Sender UI logo).

Planned for a Future Release

Here are some of the new features, changes and enhancements that will be coming in one of our upcoming releases.

Sender as signer verification: To enhance the security of transactions, a sender from a different account that needs to sign is now required to authenticate if an authentication method for that sender is specified during transaction creation. Previously, a sender from a different account could proceed directly to the signing ceremony without additional authentication after logging into the sender portal. Note that senders from the same account can still proceed directly to the signing ceremony. (refs PB-120921)  

What's New

Here are some of the new features and enhancements we have made for this release.

Expiring Signer Links

To strengthen access controls and support regulatory compliance requirements, we are introducing configurable expiration times for links to transaction that are sent to signers.

This enhancement mitigates the risk posed by long-lived URL links to transactions by limiting signer access to these links to a defined timeframe. Enforcing link expiration helps organizations align with industry regulations, internal security policies, and audit standards that require limiting access to sensitive documents to certain timeframes.

To avoid disrupting your existing workflows, the default value for expiring links will be unlimited. However, we strongly recommend defining a shorter-term value to enhance security and reduce the potential risk involved in allowing extended access to these links.

This feature will be introduced in the following releases:

• Sandbox (26.R3): Available for testing. Please contact our Support Team to enable this feature for your account.

• Production (26.R4): Available across all production environments as a self-service configuration.

Sender Authentication Tokens

A new, optional Sender Authentication Token feature is now available. Previously, when you requested a sender authentication token, you needed to specify a transaction ID. The sender authentication token that was then generated could have been used to access that specific transaction or any other transaction available to the sender.

This release introduces a new account setting which will allow you to restrict the access rights of the sender authentication token to just the transaction used to generate it.

To enable this feature, you will need to contact our Support Team. (refs PB-116234)

Notification Improvements

The following improvements have been made to our Notification features:

• SMS-only notification for transactions. In addition to email, email + SMS, senders can now choose SMS as the sole delivery method when creating a transaction. Note that a recipient email address is still required for the transaction. (refs PB-121265)
  

• Added control over notifications for unauthenticated signers. Added an account-level setting to suppress notifications for signers without authentication, improving message control. (refs PB-123469)

Electronic Consent Document Language Enhancement

The electronic consent document is now automatically updated when a transaction’s language is changed from the sender interface, provided the consent document is available in that language. Previously, the consent document would not automatically update when the transaction language changed. In addition, a new consent API is available for API-integrated customers. This API allows client applications to change the language of an existing transaction’s electronic consent document. (refs PB-120922)

Improved API authentication flexibility

You can now choose multiple authentication methods for API calls. The API Access page has been updated with checkboxes for method selection, a relocated API key under the Authentication tab, and a separate Client Apps tab. (refs PB-120542)

Template Import and Export

We have introduced new template import and export capabilities within the Sender UI. This significantly enhances the user experience by allowing users to easily transfer templates between different accounts, ensuring that they can access and use their preferred designs across multiple accounts. (refs DAG-301)

Additional New Features

• Configurable conditional signature logic across signers. You can now create conditions across signature fields belonging to different signers. To enable this feature, contact our Support Team. (refs PB-119959)

• New mobile signing options for signature and initials selection. We have enhanced our Choose Signature and Choose Initials signature types with the following: (refs PB-121912)

  • Mobile users can now sign using the Choose Signature and Choose Initials options,

  • You can now set a preferred signing method (style, draw, upload, mobile),

  • The new signature styles are now supported with Java and .NET SDKs.

• Accessibility Improvements. The Required and Optional signature previews now use 80% opacity to match the signing ceremony, and the color contrast checker now accounts for this when validating accessibility compliance. (refs PB-123922)

• Improvements to Fast Track usability. The Fast Track page now follows the template language by default, and the order of first name/last name fields respects the account’s configured name order. (refs DAG-154)

Bug Fixes

The following issues were resolved in this release.

• Fixed navigation issues on large documents. The Next button now correctly navigates to the next signature after zooming on documents over 100 pages. (refs PB-123566)

• Improved country selector display. A separator line that appeared as a block in certain OS/browser combinations has been removed. (refs PB-123881)

• Maintains page focus when reordering documents. Sometimes the current page focus would be lost after reordering documents in the Designer. This no longer happens. (refs PB‑124000)

• Corrected locale formatting errors in email notifications. Extra spaces in the language parameter are now automatically trimmed. (refs PB-124047)

• Ensures fields are not duplicated when pasting. Duplicate fields are no longer created when pasting fields in the Designer. (refs PB‑124252)

• Prevents errors when adding recipients. Fixed an issue in which an error message would sometimes appear when adding a recipient to a transaction. (refs PB‑124602)

• Increased tooltip font size on mobile devices. For better visibility and ease of use we have increased the tooltip font size on mobile devices. (refs PB-124992)

• Updated infrastructure in response to upcoming Salesforce policy changes. We have updated our backend infrastructure and Salesforce Connector to accommodate Salesforce’s upcoming enforcement of PKCE and Refresh Token Rotation polices changes. (refs PB-124844)

Known Issues

This section lists issues that have not yet been resolved for the current OneSpan Sign release.

• Duplicate sender-as-signer cannot sign a second time. A sender who is a recipient in a counter signing transaction will not see the Sign button when it is their turn to counter sign if that sender does not have manager permissions in the account where the transaction is created. Additionally, when viewing the Transaction Edit page of that transaction, they will see the recipient information as masked within the Recipients section. This issue will be fixed in an upcoming 26.R3 Sandbox deployment. (refs PB-125516)