# Signer Authentication

***

### 1. Signer Links & Access

Every signer in an S-Sign request receives a unique, secure link via email. These links act as the gateway to the document.

* **Unique Identity:** Each link is tied to a specific Signer Profile. Even if multiple signers use the same email address, S-Sign can generate distinct links for each role.
* **Signer Experience:** When a user clicks their link, they are directed to a Salesforce-hosted site to complete the signing process.
* **Link Expiration:** By default, links remain active for a set period (often 30 days), but this can be customized in the Expiration and Reminder Settings within the S-Sign template.
* **Resending Links:** If a link expires or is lost, sending a "Reminder" from the S-Sign Envelope record will generate a fresh, active link for the recipient.

***

### 2. Authentication Methods

S-Sign provides two primary levels of identity verification to ensure the person clicking the link is the intended signer.

#### A. Email Verification (Default)

This is a 2-step verification process designed to confirm access to the recipient's inbox.

1. Request Code: Upon clicking the signer link, the signer must click a "Send Email" button.
2. Receive PIN: S-Sign sends a separate, automated email containing a 6-digit verification code.
3. Validate: The signer enters this code into the S-Sign interface to unlock the document for viewing and signing.

#### B. Two-Factor PIN Verification

For higher-security requirements, administrators can enable a pre-shared PIN.

* Setup: A specific PIN is assigned to the Signer Profile before the request is sent.
* Mechanism: The signer must enter this specific PIN to gain access, adding a layer of security beyond just email access.

***

### 3. Configuration & Security Settings

Administrators can fine-tune authentication behavior at the Template Level to balance security with user convenience.

| **Feature**             | **Description**                                                                                                                                              |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Disable Verification    | Allows signers to access documents immediately after clicking the link. Only recommended for low-risk, internal documents.                                   |
| Encrypt at Rest         | If enabled, documents are encrypted while stored. This forces email verification to be enabled for all signers.                                              |
| Signer Profiles         | Defines the "who" and "how." You can specify different authentication requirements for Signer 1 (e.g., a client) vs. Signer 2 (e.g., an internal executive). |
| Audit Trail Integration | Every authentication event (PIN requested, PIN entered, Consent given) is logged in the S-Sign Audit Trail with a timestamp and IP address.                  |

***

### 4. Key Security Considerations

* Native Data Residency: Unlike non-native e-signature tools, S-Sign does not send your documents to a third-party server for authentication. The "verification" happens entirely within your Salesforce instance.
* Legal Compliance: By requiring "Consent to do business electronically" alongside authentication, S-Sign helps meet the requirements of the ESIGN Act and UETA.
* Delegation: Disabling verification allows a signer to forward their email to an assistant to sign on their behalf. If verification is enabled, the assistant would also need access to the signer's inbox to retrieve the PIN.

***


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://help.sdocs.com/s-sign/advanced-signer-scenarios/signer-authentication.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.