What's New
Get Started
- Quick start guide for administrators
- Quick start guide for users
- For Developers
- Video tutorial library
- FAQ
Administer
- Admin Console Overview
- User Management
- Adding users
- Create function-focused users
- Check for users with provisioning errors
- Change Name/Email Address
- Edit a user's group membership
- Edit a user's group membership through the group interface
- Promote a user to an admin role
- User Identity Types and SSO
- Switch User Identity
- Authenticate Users with MS Azure
- Authenticate Users with Google Federation
- Product Profiles
- Login Experience
- Account/Group Settings
- Settings Overview
- Global Settings
- Account tier and ID
- New Recipient Experience
- Self Signing Workflows
- Send in Bulk
- Web Forms
- Custom Send Workflows
- Power Automate Workflows
- Library Documents
- Collect form data with agreements
- Limited Document Visibility
- Attach a PDF copy of the signed agreement
- Include a link in the email
- Include an image in the email
- Files attached to email will be named as
- Attach audit reports to documents
- Merge multiple documents into one
- Download individual documents
- Upload a signed document
- Delegation for users in my account
- Allow external recipients to delegate
- Authority to sign
- Authority to send
- Power to add Electronic Seals
- Set a default time zone
- Set a default date format
- Users in Multiple Groups (UMG)
- Group Administrator Permissions
- Replace recipient
- Audit Report
- In Product Messaging and Guidance
- Accessible PDFs
- New authoring experience
- Healthcare customer
- Account Setup
- Add logo
- Customize company Hostname/URL
- Add company name
- Post agreement URL redirect
- Signature Preferences
- Well formatted signatures
- Allow recipients to sign by
- Signers can change their name
- Allow recipients to use their saved signature
- Custom Terms of Use and Consumer Disclosure
- Navigate recipients through form fields
- Decline to sign
- Allow Stamps workflows
- Require signers to provide their Title or Company
- Allow signers to print and place a written signature
- Show messages when e-signing
- Require signers to use a mobile device to create their signature
- Request IP address from signers
- Exclude company name and title from participation stamps
- Digital Signatures
- Electronic Seals
- Digital Identity
- Report Settings
- New report experience
- Classic report settings
- Security Settings
- Single Sign-on settings
- Remember-me settings
- Login password policy
- Login password strength
- Web session duration
- PDF encryption type
- API
- User and group info access
- Allowed IP Ranges
- Account Sharing
- Account sharing permissions
- Agreement sharing controls
- Signer identity verification
- Agreement signing password
- Document password strength
- Block signers by Geolocation
- Phone Authentication
- Knowledge-Based Authentication (KBA)
- Allow page extraction
- Document link expiration
- Upload a client certificate for webhooks/callbacks
- Timestamp
- Send settings
- Show Send page after login
- Require recipient name when sending
- Lock name values for known users
- Allowed recipient roles
- Allow e-Witnesses
- Recipient groups
- Required fields
- Attaching documents
- Field flattening
- Modify Agreements
- Agreement name
- Languages
- Private messages
- Allowed signature types
- Reminders
- Signed document password protection
- Send Agreement Notification through
- Signer identification options
- Content Protection
- Enable Notarize transactions
- Document Expiration
- Preview, position signatures, and add fields
- Signing order
- Liquid mode
- Custom workflow controls
- Upload options for the e-sign page
- Post-sign confirmation URL redirect
- Message Templates
- Bio-Pharma Settings
- Workflow Integration
- Notarization Settings
- Payments Integration
- Signer Messaging
- SAML Settings
- SAML Configuration
- Install Microsoft Active Directory Federation Service
- Install Okta
- Install OneLogin
- Install Oracle Identity Federation
- SAML Configuration
- Data Governance
- Time Stamp Settings
- External Archive
- Account Languages
- Email Settings
- Migrating from echosign.com to adobesign.com
- Configure Options for Recipients
- Guidance for regulatory requirements
- Accessibility
- HIPAA
- GDPR
- 21 CFR part 11 and EudraLex Annex 11
- Healthcare customers
- IVES support
- "Vaulting" agreements
- EU/UK considerations
- Download Agreements in Bulk
- Claim your domain
- Report Abuse links
Send, Sign, and Manage Agreements
- Recipient Options
- Cancel an email reminder
- Options on the e-signing page
- Overview of the e-sign page
- Open to read the agreement without fields
- Decline to sign an agreement
- Delegate signing authority
- Restart the agreement
- Download a PDF of the agreement
- View the agreement history
- View the agreement messages
- Convert from an electronic to a written signature
- Convert from a written to an electronic signature
- Navigate the form fields
- Clear the data from the form fields
- E-sign page magnification and navigation
- Change the language used in the agreement tools and information
- Review the Legal Notices
- Adjust Acrobat Sign Cookie Preferences
- Send Agreements
- Authoring fields into documents
- In-app authoring environment
- Create forms with text tags
- Create forms using Acrobat (AcroForms)
- Fields
- Authoring FAQ
- Sign Agreements
- Manage Agreements
- Manage page overview
- Delegate agreements
- Replace Recipients
- Limit Document Visibility
- Cancel an Agreement
- Create new reminders
- Review reminders
- Cancel a reminder
- Access Power Automate flows
- More Actions...
- How search works
- View an agreement
- Create a template from an agreement
- Hide/Unhide agreements from view
- Upload a signed agreement
- Modify a sent agreement's files and fields
- Edit a recipient's authentication method
- Add or modify an expiration date
- Add a Note to the agreement
- Share an individual agreement
- Unshare an agreement
- Download an individual agreement
- Download the individual files of an agreement
- Download the Audit Report of an agreement
- Download the field content of an agreement
- Audit Report
- Reporting and Data exports
- Overview
- Grant users access to reporting
- Report charts
- Data Exports
- Rename a report/export
- Duplicate a report/export
- Schedule a report/export
- Delete a report/export
- Check Transaction Usage
Advanced Agreement Capabilities and Workflows
- Webforms
- Reusable Templates (Library templates)
- Transfer ownership of web forms and library templates
- Power Automate Workflows
- Overview of the Power Automate integration and included entitlements
- Enable the Power Automate integration
- In-Context Actions on the Manage page
- Track Power Automate usage
- Create a new flow (Examples)
- Triggers used for flows
- Importing flows from outside Acrobat Sign
- Manage flows
- Edit flows
- Share flows
- Disable or Enable flows
- Delete flows
- Useful Templates
- Administrator only
- Agreement archival
- Webform agreement archival
- Save completed web form documents to SharePoint Library
- Save completed web form documents to OneDrive for Business
- Save completed documents to Google Drive
- Save completed web form documents to Box
- Agreement data extraction
- Agreement notifications
- Send custom email notifications with your agreement contents and signed agreement
- Get your Adobe Acrobat Sign notifications in a Teams Channel
- Get your Adobe Acrobat Sign notifications in Slack
- Get your Adobe Acrobat Sign notifications in Webex
- Agreement generation
- Generate document from Power App form and Word template, send for signature
- Generate agreement from Word template in OneDrive, and get signature
- Generate agreement for selected Excel row, send for review and signature
- Custom Send workflows
- Share users and agreements
Integrate with other products
- Acrobat Sign integrations overview
- Acrobat Sign for Salesforce
- Acrobat Sign for Microsoft
- Other Integrations
- Partner managed integrations
- How to obtain an integration key
Acrobat Sign Developer
- REST APIs
- Webhooks
Support and Troubleshooting
Content Protection enables authentication-based security to view the contents of completed agreements.
Overview
Content Protection applies an authentication-based security layer to view an agreement after it has been completed. This protection applies to all agreements regardless of how they were created (through the user interface, REST API, SOAP API, Send in Bulk, Custom Workflows, etc. Every agreement is in scope.)
Protection can be applied passively by enabling the inherited protection method. When enabled, all agreements sent from the enabled group must pass an authentication challenge before they can be viewed.
Additionally, senders can be empowered to explicitly configure their agreement to apply protection or not. This method embeds the configuration into the metadata of the agreement and can not be modified once the agreement is sent.
When trying to view an agreement with protection enabled, the participant is challenged to authenticate, either by using the original authentication method or optionally using a one-time password delivered to the participant's email address.
Supported authentication types:
- Adobe Acrobat Sign authentication
- Password
- Phone authorization
- OTP via Email (OTPvEM)
- Knowledge-Based Authentication (KBA) (with required name enabled)
Unsupported authentication types:
- None (Email)
- Knowledge-Based Authentication (KBA) (without required name enabled)
- Government ID
- Digital Identity
Unsupported authentication methods use the OTP via Email fallback method when enabled.
How it's used
There are two methods by which content protection can be applied to an agreement:
- Inherited protection allows the group-level setting (whether explicitly set or inherited from the account) to dictate the content protection value for all agreements sent from the group. Changing the setting immediately impacts if viewing the agreement is subject to the content protection authentication challenge.
- Embedded protection requires the user to explicitly choose if content protection should be embedded into the transaction metadata. The protection values are immutable once the agreement is sent. Inherited protection values don't impact agreements that have embedded the content protection defined.
Both application methods have controls to discretely enable or disable internal and external participants.
- Internal participants are defined as any participant (as identified by their email) who is within the authority of the Acrobat Sign account. If the email is on your user list, they are internal.
- External participants include every email that isn't an internal participant.
The authentication method used to grant access to view the agreement is based on the original authentication method used during the signature process.
To overcome issues like participants with no authentication method, unsupported authentication methods, and CC'd parties, there is an option to enable the Email One-Time Password via Email authentication method as an alternative vehicle to grant access. This option requires the participant to access their email, retrieve a passcode, and enter it in the challenge field.
If content protection is enabled, and the alternative Email One Time Password authentication method is not enabled, participants that use KBA, Government ID, or don't have an authentication method will receive a message that they cannot access the agreement.
This includes CC'd parties and anyone to whom the agreement is shared.
For recipients with a defined signature authentication method, the experience changes depending on that method:
- Password, Phone, and Acrobat Sign authentication methods use the same method (leveraging the same password and phone number).
- OTP via Email, Knowledge-Based Authentication, and Government ID leverage the OTP via Email method (provided it's enabled).
- If OTP via Email is disabled, then an error is presented, and the participant is denied a view of the agreement.
Configuration
Availability:
Content Protection is available for enterprise license plans only.
Configuration scope:
The feature can be enabled at the account and group levels.
The controls for this feature can be assessed by navigating to Account Settings > Send Settings > Content Protection
The configurable options are:
The inherited protection controls are defined at the group level and apply to all agreements that don't have embedded content protection defined by the sender.
One control exists for internal users, and a separate control exists for external users. Depending on your agreement strategy, one, both, or neither control can be enabled.
When configuring the controls, a challenge window appears to ensure that you want to enforce content protection. This type of protection is predicated on the control being enabled and is not a persistent form of protection should the control be disabled.
Once enabled, inherited content protection applies to all new and existing agreements.
When a participant attempts to view an agreement without embedded protection, the relevant control (internal or external) is referenced in real-time to determine if a challenge is required. When authentication is required, the participant is presented with a challenge page to complete the authentication process. Once the challenge is successfully completed, the agreement is presented.
If the challenge is unsuccessful, the participant can try again, up to the number of failed attempts allowed.
If the participant fails to authenticate more than the failure threshold allows, they are presented with an error message and are blocked from trying again for 24 hours.
Successfully authenticating to view the agreement is also limited to a configurable number of times per 24-hour period.
Any attempt to view an agreement more than the defined number of times presents an error message:
The error message is the same as the threshold for the number of successful views of the agreement. This is an intentional security measure.
Embedded protection requires that the sender configure the protection when the agreement is configured. One control exists for internal users, and a separate control exists for external users. Depending on your agreement strategy, one, both, or neither control can be enabled.
When enabling embedded protection for internal or external participants, a challenge is presented to ensure that you want to add this configuration to the sender's composition process and that you understand that whatever the sender configures is persistent for the agreement's lifetime. There is no option to add or remove this protection at a later date.
With embedded content protection enabled, a required drop-down field is inserted into the classic Send page for each control that is enabled. The sender must select Enabled or Disabled for each drop-down.
Failure to select an option triggers an error when the sender attempts to send the agreement.
If an agreement has defined the embedded protection as Disabled, content protection is denied, even if the inherited protection is enabled.
The setting defined in the agreement metadata is the absolute truth.
When a participant attempts to view an agreement, the agreement metadata is referenced to determine if an authentication check is required. If authentication is required, the participant is presented with a challenge page to complete the authentication process. Once the challenge is successfully completed, the agreement is shown.
If the challenge is unsuccessful, the participant can try again, up to the number of failed attempts allowed.
If the participant fails to authenticate more than the failure threshold allows, they are presented with an error message and are blocked from trying again for 24 hours.
Successfully authenticating to view the agreement is also limited to a configurable number of times per 24-hour period.
Any attempt to view an agreement more than the defined number of times presents an error message:
The error message is the same as the threshold for the number of successful views of the agreement. This is an intentional security measure.
The option to use an alternate authentication method is strongly encouraged unless you intend to utterly deny CC'd parties and you don't believe that there are any agreements with no authentication.
Enabling content protection will deny all attempts to view the agreement by anyone who has no authentication method available (including everyone using Email as a type of authentication).
The Email OTP is a free service with no discernable downside when enabled.
When Email OTP is not enabled, and participants with no authentication attempt to view the agreement, an error is returned:
This threshold setting only applies to the One-Time Password via Email, Knowledge-Based Authentication, and Phone authentication methods.
This setting defines the number of times an individual participant can access the agreement before they are locked out of the agreement for 24 hours.
After 24 hours, the participant can access the content again, up to the number of successful authentications defined.
When a user exceeds the access threshold, they are presented with an error banner:
This threshold setting only applies to the One-Time Password via Email, Knowledge-Based Authentication, and Phone authentication methods.
This setting defines the number of times an individual participant can fail to authenticate before they are locked out of the agreement for 24 hours.
After 24 hours, the participant can attempt to access the content again, up to the number of failed attempts defined.
When a user exceeds the failed attempts threshold, they are presented with an error banner:
The error message is the same as the threshold for the number of successful views of the agreement. This is an intentional security measure.
Best practices
It is strongly recommended that you enable One-Time Password via Email authentication if you intend to use content protection. There are agreement participants who don't have authentication methods. This free service allows an option for them to view the agreement with very little demand on their time or understanding of the process.
Most enterprise customers can likely benefit from the inherited content protection method.
- Vetting the participant's access to the agreement, even when no authentication was initially required, is generally a good idea. It offers little friction to the participant and provides security when a viewing link is accidentally forwarded in an email.
- Inherited protection also has the advantage of being dynamically applied, meaning if something breaks a downstream process, the setting can be turned off, and there's no persistent damage.
- Customers who employ authentication methods like password and phone authentication must contend with the password and phone number long term. Being able to turn off content protection provides a method of access when phone numbers change, or passwords are forgotten.
Requiring a sender to configure the embedded content protection should be carefully considered. There are certainly some processes that demand this granular level of control, but keep in mind that:
- Every agreement sent from the group must be configured explicitly by the sender; this adds process and invites eventual human error.
- There is no option to define the default values. Senders must explicitly configure the enabled drop-downs.
- Embedded content protection has no method to be changed after the agreement is sent.
- Using phone and password authentication methods presents the opportunity to be locked out from viewing the agreement if the password is lost or the phone number is changed.