Why a retired device is an access question, not a storage question
When you stop using a phone, tablet or laptop, the device itself stops mattering — but the access it carried does not. A Mastodon client that was signed in on that device may still hold a token to your account. The question worth answering before the device leaves your hands is not “what is on the disk?” but “what can still act as me?”
This guide separates three actions that are easy to blur together: logging out a session, revoking a client app, and changing the account password. They are not interchangeable, and doing one does not automatically do the others.
Mastodon account settings allow users to revoke active sessions or authorized apps. Source
The same account settings area includes password changes and two-factor authentication. Source
That is the whole official picture this guide relies on. Everything else below is a way of organizing your own decisions, not a claim about menu wording or limits on any particular server.
Step 1: Inventory the retired device before you let it go
Work from the device itself first, while you still have it in hand. You are building a list, not fixing anything yet.
- Open every app on the device that you ever signed into with your Mastodon account. Include the official app, third-party clients, and anything that asked you to authorize access.
- Note the client name as it appears in the app, not as you remember it. Two clients from the same developer can look similar in a list.
- Note whether the app still opens to your account without asking you to sign in again. If it does, it is holding a live session.
- Write down any device-level sign-in you used, such as a browser session on the same machine.
- Before wiping or handing over the device, log out of each client you can still open. This is the courteous, low-risk first pass — but treat it as housekeeping, not as proof that access is gone.
A logout performed on a device you are about to lose is the weakest of the three actions, because you cannot confirm afterward what the client did with its token. That is why the next step happens from a device you are keeping.
Step 2: Review sessions and authorized apps from an account you control
Sign in to your Mastodon account from a device you are keeping. In account settings, the same area covers active sessions, authorized apps, password changes and two-factor authentication. Open that area and read the list against the inventory you just wrote.
Do not assume the list is sorted in a helpful way, and do not assume an entry is harmless because the name looks familiar. Match entries to your worksheet by client name and by when you last used that device. If an entry does not map to anything you recognize, do not panic — first check whether it corresponds to a browser or a client you forgot. If it still does not map, treat it as unknown and act on it.
This is also the moment to confirm your recovery setup is intact before you change anything. Changing a password while your only recovery route is a mailbox you no longer control is how people lock themselves out.
Step 3: Decide what to do about each entry
Use the worksheet below. The point of the table is to stop you from reaching for the biggest hammer — a password change — for a problem that a single revocation solves, or from settling for a logout when the client is still authorized.
| Client / session | Still used? | Action | Recheck |
|---|---|---|---|
| Official app on the retired phone | No | Log out on the device if possible, then revoke the client from account settings | Confirm the entry is gone from the authorized list |
| Third-party client on the retired tablet | No | Revoke the client from account settings | Confirm the entry is gone; reopen the app on the old device only if you still have it, to see that it no longer acts as you |
| Desktop browser session on a machine you are selling | No | Log out of the browser session, then revoke any remaining session entry | Sign in from your kept device and confirm the old session no longer appears |
| Client on your current daily phone | Yes | Keep it; do not revoke | None needed |
| Client you cannot identify | Unknown | Revoke it, then watch for a client that stops working and re-authorize it deliberately | Confirm the entry is gone; re-authorize only the client you actually use |
| Any entry, after a suspected compromise | — | Change the password and review two-factor authentication in the same settings area | Sign in again on your kept devices and confirm only expected clients remain |
A compact decision rule, if you want one line: still used, keep it; not used, revoke it; unknown, revoke it and re-authorize deliberately; suspected compromise, change the password as well.
Step 4: Understand what each action actually does — and does not do
These three actions differ in scope, and none of them is a general reset of your public presence.
- Logging out a session ends that sign-in on that device. It is the narrowest action and the easiest to get wrong, because a client can be logged out locally while remaining authorized at the account level.
- Revoking a client app withdraws that app’s authorization. It is the right tool for a client on a device you are retiring. It is not the same as deleting the app from the device, and deleting the app is not the same as revoking it.
- Changing the password is a broader account action. It belongs with a suspected compromise, not as a substitute for reviewing the authorized list.
Three limits are worth stating plainly, because they are common sources of false confidence:
- Revoking access does not delete posts you already published. Your public profile and post history are a separate matter from app authorization.
- Revoking access does not change your handle. Your username is an account attribute, not a client permission.
- Revoking access on your account does not affect accounts you hold on other servers. Each server’s account settings govern that server’s account.
Common mistakes
- Treating a logout as a revocation. Logging out on the device you are about to lose tells you little about what the client still holds. Revoke from the account side.
- Deleting the app and calling it done. Removing an app from a device does not withdraw its authorization at the account level.
- Changing the password first and reviewing later. A password change is a broad action. Review the authorized list first so you know what you are resetting and can confirm the result afterward.
- Revoking everything in a panic. You will break clients you rely on and then re-authorize them in a hurry, which is how mistakes compound. Use the worksheet.
- Assuming an unfamiliar entry is an intruder. It may be a browser or a forgotten client. Investigate before you conclude, but do not leave an unknown entry in place while you investigate.
- Assuming revocation hides your public posts. It does not. If your concern is public visibility rather than app access, that is a different task — see the existing guide on hiding your Mastodon network and reviewing search indexing preferences.
- Forgetting two-factor authentication. It lives in the same settings area as sessions and password changes. Review it in the same pass rather than as an afterthought.
Protecting your own footprint after the device is gone
Once the retired device is out of your hands, the remaining work is about the public surface rather than app access. Two things are worth separating in your head:
Public identifiers are leads, not proof. If you search a username and find matching handles, matching photos or matching biographies on several platforms, that is a set of leads. It is not evidence that the accounts belong to one person. People reuse handles, copy bios, and share profile pictures; the same handle on two platforms can belong to two different people. Treat every match as something to corroborate, never as an identification.
A username search is not an account inventory. Searching a handle tells you where that string appears publicly. It does not enumerate every account a person holds, and it does not tell you which accounts are active, dormant, or renamed. If you are reviewing your own footprint, start from the handles you know you have used and check each one deliberately.
If you want a starting point for that self-review, TraceSeek checks a username across 3,000+ platforms and returns public matches in roughly 20-30 seconds, with a free first scan. It reports what is publicly visible; it does not change settings on any platform, guarantee a match, or verify anyone’s identity. For how matches should be read, see the methodology page.
Key facts
- Mastodon account settings allow users to revoke active sessions or authorized apps.
- The same account settings area includes password changes and two-factor authentication.
- Logging out a session, revoking a client app and changing the password are distinct actions with different scope.
- Revoking app access does not delete published posts, change a handle, or affect accounts on other servers.
- A public username match is a lead to corroborate, not proof that accounts belong to the same person.