The App Is Gone, but the Connection May Remain
A calendar helper, document converter, or scheduling service asks to connect to an account. You approve it, finish the task, and forget about it. Months later, deleting the app from your phone may leave that account connection untouched. The software is out of sight; the permission deserves a separate check.
Connected apps can make useful features possible without receiving your main account password. They can also accumulate access you no longer need. A careful audit identifies each connection, explains its purpose, and removes unnecessary permissions without accidentally cutting off the way you sign in.
Start with one personal account, preferably your primary email or cloud storage account. Finish reviewing it before moving to another. A short, understandable list is more useful than a heroic afternoon of clicking every revoke button in sight.
Find Connections Inside the Account
Open the provider through a saved bookmark, its official app, or an address you already know. Go to account settings and look for connected apps, linked services, integrations, or third-party access. Read the provider's help if the menu is unclear. Avoid installing a cleanup extension to perform a review the account already supports.
For Google accounts, the linked-apps area distinguishes sign-in connections from access to account data. On GitHub, Settings and Applications includes separate lists for authorized OAuth apps and authorized GitHub Apps. These examples show why one familiar app name may appear in more than one place.
Check which account is selected before making changes. A personal address, an old school account, and a work identity can have very different connection lists. For work or school accounts, follow your organization's process. Some permissions were approved by an administrator and cannot be removed by an individual user.
This review complements an audit of app permissions on your phone. Device permissions control capabilities such as camera access. Account connections control access granted through an online service. Review both layers rather than assuming that removing one removes the other.
Separate Sign-In From Data Access
A button that lets you sign in through an existing account and permission to read that account's documents solve different problems. They may be presented during the same setup, but they should receive separate decisions.
A sign-in connection establishes your identity to another service and may share basic profile information. A data connection grants specific capabilities, such as reading calendar events or managing files. An account link can also work in the other direction, allowing your main provider to access information held by the connected service.
Open the details of each connection. Write down what the permission actually says, rather than summarizing everything as “has my account.” Look for whether it can view, copy, create, modify, delete, send, or act on your behalf. Reading a calendar and changing its events deserve different explanations.
If an app has several connection types, inspect all of them. Removing its sign-in link may leave a separate data permission in place. Revoking file access may leave its own account, saved information, and ordinary login session intact. Read the confirmation dialog for the specific connection you are changing.
Give Each Connection a Current Job
Make a small inventory with five entries per app: its name and developer, the connected account, the granted capabilities, the feature you use, and your decision. Keep passwords and secret tokens out of this record. The purpose is to document access, not collect credentials in another place.
Use three decisions:
- Keep: the app is recognized, the feature is still useful, and the permissions fit that feature.
- Remove: the task is finished, the service is unused, or the access is broader than you are willing to allow.
- Investigate: the developer, purpose, or effect of removal is unclear.
For example, a scheduling service you use weekly may have a current reason to read availability and create events. A converter used once last year is harder to justify keeping connected to an entire document library. Treat these as questions about your actual use, not rules that every scheduling or conversion tool is safe or unsafe.
Prioritize access to email, private files, contacts, repositories, and anything that can send or publish in your name. A familiar icon is not enough to explain powerful permissions. Check the developer information available from the provider and compare it with the service you deliberately use.
Preserve a Working Way Back In
Before removing a sign-in connection for a service you want to keep, open that service through your usual trusted route. Check its account settings for supported alternative sign-in and recovery methods. Some services let you add a password or passkey; others rely on the external identity provider.
If an alternative is supported, configure it through the service's own settings and test it in a separate browser session while your current session stays open. Confirm that you reach the same account with the same files, purchases, or subscription. An empty account with the same email address is not proof that the original account remains accessible.
Do not assume that pressing a password-reset button will always create an independent login. If the service does not offer a supported alternative, keep the sign-in connection while investigating or export what you need before closing that service's account. There is no prize for producing a cleaner permissions list by locking yourself out.
For routine cleanup, verify recovery before revocation. If a connection is clearly malicious or actively exposing data, containment takes priority; account recovery can follow through a trusted route.
Revoke One Connection and Test the Result
Begin with a recognized app you no longer use. If it contains information you need, export that information first and confirm the export opens. Then remove the relevant permission from the account provider's connection list. Record the date and the exact connection type removed.
Return to the list and confirm that the permission is absent. If you kept the app, test the feature you still want. A calendar may stop synchronizing while the app's independent login continues to work. That is an expected consequence of removing calendar access, not necessarily an account failure.
Change one connection at a time. If a useful feature breaks, determine which permission it requires before restoring access. Where narrower options exist, approve only those. If the service offers an all-or-nothing permission bundle, decide whether the feature is worth that bundle rather than accepting it automatically.
Uninstalling a local app, signing out of a browser, changing a password, and revoking a connected app are separate controls. Do not assume one action has completed the others. Review the provider's actual connection list after the change.
Close the Data and Billing Loose Ends
Revocation addresses the account access granted through that connection. It does not retrieve information an app already copied. A service may still hold imported documents, contacts, or other information in its own account.
If you are leaving the service, use its account settings to review stored data, export anything needed, and request deletion where appropriate. Check subscription cancellation separately. Disconnecting an integration is not a reliable way to cancel billing or delete the service's account.
Keep a brief record of any deletion or cancellation request and its confirmation. This gives you something concrete to check later instead of trying to remember whether you removed access, closed the account, or merely deleted an app icon.
Escalate Connections You Did Not Approve
An unfamiliar name may belong to a forgotten service or renamed developer. Investigate through the provider's details and your own records. Do not reconnect it merely to discover what it does, and do not follow a surprise message asking you to restore permission.
If the connection comes with unexplained sent messages, changed files, or unfamiliar sign-ins, preserve its name, permissions, and any available authorization time. Then use a trusted device and the provider's security controls to revoke suspicious access and review activity, sessions, and recovery settings.
First verify unexpected account security alerts independently. If compromise is confirmed, a personal cybersecurity incident response kit helps keep containment and recovery organized. A routine permissions audit should not become improvised incident response on a potentially affected device.
Repeat the review after ending a project, leaving a service, or changing how you use an account. Keep the inventory simple enough to revisit. Every retained connection should have a current purpose, understandable permissions, and a sign-in path you have deliberately chosen to keep.