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.
