> ## Documentation Index
> Fetch the complete documentation index at: https://veriqa.app/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Stronger sign-in with a chain of channels

> One transaction confirmed in several channels: how it is designed — and why this is not strict MFA.

A sign-in that needs confirmation not in one trusted channel but in several: the same transaction is
confirmed first in, say, Telegram and then over email, and there is no partial success. Why this
matters and for whom is covered on the
[Stronger sign-in with a chain of channels](https://veriqa.app/whats-next/auth-chain?lang=en) page.
Here is how it is designed.

<Note>
  You build the core of this scenario yourself from mechanisms Veriqa already provides; what is still
  missing is listed below. We are working on making it simpler to implement in the product.
</Note>

## How it is designed

* **The linked-identity model** — several channel identities joined into one record, and the rule
  by which its stable identifier becomes the user's identifier for the application. The order of
  confirmations does not affect it, and adding or losing a channel later does not turn the user
  into someone else.
* **The "K of N" policy** — the application requires confirmation from K of the N linked channels.
  A chain of two is the special case where K and N are both two.
* **Linking and recovery** — how channels enter the set and what happens when one of them is lost.
* **The default** — off. For applications that have not enabled the chain, nothing changes.

A chain adds friction by definition, so it is meant to be switched on by the application for
sensitive actions and step-up rather than for ordinary sign-in.

## Where its limits are

<Warning>
  **A chain is not strict multi-factor authentication.** Both confirmations are of the same nature:
  possession of a channel plus trust in that channel's platform. Two messengers on one phone are
  lost together with the phone; a SIM swap can affect several at once.
</Warning>

To be equally clear: a chain **does not make sign-in phishing-resistant** and adds no cryptographic
barrier between the browser and the phone. It increases the number of independent confirmations,
not the strength of the binding between them.

The gain is real and specific all the same: an attacker needs control over two independent channels
instead of one, which is a markedly higher bar than a single stolen messenger session. The most
useful pair is a messenger and email — the two channels least likely to fail together. That is a
recommendation to whoever configures it, not a rule the product enforces.

## What not to confuse with a chain

An attribute obtained inside a channel is not another link. When a user shares their phone number
with one tap in a messenger and the platform itself confirms the number, the chain still has the
same number of channels: this is enrichment of the identity, not an additional confirmation. Its
value is that a verified number arrives without sending, paying for or waiting on an SMS code.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.