Running Telegram on a Device You Do Not Own
People ask us this a lot, usually after something’s already gone wrong: they logged into Telegram on a work laptop, a cybercafe machine, a family tablet, or a rented VPS, and now they’re not sure what that device can still do with their account. The honest answer is: more than most people assume, and the app’s UI doesn’t make that obvious.
This isn’t a scare piece. It’s a walkthrough of what a Telegram session actually is, what part of it lives on the device versus on Telegram’s servers, and what that means for anyone who needs to run Telegram somewhere they don’t fully control.
What a Telegram session actually is
When you log into Telegram on any client, whether that’s the mobile app, Telegram Desktop, or a web client, the login process (via SMS code or an existing session’s QR scan) ends with the client generating and storing an authorization key locally. That key, along with your account’s session state, is what lets the app talk to Telegram’s servers without asking for your phone number and code every time.
Two things matter here. First, this key is stored as a file on the device, not something abstract tied to the hardware itself. On Telegram Desktop it’s the tdata folder. On mobile it’s the app’s private storage. Second, once that key exists, it’s a standing, active login. Telegram calls these “sessions,” and you can see the full list under Settings > Devices. Each entry shows things like the device name and app version, but those are just strings the client reports during login. They’re not a hardware fingerprint or a security control, they’re closer to a label.
The practical implication: whoever has file-level access to that device has access to the session, full stop. They don’t need your password. They don’t need your 2FA cloud password either, because that’s only checked on new logins (via SRP), not for a session that’s already authorized and sitting on disk. If someone copies that session data off a device, they can run your account elsewhere without you noticing until you check the device list.
Why the lock screen doesn’t fix this
Telegram’s local passcode (available in Desktop and mobile) puts up a PIN or biometric prompt before the app’s UI opens. That’s a real deterrent against someone picking up an unlocked device and casually opening Telegram. It is not the same thing as protecting the underlying session data from someone who has admin or root access to the machine itself, or from a device owner who image-copies the drive, or from another user on a shared box who can read the app’s storage directory outright.
This is the distinction that gets lost: the lock screen protects the app’s UI. It doesn’t change who legally and technically owns the storage medium the session file sits on. If you don’t own the device, the device’s owner (or whoever administers it) has a path to that data that has nothing to do with your PIN.
That’s the actual trust boundary. Not “is the app locked,” but “who controls the disk.”
The proxy is a different layer entirely
We spend a lot of time on proxy configuration here, so it’s worth being precise about what an MTProto or SOCKS5 proxy actually does for you, because it’s unrelated to the problem above. A proxy sits between the client and Telegram’s servers and changes which IP address Telegram (and anyone watching the network path) sees as the connection origin. That’s useful if you’re on a restricted network, if you want your account’s connections coming from a consistent region, or if you’re managing infrastructure where IP consistency matters for how an account behaves over time.
What a proxy does not do is touch the session file sitting on the device. It has zero bearing on who can read that file, copy it, or use it. We’ve seen people assume that because their traffic is proxied, their account is “protected.” Those are two separate layers: proxy config protects your network-level identity, device custody protects your session data. Fixing one doesn’t fix the other.
What to do if you have to use a device you don’t own
Sometimes there’s no way around it. Maybe you need to check something on a work computer, use an internet cafe while traveling, or borrow a family member’s tablet because your phone died. A few concrete habits actually matter here:
Log out cleanly when you’re done, from inside the app (Settings > log out), not just by closing the window. This terminates the session server-side and invalidates the local auth key, so a copy of the leftover files on that machine is worthless afterward.
If you can’t log out cleanly, or you’re not sure you did before someone else used the device, go to Settings > Devices from another device you do own and terminate that specific session, or terminate all other sessions if you’re unsure which one it was. This revokes the auth key remotely regardless of what’s still sitting on the borrowed machine’s disk.
Don’t link anything to an account you’re using on borrowed hardware that you’d mind losing control of, meaning payment methods, bot tokens with real permissions, or channels you administer. If the session does get lifted, you want the blast radius to be small.
Check the device list periodically, not just after an incident. It’s the one place Telegram actually shows you what’s authorized. An entry you don’t recognize is your signal to terminate it and change your 2FA cloud password, since that’s what stops a new login even if someone has your phone number and can intercept a code.
Running Telegram at scale on infrastructure you lease
This applies just as much when the “device you don’t own” is a rented VPS or a shared cloud phone rather than a cafe terminal. If you’re running Telegram sessions for channel management, moderation bots, or any automated workflow on infrastructure a provider operates, the provider’s own staff or systems have the same disk-level access a device owner would. That’s not a hypothetical, it’s just how hosting works: someone administers the box you’re on.
The mitigation isn’t different in kind from the borrowed-tablet case, it’s the same principle applied at scale. Prefer infrastructure where you actually hold root or admin, so the number of parties with disk access is a known, small set. Keep session data for anything sensitive off shared or multi-tenant boxes where you can’t audit who else has access. Where the client supports encrypting local storage (Telegram Desktop’s local passcode can be configured to encrypt tdata, depending on client and version, so check the current behavior for whatever build you’re running rather than assuming), turn it on, but treat it as a second layer on top of controlling the box, not a replacement for it.
And keep the proxy and the hosting decision separate in your head. A well-configured MTProto proxy in front of a session running on a box you don’t control still leaves that session’s data exposed to whoever runs the box. Proxy config is about how the account talks to Telegram’s network. Hosting choice is about who can touch the account’s data at rest. Getting account safety right means treating both as real, distinct decisions instead of assuming one covers the other.
If you’re setting up Telegram hosting or proxy infrastructure and want to think through where the actual trust boundaries sit for your setup, that’s what we work on here. Head back to the telegramvault.org home page to see how we approach hosting and proxy configuration.
Get new guides and videos first — join the Telegram channel.