Adobe Acrobat Sign Release Notes - 2026

Search

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.
  • New TSP options for Cloud Signatures - New Trust Service Providers have been added to support digital cloud signatures:
    • Swisscom

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.

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.

Adobe Acrobat Sign release v17.0.1

Production deployment: March 17, 2026

GovCloud deployment: March 19, 2026

Improved Functionality

  • Create a copy – Expanded access points, faster reuse of agreements.
    Create a copy is now available directly from the In progress and Waiting for you filters on the Manage page, as well as from the post-send confirmation page. These additional entry points make it easier to reuse agreements at more points in the sending lifecycle, reducing the need to restart from scratch.
    Note: With this release, the administrative controls to disable this feature will be removed from the admin menu, establishing Create a copy as a standard capability available to all eligible users.

    Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: Account and Group; Enabled by default.

Experience Changes

  • Integration key expiration visibility – Expiration dates now shown on the Access Tokens tab
    The Access Tokens tab, in the Personal Preferences menu, displays the expiration date for each integration key. This gives users and administrators clearer visibility into key age and replacement timing, making it easier to monitor existing keys and avoid unexpected interruptions when a key reaches the end of its 10-year validity period.

    Available environments:     Sandbox, Commercial, Government | Available tiers of service:Acrobat Sign Solutions | Configuration scope: API
     

REST API/Webhook Updates

API and webhook updates for this release can be found in the Acrobat Sign API documentation.

  • OEM 2.0 personalized email display – Clearer sender and recipient identity across embedded experiences, and correct email delivery.
    For OEM 2.0 Partners using embedded workflows, Acrobat Sign can now display a user’s personalized email address instead of the partner-registered email across key UI surfaces and notifications. Agreements, queues such as “Waiting for you,” and “Review and Sign” emails consistently reflect the personalized identity while preserving the registered email internally for authentication and entitlements. This improves clarity for senders and signers and prevents emails from being sent to non-deliverable registered addresses.

    Available environments: Sandbox, Commercial | Available tiers of service: Acrobat Sign Solutions | Configuration scope: API - OEM 2.0 Partners; by request only

  • Webhook notification for SMS delivery failures – Real-time visibility into failed SMS sends, automated remediation, and parity with email bounces.
    Acrobat Sign now emits a new webhook event, AGREEMENT_PHONE_BOUNCED, when an agreement sent via SMS cannot be delivered due to issues such as invalid phone numbers, carrier rejection, or blocked lines. This enables customers to detect SMS delivery failures in near real time and automatically trigger follow-up actions like correcting phone numbers, retrying delivery, or opening support cases, eliminating blind spots and reducing delays in mobile-first signing workflows.

    Available environments:     Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: API
     
  • Webhook payloads – Added conditional participant extendedStatus field for dynamic participation updates, improving participant state visibility.
    Webhook notifications now include an extendedStatus field in each participant (memberInfos[]) object when the sender modifies an in-flight agreement using dynamic participation. This field provides additional participant lifecycle detail while leaving the existing status field unchanged for backward compatibility.
        {
          "participantSets": [
            {
              "id": "",
              "memberInfos": [
                {
                  "company": "TestCo",
                  "email": "signer2@someDomain.dom",
                  "id": "CBJCHBCAABAAJiZV9cH",
                  "name": "Signer Two",
                  "status": "ACTIVE",
                  "extendedStatus": "REMOVED"
                }
              ],
              "order": ,
              "role": "",
              "status": ""
            }
          ]
        }

status values (unchanged): ACTIVE, REPLACED.
extendedStatus values: ACTIVE, REPLACED, REMOVED, COMPLETED.


Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: API

Resolved Issues

Issue Description
4543515 Summary: A webhook email bounce event may be incorrectly generated for a valid signer after the signer successfully signs and the agreement advances to the next step. This can occur when a delegatee in the same signing group has an invalid email address and the sender replaces the original delegator. In these cases, the system may incorrectly attribute the “signed on behalf of…” bounce event to the valid signer instead of the participant whose email actually bounces.
Fix: The event attribution logic was corrected so email bounce events are associated only with the participant whose email actually bounces. A bounce event is no longer generated for a valid signer who has already completed signing, and webhook notifications now reflect the correct participant and email address.
4544548 Summary: Integration Keys created through the Web UI may expire after 10 years, even though the creation page states that the key provides “permanent access.”  When a key reaches its 10-year lifetime, API calls begin returning an expired token error, which may break existing integrations unexpectedly.
Fix: The user interface messaging was updated to remove the “permanent access” wording and clearly display the expiration date for Integration Keys. The updated text now states that the key retains access until the expiration date or until it is manually revoked, providing transparency about the 10-year default lifetime.
4546301 Summary: Webhook event delivery may be delayed by up to multiple hours for agreements with very large documents, even when agreement creation completes and early processing steps appear to finish within minutes. During the delay window, the webhook delivery service may repeatedly receive DOCUMENT_NOT_AVAILABLE responses when attempting to retrieve agreement documents, and the webhook event may not be delivered until the service stops retrying or the documents become available.
Fix: Document availability handling was corrected so large agreements reliably transition to a state where documents are retrievable without extended DOCUMENT_NOT_AVAILABLE responses. As a result, webhook events are delivered without multi-hour delays caused by document retrieval retries against unavailable documents.
4547823 Summary: A recipient's private message may not display for some signers when an agreement is created in the Authoring state through the API and then edited from the Manage experience. In this scenario, the UI may show the Private Message value as “None” or blank even though the agreement data includes the correct private message value. This behavior appears in shared-account scenarios where a user switches into another user’s account to edit the draft, and it may affect only specific recipients while others display correctly.
Fix: A check was added to retrieve the active share context and return the private message for authorized shared users. As a result, the Private Message value now displays correctly when viewing or sending an API-created draft from the Authoring flow.
4548274 Summary: The Modified Date for library templates may not update after a template is edited and saved in the new template experience. Users may see newly added or updated fields on the template, but the Modified Date remains unchanged in the Manage UI and in administrative views, which makes it appear that the template was not recently modified. This occurs because the new experience updates form fields through a path that does not also update the template’s modified timestamp.
Fix: The modified date update behavior was aligned across the new template experience and the related API operations. The code path that saves template field changes now also updates the template’s Modified Date so it reflects the actual time of the most recent change.
4548564 Summary: Signatures and form fields may appear invisible in the signed PDF when they are placed over pre-existing stamp annotations in the source document. In affected templates, the stamp annotations overlap or obscure the interactive fields during processing, causing completed signatures and other fields to be hidden in the final signed document.
Fix: Stamp annotation handling was updated to safely process and flatten pre-existing stamp annotations so they no longer obscure form fields or signatures. Fields placed over stamped areas now remain visible throughout signing and in the fully executed PDF.
4549103 Summary: An email bounce event may be logged again for a previously incorrect recipient after the sender replaces that recipient with a valid email address. In some cases, the audit trail may show a second bounce event for the old email, and the agreement status may reflect “email bounced” even though the new recipient successfully receives, views, or signs the agreement. This behavior can make it appear that the agreement is still targeting both the old and new email addresses.
Fix: The replace signer workflow was updated to prevent sending additional notification emails to a replaced recipient whose email has already bounced. The system now checks for prior bounce history before sending replacement-related notifications, ensuring that no new bounce events are generated for the old email address after replacement.
4549306 Summary: Users whose email addresses contain certain special characters (for example, an apostrophe) may be unable to log in from the generic adobesign.com or echosign.com public login pages. After entering the email address and clicking into the password field, the page may reload and clear the email field instead of redirecting the user to the correct shard or SSO login page. This prevents affected users from completing authentication and blocks integrations that rely on the public login endpoint.
Fix: The login shard resolution logic was corrected to properly handle and decode email addresses containing special characters before constructing the inter-shard redirect URL. Users with affected email formats are now correctly redirected to their designated shard and SSO login page without the email field being cleared.
4549331 Summary: Signatures and other form fields may appear missing or invisible in the signed PDF when certain document processing features are enabled and the source PDF contains invalid page box coordinates (for example, incorrect CropBox or MediaBox values). In this scenario, fields that rely on page coordinates may render outside the visible page area, making completed signatures appear missing even though signing completes successfully.
Fix: PDF page box handling was corrected to safely normalize invalid CropBox and MediaBox values during document processing. As a result, signature and form field placement now aligns to the visible page area, and signed PDFs display signatures as expected.
4550367 Summary: Creating a web form may fail with a generic “Server error” after selecting Preview and Add Fields when the sender’s group default signer authentication is set to Phone and the account does not have available phone authentication quota, even if the web form signer authentication is set to a non-phone method (for example, Adobe Sign). As a result, all users in the affected account may be blocked from creating web forms across all documents.
Fix: Web form creation now evaluates quota only for the authentication method actually configured for the web form signer, and it no longer applies phone authentication quota checks based solely on the group default authentication setting. This prevents false quota exhaustion errors and allows web forms to be created normally.
4551011 Summary: When a sender uploads certain scanned PDFs, adds signature fields, and sends the agreement, the signed PDF may display no visible signatures after signing completes. This behavior may occur when the uploaded PDF contains invalid page boundary metadata (MediaBox and CropBox coordinates appear reversed), which can cause signature and other field appearance layers to render outside the visible page area.
Fix: PDF page boundary handling is updated to correctly process PDFs with invalid or reversed MediaBox and CropBox coordinate values, so signature and form field appearance content renders within the visible page area and remains visible in the final signed PDF.
4551427 Summary: Some recipients who already have active, correctly provisioned accounts receive agreements as “pseudo user” recipients instead, so the agreement does not appear in their normal Manage view. This happens when recipient email addresses include leading or trailing spaces, which prevents the system from matching the email to the existing user and causes a pseudo-user record to be created.
Fix: Email parsing and user lookup were updated to normalize recipient email addresses (trim leading and trailing whitespace) before matching them to existing users. As a result, agreements addressed to existing users resolve to the registered account instead of creating a pseudo-user recipient, even if the email was entered with spaces (in API payloads and workflow recipient lists).
4553198 Summary: When an agreement includes at least one recipient configured for SMS delivery and at least one recipient configured for email-only delivery, canceling the agreement through the API does not send an SMS cancellation notification to the SMS recipient. The agreement is successfully cancelled, and email notifications are delivered, but SMS recipients do not receive a cancellation message.
Fix: The cancellation workflow was corrected to ensure that SMS cancellation notifications are sent to all recipients configured for SMS delivery when an agreement is cancelled, regardless of other recipients’ delivery methods.
4554463 Summary: When agreements include cloned radio buttons that share the same field name across combined documents, only one instance of the selected option remains selected in the final signed PDF. Although the fields appear visually as checkboxes, they are implemented as radio buttons. After signing, the selected value does not consistently propagate across all cloned instances, causing incorrect or incomplete mapping of the expected selection.
Fix: The form field handling logic was corrected so that cloned radio buttons store and propagate the selected export value rather than an internal index value. This ensures that all cloned instances of the same radio button field reflect the correct selection in the signed PDF.
4554593 Summary: Some partner integrations that use the legacy OAuth endpoints to refresh access tokens started failing with HTTP 401 errors. The service rejected token refresh requests with an error indicating that the application is not allowed to use the legacy OAuth endpoints and must use the OAuth v2 endpoints instead. This blocked customers from authenticating Acrobat Sign through partner applications, even for integrations that were previously working.
Fix: The authentication service was corrected so partner applications that are configured to use the legacy OAuth flow can successfully refresh tokens again, instead of being incorrectly forced onto the OAuth v2 endpoints. 
4554614 Summary: When a signer uses the modern eSign experience on an agreement that requires signer authentication and is configured to require acceptance of terms of use before signing, clicking Click to Sign triggers a 5-second redirect to the classic signing experience. The redirect message warns that signatures and initials entered in modern signing will be cleared, forcing the signer to re-enter them and effectively sign twice.
Fix: The signing token refresh flow was corrected so that when the signer accepts the terms of use before signing, the reissued signing token retains the signer authentication details. This prevents the final signing step from failing authentication and eliminates the forced fallback from modern signing to the classic experience.
4555656 Summary: Under specific timing conditions, an agreement state transition may appear to succeed but does not actually change the agreement state. When a webhook notification is received before backend processing completes, subsequent API calls can use stale agreement status data. In this window, certain state transition methods return HTTP 200 OK even though the agreement is not in a valid state for the requested transition. As a result, automation workflows may assume the transition succeeded while the agreement remains in the original state.
Fix: Agreement state transition logic was updated to enforce strict validation before applying a transition. If the agreement is not in a valid state, the API now returns a clear error response instead of silently returning success. This ensures invalid transitions are explicitly rejected, enables calling systems to retry appropriately, and prevents agreements from remaining in an unintended state without visibility.

Adobe Acrobat Sign release v17.1

Production deployment: May 5, 2026

GovCloud deployment: May 12, 2026

Improved Functionality

  • In-Person Signing – Enable hosted signing sessions in the web application
    In-Person Signing allows a sender to designate an internal host who facilitates an in-person signing session using a web browser. The host launches a controlled signing session from the Manage page or an email notification, temporarily hands the device to the signer to complete required actions, and regains control at completion. Session creation and completion are recorded in the audit trail, and signers may optionally provide an email address to receive a copy of the agreement.
  • Bulk Digital Signature from the Manage page – Apply a digital signature to multiple agreements with a single authorization
    Signers can select multiple agreements in the Waiting for you view and apply digital signatures as a bulk action using a single signing authorization. This reduces repetitive signing steps for high-volume workflows while preserving existing cloud signing security, authentication, and audit controls. Bulk signing requires signers to review or skip all agreements before completing the bulk action. 
  • Send Only to Internal Recipients – Restrict agreements to be sent to recipients within the same Acrobat Sign account.
    The Send Only to Internal Recipients setting prevents users from sending agreements to recipients outside their Acrobat Sign account. When enabled, agreements can be sent only to recipients whose account IDs match the sender’s. This control supports internal security requirements and prevents agreements from being shared externally.
  • Phone Transaction Usage Reporting – Expanded reporting with group-level visibility and scheduled report access
    Phone transaction reporting now provides visibility into purchased quantities, quota start dates, and detailed consumption across SMS and WhatsApp transactions. Customers can track usage at the group level and access scheduled CSV reports through a unified reporting experience, enabling more accurate budgeting, internal allocation, and proactive monitoring to prevent service disruption when transaction limits are reached.
    Reporting is now generated through scheduled reports in the reporting interface, with API access available to retrieve the latest report output.

    New endpoint:  POST /api/rest/v6/reportDownload
    This endpoint accepts a scheduleId and returns the download URL for the most recently generated CSV report associated with that schedule.

Experience Changes

  • Signature Appearance in Audit Reports – Logs the signature input method used by each signer, increasing compliance visibility and reducing manual verification
    Audit reports now record the signature appearance method used when a signer applies their signature. For each ESIGNED event, the audit trail identifies whether the signer used a typed signature, a drawn signature, an uploaded image, or a mobile-based draw or image capture. This enhancement enables compliance and operations teams to verify signature methods directly from the audit report, reducing ambiguity and preventing unnecessary agreement rejections.
    Signature appearance types:
    • Type: Signer types their name and selects a font-based signature style.
    • Draw: Signer draws their signature using a mouse or trackpad on a desktop.
    • Image: Signer uploads a signature image file from the desktop.
    • Mobile Draw: Signer draws their signature using touch on a mobile device.
    • Mobile Image: Signer uploads or captures a signature image on a mobile device.
  • Saved Signatures for API Signing URLs – Allows use of saved profile signatures during API-based signing
    Allow registered users to apply their saved profile signatures when signing agreements through API-generated signing URLs (GET /agreements/{agreementId}/signingUrls). Saved signatures appear for internal signers, and for external signers who authenticate using email OTP or Adobe ID. This capability streamlines signing workflows for backend integrations while maintaining account-level security controls.
    Enabled by Adobe on a per-account basis following security review.
  • Personal address book management in the modern experience – Users can delete saved email addresses directly from their personal address book in the modern Request Signature experience, making it easier to keep personal recipient lists accurate and up to date.
  • Agreement Expiration Window – Extended default expiration period to 365 days
    The maximum completion deadline for agreements has been extended from 180 days to 365 days. When document expiration is enabled, agreements are now automatically assigned a 365-day expiration date that cannot be removed. This change ensures all agreements have a defined lifecycle, improves long-term tracking and compliance, and reduces the risk of agreements remaining open indefinitely while still allowing users to set earlier deadlines when needed.
  • Revamped Home Page – Improves workflow access, surfaces critical actions
    The Home page has been redesigned to make it easier to start agreements, monitor activity, and access key features, including the ability to copy recently sent agreements, view action tiles in a more intuitive order, quickly identify In Progress and Waiting for You items, and experience a streamlined What’s New banner that reduces visual clutter, helping users move faster, reduce missed agreements, and navigate a more focused Home experience.

    The new Home page will be rolled out across 10 days after the release. Refer to the Technical Notice for the schedule.
  • Trial Enhancements - The latest onboarding experience has been added to Sign Trial.
    Sign Trial now includes the enhanced onboarding experience and features introduced in recent paid releases.
  • New Custom Workflow Designer becomes default – Promote modern designer, remove user switch controls, retain admin flexibility
    The new Custom Workflow Designer experience is now the default for all accounts. Users no longer see switch links to revert to the classic designer, while administrators retain the ability to re-enable access to the previous experience if needed. This update advances the transition to the modern workflow design interface while preserving administrative control during the transition period.

REST API/Webhook Updates

API and webhook updates for this release can be found in the Acrobat Sign API documentation.

  • mTLS key management for webhooks – Add Acrobat Sign-generated key option, enable certificate signing workflow, improve security compliance
    Developers can now choose how private keys are managed for webhook mTLS authentication in Acrobat Sign. In addition to the existing model where customers generate and upload their own private key and certificate, Acrobat Sign can now generate the private key and a certificate signing request (CSR). Customers can use the CSR to obtain a certificate from their certificate authority and upload it to complete the configuration. This option improves security by keeping private keys within Acrobat Sign while maintaining compatibility with existing webhook mTLS behavior.
  • Digital identity initialization via login_hint parameter – Allows API senders to initialize Digital identity authentication with a recipient-specific login identifier.
    Several v6 REST API /agreements endpoints now support a loginHint parameter that allows API senders to initialize Digital Identity Gateway authentication using a known login identifier, such as an email address or user ID number. The identity provider controls the user experience, but the identifier typically pre-populates the login screen to strengthen high-trust authentication workflows and reduce impersonation risk. The identifier appears in masked format on the Digital Identity Gateway landing page and in the audit report to preserve traceability while protecting sensitive data.
    The following endpoints have been updated to include the loginHint parameter:
    • POST /agreements
    • PUT /agreements/{agreementId}
    • PUT /agreements/{agreementId}/participantSets/{participantSetId}/participants/{participantId}/securityOptions
    • GET /agreements/{agreementId}
    • GET /agreements/{agreementId}/members/participantSets/{participantSetId}
    • GET /agreements/{agreementId}/participantSets/{participantSetId}/participants/{participantId}/securityOptions
    • GET /agreements/{agreementId}/members
  • OEM 2.0 Identity and Trust Boundary Enhancements – The "Show Personalized/OEM email address everywhere" feature now prioritizes users provisioned by the same partner and automatically creates a recipient when no match is found
    When the Show Personalized/OEM email address everywhere feature is enabled, agreement participant resolution prioritizes users provisioned by the same partner and automatically creates a recipient record when no matching user exists, ensuring consistent identity handling across accounts.

    Additionally, with Show personalized/OEM email everywhere enabled, audit reports indicate whether a sender is partner-provisioned or a personal account, and signer flows guide users to switch accounts when identical email addresses exist across different account types, reducing confusion and preventing unintended access.

Resolved Issues

Issue Description
4520028 Summary: The Group column on the Manage page displayed incorrect or inconsistent values when users belonged to multiple groups. Changing the user’s primary group caused agreements to show the wrong group, including the last selected primary group or multiple groups, instead of the group the agreement was originally sent from.
Fix: Updated the Manage page logic to use the agreement’s sending group (agreement_group_id) instead of the user’s current primary group when rendering the Group column.
4532690 Summary: Users could not edit draft agreements created from custom workflows when both “Enable agreements to only be sent by using a workflow” and “Enable new Custom Workflow send experience” were enabled. The system incorrectly blocked access to the compose page when editing an existing draft, treating it as a new send action instead of a draft edit. 
Fix: Updated the Compose page logic to detect draft editing scenarios and bypass the workflow restriction check, allowing users to edit existing draft agreements created from custom workflows.
4536764 Summary: Sending agreements through a custom workflow resulted in a server error due to a failure processing specific template PDFs. The error was caused by invalid or missing annotation appearance data in one or more source documents, which triggered a rendering exception during prefill. The issue was not consistently reproducible and could not be replicated outside the affected workflows. 
Fix: Improved handling of rendering exceptions in the PDF processing layer.
4537197 Summary: When using the new Send in Bulk experience with manually entered recipient names, the second name field was removed during signing due to incorrect handling of required recipient name data across documents. 
Fix: Updated document processing logic to correctly retain all recipient name fields when sending agreements in bulk.
4538172 Summary: Copying workflows that include recipient groups failed during Sandbox Sync with an “Error executing request” message due to invalid recipient group references. The workflow used environment-specific recipient group IDs, which are not portable across environments, causing validation to fail during sync.
Fix: Updated Sandbox Sync handling to correctly validate and process recipient group references during workflow copy operations, preventing failures when recipient groups exist in both environments.
4538251 Summary:  In the new Send in Bulk experience, fullname and email signer info fields did not appear during signing or in the final document when the source file contained existing AcroForm fields. The issue was caused by incorrect handling of merge field data when combining signer info fields with pre-existing form fields, resulting in the fields not being rendered in child agreements
Fix: Updated merge and form field processing logic to correctly apply signer info fields in documents that include existing AcroForm fields.
4545485 Summary: Agreement creation intermittently failed when thumbnail generation encountered malformed PDF form fields. The failure was caused by source documents containing form fields without valid names and invalid nested field structures, which triggered processing errors during PDF generation. 
Fix: Added validation and null checks during PDF processing to handle malformed form fields and prevent failures during thumbnail generation and agreement creation.
4545814 Summary: Fields are misaligned and text tags remain visible when processing landscape-oriented documents generated from XDP-based workflows. Incorrect coordinate calculations in landscape layouts cause improper field placement and prevent text tags from being properly parsed and removed.
Fix: Updated the field rendering logic to correctly calculate and place form fields in landscape-oriented documents, ensuring proper alignment and removal of text tags during processing.
4545978 Summary: Accented characters in signer names render incorrectly in the visible signature block when using local digital signing. The issue occurs because the default font embedded in the document lacks proper encoding for Western European characters, causing incorrect character substitution during signature appearance rendering.
Fix: Updated the embedded font configuration to include proper encoding for accented characters, ensuring correct rendering of signer names in the signature appearance
4547100 Summary: Cloned multiline text fields render inconsistently in the signed PDF. Multiline clone fields are missing the default appearance dictionary, which causes cloned fields to display fewer lines than the source field even when both fields use the same size and settings.
Fix: Added the default appearance dictionary to multiline cloned fields so cloned and source fields render consistently in signed documents.
4548305 Summary: The onboarding checklist shows “Request BAA for HIPAA readiness” as Pending even when HIPAA is enabled. The checklist evaluation logic incorrectly treats inherited HIPAA-related settings as incomplete, causing the task status to remain Pending despite the feature being enabled.
Fix: Updated checklist evaluation logic to correctly interpret HIPAA-related settings, including inherited values, so the onboarding task reflects the completed state when HIPAA is enabled.
4550731 Summary:  A large gap appears between the signature underline and timestamp when signing documents using Fill & Sign. The issue occurs when the signature field is not wide enough to accommodate the rendered signature content, causing incorrect spacing in the signature appearance
Fix: Updated signature rendering to respect the defined field dimensions and adjust spacing appropriately, reducing the gap between the underline and timestamp.
4550906 Summary: The Change Password link points to an invalid URL for certain users, causing a browser error. The issue occurs when the application reads an outdated endpoint from configuration instead of the correct URL, leading to inconsistent behavior across environments.
Fix: Updated the configured password change endpoint to use the correct URL across affected environments.
4550992 Summary: Editing certain templates in the new experience redirects to the Create Template page instead of opening the template in edit mode. The issue occurs because the system determines the experience based on the template owner’s settings rather than the current user’s settings, causing incorrect routing when editing shared templates.
Fix: Updated template editing logic to use the current user’s experience settings instead of the template owner’s settings, ensuring templates open in the correct edit mode.
4551756 Summary: Approval request emails display unresolved template variables in the recipient field, causing incorrect email formatting. The issue occurs due to a failure in the email template rendering logic when generating entitlement conflict notifications.
Fix: Updated email template rendering to correctly resolve and populate recipient fields, ensuring valid email addresses are displayed in approval request emails.
4551768 Summary: Signers encounter an unhandled error when accessing or completing agreements due to a failure in form field appearance processing. A malformed appearance object causes a ClassCastException during document generation, leading to agreement rendering failure.
Fix: Updated form field processing logic to validate appearance object types before casting, preventing exceptions and ensuring agreements render correctly for signing.
4552272 Summary: Cancelled or abandoned agreements appear under Waiting for you on the Manage page. The issue occurs when a workflow restart event does not properly clean up participant status data, leaving stale visibility and indexing data that surfaces the agreement in incorrect views
Fix: Updated workflow restart handling and indexing logic to correctly clear prior participant status data and ensure agreements appear only in their correct state.
4553158 Summary:  In RTL language environments on iOS, the signature panel does not respond correctly when drawing a signature. The panel scrolls instead of capturing input, requiring users to manually scroll to draw and apply the signature, which prevents normal signing behavior when the new recipient signature experience is enabled.
Fix: Updated signature panel interaction handling for RTL layouts on iOS to correctly capture drawing input without unintended scrolling, enabling normal signature creation and application.
4553583 Summary: Workflows allow email addresses with leading or trailing spaces, which causes agreements to fail silently when sending in the new experience. The system does not validate or normalize the input, and no error message is shown to indicate the issue.
Fix: Updated input handling to automatically trim whitespace from email addresses and prevent saving invalid values, and added handling for existing workflows so agreements can be sent successfully.
4553676 Summary: Hyperlinks display incorrectly in the Manage view, where the agreement title is appended to the URL, resulting in broken links. The issue occurs due to incorrect URL parsing when rendering hyperlinks in the Manage interface.
Fix: Updated hyperlink rendering to use proper URL parsing, ensuring links remain unchanged and function correctly across all views.
4555021 Summary:  OTP validation fails with an “expired” error even when the code is entered immediately. The issue occurs due to a race condition in the authentication flow, where multiple submission events cause the OTP to be invalidated prematurely. 
Fix: Updated OTP validation flow to handle duplicate or rapid submission events correctly, preventing premature expiration and allowing valid OTP entries to succeed.
4555028 Summary: Removing the next recipient to sign can fail with a system error and leave the agreement stuck in a pending revision state. The issue occurs when the recipient has an active reminder, which prevents the agreement update from completing successfully.
Fix:  Updated recipient removal logic to handle cases where the next signer has active reminders, allowing the agreement update to complete without errors.
4555319 Summary: Web form creators see only Type and Draw signature options when previewing the form, while signers see all available options (Type, Draw, Image, Mobile). The issue occurs because the preview mode does not correctly apply enabled signature input settings when the creator is not acting as a signer. 
Fix:  Updated web form preview behavior to apply the full set of enabled signature input types, ensuring creators see the same signature options as signers.
4555345 Summary:  Agreements with multiple Signer with Witness recipients fail to open in Preview from Draft with the error “ParticipantSetsInfo cannot be modified.” The issue occurs due to incorrect participant and witness ordering logic in custom workflows, which prevents the agreement from transitioning back to the authoring state
Fix: Updated participant and witness ordering logic in custom workflows to correctly calculate execution order, allowing agreements to return to the authoring state and proceed normally.
4555615 Summary: Webhook event payloads for delegated and replaced recipients do not include the privateMessage field. The issue occurs because the private message is not propagated to the recipient state used to generate webhook payloads, resulting in missing data for affected events.
Fix: Updated participant data handling to ensure private messages are included in webhook payloads for delegated and replaced recipients.
4555687 Summary: Agreements can be auto-cancelled and moved to a hidden state after signing due to a document visibility validation failure. When a participant is delegated or replaced, the document visibility mapping is not correctly transferred, causing a mismatch between assigned fields and visible documents, which can trigger an automatic cancellation.
Fix:  Delegation and replacement logic now correctly clone document visibility mappings for new participants, preventing validation failures and unintended agreement cancellation.
4556516 Summary: Form fields can ignore configured font sizes and render inconsistently in generated agreements. The issue occurs in multiline fields when the document processing engine adjusts font size to prevent text clipping, overriding fixed font size settings. 
Fix: Updated font rendering behavior so multiline fields respect fixed font size settings, aligning behavior with expected output and preventing unintended size adjustments.
4556967 Summary: Selected checkboxes can appear unselected in the finalized signed PDF for web forms. The issue occurs when certain hidden values (for example, “no”, “false”, “0”, “off”, “unchecked”) are used, which can cause checkbox states to be misinterpreted during document processing when Gibson is enabled. 
Fix: Updated checkbox processing to correctly interpret hidden values and preserve selected states in the finalized document, ensuring consistency between signing and the signed PDF.
4557222 Summary:  Link fields from field templates can disappear on the authoring page when used within a workflow. The issue occurs because link fields are not included in the agreement form field data returned during workflow-based authoring, resulting in missing fields.
Fix: Updated form field handling to include link fields from field templates during workflow processing, ensuring they are correctly merged and displayed on the authoring page.
4557272 Summary: The Date of Signing field can fail to appear in the finalized signed PDF. The issue occurs when text field rendering fails during document processing, preventing the date field from displaying in the output document.
Fix: Updated text field rendering to handle null or empty values correctly, ensuring the Date of Signing field is consistently displayed in signed documents.
4557282 Summary: Radio button fields in web forms can display an unexpected tooltip value (“object Object”) when created using the new template experience. The issue occurs due to incorrect handling of empty tooltip values, causing placeholder data to be rendered instead of being suppressed. 
Fix: Updated tooltip handling logic to properly ignore empty values, preventing unintended placeholder text from appearing in web forms.
4557589 Summary: Prefilled checkbox fields can appear unchecked when the agreement is sent for signature. The issue occurs when duplicate or conflicting hidden values are defined for checkbox or radio inputs, which can cause incorrect interpretation of the selected state during document processing. 
Fix: Updated field value handling to correctly process hidden values and preserve prefilled selections, ensuring checkbox states remain consistent when agreements are generated and sent.
4557672 Summary: The new request signature experience can display a generic error (“The request provided is invalid”) when sending an agreement, without identifying the specific field causing the failure. This can occur when recipient details (such as phone number format) fail validation, but the error is not surfaced clearly to the user. 
Fix: Updated validation handling to provide specific, field-level error messages, helping users identify and correct invalid inputs before sending the agreement.
4557680 Summary: Checkbox or radio button mappings can fail in some agreements when combining multiple documents, resulting in expected values not being applied. The issue occurs when default values do not exactly match defined export values, which can cause fields to be treated as separate groups and break mapping behavior.
Fix: Updated field mapping logic to ignore mismatched default values and correctly associate fields across documents, improving consistency of checkbox and radio button behavior.
4557902 Summary: An extra gap can appear between the signature and the date and time stamp in Fill and Sign agreements. The issue occurs due to incorrect spacing calculation in well-formatted signatures, leading to inconsistent layout compared to other signing flows.
Fix: Updated signature layout calculation to correctly position the signature and timestamp, removing unintended spacing and ensuring consistent formatting.
4557947 Summary: Checkbox fields can appear unchecked in the finalized signed PDF when using library templates, even though the signer selected them. The issue can occur when checkbox fields are misconfigured or use certain hidden values, which leads to incorrect interpretation of the selected state during document processing.
Fix: Updated checkbox processing to correctly interpret hidden values and preserve selected states, ensuring checkbox selections are retained in the signed document.
4558295 Summary: Required radio button values can be missing in the finalized signed PDF. The issue can occur when field values contain special characters (for example, quotes or symbols) that are not properly processed, leading to the selected value not rendering in the document output.
Fix: Updated field value processing to correctly handle special characters, ensuring selected values are preserved and displayed in the signed PDF.
4558307 Summary: Form fields can ignore configured font sizes and render inconsistently in generated agreements. The issue can occur in multiline fields when the document processing engine adjusts font size to prevent text clipping, overriding fixed font size settings. 
Fix: Updated font rendering behavior so multiline fields respect fixed font size settings, preventing unintended resizing and ensuring consistent output.
4558554 Summary: Signers can complete agreements without interacting with the Signature Block. The issue can occur in Gibson-enabled accounts when the Signature Block is not properly rendered or enforced during signing, allowing completion with only the Signature Field.
Fix: Updated signature rendering and validation logic to ensure Signature Blocks are correctly displayed and required before agreement completion.
4558725 Summary: Text tags can fail to render or convert into form fields during preview. The issue can occur when the uploaded PDF contains unsupported or invalid elements (for example, null annotations or existing fillable fields), which prevent text tag processing from completing successfully.
Fix: Updated text tag processing to handle PDFs with invalid or unsupported annotations more reliably, allowing fields to be generated as expected during preview.
4559285 Summary: Phone authentication can fail for certain regions when selecting a country code in the new request signature experience. The issue occurs when the UI displays an incomplete or incorrect country code (for example, “+1” instead of “+1246” for Barbados), which can cause validation errors when sending the agreement.
Fix: Updated country code handling to use the correct full dialing codes, ensuring phone numbers are validated and processed correctly in the new experience.
4560119 Summary: Text in form fields can appear misaligned or overlap in generated agreements. The issue can occur in multiline text fields when rendering differences are introduced by the document processing engine, leading to layout shifts compared to the authoring view.
Fix: Updated text rendering and layout handling for multiline fields to improve alignment and prevent overlapping, ensuring more consistent display between authoring and final documents
4562058 Summary: The recipient name can remain unchanged when selecting a different email from the address book on the Send page. The issue occurs because the name field does not refresh when a new contact is selected, causing a mismatch between the displayed name and selected email. 
Fix: Updated recipient selection behavior so the name field always refreshes when a new contact is selected, ensuring the name and email remain synchronized.
4566339 Summary: Incorrect checkbox states can appear when processing static XFA PDFs with malformed field values. The issue can occur when unsupported or invalid XFA data (for example, string values in numeric fields) is handled inconsistently, particularly in Gibson-enabled environments where checkbox defaults can be misinterpreted.
Fix: Updated XFA handling in the document processing pipeline to normalize or ignore malformed values more consistently, preventing incorrect checkbox states and aligning behavior across environments.
4567278 Summary: Read-only text fields can fail to appear on the signing page when dynamic participants are enabled. The issue occurs due to field rendering inconsistencies during participant resolution, which can cause non-editable fields to be omitted from the signer view.
Fix: Updated field rendering logic for dynamic participants to ensure read-only fields are consistently included and displayed during signing.
4568023 Summary: Image and Mobile signature options can fail to appear in web forms during signing. The issue can occur due to inconsistent loading of signature options in the web form entry flow, where certain signing methods are not surfaced until the session is reloaded or accessed through an alternate path.
Fix: Updated web form signing initialization to consistently load all enabled signature options, ensuring Image and Mobile methods are available across all entry points.

Adobe Acrobat Sign release v17.1.1

Production deployment: June 16, 2026

GovCloud deployment: June 18, 2026

Improved Functionality

  • Recipient Filter in Reporting – Add recipient-based filtering to reports and data exports.
    Add a Recipient filter to modern Reporting for Agreement and Transaction reports and Data Exports. Administrators can filter by recipient email to return all agreements that include the specified recipient, regardless of role or signing order. The filter supports autocomplete and multi-select behavior consistent with the existing Sender filter and applies to both visual reports and CSV exports.
  • Inline Document Editing During Authoring – Edit document text directly in the authoring experience
    Senders can edit document text directly in the authoring environment without downloading and re-uploading the file. The Edit Document option preserves existing fields and agreement configuration, reducing disruption during pre-send updates. Editing is available only while the agreement is in a draft state and is not available after the agreement is sent.

    In-line document editing is to be released on a rolling schedule, as referenced in the technical notification.

    This feature is enabled by default for all users in supported accounts, allowing senders to edit documents that are sent through Request Signature.  Account and group admins can disable document editing through the Send Settings. 

    In-line document editing is not available in Acrobat Sign for Government or for accounts using the legacy user management system.

Experience Changes

  • Bio-Pharma (CFR) Support in Modern eSign – Adds signing reason capture and enforced sign-time reauthentication
    Bio-Pharma signing settings, including signing reason capture and sign-time reauthentication, are now supported in the modern eSign experience. Agreements using these settings no longer fall back to the classic signing experience. No customer action or admin setting change is required.

REST API/Webhook Updates

API and webhook updates for this release can be found in the Acrobat Sign API documentation.

  • Suppress agreement notifications via API – Add granular control over recipient messaging
    Using the REST v6 POST /agreements API, control which notifications are sent when creating agreements by suppressing specific email types for participants, CCs, or the sender. This reduces unnecessary emails and supports cleaner, more controlled signing experiences in integrated workflows.

    Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: REST v6 API
     

Resolved Issues

Issue Description
4545881 Summary: Signers using Download and Sign in Acrobat could receive an "Adobe Acrobat Sign cannot recognize" error after uploading a digitally signed PDF when the Digital ID certificate did not include an expected signer name value, such as commonName, givenName, or pseudonym. The agreement could not be completed even though the signed PDF was uploaded.
Fix: Acrobat Sign now handles Digital ID certificates with missing signer name values without throwing an error during the upload validation process. Signing can complete successfully, though the signer name may not display if the certificate does not include one.
4547132 Summary: When agreements were created through the POST /agreements API request and securityOption was set to null, external recipients could be assigned None as the authentication method even when account settings required Email OTP as the default authentication method. Internal recipient authentication was applied correctly, but external recipient authentication was not.
Fix: Acrobat Sign now correctly applies the account-configured default authentication method when API-created agreements include recipients with a null securityOption value. External recipients now receive the required default authentication method instead of None.
4553171 Summary: In developer accounts using the new Create Template experience, reusable templates could show the [DEMO USE ONLY] prefix on the Manage page, but the prefix was not available when editing the template name. Users could not remove the prefix from the existing template name unless they replaced the full name or switched to the classic template experience.
Fix: The new Create Template experience now keeps the reusable template name and agreement name aligned for developer account watermark behavior. Users can edit the full template name, including the [DEMO USE ONLY] prefix, without switching to the classic experience
4556731 Summary: After a sender replaced a recipient with themselves and then delegated the agreement to another recipient, the agreement returned to In progress, but the Upload Signed Document option remained unavailable. This prevented the sender from uploading a signed copy for eligible in-progress agreements after that delegation sequence.
Fix: Acrobat Sign now correctly restores the Upload Signed Document option after a recipient is replaced with the sender and then delegated to another recipient, when the agreement is eligible for signed document upload.
4557576 Summary: When a signature block was assigned to a recipient group with multiple members, the email value in the signature block could be cut off instead of displaying clearly. This could make the recipient group information difficult to read before a group member completed signing. 
Fix: Acrobat Sign now displays recipient group email information in signature blocks without abruptly cutting off the visible text. Long recipient group email values are handled so the displayed information remains readable within the signature block. 
4561898 Summary: Some recipients could encounter a server error after authentication or when finalizing signing for agreements that used specific PDF documents. The failure was caused by an issue handling PDF structure data during signed document generation, which prevented the signer from completing the agreement.
Fix: Acrobat Sign now handles PDF structure data more defensively during signing and document generation. The fix prevents structure tree conflicts from blocking completion, allowing recipients to authenticate, sign, and complete affected agreements successfully. 
4562041 Summary: Some webhook notifications could be delayed or fail to publish when Acrobat Sign received an internal server error while building the webhook payload. For the affected account, several events on March 19, 2026, were impacted, including AGREEMENT_WORKFLOW_COMPLETED and other agreement events, which delayed downstream customer workflows
Fix: Acrobat Sign now handles webhook payload generation failures more reliably so failed internal responses do not get cached in a way that blocks or delays event delivery. The fix was validated through regression testing and is intended to prevent affected webhook events from being delayed by the same payload-generation failure path. 
4562458 Summary: Recipients could receive an Invalid agreement ID specified error when opening a signing URL for agreements sent to inactive users on claimed account domains, when recipient authentication such as Email OTP or password authentication was used. The signing flow created a single-use pending user to continue the signing process, but the signing information request could read stale agreement data that did not include the newly created participation, blocking access until the signing link was regenerated or the data refreshed.
Fix: Acrobat Sign now retrieves current agreement participation data when opening authenticated signing URLs in this workflow. This prevents stale cached agreement data from causing invalid agreement ID errors and allows recipients to complete authentication and access the e-sign page successfully.
4566894 Summary: Some expired agreements created from multiple templates could not be copied from the Manage page. When users selected Create a Copy, the copy operation failed with Unable to copy agreement. Please try again later because template access validation failed while copying agreements with more than one template. 
Fix: Acrobat Sign now correctly validates template information when copying agreements that were created from multiple templates. Affected agreements can now be copied without triggering the backend session error.
4568666 Summary: Webhook notifications could intermittently fail for agreements that included witness participants without an assigned user ID. The core agreement event was created, but webhook payload generation could fail when participant data was processed in an unpredictable order, causing some expected webhook events to not be delivered after AGREEMENT_CREATED.
Fix: Acrobat Sign now handles webhook participant data with missing user IDs safely during payload generation. This prevents witness placeholder participants from causing webhook payload failures and allows expected agreement webhook events to be delivered consistently.
4571682 Summary: In some agreements where Power Automate modified recipient groups before a later form filler’s turn, read-only fields could fail to appear for the subsequent form filler. After the form filler completed their editable fields, those fields could also disappear from the agreement, even though the fields were still assigned correctly and marked visible through the API.
Fix: Acrobat Sign now preserves field visibility for subsequent recipient groups after recipient group membership changes. Read-only fields, signature blocks, dropdown selections, and other completed field values remain available for later recipients and in the downloaded PDF for the fixed scenarios.
4571845 Summary: In-person signing can fail with a server error when the in-person signer email matches an existing user account on a different shard, preventing the agreement from being completed.
Fix: Updated in-person signer processing to correctly create and use a temporary signer record, preventing cross-shard user conflicts and allowing the signing session to complete successfully.
4573019 Summary: Recipient group order can be calculated incorrectly after dynamic participant updates that remove a mix of recipients and recipient groups, causing the remaining group to display the wrong routing order.
Fix: Updated participant order recalculation so recipient groups retain the correct order after complex dynamic participant removals, including cases where a group is reduced to a single remaining member.
4572455 Summary: Some signers could see an Unhandled Error or Something went wrong message after completing signing, even though the signature was applied and the agreement advanced to the next recipient. The issue occurred when dynamic participants were enabled and the signing flow tried to prepare the document for the next signer but could not find the expected signed document version. 
Fix: Acrobat Sign now checks for the correct signed document version when preparing an agreement for the next signer. This prevents the signing flow from showing an error after a successful signature when dynamic participants are enabled.

Adobe, Inc.

Get help faster and easier

New user?

Quick links

View all your plans Manage your plans
View quick links
Hide quick links

Legal Notices    |    Online Privacy Policy