Acrobat Sign supports a powerful integration pattern that lets you embed the signing experience directly inside your own application. This article explains how signer identity and authentication work in that pattern, what Acrobat Sign records in the audit trail, and what your application is responsible for — so you can design integrations that are secure, legally sound, and appropriate for your use case.

How Embedded Signing Works

In a standard Acrobat Sign workflow, Adobe sends the signing invitation by email, and the signer authenticates before they can access the document. In an embedded workflow, your application takes on that role.

The flow works like this:

Your application creates an agreement via the API and specifies who the signers are.
Your application calls GET /agreements/{agreementId}/signingUrls to retrieve a signing URL for each participant.
Your application presents that URL to the signer — typically by embedding the signing page in an iframe or a webview inside your portal.
The signer completes signing inside your application. Acrobat Sign records the event in the agreement's audit trail.

Note

In plain terms, authentication responsibility in embedded signing is shared. Acrobat Sign authenticates signers when they use Adobe-provided methods (such as Acrobat Sign login or Email OTP). When you retrieve a signing URL and present it in your own application, your application is responsible for verifying the signer's identity before giving them access to that URL.

Who Is Responsible for Authenticating the Signer

This is the most important concept to understand when building an embedded signing integration.

When a signer accesses the signing page through a URL your application retrieved, Acrobat Sign does not independently verify that the person opening the URL is the intended signer. The signing URL itself is not tied to a login — it is a direct link to the signing session for that participant.

This is by design. The integration model assumes that your application controls the session and has already established who the user is. Just as a user who is logged into your portal to access their account is understood to be authenticated by your system, a user who reaches the signing page through your portal is understood to have been verified by you.

Note

This pattern is widely used across industries — financial services firms presenting agreements in advisor portals, HR systems surfacing onboarding documents in employee dashboards, and service management platforms embedding approvals in existing workflows are all common examples.

It is also how every other major e-signature platform supports API-based integrations.

There are two ways to satisfy this responsibility:

Option A — Use your own application's authentication

If your signers are already authenticated users of your application, that authentication serves as the identity verification. Examples:

An employee accesses a signing request through your HR system after logging in with their corporate credentials.
A client signing a contract after authenticating in your customer portal with their account credentials and a second factor.
An advisor completing a form inside your platform after passing your firm's identity verification step.

In these cases, your application's authentication records — login events, session tokens, MFA logs — serve as evidence of the signer's identity. These records should be retained alongside the Acrobat Sign audit trail.

Option B — Use Acrobat Sign's built-in authentication methods

You can configure authentication on the agreement itself so that Acrobat Sign challenges the signer to prove their identity at the point of signing. For example, the following methods establish a verified link between the signer and their Acrobat Sign profile:

Method	How it works
Adobe ID	The signer must log in to their Adobe account before they can sign. Equivalent to the identity assurance of an authenticated portal session.
One time password	A one-time code is sent to the signer's email address. Signing requires entering that code, confirming delivery to the right inbox.

Other authentication methods available in Acrobat Sign — such as passwords — are configured by the sender rather than tied to the signer's identity and are suitable for access control scenarios but do not independently establish that the signer is the person they claim to be.

What the Audit Trail Records — and What It Does Not

Acrobat Sign maintains a tamper-evident audit trail for every agreement. For embedded signing workflows, it is important to understand both what the audit trail captures and where its scope ends.

What Acrobat Sign records

The creation of the agreement and who sent it.
That the signing URL was retrieved via the API, and by which sender account.
That a signature was applied, and which participant's signing step was completed.
The timestamp and, if enabled, the IP address of the signing event.
Any Adobe-provided authentication steps that were completed (e.g., Email OTP verified).

What the audit trail does not record

Authentication steps that happened inside your application before the signer reached the signing URL.
The identity verification method your application used — that information lives in your own systems.

Tip

Practical guidance: For embedded signing workflows, the Acrobat Sign audit trail should be read together with your application's own authentication and access logs. Together, these records provide a complete picture of who signed and how their identity was established. Neither record alone tells the full story.

The Key Risk to Understand

Because the signing URL is retrieved by the sender's system, the sender — or anyone operating with the sender's API credentials — technically has access to that URL before it is presented to the signer.

In a well-designed integration, the signing URL is immediately surfaced to the authenticated signer, and the sender's system does not retain or use it beyond that. But if an integration is not carefully designed, or if access controls are insufficient, there is a possibility that someone other than the intended signer could access the signing URL.

This is not a vulnerability in Acrobat Sign — it is a consequence of the integration model, and it is manageable through good integration design. The steps below describe how to address it.

Designing a Trustworthy Embedded Signing Integration

The following practices are recommended for all integrations that use the signingUrls API.

Always authenticate the signer before surfacing the signing URL

The signing URL should only be presented to a user who has been verified by your application. Do not expose signing URLs on unauthenticated pages, in unprotected links, or in emails sent without access controls. The signer should reach the signing page only after your application has confirmed who they are.

Keep the signing URL short-lived and scoped to the signer's session

Retrieve the signing URL as close to the moment of use as possible. Avoid storing signing URLs in logs, databases, or caches where they could be accessed by unintended parties. Pass the URL directly to the signer's session rather than persisting it.

Separate the sender role from the signing workflow

Where your architecture permits, design your system so that the component responsible for creating agreements and retrieving signing URLs does not have the ability to present those URLs to itself. The URL should flow only toward the authenticated signer, not back to the sender's session.

Retain your authentication records

Your application's login and authentication logs are the evidence that the correct person signed. Retain these records in line with your document retention policies and ensure they can be correlated with the Acrobat Sign audit trail if needed for compliance or legal purposes.

Enable IP address recording in the audit trail

Acrobat Sign can capture the IP address from which each signature action was taken. This adds a useful data point to the audit trail that can help with attribution in the event of a dispute. This setting can be enabled by your account administrator.

Consider using Acrobat Sign authentication methods for higher-assurance scenarios

For agreements where the stakes are higher — legal contracts, financial authorizations, regulated documents — consider configuring Acrobat Sign's Email OTP or Acrobat Sign Authentication on the agreement. This shifts identity verification into the signing flow itself and records it directly in the audit trail, giving you a stronger evidentiary record without relying solely on your application's logs.

For more information on configuring authentication methods for your agreements, see the Acrobat Sign API documentation and the Authentication Methods help article.

Get help faster and easier

New user?

Understanding signer identity in API-based signing workflows