What “without an account” means in practice

Asking someone to sign a document online does not have to require registration. The recipient will typically receive an individual link by email or another agreed channel. The link opens a browser-based signing page where the recipient can review, confirm and sign the document.

Not requiring an account does not mean dispensing with all checks of the person’s identity. Depending on the document and the required signature level, the process may include additional steps such as:

• confirmation through a single-use link,
• a code sent by SMS or a separate channel,
• verification of specific personal details,
• an electronic identity check,
• confirmation through a trust service provider.

A dedicated app is not necessarily required for these steps. Many workflows can be completed entirely in a browser. A qualified electronic signature may, however, require formal identification. Whether that identification can also take place without extra software depends on the identification method and trust service provider involved.

A typical browser-based signing process

An efficient process begins with document preparation rather than the visible signature. The sending organisation defines who needs to sign, where information is required and in which order multiple parties should complete the document.

A typical workflow may look like this:

1. A contract is uploaded as a PDF or generated by a business system.
2. The names, email addresses and, where relevant, roles of the signers are entered.
3. Signature, date and text fields are assigned to the appropriate people.
4. Each person receives an individual access link.
5. The document opens in the browser and can be reviewed in full before any declaration is made.
6. The signer completes the required fields and confirms their intention to sign.
7. Once the process is complete, the parties receive the signed document or secure download access.
8. An audit trail records relevant process events.

The signer’s intention must be unambiguous. A script-style font, a drawn signature or a typed name does not, by itself, determine the legal quality of the transaction. The overall process, attribution to the signer, integrity of the document and evidence of intent are what matter.

Which type of electronic signature is required?

The eIDAS Regulation distinguishes between simple, advanced and qualified electronic signatures. The appropriate level is not determined merely by how important a document appears internally. It depends on applicable form requirements, risk and the level of evidence needed.

Simple electronic signature (SES)

An SES may consist, for example, of confirming a document through a personal link or entering a name. It is often used for transactions without a statutory written-form requirement and with manageable risk, such as internal approvals, acknowledgements of receipt or many ordinary commercial agreements.

Advanced electronic signature (AES)

Under eIDAS, an AES must be uniquely linked to the signer, be capable of identifying that person, be created under the signer’s control and make subsequent changes to the signed data detectable. In practice, identity or authentication attributes, cryptographic controls and reliable process records are combined to meet these requirements.

Qualified electronic signature (QES)

A QES is based on a qualified certificate and created using a qualified electronic signature creation device. Under eIDAS, it has the equivalent legal effect of a handwritten signature. A QES may be implemented as a remote signature, but it requires reliable identification and the involvement of a qualified trust service provider.

Article 25 of eIDAS also states that an electronic signature must not be denied legal effect or admissibility as evidence solely because it is electronic or does not meet the requirements for a QES. This does not mean that every type of electronic signature is sufficient for every contract.

Check formal requirements before sending

Many contracts can generally be concluded without a prescribed form. Other transactions are subject to statutory written-form, text-form or sector-specific requirements. The parties may also have agreed on a particular form in an existing contract.

Before digitising a process, organisations should consider:

• Is the document subject to a statutory form requirement?
• Can an electronic form satisfy or replace that requirement?
• Is electronic form expressly excluded?
• Do appendices, powers of attorney or supporting records need to be included?
• Must several people sign in a particular order?
• Which evidence would be useful if the transaction were later disputed?

A QES can replace a legally required handwritten signature in many situations, but not in every case. Certain legal transactions are excluded or subject to additional requirements. The method should therefore be selected for the specific use case, with qualified legal input where the position is unclear.

No account does not mean no security controls

An accessible signing process should not rely on an unprotected link that can be forwarded indefinitely. The safeguards required depend on the risk associated with the document.

Possible controls include:

• individual, randomly generated links with a limited validity period,
• additional codes delivered through a separate communication channel,
• defined expiry dates and reminder periods,
• closure of a transaction after completion or withdrawal,
• encrypted transmission and protected storage,
• role and permission controls for internal staff,
• logging of delivery, access, consent and completion events,
• integrity protection for the final signed document.

An email address alone is not always sufficient evidence of identity. Stronger authentication may be appropriate or necessary for sensitive or economically significant transactions. At the same time, the process should not verify or collect more identity data than the purpose requires.

GDPR and data minimisation

Electronic signature workflows commonly process names, contact details, contract contents, timestamps and technical log data. Depending on the document, special categories of personal data may also be involved. Controllers should therefore define in advance which data is processed, for what purpose and for how long it is required.

Practical review points include:

• the legal basis and transparent information for data subjects,
• the allocation of roles between the controller, processor and any subprocessors,
• a data processing agreement where required,
• storage locations and rules for international data transfers,
• technical and organisational security measures,
• deletion and retention periods,
• procedures for access, rectification and erasure requests,
• controlled access to documents and supporting evidence.

Data minimisation also applies to the audit trail. It should record the events required for security and evidence, but should not collect technical data indefinitely merely because it might be useful. Retention periods for the contract, signature evidence and temporary workflow data may differ.

The audit trail as part of the evidence

An audit trail records the course of a signing transaction. Depending on the system and its configuration, it may include delivery times, access events, authentication steps, consent, signing times and final status. Hash values or certificate information may also help demonstrate the integrity of the document.

An audit trail does not replace a required identity check or automatically create a particular signature level. It does, however, provide context showing how a declaration was made. It should therefore be exportable with the final document and retained in a way that preserves the connection between the evidence, the document and the transaction.

Practical examples

A sales quotation

A sales representative prepares a quotation in a CRM system and sends it for acceptance. The customer opens a link in the browser, checks the scope and price, and confirms the quotation. The accepted PDF and process record are then stored in the CRM. Whether an SES is sufficient or stronger safeguards are appropriate depends on the content, risk and applicable form requirements.

HR documents

An HR team sends a policy acknowledgement or an amendment agreement. The employee does not have to create another account and can complete the transaction on a personal or company device. Before implementation, the organisation should establish which form applies to that particular HR document and which access restrictions are required because of the sensitive data involved.

A trade or repair order

After an on-site appointment, a contractor sends the scope of work as a PDF. The customer can read and confirm it on a smartphone without printing, photographing or returning paper. Changes should not be made through competing PDF copies; a new, clearly versioned document should be issued for signature.

What matters during implementation

A well-designed process reduces friction without neglecting evidence or security. Before going live, the full workflow should be tested on different devices and with multiple signers, expired links, refusals and subsequent corrections.

Invitations should be clear, the entire document should be available before signing, buttons should state what action they perform, and completion should be confirmed. Signers should be able to identify the sender, understand the declaration they are making and know how to obtain a copy.

“Without an account, app or paper” therefore describes a low barrier to access, not the absence of controls. A reliable digital contract process still requires a deliberate choice of signature level, proportionate authentication, data protection, document integrity and traceable records.