Which Apps Can Access Your Google or Microsoft Account?

Signing into another service with a Google or Microsoft account can be convenient. Instead of creating another password, the user authorises the service to use an existing identity. It takes a few seconds, and the application handles the rest.

However, some applications request access to far more than basic sign-in information. Depending on what the user approves, a connected application may be able to read email, view files, access calendars, read contacts, act on behalf of the signed-in user, or maintain access when the user is not actively using it. That access may persist long after the original task is complete — and long after the user has forgotten the application exists.

Deleting an application from a device, cancelling a subscription or changing the account password does not necessarily remove every previously granted permission. Users and administrators should therefore review connected applications regularly and remove anything that is unfamiliar, unused, excessive, unsupported or no longer required.

Last checked: 29 July 2026.

What is a connected application?

A connected application is an external service that has been linked to a Google or Microsoft account. The connection is typically created when a user selects Sign in with Google, Sign in with Microsoft, or authorises an application to access specific data or services. Common examples include:

• Meeting schedulers and calendar tools
• CRM systems and sales platforms
• Document-signing services
• Cloud backup applications
• Automation and workflow platforms
• AI services and writing assistants
• Accounting software
• Survey and form tools
• Email add-ons and productivity services
• Mobile applications requesting account access

Once authorised, the application typically uses a permission token to access approved information or services. It does not store or receive the account password.

Some visitor passes provide basic identity only. Others allow access to specific data. Some permit actions — such as sending email or editing files. Some allow continuing access even when the user is not signed in. Some apply to one person; others may be approved across an entire organisation.

What does “Sign in with Google or Microsoft” mean?

Using a trusted identity provider to sign into another service can improve security. Potential benefits include fewer separate passwords to manage, support for multi-factor authentication (MFA), central account suspension, fewer credentials held by smaller services, easier account recovery and improved sign-in monitoring.

However, “Sign in with” describes how the application identifies the user — not everything it may be allowed to do afterwards. There is an important distinction between two types of access:

The issue is not federated sign-in itself, which can be a sound security practice. The issue is understanding and actively controlling the permissions requested.

What is OAuth?

OAuth is a widely used authorisation framework that lets one service access permitted information from another without requiring the user to hand over their password. When an application uses OAuth to access a Google or Microsoft account, the process normally involves the following steps:

1. 1The user opens an application or selects a sign-in option.
2. 2The application redirects the user to Google or Microsoft.
3. 3Google or Microsoft authenticates the user.
4. 4A consent screen explains the permissions the application is requesting.
5. 5The user or administrator approves or rejects the request.
6. 6The application receives a token representing the authorised access.

It is important to distinguish three related concepts: authentication establishes who the user is; authorisation defines what the application may do; consent records the user's or administrator's decision. The token enables ongoing access within those agreed limits. A refresh token may also be issued, allowing an application to maintain access over a longer period without the user re-approving each time.

OAuth itself is not insecure. Risks typically arise through deceptive applications requesting excessive permissions, poor consent decisions, compromised applications, stale access that is never revoked, weak governance or malicious consent requests designed to trick users into approving access.

Permissions in plain English

The consent screen presented when an application requests access should describe the permissions it is asking for. The exact permission names differ between Google and Microsoft. The table below illustrates common permission categories in plain language. The presence of a permission shows capability, not necessarily what the application has already done.

Why old connections become risky

Applications accumulate over time. Free trials, former CRM systems, old meeting schedulers, abandoned productivity tools, survey platforms, file-conversion services, accounting integrations and AI applications can all create connections that persist long after the original purpose ends. An application may become riskier because:

• It is no longer used by the business
• The developer has stopped maintaining it
• The company has been acquired or changed ownership
• Its terms or privacy policy have changed
• Its infrastructure has been compromised
• The employee who approved it has left
• No internal owner remains
• The business has forgotten why it was connected
• Permissions have expanded since original approval
• The supplier relationship has ended

How to review Google account connections

Google account holders can review third-party applications by visiting their Google Account and navigating to the security or connections area. The current interface may present connections under sections for Sign in with Google, access to Google Account data, linked accounts or other third-party connections. Google may update wording or navigation — users should use the current Google Account security area rather than relying on an old screenshot.

For each application listed, review:

• The application name and developer
• How the account is connected (sign-in, data access, or both)
• Which data or services are accessible
• Whether the application is still actively used
• Whether the connection was intentionally created
• Whether the access requested remains proportionate

Removing a Google connection may stop future access, stop Sign in with Google for that service, prevent linked features from working, and require the user to create another sign-in method with the third-party service.

For Google Workspace accounts, individual users may see their own connections. Administrators have broader controls over which applications are permitted across the organisation — see the Administrator Technical Note below.

How to review Microsoft personal account connections

A Microsoft personal account is typically used for Outlook.com, Hotmail, personal OneDrive, Xbox or a personal Microsoft 365 subscription. Personal account holders can review connected applications and services through their Microsoft account privacy or security settings. The interface may present connected applications, services with account access and recent sign-in activity.

When reviewing connections, take care to distinguish application permissions from Windows privacy permissions, registered devices, active subscriptions and products linked to the account — these are separate items managed in different parts of the account settings.

Microsoft may update the wording and navigation of personal account settings. Users should use the current Microsoft account management area rather than relying on instructions that may no longer match the live interface.

How to review Microsoft work or school account applications

A Microsoft work or school account is normally governed through Microsoft Entra ID (formerly Azure Active Directory). The experience and available controls differ significantly from a personal Microsoft account.

An ordinary user may be able to review applications through the Microsoft My Apps portal, the My Account portal, or permission-management options available within specific applications. However, there are important limitations:

• Users may revoke permissions they personally granted
• Permissions granted by an administrator may not be removable by an ordinary user
• Removing an application tile from My Apps is not necessarily the same as revoking access
• Some applications are assigned by the organisation and cannot be removed by the user
• Some permissions may apply tenant-wide, affecting the whole organisation

If an application is unfamiliar, cannot be removed or appears to have organisation-wide access, the right action is to escalate — not to attempt removal independently. Contact the organisation's IT administrator or security provider.

What happens when you remove access?

Revoking an application's access typically prevents the application from making further authorised requests using the revoked permission. However, it does not automatically:

• Delete the third-party account
• Delete information already copied or processed
• Cancel a subscription
• Remove locally downloaded files
• Undo messages already sent on the user's behalf
• Remove data shared with other parties under previous terms
• Revoke another administrator's separate consent
• Terminate unrelated browser sessions

Removing an application may also affect functionality — calendar synchronisation, cloud backup, automated workflows, file synchronisation or sign-in capability may stop working. Where a critical business integration is involved, check dependencies before revoking access. Depending on circumstances, the user may also need to sign into the third-party service directly, cancel the service, request deletion of retained data, or contact the provider.

Why changing the password may not be enough

Connected applications commonly use tokens rather than repeatedly using the account password. Changing the password protects the front door — it is the right action when credentials may have been stolen, when suspicious sign-ins are present or when the account may have been compromised. However, a password change and an application-consent review solve different problems.

A complete incident response to account compromise may require several actions in combination: change the password, enable or reset MFA, revoke application permissions, terminate sessions, review inbox and forwarding rules, review recovery details, review registered devices, review any administrator changes, and investigate audit logs. No single action addresses every risk.

MFA and consent phishing

Multi-factor authentication protects the authentication step — verifying who is signing in. It does not stop a properly authenticated user from approving a malicious application consent request.

A consent-phishing attack typically works as follows: the user is directed to a genuine Google or Microsoft sign-in page; the user authenticates normally; a consent screen then appears requesting permissions for an unfamiliar or deceptive application; the user approves. The attacker never needs to steal the password or intercept the MFA code — they receive the permission token directly.

Warning signs that a consent request may be malicious include an unfamiliar application, an unexpected consent screen, permissions unrelated to the stated service, requests to read or send email, access to all files, requests for continuing access, an unverified or unclear publisher, urgent pressure to approve, an application reached through an unsolicited message, a misleading application name, or minor spelling variations of a known brand.

Not every unverified publisher is malicious — many legitimate applications have not completed Microsoft's publisher verification programme. However, unverified status alongside unexpected or excessive permissions deserves additional scrutiny.

Warning signs that an app connection needs reviewing

• The user does not recognise it
• Nobody remembers approving it
• The application is no longer used
• The supplier relationship has ended
• It requests access to the full mailbox
• It can send email on behalf of the user
• It can edit or delete files
• It requests ongoing or offline access
• The developer or publisher is unclear
• The privacy policy cannot be found
• The application has changed ownership
• It duplicates an already-approved service
• It was installed for a one-off task
• It relates to a former employee's personal account
• It was approved following an unsolicited message
• It appears to imitate a known brand
• It has no current business owner
• It is no longer supported by the developer
• The application has received a security warning
• It is not present in the approved software register

Immediate steps for individual users

1. 1Review both accounts — check personal and work accounts separately, as they have different controls and different application histories.
2. 2Identify each application — note the name, developer and how the connection was created.
3. 3Check the purpose — understand why it was connected and whether that reason still applies.
4. 4Review the permissions — look specifically for access to email, files, calendars, contacts, send or edit capability, and continuing or offline access.
5. 5Remove unused connections — revoke applications that are clearly no longer needed.
6. 6Escalate unfamiliar business integrations — ask IT or the responsible administrator before removing shared or organisation-managed services.
7. 7Check the third-party account — consider whether to cancel or delete the separate account with that provider.
8. 8Review account security — check recent sign-ins, MFA settings, recovery details, registered devices and active sessions.
9. 9Report suspicious consent — notify the business promptly if an unexpected or unfamiliar consent grant is found.

Practical steps for businesses

Maintain an approved-application register

Record each connected application with its supplier, business owner, purpose, user base, data accessed, permissions, approval date, renewal date, contract reference, risk assessment and offboarding process. An undocumented application cannot be properly reviewed.

Control user consent

Decide which applications ordinary users may approve themselves. Consider restricting consent for applications requesting elevated or sensitive permissions and routing those requests through an administrator approval workflow.

Apply least privilege

Approve only the permissions genuinely required for the application's business function. Where a reduced permission set can meet the requirement, request the reduction before approving.

Review regularly

Carry out periodic reviews of connected and enterprise applications. Remove integrations that are no longer required. Review applications when suppliers change ownership, terms change or when the business changes its technology stack.

Joiners, movers and leavers

Application governance must be part of the identity-management lifecycle. When a member of staff joins, ensure they connect only approved applications. When a member of staff changes role, reassess their application connections and remove access relating to the former role. When a member of staff leaves, disable the identity, revoke sessions, review applications they personally owned or approved, transfer ownership of integrations, and identify any shared automated workflows that may be improperly tied to the departing individual's account.

Disabling a user's account may interrupt legitimate business automations if those workflows were set up under that individual's personal credentials. Identify these before the account is disabled.

Educate staff

Teach staff to read consent screens before approving them. An accept click takes seconds. Reversing an unnecessary permission grant is more complex.

Questions to ask before clicking Allow

1. 1Did I start this sign-in process?
2. 2Do I recognise the application?
3. 3Is the publisher clearly identified?
4. 4Is this the genuine application and not an imitation?
5. 5Why does it need access to my account?
6. 6Does it need access to email?
7. 7Does it need every file or only selected files?
8. 8Does it need to send messages on my behalf?
9. 9Does it need to edit or delete information?
10. 10Does it need continuing access?
11. 11Is the requested access proportionate to the feature being used?
12. 12Is there an already-approved alternative?
13. 13Is this application authorised by the business?
14. 14What information will leave Google or Microsoft?
15. 15Where will that information be stored?
16. 16How long will it be retained?
17. 17Can the data be deleted later?
18. 18Who will support the application?
19. 19What happens when the employee leaves?
20. 20Who will review this access again?

Practical business implications

Password security is only part of account security

Tokens and consent grants must also be reviewed. A well-protected password does not prevent an application from using a permission token that was granted months or years earlier.

Convenience creates long-term connections

One-click sign-in may create a connection that outlives the original task by years. Every convenient shortcut has a corresponding governance requirement.

Users cannot always see tenant-wide risk

An individual user may revoke their personal consent but remain unaware of administrator-granted access that applies across the organisation. Administrators need organisational visibility that individual users do not have.

Removal can affect business processes

Applications should be reviewed before critical permissions are revoked. Removing a key integration without checking dependencies can interrupt business processes, break automated workflows or prevent other users from accessing a shared service.

Data already shared may remain

Revocation closes the connection. It does not guarantee that a third party will delete information it received during the period of access. Where data deletion is required, a separate request may be necessary under the third party's privacy or deletion process.

MFA does not replace consent education

A properly authenticated user can still approve the wrong application. Strong authentication confirms identity; it does not confirm judgement.

The IT Club View

Businesses invest heavily in stronger passwords, MFA, passkeys, endpoint protection and phishing training. These are important. But many organisations pay far less attention to the applications that employees have already authorised — often through entirely legitimate processes that nobody later reviews.

A user can sign into a service, approve a consent screen and give an external application continuing access to business email, files and contacts. Nothing has necessarily been hacked. The risk has been created through a valid permission that nobody later questions.

The solution is not banning all connected applications. Modern businesses depend on integrations. The goal is to ensure each connection has a clear business purpose, a known owner, proportionate permissions, an approved supplier, a review date and an offboarding process.

Related business questions

Does changing my password remove connected apps?

Not necessarily. Connected applications typically use permission tokens rather than storing the account password. Changing the password is the right action when credentials may have been stolen or the account has been compromised. However, it does not automatically revoke application tokens. To remove an application's access, revoke its permissions through the Google or Microsoft account settings directly. Both actions may be required following an account-security incident.

Does Sign in with Google give the app my password?

No. When you use Sign in with Google or Sign in with Microsoft, the application receives a permission token — not your password. The token tells the application which information it is permitted to access. Your actual password remains with Google or Microsoft. This is one reason why revoking a connected application's access requires a separate action in the account settings, not simply changing the password.

Can a connected app read my email?

It depends on the permissions approved. Some applications request only basic identity information such as name and email address. Others request the ability to read email content, access attachments or send messages on the user's behalf. The consent screen should describe what is being requested. If an application holds mail-read or mail-send permissions, it may be able to access message content. Review the permissions listed for each application in the Google or Microsoft account settings.

What happens when I revoke app access?

Revoking access prevents the application from making further authorised requests using the revoked permission. However, it does not delete the third-party account, remove information already transferred, cancel a subscription, undo actions already performed, or automatically delete any data the third party holds. The application may also lose functionality as a result. Where a business integration is involved, check dependencies before revoking access.

Does removing an app delete my data?

Not automatically. Revoking access through Google or Microsoft closes the connection but does not compel the third party to delete information it has already received. Data deletion normally requires a separate request directly to the third-party provider, either through their privacy settings, a deletion request form or a formal erasure request under data-protection law. Reviewing the provider's privacy policy and retention practices is a useful starting point.

Can MFA stop malicious app consent?

No. MFA protects the authentication step — confirming that the person signing in is who they claim to be. It does not prevent that person from then approving a malicious application consent request. In a consent-phishing attack, the user authenticates legitimately through MFA and is then presented with a deceptive consent screen. Approving that screen grants the attacker access without any credential theft. MFA and consent education are complementary protections addressing different risks.

How often should a business review connected apps?

The appropriate frequency depends on the size of the organisation, the volume of integrations and the sensitivity of the data involved. As a starting point, a quarterly review is reasonable for most small businesses. Higher-risk environments or organisations with many third-party integrations may benefit from monthly checks. Reviews should also be triggered by specific events: staff changes, supplier changes, security incidents, application ownership changes and contract renewals.

What should I do if I do not recognise an application?

Do not remove it immediately if it may be a shared business integration. Check with colleagues and the IT team first. Research the application name and publisher before revoking access. If the application is personal and genuinely unrecognised, check when it was last active and what permissions it holds. If it has access to email, files or continuing offline access and cannot be explained, revoking access and reviewing recent account activity is a reasonable precaution.

Operational Heartbeat

Connected-application risk changes as employees approve new applications, permissions expand, suppliers change ownership, developers change terms, users change roles, employees leave, applications become unused, integrations are replaced, tokens remain active, administrator consent is granted, publisher status changes, applications become compromised and new high-risk permissions are introduced.

A recurring review should check connected applications across personal and work accounts, enterprise applications in Entra, OAuth grants in Google Workspace, user and admin consent, application owners, unused applications, last activity dates, high-risk permissions, verified-publisher status, supplier changes, privacy-policy changes, users and groups assigned, service accounts, domain-wide delegation, leaver-owned applications, stale integrations, security alerts and corrective actions.