Notifications
Clear all
Topic starter
25/06/2026 12:19 am
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
25/06/2026 9:12 am
Signing URL exposure is a transaction identity problem, not a document delivery problem. The security failure begins when organisations assume the link itself can stand in for signer verification. That assumption is weaker than the controls used for login, privileged access, or API access, even though the business consequences can be just as severe. The practitioner conclusion is simple: the workflow must prove who is signing, not merely who clicked.
A few things that frame the scale:
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
- The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, which is why bearer-link style access deserves the same scrutiny as other exposed credentials.
A question worth separating out:
Q: When should teams use stronger authentication for signing workflows?
A: Teams should use stronger authentication when the signing transaction carries legal, financial, or high-PII risk, or when the link may travel through multiple systems before reaching the recipient. Higher assurance is warranted whenever impersonation would create material harm.
👉 Read our full editorial: eSignature signing URLs need authentication, not trust by default
