Behavior Changes for this Release
Here are some of the changes in behavior that you might want to be aware of.
Senders from other accounts must now authenticate before signing. If a sender from a different account is a signer in a transaction, and an authentication method was set for them when the transaction was created, they must now complete that authentication before signing, including when they open the transaction from their Sender Inbox. Until now, they went straight to the signing ceremony after logging in to the sender portal. Senders from the same account can still go straight to the signing ceremony. (refs PB-120921)
Signature types are now validated when they're added or updated. The Choose Signature and Choose Initials types can't be combined with any other signature type for the same recipient. Previously, this was checked only when a transaction was sent, so a mismatch in a template didn't appear until a sender tried to use it. It's now checked as soon as a signature is added or updated, in both templates and transactions, across all documents. (refs PB-125156)
In the web UI: When you add a signature or initials field, its signature type automatically matches the type the recipient already uses, and a message confirms the match. If you change a field to a type that can't be combined with the recipient's other signatures, this error appears: "Choose Signature and Choose Initials signature types cannot be combined with any other signature type."
In the API: Creating or updating documents and approvals (POST/PUT) returns the same error when the request would mix signature types for one recipient. Integrations that add signatures one at a time and change their type afterwards may need to be updated. Creating a transaction in a single API call isn't affected. Those transactions are still validated when they're sent.
Initials fields are now more compact in the Designer. New Initials fields are now 80 x 59 by default (previously 264 x 59, the same as a signature field), so you no longer need to resize each one by hand. They can still be resized freely. The field label now shows the recipient's initials instead of their full name (for example, Martine Hellman-Peters appears as "M H-P" with "Init" on a second line), and the pencil icon has been removed. Existing Initials fields in saved transactions and templates aren't resized. Signature fields are unchanged, and nothing changes for signers or in the signed document. (refs PB-129595)
Fast Track URLs require Fast Track to be enabled. You can no longer generate a Fast Track URL, or access an existing one, when Fast Track isn't enabled on your account. (refs PB-131106)
What's New
Here are some of the new features and enhancements we have made for this release.
Designer
Set a default value for Date Picker fields. Senders can now define a default date for a Date Picker field. Signers see this date pre-filled and can change it if needed. (refs PB-126496)
Expand the clickable area of checkbox and radio button fields. You can now define a larger clickable area around checkbox and radio button fields. Signers can then select or clear the field by clicking anywhere in that area, not only on the box itself. This helps most when a checkbox or radio button sits next to a label or statement, because signers can click the text instead of aiming for a small target. You can set up clickable areas in the Designer, through the API, or with the SDKs. The expanded area doesn't change keyboard navigation or screen reader behavior, and assistive technologies still see only the field itself. To enable this feature, contact our Support Team. (refs PB-127919)
Clickable areas can't be set through text tag extraction or document extraction.
Set validation rules and numeric options for text fields in the Designer. Senders can now require signers to enter text fields in a specific format directly in the Designer, without using the API. Previously, the Designer could only make a text field required or limit its length. Text fields now have a new Validation rule section in their properties panel, between Settings and Layout. (refs PB-129589, PB-129591, PB-130996)
Formats: Choose from None, Phone (North America), Email, SSN (US), Zip Code (US), Postal Code (CA), SIN (CA), Numeric, Alphabetic, or Custom regex. When you type a custom pattern, the Designer checks it as you type and won't save a pattern that isn't valid.
Ready-made error messages: Each format includes a clear error message that tells signers what's expected. You can replace it with your own wording in the Error message box. While the box is empty, the panel previews the message signers will see.
Exact text: Enter the value signers must type, such as a reference code or an acknowledgement phrase, in Required text. Signers can't see this value unless you include it in the field tooltip or the error message. The Designer shows a reminder about this.
Numeric options: When you choose Numeric, you can set Allow decimals, Decimal places (Any, 1, 2, 3, or 4), and Allow negatives. For example, to accept 125.50 but not 125.505 or -125, set Decimal places to 2 and turn off Allow negatives.
Accessibility: During signing, the field's tooltip and error message are linked to the input, so screen readers announce both.
Compatibility: Fields that already have a rule set through the API show that rule correctly in the Designer, and saving doesn't overwrite it. Signers are checked when they try to move past the field, and format rules work together with Required and Max Length.
Limitations: Validation rules apply to text fields only. Numbers can't include thousands separators (for example, 1,000) or currency symbols. Minimum and maximum values aren't supported. A field set up with Exact text reopens in the Designer as Custom regex, but the rule is kept and enforced exactly as before.
Recipient Management and Authentication
Assign authentication methods to placeholder recipients. You can now assign an authentication method to a placeholder. The method applies wherever the placeholder is used, so every transaction built from it gets the same identity checks without extra setup. Senders can still override the method for a specific recipient when needed. Placeholder authentication can be configured from the web UI, the API, and the SDKs. NOTE: To use SDKs you must upgrade to the latest available version. To enable this feature, contact our Support Team. (refs PB-126835)
Bulk Send: A new transaction-level setting, Enforce bulk send authentication, controls how placeholder authentication applies during Bulk Send. To enable it, contact our Support Team.
Not enforced (default): The authentication details in the Bulk Send CSV take priority over the method defined on the placeholder.
Enforced: The authentication method in the CSV must match the method defined on the placeholder. If it doesn't match, an error appears when you upload the CSV, and you must correct the file before you can continue. Authentication details in the CSV, such as phone numbers or question-and-answer values, are still used.
Limitations: Identity Verification isn't supported as a placeholder authentication method. Fast Track ignores placeholder authentication. When a template is used through Fast Track, authentication for placeholder recipients is reset to None.
CC recipients are now generally available. The CC recipient type introduced in release 26.R5 is now generally available. 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)
Show or hide masked Q&A authentication answers. Masked answer fields on the Q&A authentication page now include an eye icon, the same one already available for SMS authentication. Answers are hidden by default, and signers can click the icon to check what they typed. Fields that aren't masked don't show the icon. (refs PB-129128)
Specify Recipients enhancements. We have made the following improvements to the Specify Recipient feature. (refs PB-129967)
"This is me" option: We've made it easier for recipient specifiers to replace a placeholder with themselves by clicking This is me in the placeholder's action menu. Their name, email, and other details are filled in automatically, and the placeholder's authentication method is replaced with the specifier's own. A confirmation message appears before the replacement is applied and warns if an existing authentication method will be replaced. Once confirmed, the placeholder's original details and authentication method can't be restored.
Countersigning support: Specifiers can now assign themselves, or a recipient who is already in the transaction, to a placeholder. When both recipients have the same signing order and their required actions can be completed together, they're merged into one recipient. Otherwise, the new recipient is added as a countersigner. Counter signing must be enabled on the account and the specifier - or the recipient they are adding - must be an account sender. If the recipients can't be merged or added as countersigners, an error message appears.
Recipients Specified callback: A new Recipients specified event notifies integrators when the specifier has finished filling in placeholders and the transaction has been updated. For example, integrators can use it to generate and send signing links right away. You can find this event in the Sender UI under Generated by participants.
Signers can sign documents in any order. A new account-level setting lets signers complete documents in any order, the same way transactions created through the API already allow. By default, this setting is off, and signers must follow the document order set when the transaction was created. Once it is turned on, it applies only to new transactions. To turn it on, contact our Support Team. (refs PB-130253)
Attachments and Not in Good Order Document Verification
NIGO Good Order Checks improvements (Early Access). This release brings several improvements to NIGO attachment validation for Early Access Program participants. (refs PB-129013)
New document type: Senders can now choose Indigenous Identity Document (CA) as the expected document type for an attachment requirement in the Sender UI, the API, or the SDKs. When Verify Document is selected, NIGO extracts the name, date of birth, expiry date, address, and issuing organization. Fields that aren't printed on the card are shown as missing, not guessed. The applicable checks are expiry (when present), image quality, file integrity, and data completeness.
Clearer messages when no data is extracted: The Extraction section now explains why no data was returned. For example, it shows whether Verify Document wasn't selected for the attachment, data extraction isn't enabled for the account, or extraction ran but failed.
Structured extraction results: Extraction results now include a status (completed, not performed, or failed). When no data is produced, they also include a reason code, so integrators can handle each case in code instead of parsing error text. This is available in the REST API and in the Java and .NET SDKs, and is backward compatible.
NIGO result notification: A new callback event is sent when NIGO finishes analyzing a signer-uploaded attachment. One notification includes the document type match, extracted data, and verification check results, along with an overall status (clean, flagged, needs review, or error). The event is sent for every analyzed attachment, including when the analysis couldn't be completed, and never delays the transaction. It's off by default. Enable it in Admin > Event Notifications or through the callback API.
More complete attachment audit trail: Every upload is now recorded, including re-uploads and replacements, with the file name. A new Rejected File Attachment entry records which file was rejected and the message sent to the signer. Marked as Verified entries now show the file name, and undoing Mark as Verified is also recorded. These changes apply to new transactions only.
Attachment preview and Mark as Verified are now available to all accounts. Previously, senders without NIGO had to download each signer attachment one at a time to review it, and had no way to record that they had reviewed it. Now, every sender can open an attachment in the preview window, view it in place, and click Mark as Verified. This action is recorded in the transaction's audit trail. NIGO accounts continue to see the Document Summary, Verification Checks, and Extraction panels in the same window. Senders can still download and reject attachments as before. No setup is needed. (refs PB-130678)
Longer attachment descriptions. The attachment description field now accepts up to 500 characters (up from 250), so you can give signers more detailed instructions. (refs PB-131027)
NIGO Tamper Detection (Early Access). NIGO now checks PDF attachments uploaded by signers for signs of editing or forgery, adding a layer of verification on top of the existing Good Order Checks. Tamper Detection requires NIGO attachment validation and is enabled separately. The checks are designed for documents an institution issues from its own systems, such as bank statements, pay stubs, utility bills, and tax returns. They don't apply to photo ID documents, which are normally uploaded as images. (refs DAG-389)
What's checked: OneSpan Sign reviews the file's internal information, including the software that created it, whether it was modified, and its dates. The checks flag an unexpected source (such as a design tool, PDF editor, or code library), a possibly AI-generated file, edits after creation, inconsistent file dates, and a file last changed long after the date printed on the document.
Verdicts: The results are combined into one of four verdicts: Integrity verified, Minor integrity concerns, Authenticity cannot be confirmed, or Potential tampering detected. Stronger warning signs count more than weaker ones, and a single warning sign on its own never produces Potential tampering detected.
What reviewers see: A new integrity section appears in the attachment preview window, next to the existing NIGO verification checks. It shows the overall verdict, followed by one line per check sorted by severity. Hover over a line to see the full explanation. Checks that couldn't be run are shown as neutral, never as a pass. In the attachments list, flagged documents show Check integrity or Review required.
Advisory only: Tamper Detection never blocks or cancels a transaction, and signers don't see the results. A flag is a signal that the document deserves a closer look, not proof of fraud. Likewise, Integrity verified means no warning signs were found, not that the document is guaranteed to be genuine. The reviewer always makes the final decision.
Sender UI
Select a range of transactions or templates with Shift + click. Select one item's checkbox, then hold Shift and select another to select every item in between. The range replaces the current selection. This works in Inbox, Drafts, Archived, Trashed, and Templates, within the current page. (refs PB-129594)
Set accept-only documents for the transaction owner. Senders can now set a document as accept-only for themselves from the Sender UI. This was previously available only through the API. (refs PB-130995)
Longer email messages. The Message to all recipients and Personal message fields now accept up to 4,000 characters (up from 1,024), matching the limit already available through the API. (refs PB-131038)
The 4,000-character limit applies to the message as it's stored, not just the text you see. If your message contains HTML, the tags count toward the limit along with the visible text. For example, <b>Hello</b> is stored as 12 characters, even though only 5 are displayed. A message with HTML can therefore exceed the limit even when the visible text is well under 4,000 characters. To avoid this, keep HTML formatting to a minimum, or leave room below the limit when you use it.
Integrators and API
Manipulate metadata at any transaction status with SDKs. The Java and .NET SDKs now support updating transaction, document, and role metadata at any transaction status. This requires the account feature Allow update transaction metadata regardless of transactions status. (refs PB-126494)
New API: Field overlap validation. Overlapping fields can make a document harder to complete and cause problems during signing, and they're easy to miss when fields come from the API, templates, or PDF field extraction. Integrators can now check any transaction or template for overlapping fields with a new endpoint: GET /api/packages/{packageId}/validate/field-overlaps. To check a template, use its template ID as the packageId, so you can catch overlaps once in the template instead of in every transaction created from it. (refs PB-127937)
The endpoint detects fields that overlap other fields, clickable areas that overlap fields, and clickable areas that overlap other clickable areas.
Each result includes the conflicting field IDs, the document, page, recipient, and type of overlap. Only fields belonging to the same recipient are compared, and each overlapping pair is listed once.
The check only reports what it finds. It never blocks creating or sending a transaction. It uses the same permissions as GET /api/packages/{packageId}, and is also available in the SDKs.
Documents and Evidence Summaries
Completed documents can be sent as individual PDFs. Completion emails can now include the signed documents, the evidence summary, and other completed transaction files as separate PDF attachments, instead of a single .zip archive. This requires the Email Documents and Evidence Summary feature to also be enabled on your account. To enable this feature, contact our Support Team. (refs PB-130572)
Original client IP addresses in the Evidence Summary. The Evidence Summary audit trail can now show two IP addresses for each recorded action. The first is the IP address that OneSpan Sign sees. The second is the original client IP address, which appears when a user connects through a corporate network, proxy, or CDN. To enable this feature, contact our Support Team. Note that the following do not include IP addresses: (refs PB-131307)
Logins through SSO show only the standard IP address.
Final identity verification results don't record an IP address.
When an SMS passcode is resent, the resend doesn't include IP information.
Self-serve consent document management. Account administrators can now upload and manage their own consent documents from the Admin UI or the API, without opening a support request. To enable this feature, contact our Support Team. (refs DAG-383)
You can upload a separate consent PDF for each language your account uses. Signers automatically see the version that matches their transaction or recipient language. You can also choose a default fallback language, or set a language to No Consent so that signers in that language skip the consent form.
An Admin can replace, rename, or download the consent document.
Admins can replace or rename a saved consent document at any time, or download a copy of any active consent document for your records.
Note that changes apply to new transactions only. Drafts and transactions already in progress are not affected.
Templates can be updated with the latest consent document: Any user who can edit a template can refresh it to use the latest active consent document. Transactions created from a template always use the consent document that is active when the transaction is created.
Additional New Features
Completion dates now use the transaction time zone. When $COMPLETION_DATE; is included in an email notification, the date now appears in the transaction's time zone instead of GMT. (refs PB-128202)
Administrators can set a default time zone for the account. Time zones can now be configured at the account level, so time zones stay consistent across senders and transactions. This is available in the web UI and through the API. (refs DAG-408)
By default, senders can still set their own time zone, so nothing changes unless an administrator updates the setting.
Administrators can turn off Allow senders to change their time zone. When it is off, each sender's time zone is replaced with the Account Owner's time zone.
New transactions use the time zone of the transaction owner: the sender's own time zone, or the Account Owner's if senders can't change theirs.
The change applies only to transactions created after it is made. Existing transactions keep the time zone they already had.
Bug Fixes
The following issues were resolved in this release.
Sender UI
When you edit an existing permission set, the page title and button now read Edit Permissions and Save instead of Add Permissions and Add. (refs PB-130394)
Transactions waiting for recipients to be specified now appear in the specifier's Requires My Action filter. (refs PB-131655)
Signing Ceremony
On mobile devices, the Accept button on short consent documents is now visible without scrolling. (refs PB-130095)
Signers who sign as a member of a group can now use the Reassign Recipient feature. (refs PB-130612)
Documents and Signatures
Custom signature logos no longer make signed documents disproportionately larger as the logo size increases. (refs PB-128675)
The signing date returned when you retrieve a transaction now matches the date returned by the field summary call and shown on the signed document. (refs PB-129816)
Other Fixes
Account reports now generate correctly. Previously, missing address records could prevent them from being generated. (refs PB-126569)
In the Designer, conditional fields once again highlight their linked fields on the document. (refs PB-129812)
Names containing the string eval are no longer incorrectly flagged as security vulnerabilities. (refs PB-131081)
Vulnerabilities
This release also includes important security and vulnerability fixes.