Last updated on
10 February 2026
Adobe Acrobat Sign Release Notes: 2026
Adobe Acrobat Sign release v17.0
Production deployment: Febbruary 3, 2026
GovCloud deployment: February 10, 2026
Improved Functionality
- Grouped Checkboxes in Authoring and Templates – Senders can now create checkbox groups through the modern Request Signature and Library Templates, authoring environments with validation rules such as selecting exactly, at least, at most, or a range of X out of Y options. Send in Bulk, Web forms, and Custom Workflows are supported through the use of Library Templates. This enhancement ensures consistent form logic and improves data accuracy across signing workflows.
- Allowed IP ranges – Expanded control over API and mobile access - Administrators can now explicitly control whether IP restrictions apply to API-based clients, including Acrobat Sign mobile applications and certified integrations.
- Authentication support for modern e-Sign – Modern e-Sign now supports three authentication methods: Acrobat Sign authentication, password, and phone-based 2FA.
- Adding Recipient Groups in Hybrid Routing for modern Request Signature – Recipient groups can now be included in hybrid routing, allowing multiple recipients or groups to act in parallel within the same routing step. Group modes support either one or all members to complete the action, providing greater flexibility for complex approval and signing workflows.
- Copy terminal agreements sent from Request Signature—Senders can now create a new draft agreement by copying a previously completed, canceled, or expired agreement. All recipients, settings, files, and form fields are automatically prefilled. The copied agreement opens in the Compose page for quick edits before sending, reducing setup time, minimizing errors, and improving productivity for repetitive workflows such as renewals or corrections.
- Disable the Download agreement link for In-Progress Agreements – Administrators can now remove the “Download a copy” link from post-signing confirmation pages at the account or group level, preventing recipients from downloading agreements from the post sign page.
- Resources Tab in Top Navigation – A new Resources page is available in the top navigation for admins and users, providing direct access to Acrobat Sign educational content, webinars, blogs, and product update videos. The page organizes tutorials by user level—beginner, experienced, and administrator—and links directly to additional support documentation.
- Dynamic Participation for In-Flight Agreements – Remove Recipients – Senders can now remove recipients from agreements that are already in progress without canceling or restarting the transaction. When a recipient is removed, Acrobat Sign automatically revokes their access, updates reminders, audit trails, removes the assigned fields, and transitions the agreement seamlessly back to its active signing state. This flexibility helps organizations maintain accuracy in live routing workflows—such as when a signer becomes unavailable—while preserving legal integrity, compliance, and a complete audit history.
- Require digital signatures for individual recipients during agreement configuration - Senders can now require digital signatures for selected recipients, ensuring stricter signing requirements where needed without impacting other recipients. The signing experience adapts automatically, enforcing required digital signature fields and exposing identity checks when supported, reducing errors and improving compliance for regulated workflows.
- Digital Identity Providers as Default Authentication Methods – Administrators can now select a Digital Identity Gateway provider as the default signer authentication method for internal and external recipients in Send Settings. The configuration applies automatically to agreements, web forms, bulk sends, and workflows, ensuring consistent and compliant recipient verification. This enhancement simplifies authentication setup, enforces organizational identity policies, and improves support for government and enterprise customers that rely on Digital Identity-based authentication.
- Verified Form Fields Using Identity-Verified Data – Form authors can now create verified form fields that automatically populate with data returned by an identity provider (such as OneID) during signer authentication. These fields can be set as read-only or editable, ensuring verified identity data is accurately captured and optionally locked against edits (e.g., name, address, or account number). This strengthens identity assurance, reduces manual entry errors, and streamlines compliance for workflows that require validated signer data.
- Recipient Groups in CSV File for Send in Bulk – Senders can now define recipient groups directly within the Send in Bulk CSV file, enabling multiple recipients to act at the same routing step. Each group can be configured in ONE or ALL mode—requiring either one member or all members to complete their action before routing advances. Group definitions, validation, and audit tracking are all handled per CSV row, with errors reported through downloadable validation files.
- Library Template – Share with Multiple Groups – The modern Create Library Template experience now supports sharing templates with multiple groups within an account, matching the functionality previously available in the classic workflow. Users can select one or more groups when creating or editing a template, ensuring consistent behavior across groups. This enhancement eliminates fallback to the classic experience, improves collaboration, and simplifies template management for multi-group organizations.
- File Attachments for all recipients using digital signatures – All recipients in a digitally signed workflow can now attach files (not just the first signer). A new attachment method using Paperclip annotations displays a visible paperclip icon in the document and remains compatible with multiple digital signatures. Each attachment is added before the signer’s digital signature is applied, preserving signature validity and providing a clear visual indicator of attached files. This enhancement improves legal integrity, transparency, and consistency across e-signature and digital-signature workflows.
Experience Changes
- Workflow agreement cancellation notifications – Cancellation notification updated to reflect the workflow behavior.
When cancelling a workflow-created agreement, the “Notify recipients” checkbox no longer appears. Notifications are always sent based on the workflow’s settings. This change adjusts the message to reflect this behavior in the cancellation challenge.
- Login Page Improvements - The Acrobat Sign login page now offers a cleaner and more consistent experience. As soon as you enter your email address, the page automatically detects your account type and sends you to the right sign-in method, removing unnecessary steps and legacy screens. This makes logging in faster, simpler, and more intuitive for everyone.
- New email format for Acrobat Sign enterprise users who log directly into the web interface - Acrobat Sign now enforces a 64-character limit to the local part of an email address (the portion before the “@” symbol) when editing an existing email, or creating a new user.
All users with a local part over 64 characters have been evaluated and determined to be inactive or test userIDs.
- New email format for Acrobat Sign enterprise users who log directly into the web interface - Acrobat Sign now enforces a 64-character limit to the local part of an email address (the portion before the “@” symbol) when editing an existing email, or creating a new user.
Note that this experience is delivered through a rolling release based on the Acrobat Sign server environment. The rollout schedule is published in the Updated Login experience Technical Notification.
- Enable Management of User Details for Inactive Users – Administrators can now edit user details for inactive users directly in the Admin UI and through CSV uploads without reactivating accounts. This includes updating group assignments (for both single and multi-group configurations), managing the “User can sign documents” attribute, and performing bulk edits for compliance and record maintenance. The change streamlines enterprise user lifecycle management, reduces administrative overhead, and supports cleaner group organization and GDPR-aligned record handling.
Resolved Issues
| Issue | Description |
|---|---|
| 4528600 | Summary: Field validation settings do not work when a form field layer is attached to a custom workflow. Validation rules, such as regex or numeric range limits, are removed when the workflow is started, causing fields to accept invalid input. |
| Fix: Validation rules now apply correctly when form field layers are included in custom workflows. Fields retain their validation behavior across both classic and new authoring experiences. No action is required from users. | |
| 4528748 | Summary: Admins intermittently see an “Unhandled error” when adding group membership to newly synced users (Azure sync). Some new users in the group have the groupID set as null |
| Fix: If a user's group is null after creation, they are placed in the account's Default group. | |
| 4529934 | Summary: In Manage > Web Forms, “Download Form Field Data” keeps loading and never finishes—especially on web forms with many submissions. Teams customers without API access can’t export data (e.g., May 1–31) for reporting |
| Fix: Added paginated, faster CSV export in the UI. Form data downloads complete reliably for selected date ranges, without hanging. | |
| 4532186 | Summary: In the new authoring experience, field color highlighting does not match the behavior of Classic Authoring. When multiple recipients are involved, all fields remain fully colored rather than dimming non-selected recipients’ fields. This makes it difficult to verify field assignments. |
| Fix: Restored visual clarity by dimming (20% opacity) fields that belong to non-selected recipients. This replicates the clarity of Classic Authoring while preserving the modern design system. Highlighting now helps users easily identify the currently selected recipient’s fields and reduces the risk of misassignment. | |
| 4534061 | Summary: The "Download a copy" link appears on the post-sign confirmation page even when the account or group setting is configured to disable it. |
| Fix: A new setting has been added to explicitly suppress the Download option for all post-send pages. The post-sign page now correctly respects the download control setting, hiding the "Download a copy" link when the setting is disabled. | |
| 4536347 | Summary: In Classic Experience, senders could not add a second file (or retry adding a file) when starting certain workflows, blocking multi-document workflow sends, due to an error in how the file picker handled templates shared across multiple groups. |
| Fix: Corrected the file picker’s handling of templates shared across multiple groups so users can add additional files or retry file selection in Classic Experience without errors. | |
| 4537504 | Summary: A conditional dropdown value was missing from the signed document even though it was correctly selected during signing, due to the visibility logic evaluating against a hidden dependent field and not persisting the rendered value into the final signed PDF. |
| Fix: Updated conditional field rendering to correctly resolve visibility dependencies at signing time and persist the selected dropdown value into the signed document when conditions are met. | |
| 4537995 | Summary: In recipient groups, changing the authentication method for external users reverted to Phone after saving, preventing Email OTP from being applied, due to a front-end state handling error that overwrote the user’s selection. |
| Fix: Corrected the recipient group UI logic to properly persist and reapply the selected authentication method across save actions, ensuring the chosen value is retained instead of being reset to the default. | |
| 4539214 | Summary: In custom workflows, a long message label causes the message text to overlap and obscure the message template hyperlink on the Send page, due to improper layout handling of excessive label content. |
| Fix: Updated the Send page layout logic to correctly constrain and wrap long message labels so the message template hyperlink remains visible and accessible. | |
| 4539854 | Summary: Some signers are redirected away from the signing experience when opening certain agreements, due to a malformed link field in the underlying document that lacks a required name attribute. |
| Fix: The signing flow now handles unnamed link fields correctly by assigning a valid name at processing time, preventing errors and allowing signers to complete agreements without redirection. | |
| 4539858 | Summary: On iOS devices, approvers using the Chinese handwriting keyboard cannot complete approval because the Approve button remains disabled after entering their name, due to the signing page not detecting handwriting input events as valid text entry. |
| Fix: Updated the input handling logic to recognize handwriting-based text input on iOS, ensuring the Approve button enables correctly once valid characters are entered. | |
| 4540392 | Summary: Admins intermittently see HTTP 400 errors and recipient groups appear missing in workflows even though the groups exist and access is correctly configured, due to request headers exceeding the platform’s header size limit when users belong to a large number of groups. |
| Fix: The server-side request header size limit was increased so recipient group lookups no longer fail when users have many group memberships. | |
| 4541258 | Summary: Admins could only see the first 100 templates in the Production or Sandbox Sync UI, with additional templates missing from the Local and Remote lists, due to the sync page loading a limited dataset and the search function filtering only templates already loaded in the browser. |
| Fix: The sync UI was updated so that entering text in the search field loads all templates for the selected environment (up to 5,000), ensuring templates beyond the initial 100 are available for search and selection | |
| 4541739 | Summary: Replaced recipients were blocked from digitally signing and saw “The agreement cannot be digitally signed since it is not in the digital sign phase,” due to the workflow failing to transition future replaced signers into the digital signing phase when digital signature fields were present. |
| Fix: The signing workflow was updated to correctly transition replaced or delegated recipients into the digital signing phase when digital signature fields exist, allowing them to sign and complete the agreement. | |
| 4541849 | Summary: Single-line auto-font-size text fields prefilled with multibyte characters were truncated in signed PDFs, causing part of the text to be cut off due to incorrect text sizing during PDF rendering. |
| Fix: Corrected text measurement and auto-font-size behavior for multibyte characters so the full value fits within the field without truncation. | |
| 4542574 | Summary: Editing a library template allowed required dropdown fields to include unpaired values, causing the Click to sign button to remain unavailable during signing when those values were selected, due to missing validation that ensured dropdown display values and export values remained correctly paired. |
| Fix: Template editing now enforces validation on dropdown fields so only properly paired values can be saved, preventing unpaired entries and ensuring required dropdown selections do not block signing. | |
| 4542942 | Summary: In webforms, required fields disabled by conditional logic continued to display the required asterisk, misleading signers into thinking input was still required, due to the UI not updating required indicators when fields were disabled. A separate mobile signature alignment issue was identified but addressed under a different scope. |
| Fix: The webform UI now hides the required asterisk when a field is disabled by conditional logic, ensuring required indicators accurately reflect whether signer input is expected. | |
| 4543157 | Summary: In the Manage page’s In Progress view, the Recipients column continued to show the delegator’s name after a signing role was delegated, even though a different signer was actively signing, due to the UI not updating the displayed recipient to reflect the current delegatee. |
| Fix: The Manage page logic was updated so the Recipients column now displays the active delegatee’s name when a signing role is delegated, ensuring the In Progress view accurately reflects who is currently signing. | |
| 4543253 | Summary: In the Classic Workflow Experience, witness-assigned fields (signature, name, date) disappeared after saving an agreement in Draft state, even though the fields existed on the backend, due to the draft rendering logic failing to restore witness fields when progress was saved. |
| Fix: The draft rendering logic was corrected to preserve and display all witness-assigned fields after saving progress, ensuring agreements opened in Draft state retain the same field visibility as during authoring and signing. | |
| 4543513 | Summary: Users were blocked from sending agreements in the Sign Web UI with the error “Locale is either invalid or missing,” due to locale validation incorrectly enforcing API-level locale rules in the web interface when the sending group’s locale differed from the user’s inherited primary group locale. |
| Fix: Locale validation was corrected so the Sign Web UI properly resolves and accepts valid group and user locale combinations, preventing API-only locale restrictions from blocking agreement sending in the web experience. | |
| 4543592 | Summary: Some Audit Reports showed “Recipient authenticated with Adobe Acrobat Sign” after “Document e-signed” and “Agreement completed,” due to events being stored with second-level timestamps, causing authentication and signing actions occurring in the same second to appear out of order. |
| Fix: Audit event logging was updated to store and display timestamps with millisecond precision, ensuring authentication, signing, and completion events are sequenced correctly in the Audit Report. | |
| 4543617 | Summary: Creating a template from an agreement launches the Classic experience instead of the New experience, despite the New experience being the default, due to the action still being routed to the legacy authoring flow. |
| Fix: The “create template from agreement” action was updated to open in the New experience, aligning the CTA behavior with the default UX and avoiding unexpected context switches for users. | |
| 4544564 | Summary: Hidden fields added or updated via the API (visible:false) rendered as visible in the Modern eSign experience. The signing UI ignored the field visibility flag, so recipients could see fields that should stay hidden. |
| Fix: Updated the Modern eSign UI to filter out fields where visible is false across rendering and navigation logic, so hidden fields never display and do not affect page behavior. | |
| 4544571 | Summary: The WhatsApp delivery option was missing from Send Settings even though WhatsApp was enabled for the account and available during agreement sending, causing inconsistent behavior and confusion for administrators. |
| Fix: The WhatsApp delivery option was restored in Send Settings wherever the feature is available, ensuring consistent visibility and configuration between admin settings and the send agreement experience. | |
| 4545381 | Summary: The Roboto font was missing from the New Request Signature Experience, even though it was available in the Classic Experience, due to the new authoring experience not including all legacy-supported fonts. |
| Fix: Roboto was added to the font list in the New Request Signature Experience, restoring font parity with the Classic Experience and allowing consistent formatting when authoring agreements. | |
| 4545484 | Summary: Some administrators were unable to access or create recipient groups from Admin > Address Book due to a backend request failure, resulting in a 400 error when loading recipient group data. The issue blocked initial setup of recipient groups for affected admins. |
| Fix: The backend request handling was corrected so recipient group search and creation no longer fails with a 400 error. Admins can now reliably access and manage recipient groups regardless of network or location. | |
| 4545547 | Summary: Agreements created from AutoCAD PDFs failed to send when a digital signature field was added, showing a generic send error, due to the system not correctly handling page rotation when validating digital signature field placement. |
| Fix: Digital signature field coordinates are now adjusted to account for rotated pages, ensuring fields are validated against the correct page boundaries so AutoCAD-generated PDFs can be sent successfully with digital signatures. | |
| 4545894 | Summary: When a recipient group is used and no signature field is manually placed, the auto-generated signature block shows the email address text at a very small size. The text becomes progressively smaller as more recipients are added to the group. |
| Fix: The auto-generated signature block now correctly renders the email address at a normal, readable size, regardless of how many recipients are included in the recipient group. | |
| 4546085 | Summary: When using Add Myself in the New Request Signature experience, email addresses containing an apostrophe are displayed incorrectly. The malformed address prevents the agreement from being sent unless the email is manually re-entered or Classic Send is used. |
| Fix: Email addresses with apostrophes are now correctly decoded and displayed when Add Myself is selected in the New Request Signature experience, allowing agreements to be sent without manual correction. | |
| 4546110 | Summary: In the New Template authoring experience, adding a Hyperlink field assigned to a specific participant causes the template save to fail. The same field works when assigned to all participants or when using the Classic experience. |
| Fix: Hyperlink fields now support placeholder participant assignments in the New Template experience, allowing templates to save correctly when the field is assigned to a specific participant. | |
| 4546257 | Summary: In the Sandbox environment, agreements sent through a custom application API incorrectly show a Back button on the authoring page due to Sandbox loading settings from an Adobe-managed application with seamless authoring enabled, unlike Swagger or Production. |
| Fix: Sandbox behavior was aligned with Production and Swagger by ensuring the authoring page respects the intended application settings, preventing the Back button from appearing for agreements sent via custom application APIs. | |
| 4546547 | Summary: Web forms failed to update the counter signer and returned a miscellaneous error due to older user records missing a required internal flag, which caused a null value to be processed during counter signer replacement. |
| Fix: The counter signer update logic was hardened with null-safe handling so web forms can successfully replace counter signers even when older user records lack the expected internal flag. | |
| 4546553 | Summary: Users assigned to multiple groups could create templates in a group where template creation is disabled when the New Create Template experience is enabled. This allowed bypassing group-level restrictions. |
| Fix: Template creation now enforces group-level permissions consistently across the new and classic experiences. Users can no longer create templates in groups where template creation is disabled, even if they belong to other groups with that permission enabled. | |
| 4547744 | Summary: Group Admins could assign Account Admin rights to users through the new User Management page. This exceeded their permission scope and created a compliance risk by allowing elevation of privileges beyond the Group Admin role. |
| Fix: The role selection control is no longer available to Group Admins. Only existing Account Admins can assign or revoke Account Admin rights, ensuring role changes align with permission boundaries. | |
| 4547796 | Summary: Some senders using the Polish UI occasionally receive a confirmation email with incorrect "cannot provide a digital signature" text, even though the agreement sends and signs normally. |
| Fix: Corrected Polish translations for sender confirmation emails so the message shows "sent for signature" instead of the incorrect "cannot provide a digital signature" text. | |
| 4548315 | Summary: When the sender is included as a CC recipient in the new Send Workflow, no validation error is shown and CC email notifications are not sent to any recipients listed after the sender in the CC list. This differs from Classic Workflow behavior and can cause CC recipients to miss notifications. |
| Fix: Updated the new Send Workflow logic so that all CC recipients, excluding the sender, receive CC email notifications regardless of their position in the CC list, aligning behavior with expected outcomes. | |
| 4548583 | Summary: PDF/A could not be enabled for a group if the user’s default group had written signatures enabled, even when written signatures were disabled for the group being edited. This blocked valid PDF/A configuration for non default groups. |
| Fix: Updated the validation to check written signature settings on the group being modified, not the user’s default group, allowing PDF/A to be enabled correctly where permitted. | |
| 4549337 | Summary: SMS notifications for cancelled agreements were suppressed when the Email Agreement Cancelled setting was disabled. This prevented customers who disable email notifications from sending required SMS cancellation alerts. |
| Fix: Decoupled SMS and WhatsApp cancellation notifications from the email setting by introducing a dedicated notification control, allowing SMS delivery for cancelled agreements even when email notifications are disabled. | |
| 4549472 | Summary: In Acrobat Sign for Government, users could not create reusable templates using the new Create Template experience. After uploading a document, the workflow stalled on a blank screen, blocking template creation. |
| Fix: Restored the missing authoring dependency required by the new Create Template experience in Gov environments, allowing the authoring screen to load correctly and templates to be created successfully. | |
| 4549862 | Summary: When the landing page is set to the New Request Signature experience, the configured login warning message does not display after sign-in. This prevents organizations from showing critical maintenance or disruption notices when users land directly on the Send page. |
| Fix: Restored support for displaying the login warning message in the New Request Signature experience. When users land on the Send page after login, the configured warning message now appears as a notification, matching prior behavior and customer expectations. | |
| 4550175 | Summary: Pressing Enter after entering a phone number for phone authentication in a workflow submits the form prematurely and triggers a system error, interrupting the workflow flow due to the form being submitted instead of waiting for explicit confirmation. |
| Fix: Updated the recipient dialog to prevent form submission on Enter for phone authentication fields, ensuring users remain on the dialog and must click Continue, eliminating the unintended workflow interruption. | |
| 4550302 | Summary: German signature requested and reminder emails used inconsistent forms of address, switching between informal “Du” and formal “Sie” within the same message, causing confusing and unprofessional wording. |
| Fix: Updated the German email translations to use a single, consistent form of address throughout the template, ensuring uniform and predictable language in all signature requested and reminder emails. | |
| 4550556 | Summary: Agreements containing large architectural plan PDFs failed to send when digital signature fields were added, returning an error during authoring due to page rotation and size handling in digital signature placement. |
| Fix: Updated digital signature field processing to correctly handle rotated, large-format pages, allowing agreements with architectural plans to send successfully with digital signatures applied. | |
| 4550579 | Summary: When an agreement was completed by removing the last remaining recipients during an in-revision state, the system did not generate the AGREEMENT_WORKFLOW_COMPLETED event, so no webhook notification was sent, breaking workflows that rely on this event to detect completion. |
| Fix: Updated event handling so agreements completed via recipient removal in revision now generate the appropriate completion events, ensuring AGREEMENT_WORKFLOW_COMPLETED webhooks are triggered as expected. | |
| 4550998 | Summary: Prefilled checkboxes appeared checked in authoring but were unchecked for signers because checkbox values were stored as non-empty text strings instead of explicit YES/NO states, causing the signing experience to treat them as unchecked. |
| Fix: Updated checkbox value handling so any non-empty prefilled value is interpreted as checked and empty or missing values as unchecked, ensuring checkbox states remain consistent for signers. |