Signing URLs and authentication gaps: what IAM teams need to know

TL;DR: Unsigned eSignature links are a straightforward path to PII exposure, impersonation risk, and enforceability problems when public signing URLs are accessible without signer authentication, according to OneSpan. The governance issue is not the document workflow itself, but the assumption that possession of a link is enough to prove the right signer.

NHIMG editorial — based on content published by OneSpan: eSignature security tip, How to protect your signing URLs against cyberattacks

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

Questions worth separating out

Q: How should security teams protect public eSignature signing URLs?

A: Security teams should require signer authentication before any document can be opened, because a public signing URL is a bearer link, not proof of identity.

Q: Why do public signing links create identity risk?

A: Public signing links create identity risk because possession of the URL often becomes the only gate to the transaction.

Q: What do organisations get wrong about eSignature authentication?

A: The common mistake is assuming that the communication channel proves identity.

Practitioner guidance

• Classify signing URLs by exposure model Separate embedded application sessions from public link workflows, then require different controls for each.
• Bind signature access to signer authentication Require a verified identity step before any document is shown, especially for contracts, mortgage files, and account-opening flows that carry PII.
• Match assurance to document risk Use stronger methods for higher-risk transactions, such as passkeys, certificates, or government credential systems, and reserve lighter methods for lower-risk use cases.

What's in the full article

OneSpan's full article covers the operational detail this post intentionally leaves for the source:

• A practical breakdown of when signing URLs are exposed in B2E, B2C, and partner workflows.
• A full list of authentication methods, including security questions, KBA, SMS OTP, certificates, passkeys, and government credentials.
• Guidance on matching authentication strength to signature risk and completion-rate tradeoffs.
• Implementation context for automated eSignature workflows via API versus manual one-off requests.

👉 Read OneSpan's guidance on securing eSignature signing URLs with authentication →

Signing URLs and authentication gaps: what IAM teams need to know?

Explore further

View Full Forum →  |  NHI Foundation Course →