Topic starter
25/06/2026 12:19 am
TL;DR: Public eSignature links can expose contracts and personal data if the signer is not authenticated, and AI-enabled scanning of exposed URLs increases the attack surface, according to OneSpan. The real control question is no longer convenience versus security, but whether the signing workflow proves identity before access is granted.
Editorial analysis by NHI Mgmt Group, based on content published by OneSpan: “Comment protéger vos adresses URL de signature électronique contre les cyberattaques”.
Key questions
Q: What breaks when eSignature links can be opened without signer authentication?
A: The workflow stops proving who accessed the document and becomes vulnerable to forwarding, interception, and automated URL discovery.
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: How should security teams choose the right signer authentication method?
A: Start with the business risk of the transaction, then choose the least disruptive method that still proves identity to an acceptable level.
Practitioner guidance
- Require signer authentication before document access Make the signing ceremony inaccessible until the recipient proves identity with a method appropriate to the transaction’s risk and legal weight.
- Separate embedded signing from public-link workflows Use embedded signing when the application session already authenticates the user, and reserve public links only for cases where added authentication is enforced.
- Map authentication strength to document sensitivity Apply stronger methods such as passkeys, certificates, or identity proofing for contracts that contain personal data or create higher legal exposure.
Bottom line: Public eSignature links can become bearer-style access paths when signer identity is not verified before the ceremony opens.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 9:13 am
Bearer-link signing is now an identity problem, not just a document-delivery problem. When access to a signing ceremony depends on possession of a URL, the link itself functions like a credential. That shifts eSignature governance into the same control logic that applies to other bearer secrets: who can present it, who can intercept it, and what identity proof exists before disclosure. Practitioners should stop treating signature links as neutral transport and start treating them as access gates.
A question worth separating out:
Q: What is the difference between embedded signing and public-link signing?
A: Embedded signing requires the user to authenticate inside the application before the transaction is reached, while public-link signing sends a standalone URL that must carry its own access control. The first inherits the application’s session trust, while the second needs explicit signer authentication at the link itself.
👉 Read our full editorial: Electronic signature URL authentication is now a control point