Your account can have more than a password and a sign-in method to review. Apps and websites may remain connected through federated sign-in or through permissions to account data. Depending on the permissions granted, those connections can involve services such as Gmail, Drive, Calendar, Photos, and Contacts. Google describes the types of access that third-party apps may request.
This guide is not a security test and does not judge any particular app. It is an editorial practical template for building an inventory of external access, checking what each app can read, create, edit, delete, or share, and removing access that is no longer needed. Repeating the review on a schedule you choose, and after changing jobs, leaving a project, or stopping a service, is an editorial recommendation in this article rather than a provider-mandated interval.
What should you review?
Do not rely on the app name alone. A connection may be about how you sign in, or it may grant the app permission to account data. Keep two questions separate:
- How do I sign in? Do you use Sign in with Google, Sign in with Apple, or a Microsoft-linked sign-in route?
- What can the app do? Can it read, create, edit, delete, or share data?
Google provides a linked-apps page for reviewing connections, inspecting permissions, and removing access. See Google’s instructions for managing links between a Google Account and third-party apps. When you inspect a permission, record the specific data or action rather than recording only the product name.
A practical review workflow
- Start with your main accounts. Open the security or account-connections page for each provider you use. Reviewing one provider does not cover the others.
- Create a small inventory. Record the app name, connection method, visible permissions, and the account or team that depends on it.
- Classify the connections. Mark apps you no longer use, do not recognize, or that appear to request broader access than their function would suggest. This classification is a practical suggestion in this article, not proof that an app is malicious.
- Inspect the details. Ask whether the app really needs read access, or whether it needs to create, edit, delete, or share data. If you cannot explain a permission, mark it for investigation rather than treating that fact alone as a final verdict.
- Check dependencies before removal. Note any workflow or data that relies on the app. Removing permissions can cause some app features to stop working. Google notes that app features may stop after access is removed.
- Remove unnecessary access. After confirming that the app is no longer needed, use the removal option provided by the relevant provider.
- Separate revocation from deletion. If you want data already copied by the app deleted, contact the developer separately. Revoking access may stop future access, but it does not necessarily delete data the developer retained. Google explains the distinction between revoked access and retained data.
Google: review the connection and the permission
For a Google Account, use the linked-apps page to review connections, inspect permissions, and select Remove access. Google documents this review and removal process. Depending on what you approved, permissions may involve Gmail, Drive, Calendar, Photos, or Contacts. Google describes the account data that third-party developer apps may request.
Before granting new access, Google advises reviewing the developer’s privacy policy and security disclosures. See Google’s guidance on checking the developer before granting access. This is not a certification that an app is suitable for you; it is a review step to record in your inventory.
Removing a connection also does not necessarily close the separate account held by the outside service. Google states that the Google Account and the linked app account can remain distinct. Google explains the relationship between the two accounts. If your goal is to close the third-party account or request deletion of its data, use the third party’s process rather than relying only on connection removal.
Apple: review Sign in with Apple
On an iPhone or iPad, a user can open Settings, select their name, and then select Sign in with Apple to review connected apps. On the web, Apple Account settings provide Sign-In & Security followed by Sign in with Apple. Selecting an app allows the user to stop using Sign in with Apple for that app. Apple documents these paths and the option to stop using the sign-in method.
For this review, record the app name and whether you still need to sign in to it. If you stop using Sign in with Apple, test the app’s available sign-in or account-management path afterwards; that is a test recommendation in this article, not a guaranteed result or a claim about every app.
Microsoft Entra: do not rely only on an individual user review
For work or school accounts, users can review and remove many non-Microsoft applications through the My Apps portal. Microsoft Entra documents the consent experience and application review. An individual user’s view may not be the complete organizational picture, so the responsible team should maintain an approved-app record under its own policy.
For small and medium-sized organizations, this is an editorial recommendation: maintain an approved-app list, require the least privilege needed, include publisher status in the review, and inspect organization-wide consent. Microsoft recommends restricting user consent to verified publishers and selected permissions, and Microsoft Entra administrators can configure user-consent policies to reduce the risk of malicious or excessive application permissions. Microsoft explains restrictions for verified publishers and selected permissions and user-consent policy configuration.
Record the decision instead of deleting blindly
| Question | What to record | Action suggested by this template |
|---|---|---|
| Do I recognize the app? | Name and displayed owner or developer | If not, move it to an investigation list |
| Do I still use it? | Connected service or workflow | If not needed, check dependencies and remove access |
| What is the permission level? | Specific data and actions | Compare it with the expected function and request the least practical access |
| Do I want earlier data deleted? | What the app may have retained | Contact the developer separately from revoking access |
Bottom line
Treat third-party access as an account-permission inventory, not merely a list of app names. Review Google, Apple, and Microsoft through their respective paths; inspect data and actions; remove stale or unnecessary access after recording dependencies; and keep a clear distinction between stopping future access and deleting data already held by a developer. The right review interval, record-retention rule, and approved-app list are operational decisions for the individual or team to set according to its needs.