Links and text messages are not signature types

A contract can be made available for signing through a link in an email, a customer portal, a messaging service or an SMS. These channels do not determine the type of electronic signature created. Their primary function is to give the signer access to the signing process.

The legal and technical classification depends on other characteristics:

• How is the person’s identity or access verified?
• How is the signature linked to the document?
• Can subsequent changes be detected?
• Which logs and timestamps are retained?
• Which signature level is required for the transaction?

A signature opened from a text message is therefore not automatically more secure or legally stronger than one accessed through an email link. Conversely, a simple link is not necessarily insecure. What matters is the design of the complete workflow.

What signing by link means in practice

In a link-based process, the recipient receives a URL leading to a browser-based signing interface. The link may be delivered by email, through a portal or by another channel. After opening it, the recipient sees the document, any required fields and the intended signing action.

Typical advantages include:

• The contract and explanatory information can be provided in the same email.
• The process can work on desktops, tablets and smartphones.
• Multiple documents and attachments can be presented clearly.
• The sender, subject line and accompanying message fit established business communication.
• Recipients can review the contract on a larger screen before signing.

An email link is useful, for example, for a B2B proposal that must be reviewed internally before an authorised person signs it. However, that same ability to forward an email becomes a risk if anyone possessing the link can complete the process.

Links should therefore have a limited validity period and, where possible, be bound to a particular transaction or recipient. Depending on the required protection, the workflow may add a one-time code, login to a customer account or an identity verification step.

What changes when SMS is the delivery channel

An SMS usually also contains a link to a browser-based signing process. The key difference is the delivery channel: a mobile number is used instead of an email address.

SMS can be suitable when recipients mainly work on mobile devices, rarely check email or need to act while on site. Examples include confirming a service order, accepting completed trade work or signing a time-sensitive appointment agreement.

Potential benefits of SMS include:

• The recipient can start directly on a mobile device.
• No application has to be installed.
• The process may feel shorter in mobile working situations.
• A mobile number can serve as an additional contact channel.

There are practical limitations. Mobile numbers may be outdated, shared or reassigned. Roaming, poor reception, message filtering and international number formats can complicate delivery. Reviewing a long contract on a small display can also be inconvenient.

An SMS delivery status does not, by itself, prove that the intended person read the message or signed the contract. The same basic limitation applies to technical delivery or opening events associated with email.

Separate authentication from delivery

The central question is not merely “Where was the link sent?” but “How was the person completing the process verified?”

A freely transferable link provides only limited attribution to the intended signer. Sending an SMS to a known number does not establish identity conclusively either. Access to a phone can be an authentication factor, but it is not equivalent to full identity verification. Shared devices, forwarded messages and SIM-swapping are examples of risks that may need to be considered.

Possible levels of protection include:

1. Personalised one-time link: The link belongs to one transaction, expires and is disabled after completion.
2. Separate one-time code: The link and code are sent through separate or deliberately selected channels.
3. Account login: The signer authenticates through an existing customer or employee portal.
4. Identity verification: An appropriate identification procedure is integrated when required by the intended signature level.
5. Qualified electronic signature: The process meets the eIDAS requirements, including a qualified certificate and qualified signature creation.

Adding more factors is not automatically better. Authentication should reflect the risk, target group and required signature level without creating unnecessary barriers.

eIDAS: the channel does not define the signature level

The eIDAS Regulation distinguishes between simple, advanced and qualified electronic signatures. Whether a process creates a simple electronic signature, an advanced electronic signature or a qualified electronic signature depends on the applicable requirements and technical implementation—not on whether access begins through email or SMS.

A typed name, selected checkbox or drawn signature may form part of a simple electronic signature. Adding an SMS code does not automatically turn it into an advanced electronic signature. An advanced signature must, among other requirements, be appropriately linked to the signer and enable subsequent changes to the signed data to be detected.

Under eIDAS, a qualified electronic signature has the equivalent legal effect of a handwritten signature. Whether it is required for a particular contract, and whether an electronic form is permitted, also depends on the applicable law and transaction. Documents subject to formal requirements or carrying substantial risk should therefore be assessed separately.

Evidence and the audit trail

If a transaction is disputed, the visible signature in a PDF is not the only relevant element. A robust process should document what happened, when it happened and which version of the document was involved.

An audit trail may include:

• unique transaction and document identifiers,
• a hash or other integrity data for the signed version,
• delivery, access and completion timestamps,
• authentication steps used during the process,
• records of signing intent and relevant confirmations,
• rejected, abandoned or expired invitations,
• the relationship between the completed document and its original transaction.

Logs should be exportable in an understandable form and retained with the signed document. Individual technical attributes such as an IP address or an SMS delivery event do not establish identity reliably on their own. Evidence becomes more meaningful when several consistent events can be assessed together.

GDPR and confidentiality

Email addresses and mobile numbers are generally personal data. Contract content, activity logs and any identity evidence may also be personal data. The process must therefore account for GDPR principles such as purpose limitation, data minimisation, transparency, security and storage limitation.

Text messages and email subject lines should not reveal unnecessary contract details. The URL itself should avoid readable names, contract information or other sensitive data. For confidential documents, an additional authentication step before displaying the content may be appropriate.

Other points to review include:

• controller, processor and subprocessor roles,
• storage locations and possible international data transfers,
• deletion and retention policies,
• access available to internal administrators,
• procedures for incorrectly entered email addresses or phone numbers.

The appropriate legal basis and retention period depend on the workflow and contractual context. There is no single configuration suitable for every document category.

Choosing by use case

Email link for a detailed B2B proposal: The contract has several attachments and requires review before signing. A personalised email link is often practical, potentially combined with a code delivered separately.

SMS for completing a mobile service job: After a repair, the customer receives a link on their phone while still on site. The interface should provide a readable summary, access to the full document and a clear final confirmation.

HR document containing sensitive data: An open email or a basic SMS workflow may be inappropriate. A protected employee portal with additional authentication can support confidentiality and attribution more effectively.

Document requiring a qualified electronic signature: Email or SMS may provide the entry point. The signature itself must still be completed through a QES-compliant process using the necessary qualified components.

Link, SMS or a combination?

For many routine contracts, a personalised email link is a practical starting point. SMS is particularly useful for mobile, immediate and relatively short processes. A combination can make sense—for example, sending the link by email and a one-time code by SMS. It also adds complexity, support requirements and additional data processing.

The decision should be based on a small set of concrete questions:

• Which device will the target group actually use to review the contract?
• How confidential are the document and its metadata?
• How serious would incorrect attribution be?
• Which eIDAS signature level and legal form are required?
• Which evidence must be exportable later?
• What happens if contact details are incorrect, outdated or shared?

The channel alone does not make a signing process reliable. The decisive factor is the coordinated combination of delivery, authentication, signature technology, integrity protection, audit trail and clear user guidance.