tdata, session strings and authorizations: how Telegram account access actually works

The Telegram automation world runs on two file formats - tdata folders and session strings - and almost nobody explains what they actually are. The gap produces predictable losses: keys pasted into online converters, accounts driven by two tools at once until Telegram kills the key, device lists nobody audits.

This guide covers the mechanics honestly: what an authorization is, how the formats differ, what import and export really do, and which controls matter.

An authorization is a key, not a login

When you sign in to Telegram on a new device - SMS code, then the cloud password if you have one - the client and server negotiate a long-lived secret called an auth key: 256 bytes of random material stored on the device. From then on the device authenticates with that key alone; password and SMS code are never asked again. The sign-in ceremony exists only to mint the key.

The key is per-device, not per-account. Sign in on a phone, a laptop and a work PC - three independent authorizations, each with full access, each revocable on its own. The list in Settings → Devices is not a cosmetic history; it is literally the inventory of live keys the server will still honour.

• Changing your password does not rotate or invalidate any key - existing devices stay signed in.
• Terminating a device's session is the only way to kill its key; once revoked, every copy of that key anywhere is dead.
• “The account” does not live in any file. What lives in files is a key - and the server cannot tell a copy from the original device.

tdata vs session string: same key, different packaging

tdata is the working directory of Telegram Desktop: the auth key, data-center id, user id, caches and settings, encrypted with a locally stored key (the key_datas file). Unless you set a local passcode, the decryption key sits in the same folder, so copying the folder copies the access. The session inside was minted by Telegram Desktop, so it also carries that app's API identity and device profile - a detail that matters once it moves elsewhere.

A session string is the same essentials serialized into one line of base64: data-center id, API id, the auth key itself and the user id. The exact layout differs between client libraries (Pyrogram-family strings and Telethon strings are not interchangeable), but the payload is the same idea.

Functionally they are the same key in different packaging. Both circulate on account marketplaces, which sell accounts in either packaging - as a tdata archive or as a session string plus a device-parameter JSON (checked August 2026; see what buying accounts actually gets you).

Possession is access - treat both like private keys

Whoever holds the file holds the account. Using a copied tdata or session string triggers no SMS, no password prompt, no new-device alert and no new row in the device list, because it is not a new sign-in - it is the existing authorization, indistinguishable from the original device. The only trace is behavioural: activity from an IP or in a rhythm that is not yours.

This is why stealer malware harvests tdata folders specifically, and why a major account marketplace labels its listings by origin at all (documented in the buying guide). A session file is not “account data”; it is the credential itself.

• Encrypt session material at rest - a plain-text session string in a note or spreadsheet is an incident waiting to happen.
• Never commit sessions to git and never send them through chats: both create copies you no longer control.
• One custodian per file. If a session has passed through several hands, assume every hand kept a copy.
• On any suspicion, terminate the authorization in Settings → Devices - revocation kills every copy of that key at once.

Migration mechanics: import preserves, export mints

Import - bringing an existing tdata or session string into a tool - preserves the authorization: the tool reads the auth key, data center and user id and keeps using them, and the device list does not change. Done properly, import also preserves the app identity - a session minted by Telegram Desktop should keep presenting its API credentials and device profile, otherwise the authorization looks like it teleported into different software. This is how Teleliner handles it: a tdata archive keeps its own API credentials and fingerprint, duplicates are detected by Telegram user id rather than phone number, and stored sessions are encrypted at rest, decrypted only at runtime.

Export - handing the account to a new device while the original keeps running - cannot safely reuse the existing key, since two drivers on one key is the failure mode below. So export mints a new authorization instead, typically via QR login: the new device gets its own auth key. The visible consequence is one more row in Settings → Devices - one more live key that can be stolen.

One key, one driver

Start with the distinction that gets muddled everywhere. Several authorizations on one account are normal. A phone, a laptop and an automation tool can hold three separate keys and run at the same time - that is what the device system is built for, and Telegram shows all three in the device list without complaint. The dangerous pattern is narrower: one auth key driven by two processes at once.

When Telegram sees a single key active from two network paths at the same time, it can invalidate that key outright - client libraries surface this as AUTH_KEY_DUPLICATED - which logs out both sides. Even when the key survives, the two clients fight over shared state, and the pattern is precisely what account-takeover detection is built to notice. This is why copies matter: opening Telegram Desktop on the tdata that an automated session is already driving, “just to check”, is not a second authorization - it is a second driver on one key, and it can end with a healthy account frozen.

So the correct way to use one account from several places is several authorizations: each tool gets its own key through a real login, one driver per key. Teleliner enforces this internally - a single engine process holds the session of each managed account, and dashboard actions go through that holder rather than opening a parallel connection. Network identity follows the same rule: a key that jumps between exit IPs looks wrong for the same reason, which is why a sticky per-account proxy matters.

The cloud password is the control that actually matters

Telegram's two-step verification - the cloud password - is an extra secret demanded after the SMS code at every new sign-in. It does not encrypt existing sessions and does not stop someone who already holds your tdata; what it gates is the minting of new authorizations. That gate covers exactly what a phone-number identity is most exposed to: SIM swap, SMS interception, a login code phished in real time. Where the number comes from decides how realistic those attacks are; the cloud password is the layer that holds when the number fails.

Two boundaries worth knowing. QR login respects it: approving a new device on a password-protected account still requires the password, so export flows cannot bypass 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; a serious setup uses both.