Telegram two-step verification: the cloud password, the recovery email and the traps

By default a Telegram account is protected by one thing: whoever receives the SMS gets in. That is a thin defence for an identity that carries your chats, your contacts and, on a working fleet, your business. Two-step verification - what Telegram calls the cloud password - is the layer that holds when the number stops being yours.

It is also the control most often set wrong. Half-configured, it looks enabled while a stranger keeps the key; set with someone else's recovery email, it is not protection at all but a lock whose spare key lives in another person's mailbox. This guide covers what it gates, what it cannot do, and the traps that make a password look stronger than it is.

What the cloud password actually gates

The cloud password is an extra secret demanded after the SMS code at every new sign-in. Under the hood Telegram verifies it over SRP: the password itself never travels to Telegram's servers, only a mathematical proof that you know it. What the password gates is narrow and specific - the minting of new authorizations. It does not encrypt anything you already have, and it does not touch keys that already exist.

That table contains the single most misunderstood line. A cloud password does nothing against a leaked session file: an authorization is a key, and a key that already exists is not asked for passwords again. Whoever holds a copy of your tdata is already inside, password or not. The only remedy there is terminating the session, which kills every copy of that key at once.

One more boundary worth knowing: QR login respects the password. Approving a new device on a protected account still requires it, so flows that mint a second session cannot slip past it. And it is not Telegram Desktop's local passcode - the passcode encrypts tdata on disk, the cloud password gates sign-ins server-side. They cover different attacks, and a serious setup uses both.

The recovery email is a spare key - to somebody

A recovery email is the escape hatch for a forgotten password: Telegram mails a code and the password resets in minutes. Without one, the only way back is the seven-day password reset (account.resetPassword): request it, wait seven days, and the two-step verification comes off by itself. The wait is not a lockout - the account and its live sessions keep working normally throughout. What it costs is the ending: when the seven days are up every session is signed out and the account sits with no password until you set a new one. That is worth avoiding, so the email is worth having. The same seven days requested by somebody else are a different story - see the password reset.

There is a condition on that route back, and it is easy to miss. A reset can be declined by any live authorization on the account - your own reset included - and a copy of your key is a live authorization. So if somebody else is still holding a session file for this account, the seven days are not a way back for you at all: the copy they were handed cancels your request, and the wait you started ends with nothing. The route works while the key is genuinely yours alone, which is what the handover order is for.

The flip side is exact and unforgiving: whoever controls that mailbox controls the password, and therefore the account. A recovery address you did not set is not a detail to clean up later - it is a live backdoor, and it survives almost everything you would instinctively do about it.

Note also what no tool can do for you: attaching a recovery email cannot be automated. Telegram answers a password-with-email request with EMAIL_UNCONFIRMED and waits for a confirmation code delivered to that mailbox, so any honest platform sets the password without an email and leaves the address to you. Add it by hand, in an official client, to a mailbox you control - ideally a separate alias per account, with its own two-factor protection. Never let one mailbox become the recovery address for a whole fleet: that concentrates every account's recovery rights in a single point of failure.

The sign-in email is the second address, and the quieter one

Telegram also supports signing in with an email instead of an SMS code. It is a separate setting from the recovery address - Settings, then Privacy and Security, then Login Email - and it is the one people forget to look at. An account carrying somebody else's sign-in email can be entered without the phone number at all: the cloud password does not cover that address, and changing the password does not remove it.

Read it together with the section above and the shape of the problem is clear. The recovery address hands over the password. The sign-in address hands over the code - and the code is what both reset doors ask for: deleting the account, or taking it over after seven days. Of the two leftovers a seller can keep, this is the one that survives a normal intake untouched: you replace the password, you terminate every session, and every login code still lands in their mailbox.

Teleliner reads the address on the account's cloud password screen, shows it masked the way Telegram masks it, and can repoint it from the same screen: enter a mailbox you control, then the code Telegram sends there. Two limits come from Telegram rather than from us - an account with no sign-in email cannot be given its first one from a running session, and an existing address cannot be detached at all, only replaced.

An account that came from someone else

Everything above compounds on a purchased account, where the seller had full control right up to the sale and may have arranged to keep it. What is really on sale and how origin is labelled is a separate question; this is the hygiene that applies the moment an account you did not register lands in your hands. The list below covers the password and the two addresses only - it is not the handover order, which starts with the key and is written down in preparing a bought account.

1. Read the current state before changing anything: is a password already set, is a recovery address attached, is a sign-in email attached, which sessions are live.
2. Remove the existing cloud password and set your own from scratch. Do not merely change it - a change keeps the previous owner's recovery address attached.
3. Terminate every authorization you did not create: other people's devices are visible in that list and can be evicted. Run it from an established device - a session younger than about 24 hours is not allowed to terminate others. And if the account reached you as a session file, do not revoke the authorization you are working from until you have minted one of your own - the order for that is below.
4. Attach your own recovery email by hand in an official client, to a mailbox you control.
5. Replace the sign-in email if one is attached and is not yours - on the same cloud password screen, with the code Telegram sends to your mailbox. It is a separate address from the recovery one and none of the steps above touches it.
6. Only then let the account do anything that matters - and treat the first weeks as warming, not production.

Step two is the one people skip; step three is the one they overrate. A password you changed rather than replaced leaves the previous owner a way back in. And terminating sessions evicts other people's devices - it does not reach a copy of the account's own key: a session file the seller sent you is the same authorization you are working from, it has no separate row in that list, and it stops working only when that authorization is revoked. Doing that in the wrong order locks you out along with them, so the sequence is written down in one place: the handover in preparing a bought account - the same guide that carries the rest of intake, proxy first and quarantine after, and the signals that say an account is not salvageable.

A sign-in that stops at the password is an alarm

The cloud password doubles as a sensor. When an attempted sign-in reaches the password prompt and stalls there, it means the SMS code has already been obtained and used - the password is the only thing that held. That is not routine: it is evidence that the code delivery path is compromised, whether through SIM swap, an SMS-rental service reselling the number, or a phished code.

React as if the number is burned until you know where the code leaked: audit the device list, terminate anything unfamiliar, and plan the account's future on the assumption that codes to that number can reach someone else. One caveat on that list - it shows devices, not copies of the key. If this account arrived as a session file, the copy the sender kept has no row of its own and goes away only when the authorization you are working from is revoked, which is a sequence of its own: the handover order. Where the number came from usually explains how the code leaked in the first place.

There is a second half to that reaction, and it is the time-critical one. A sign-in stopped at the password says two things at once: someone has a working way to receive the codes, and they have just found out they cannot get in. What Telegram offers them next are the two doors that need nothing but the code: delete the account, or start the seven-day password reset and be handed it whole. The second one will not announce itself again after that first service message, so treat the flag as a countdown rather than a scar: check the account's protection state for a reset already armed, work out where the code could have been delivered - the sign-in email first - and close that path while the account is still yours.

Teleliner surfaces this signal on the account itself rather than making you go looking: when an authorization is seen sitting at the password prompt, the account is flagged. The flag means the password did its job - and that the number no longer belongs to you alone.

The password reset: seven days the account will not mention

If you are looking at a countdown on one of your accounts, this is what it is. Someone who can receive that account's login codes has asked Telegram to remove its two-step verification (account.resetPassword). The request needs the code and never the password - the same entry ticket account deletion uses - and Telegram answers it with a date seven days out. On that date the password comes off by itself, every authorization on the account is signed out, and the next login code lets its holder in unopposed.

The counter-move is one call, and it is yours today: decline the request from a live session (account.declinePasswordReset). No password and no code are asked for - holding a working authorization is the whole permission - and Telegram's message about the request, the one sitting in the account's own service chat, carries a button that does exactly this. Declining removes the request and takes the account off the clock. Nothing else you can do to the account stops that date, so this goes before any other repair.

It is worth knowing which of the two doors you are looking at, because this is the expensive one rather than the mild version of the other. Deletion frees the number and leaves whoever pushed it an empty shell. The reset leaves them the account: the history, the channels and groups it belongs to, the username, the contacts, the subscriptions, every week of warming behind it. Nothing is broken and nothing is missing at the end - the account simply has a different owner.

With the request gone, the work is on the code path. In order:

1. Close the way the code travels: the sign-in email first, because it survives everything else you do, then the recovery address, then the number itself.
2. Account for every live key. Whoever holds a copy of this account's session file receives its login codes in the same service chat you do, so the code path is not closed while a copy is out there. Ending that is a sequence of its own: the handover order.
3. Re-read the account's protection state afterwards. The pending date comes from Telegram itself, so it is the one honest confirmation that the request is gone and that nothing has taken its place.
4. If the code path cannot be closed - the number is rented, or you simply cannot tell where codes land - treat the week as notice. Move what can be moved to an account whose codes reach you, and stop putting anything new into this one.

Two things look like a fix here and are not:

• A changed address is not a cancellation. Repointing the sign-in email, changing the recovery address, replacing the password, terminating sessions - none of it touches a reset that is already armed, and it runs to its date all the same. The new address only decides who receives the next code.
• A decline is not a closed door. It removes this request and takes the account off the clock; whether the same person can arm another one, and how soon, is something we have not measured. Read it as time won, not as the matter settled - which is why the code path is the next thing you do and not a later one.

Two cases come up constantly. The message cannot be found - read and cleared, or the account simply runs unattended: the decline does not depend on it. Any live session can send the call, and the date itself is part of the account's protection state, so it is readable from the cloud password screen whether or not the notification survived. The date has already passed - then there is nothing left to decline. Two-step verification is off, every session including yours has been signed out, and getting back in takes a login code, which hands the account to whoever receives that code. If that is still you, sign in and set a new password in the same sitting. If it is not, the account is gone, and the work left is around it: the channels it administers, and any other account that shares its mailboxes.

All of this rests on somebody noticing that one message, and the chain breaks there twice over. It arrives once, in the account's own service chat, and nothing raises the subject again. And a service chat is not a private inbox - every live authorization on the account reads it. So if a copy of the key is out there, the single warning Telegram sends is delivered to the person it is warning you about. They are watching that chat on purpose; a quietly running account often has nobody reading it at all.

Teleliner does not depend on that message. The date is part of the account's protection state - Telegram returns it in the cloud password snapshot - so the platform reads it directly, shows the deadline and the countdown on the account, and declines from the session it already holds, either on your click or on its own: auto-decline is on by default, because the accounts this happens to are exactly the ones nobody goes back to reconfigure. Two limits stated plainly. It is a periodic check rather than an instant alarm, and it needs a working session - an account that is switched off, or standing on a dead proxy, is not being watched at all. And it cannot tell whose request it is: if you ever start a seven-day reset yourself, turn auto-decline off on that account first, or the platform will helpfully undo it.

Telegram's quarantines after a password change

Right after you set or change a password, and right after a new session signs in, Telegram applies day-long quarantines. They look like breakage and are not.

• FRESH_RESET_AUTHORISATION_FORBIDDEN - a session younger than roughly a day cannot terminate other sessions. Revoke from an older device, or wait it out.
• PASSWORD_TOO_FRESH and SESSION_TOO_FRESH - certain sensitive operations are refused for a period after a password change or a fresh sign-in, and the error carries the remaining seconds.
• A full password reset without a recovery email completes only after seven days - and unlike the quarantines above it restricts nothing meanwhile: the account keeps working the whole week, whoever asked for the reset.

The practical consequence: do the security work in the right order and with time in hand. Setting a password and immediately trying to clear old sessions from that same fresh session is exactly the sequence the quarantine blocks - which is why the checklist above starts from an established device.

Two-factor on the dashboard is a different thing

Do not confuse the account's cloud password with two-factor on the tool that manages the account. They protect different doors. If a platform holds sessions for a fleet, its login is the most valuable single credential you own: one stolen dashboard password would otherwise hand over every account behind it.

In Teleliner that door has its own second factor: a standard TOTP code from any authenticator app, enabled in Settings, plus one-time backup codes issued when you turn it on. The protection lives on the user rather than on the login method, so signing in with Google instead of a password does not skip it. Sensitive operations - exporting an account's session, for instance - additionally ask for a fresh code even inside an already authenticated session, so a hijacked browser tab is not enough to walk away with your fleet. Recovery is by backup codes only, which is why they are worth storing somewhere safe.

One honest note on storage, since it is a fair question to ask of any tool that logs in on your behalf: cloud passwords, session keys and proxy credentials are stored encrypted, each record under its own key, so a stolen copy of a database is not a usable copy of a fleet.