Auditing Connected Apps on X: Finding Standing Access and Revoking It Safely

Why this set gets overlooked

A password is something you remember. Logged-in devices are something you can look at. Connected apps are different: the moment you clicked allow, they largely vanished from view.

Time makes it worse. Grants typically do not expire, and they do not lapse just because you stopped using the application. An authorization clicked while trialling a scheduling tool can still hold read and write access to your account three to five years later.

Changing the password does not block it, because the grant runs on a platform-issued token unrelated to the password. That is why the authorization list deserves its own check during any security review.

Step one: pull the list

The connected apps list shows each application's name, when it was authorized, and what it can reach. Note four things while going through it:

• The name, and whether you remember it. Sources you cannot place deserve the closest look.
• The authorization date. Older entries are more likely to be forgotten trials.
• The scope. Whether write access is included is the key signal.
• Whether the service still operates. Defunct applications are obvious removals.

Record only at this stage; do not revoke yet. Revocation is immediate, and if the list includes something you still use, revoking while reading is an easy way to break your own setup.

Step two: sort them into tiers

Tier	Signals	Suggested action
High	Write scope, unclear origin, or defunct	Revoke now
Medium	Write scope but in active use; or read-only from an unclear origin	Review, then revoke after short projects finish
Low	Read-only, known origin, still in use	Keep, and note a review date

Write scope is the deciding factor. A read-only grant can at worst read content. Write scope means posting, deleting or editing account content on your behalf. The distinction is set out in read versus write access.

There is another dimension people miss: whether the application holds your own credential. Proper implementations use platform authorization and you never supply a password. If a service asks you to type your password in, it holds a long-lived credential that can sign in directly, and that raises its tier on its own. More on this in reading a tool's privacy policy.

Step three: when and how to revoke

Revoking is unbinding, not deleting data inside that service. Worth knowing in advance: after revocation, the service may still hold whatever it synced earlier. Handling that properly means filing separately under each service's privacy policy, covered in exercising the right to erasure.

Timing depends on the use case:

• One-off projects: revoke as soon as the work finishes rather than keeping it in case you need it later.
• Ongoing services: keep, but check annually whether the scope has widened.
• Unused but never revoked: revoke. There is no case for keeping it.
• Unclear origin: revoke first, then decide whether to re-authorize.

What revocation breaks

Revocation is immediate and not reversible, and continuing to use the service means going through authorization again. In practice three kinds of functionality are affected:

What you revoke	What stops working
A scheduling tool	Queued but unpublished items, and future automatic posting
An analytics tool	Incremental syncing; previously synced history usually stays
A cleanup tool	Any task currently in progress, which typically cannot continue

The second row matters. Revocation affects future syncing, not data already transferred. If that earlier sync carried sensitive content away, revoking does not undo it, and you would have to pursue the service separately.

Step four: make the review a habit

Authorization lists only grow, so a recurring review beats a one-time purge. For the habit side, see the 30-day footprint habit plan for folding this into a fixed rhythm.

Frequency depends on the account. Once a year is enough for a personal account. For a brand or corporate account with shared access, many integrations and staff turnover, quarterly is better, plus an immediate review whenever someone leaves. The corporate case is covered in company accounts and employee posts.

A simple test while reviewing: an application nobody has actively used in six months has no case for keeping its access. Applying that rule clears most of the list, and only the remainder needs individual judgement, which is far faster than a full analysis every time.

Do it alongside two other checks

This review works best alongside two others that together cover the account's main entry points:

• Logged-in devices and two-factor, in the login device audit and enabling two-factor.
• The distribution of sensitive information inside the account, which is the content-side exposure.
• After a takeover, the cleanup order is laid out in the account takeover recovery checklist.

All three take under half an hour together, after which a calendar reminder keeps them on schedule.

About digital-footprint-health.shop

An authorization review covers the account's entry points. digital-footprint-health.shop covers what sits behind them. The tool parses your X archive on your own device, lists where phone numbers, emails and addresses appear and in which years, and returns a 0-100 health score with a prioritised work list. It is read-only, uploads nothing, and needs no credential to show you results. Start with the free audit and see downloading your X archive for the import step. When you want to act, deletion runs per tweet, described in the bulk deletion walkthrough.