Behavior Changes for this Release
API KEY GENERATION
As mentioned in our 25.R2 and 25.R3 Release Notes, and in Managing API Access and Authentication Settings, to increase the security of our API keys, we implemented a new generation algorithm that will generate longer keys. The new longer API key format is 76 characters in length.
This change means that all existing API keys have been converted to follow the new format. Additionally, any new keys that are created with the creation of a new user will also follow this new format.
Note that any integrations that were implemented using the older keys no longer work as of December 1st, 2026.
What do I need to do?
To accommodate this change OneSpan recommends that you do the following:
Validate that your systems and applications can accommodate the new longer API key format. This may involve changes to your codebase and configuration settings.
Migrate to the new longer API key format as soon as possible. While these keys will be generated for you, any integrations that you have made using the shorter key format will have to be manually updated. THESE INTEGRATIONS WILL NO LONGER WORK AS OF DECEMBER 1, 2026.
To ensure a smooth adoption of the API keys, please migrate your Sandbox and Production environments to the new keys as soon as possible.
Should you need any assistance during this transition phase, please contact our Support Team.
Other Changes
Signer verification for senders signing from another account. A sender from a different account who needs to sign is now required to authenticate if an authentication method is specified for them during transaction creation. Previously, these senders could proceed directly to the signing ceremony without authentication. Senders signing within their own account are unaffected. (refs PB-120921)
"Requires my signature" filter renamed. The "Requires my signature" filter on the Dashboard and Inbox is now called "Requires my action," and returns transactions requiring the logged-in user's signature as well as any pending recipient specification. (refs PB-125852)
Designer layout fields updated for easier size adjustments. The layout fields on the Designer page have been updated: X/Y are now labeled X Position/Y Position and include built-in arrows to adjust values, Width/Height controls also include built-in arrows, and Checkbox/Radio fields are combined into a single Checkbox Size/Radio Size field with built-in arrows. If your integration passes different values for width and height, the UI will continue to display both fields as before.
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.
OTP via SMS Updates: We are updating the terminology for SMS authentication. Existing customized strings will not be impacted.
In the sender UI, "SMS" will be replaced by "One Time Passcode".
In the signer UI, the message will be updated to "A one-time passcode has been sent via SMS to [XXXXX1234]. Enter it below to access your transaction"
The request link will change to "Resend code via SMS".
For In-Person Signing the word SMS will be replaced by OTP.
What's New
Here are some of the new features and enhancements we have made for this release.
Full PDF Flattening Support
New PDF rendering operations for Microsoft Edge browser. To enable documents to be rendered correctly in Edge, the visual appearance of annotations (text fields, signatures, checkboxes, radio buttons, etc.) can now be directly embedded into the page before the annotations are deleted. (refs PB-128204, PB-128679)
Previously, annotations remained on the page after flattening, but became non-interactive when viewed in Edge.
To enable this feature, contact our Support Team.
Designer
More recipient colors in Designer. The Designer page now supports up to 100 recipient colors, increased from the previous limit of 20. (refs PB-127628)
Read-only documents in Designer. Documents can now be set to read-only, preventing existing signatures and fields from being modified and new signatures or fields from being added on the Designer page. This property can currently only be set through the API or SDKs. (refs PB-127630)
Recipient Management
Enhanced Specify Recipient functionality. The Specify Recipient feature now supports duplicate signers, allows recipient specification directly from the sender interface, and takes the specifier straight into the signing ceremony when they have documents to sign. (refs PB-124291)
Dispute recipient specification. Specifiers can now dispute a recipient specification request. Disputed transactions are set to Declined and moved to the sender's Drafts folder, with an email notification and optional callback available to the sender. (refs PB-126836)
CC non-signing recipients on a transaction. Organizations can now include non-signing stakeholders on a transaction as CC recipients, who automatically receive the completed signed documents once the transaction is finished, with the same authentication controls available to signers. CC recipients don't participate in signing and only receive documents after completion. (refs PB-127625)
Preview documents before specifying recipients. Specifiers can now preview placeholder signatures and fields across all documents, or for a specific placeholder, before replacing them with actual signers. Previews respect the specifier's existing document visibility settings. (refs PB-127638)
Document Validation
Expanded NIGO document types and data extraction. NIGO Document Validation now supports eight additional document types — including T4 slips, state ID cards, void cheques, and vehicle registrations — with expanded data extraction and new expiry, recency, and authenticity checks for each. Signers now see the specific document type named in classification error messages, and the new types are available through both the web UI and the SDKs. This capability remains in Early Access and is available in the Sandbox environment only. (refs PB-128417, PB-128440, PB-128442, PB-128531)
Beta Analytics Insights Program Concluded
The Analytics Insights beta has been concluded. After evaluating the results, we have made the decision to not move forward with this version and the feature will be discontinued after 26.R5.
Many thanks to our customers who have participated in the beta. We will be contacting you shortly with more details.
Additional New Features
Import DocuSign templates with Template Ingestion. Customers can now import DocuSign templates directly from the Sender UI Templates section and automatically convert them into equivalent OneSpan Sign templates, easing migration by reducing manual template recreation effort. Unsupported DocuSign-specific features are skipped silently during conversion rather than causing an error. (refs PB-124256)
Czech language support. OneSpan Sign now supports Czech for both senders and signers. This language is not currently supported for IDV, Integrations/Connectors, or TSP. (refs PB-127435)
More flexible text anchor placement. Two new optional parameters give customers finer control over text anchor behavior: ignoreMissingAnchor allows a transaction to proceed instead of failing when an optional anchor's text isn't found, and findAll automatically places a field everywhere the anchor text appears, removing the need for index-based logic. Both default to off. (refs DAG-338)
Document Domain must be enabled to use this functionality. To enable Document Domain, contact our Support Team.
Prompt before leaving with tasks outstanding. If a signer closes the tab or window before completing all their required tasks, a confirmation dialog now appears asking whether they want to leave. This is aimed at reducing accidental drop-off part-way through a transaction, particularly where uploads are required after signing. Work already completed is saved either way — a signer who has signed but not yet uploaded a required document keeps their signature and can return through their original link to finish. The prompt only appears while tasks remain outstanding. (refs PB-126205)
Bug Fixes
The following issues were resolved in this release.
Sender name fields now accept URLs as plain text. URLs entered in the sender's first or last name field now display as plain, non-clickable text in emails instead of being blocked. (refs PB-126671)
Resolved accessibility issues in the signing experience. Several accessibility issues affecting the signing experience have been fixed. (refs PB-127544)
Signing links now generate correctly for hashtag email addresses. Signers with a hashtag in their email address can now receive a valid signing link; previously, the link failed to generate. (refs PB-127118)
Corrected row alignment for mixed-size document previews. Documents with mixed page sizes (for example, Legal and Letter) no longer break row alignment in the Designer's Documents panel preview thumbnails. (refs PB-128134)
Easier document renaming. The rename field for a document is no longer too small to comfortably edit, matching the size of the document name field. (refs PB-128904)
Improved SQL query performance for large result sets. We have resolved an issue where SQL query results were not being capped correctly, which could affect performance on accounts with a large volume of data. Result set limits are now applied as expected. (refs PB-129189)
Corrected date-based transaction search results. Searching transactions by date now returns results correctly, even when the "from" date entered doesn't exist in the data set. (refs PB-129334)
Fixed an issue where entries from Choose Signature type fields could not be extracted unless the signer was added prior to uploading the document. Now, entries can be extracted from the corresponding text tags even if the signer is added after the document is uploaded. (refs PB-129592)
Fixed accessibility issues in the signing ceremony. (refs PB-129854, PB-129969)
Fixed duplicated signature fonts for names with apostrophes. Signature fonts are no longer duplicated when a user's name contains an apostrophe. (refs PB-129861)
Vulnerabilities
This release also includes important security and vulnerability fixes.
Known Issues
Here are some of the known issues that we are currently working on, and plan to have fixed in a future release.
When re-accessing a signing ceremony and navigating to the Upload Attachment page from the Welcome Back page, the page may flicker upon loading if the cookie consent banner is open or if browser zoom is set to 110% or higher. Dismissing the cookie consent banner resolves this issue. (refs PB-130750)