Stronger sign-in with a chain of channels
What this is
In the normal Veriqa flow a sign-in is confirmed in one trusted channel. A chain sign-in requires two: the user confirms the same transaction first in one channel — say Telegram — and then in a second one, say e-mail. Both confirmations belong to one transaction; if either is declined or times out, the whole sign-in fails. There is no partial success.
The two channels are not two unrelated accounts. They are linked into one identity, and it is that linked identity the application sees: the order of confirmation does not change who the user is, and adding or losing a channel later does not turn them into somebody else.
What it is for
- Step-up before a sensitive action — a large payment, a change of payout details, access to someone else's data.
- Administrative surfaces, where the cost of one stolen session is high enough to justify a second confirmation.
- Confirming critical operations, where the record of "confirmed twice, in two channels" matters as much as the access itself.
Not for the default sign-in. Veriqa exists for conversion and for sign-in and registration in a few seconds; a chain doubles the friction by definition. It is therefore strictly opt-in per application, off by default — and for applications that do not enable it nothing changes at all.
Profile enrichment along the way
A chain of channels solves a second problem in passing: the channel that confirms a sign-in can, with the user's consent, also fill in the identity behind it — a verified phone number, a mail address, other attributes. The phone number is the clearest case: in a messenger the user shares it with a single button, the platform itself vouches for it, and an SMS code need not be sent, paid for or waited on. That step is an attribute obtained inside a channel, not a third leg of the chain: in the example Telegram plus sharing a phone number plus mail there are still two channels. One rule governs this: an attribute is asked for when it is genuinely needed, and only with explicit consent — otherwise enrichment eats the very low friction Veriqa exists for.
Where the boundary runs
A chain is not strict multi-factor authentication. Both confirmations are of the same kind — possession of a channel — plus trust in that channel's platform. Two messengers on one phone fail together with the phone; a SIM swap can affect several of them at once. What the chain does buy is real but specific: an attacker now needs control of two independent channels instead of one, which is a meaningfully higher bar than a single stolen messenger session.
Nor does a chain make the sign-in phishing-resistant or add a cryptographic barrier between the browser and the phone. It raises the number of independent confirmations, not the strength of the binding between them. Where the risk model needs that kind of guarantee, a chain is not the answer to it.
The most useful pairing is a messenger plus e-mail — two channels that are least likely to fail together. That is a recommendation for whoever configures it, not a rule the product enforces.
Where this stands
We are working on this: what works out will appear in releases as it is developed; if the direction does not hold up, this page will say so.