Block Unknown Apps Without Breaking Sign in With Google
The safest setting for most small teams is the middle one. Allow only apps that request basic sign-in information, then mark the handful of tools you rely on as Trusted.
That setup takes under an hour on any Business plan, which start at $7 per user per month as of Sep 2026. Staff keep their sign-in buttons, and no unreviewed app can read mail or files.
The strictest option blocks every unreviewed app, including sign-in-only ones. It suits teams holding client data, but it generates access requests you must answer promptly.
Why the Default Leaves the Door Open
A new Google Workspace account starts with a permissive rule. Every user can connect any third-party app to their work account, and no administrator is asked first.
That default makes sense for a vendor chasing adoption. For a small business, it means the person who signs up for a trial decides what that trial can read.
Our explainer on what a SaaS tool gets when you sign in with Google covers the individual consent screen. This guide is the company-wide version, where one administrator sets the rule for everyone.
Where the Setting Lives in the Admin Console
Sign in to the Admin console with an account holding the Service Settings administrator privilege. A super administrator has it, and a delegated admin needs it granted explicitly.
Open the menu and go to Security, then Access and data control, then API controls. Everything in this guide happens on that page or one click below it.
The page has three parts worth knowing. App access control handles third-party apps, the Google services list decides which services count as restricted, and domain-wide delegation covers server-to-server integrations.
Changes usually take effect within 24 hours, although many apply sooner. Plan edits for a quiet afternoon rather than just before a client deadline.
Four Access Levels and Three Defaults Side by Side
- ● Trusted reaches restricted services
- ● Limited stays on unrestricted ones
- ● Blocked reaches nothing
Google gives each configured app one of four access levels. Every app nobody has configured falls under a single default setting with three possible values.
| Setting | Applies to | What the app can reach | Sensible use |
|---|---|---|---|
| Trusted | One configured app | All services, including restricted ones | Core tools such as your CRM or backup service |
| Specific Google data | One configured app | Only the scopes you choose | A tool that needs calendar but not mail |
| Limited | One configured app | Only unrestricted services | Low-risk utilities you tolerate but do not rely on |
| Blocked | One configured app | No Google data at all | A tool you have decided against |
| Allow users to access any third-party apps | Every unconfigured app | Whatever the user approves | The out-of-the-box default |
| Allow only apps requesting basic info needed for Sign in with Google | Every unconfigured app | Name, email address and profile picture | Most teams of five to fifty |
| Do not allow users to access any third-party apps | Every unconfigured app | Nothing until you configure it | Teams holding regulated or client data |
The last three rows describe the rule for apps nobody has reviewed. The first four describe exceptions you create one app at a time.
Specific Google data is the underused row. It lets you approve a scheduling tool for calendar access while refusing the mail scope it also requests.
The Default Setting Most Small Teams Should Choose
The middle default is the practical choice for most offices. Google describes it as allowing apps that request only basic profile details, meaning name, email address and profile picture.
Sign-in-only tools keep working without an admin ticket. A tool that asks to read Gmail or edit Drive files is refused until someone reviews it.
This is the same distinction between identity and access that applies on an individual consent screen. The difference is that the company now makes the call instead of whoever clicked first.
Staff can ask for access to a refused app when the request setting is switched on. Requests appear in an Apps pending review list, which turns shadow tools into a visible queue.
Restricting Gmail and Drive Cuts Off Existing Apps
- ● Trust the tools you keep first
- ● Untrusted tokens are revoked
- ● Test on a small group
The default setting governs new connections. Restricting a service is the stronger lever, because it changes what already-connected apps can do.
Under Manage Google Services, you can mark Gmail, Drive, Calendar and other services as Restricted. Only apps set to Trusted or Specific Google data can then reach them.
Google is explicit about the consequence. Previously installed apps you have not trusted stop working, and their tokens are revoked.
For Gmail, Drive and Chat, you can go narrower and restrict only high-risk scopes. Full Drive access, reading mail and sending mail sit in that high-risk group.
This is why the order matters. Trust the tools you depend on first, then restrict the service, or your backup tool and email sequencer fail overnight.
A Rollout Order That Avoids a Monday Morning Outage
Start by opening the accessed apps list and copying it into a shared sheet. It shows which third-party apps your users have already authorized, with the scopes each one holds.
Allow for a delay before trusting it completely. Google notes the list updates about 48 hours after a token is granted or revoked, and new app details can take 24 to 48 hours.
Sort every entry into keep, replace or remove. Ask the person who connected each tool whether it still does a job, because an admin guessing from app names gets this wrong.
Configure each keep tool as Trusted or Specific Google data, searching by app name or OAuth client ID. Set each remove tool to Blocked so it can no longer reach Google data.
Only then change the company-wide rules. Switch the unconfigured apps default to the basic sign-in option and turn on access requests in the same session.
Restrict Gmail and Drive last, after a week without surprises. By then the trusted list reflects what people actually use rather than what the inventory suggested.
Run the change on a test organizational unit first if you have one. Moving two or three volunteers there gives you a week of warning before the whole company follows.
The inventory step overlaps heavily with a subscription audit. Our guide to auditing SaaS subscriptions and cutting wasted seats uses billing records to find the same tools from the other direction.
Judging an Access Request in Two Minutes
Once requests are switched on, the policy lives or dies on response time. A request left for a week teaches staff to use personal accounts instead.
Start with the job the tool was requested for. A transcription tool needs calendar access to join meetings, but a request for full Drive access on top of that deserves a question.
Then check whether a narrower grant would work. Specific Google data lets you approve the calendar scope alone, which often satisfies the requester without opening everything else.
Next, look at who publishes the app and what happens to the data. A vendor with a clear deletion process and a signed data processing agreement is an easier yes than an anonymous extension.
Finally, ask whether something already in your stack does the same job. Duplicate tools double the access surface and the bill, so a polite no with an alternative is often the best answer.
Record each decision in one line, with the app, the scopes approved and the reason. That note is what the next administrator reads when the same request arrives six months later.
What Business Starter Can and Cannot Do Here
API controls sit in the security section of every business Admin console. The limits appear in the more advanced tools layered on top of them.
Pricing sets the context. As of Sep 2026, Google lists Business Starter at $7, Business Standard at $14 and Business Plus at $22 per user per month on annual plans.
Business plans cap out at 300 users, and a 14-day trial is available. Confirm current pricing on the official site, since introductory discounts come and go.
Context-Aware Access is the notable gap. It controls access by device, location and IP address, and Google lists it only for Frontline, Enterprise, Education Standard and Plus, and Cloud Identity Premium editions.
None of the Business plans appear on that list. A small team gets app-level control from API controls but not device-aware rules, which is usually an acceptable trade.
Before paying for a higher tier, check whether the feature you want is actually single sign-on or provisioning. Our look at whether SSO is worth the enterprise upgrade breaks down what that jump buys.
How Microsoft 365 Handles the Same Decision
Microsoft calls this setting user consent. Its default lets users approve apps for permissions that do not need admin consent, which Microsoft notes can include reading their own mailbox.
Administrators change it in the Microsoft Entra admin center under Enterprise apps, then Consent and permissions, then User consent settings. Microsoft recommends allowing consent only for apps from verified publishers.
The built-in middle option is called Allow user consent for apps from verified publishers, for selected permissions. It plays roughly the role of the basic sign-in option in Google Workspace.
One difference matters for cleanup. Microsoft states that changing consent settings affects only future consents, and existing grants remain until you revoke them separately.
Teams weighing the two suites for other reasons can read our Google Workspace versus Microsoft 365 comparison. App governance is rarely the deciding factor, but it is worth knowing both sides work similarly.
Which Lockdown Level Fits Your Team
- ● Solo owners can skip the policy
- ● Small teams need the middle option
- ● Client data needs restricted services
Solo owner with one Workspace account: skip the company policy and review connected apps twice a year. Your personal third-party access page does the same job with less setup.
Team of three to twenty with no regulated data: choose the basic sign-in default and enable access requests. Trust your four or five core tools, and leave services unrestricted for now.
Agency or consultancy holding client files: use the basic sign-in default and restrict Drive and Gmail high-risk scopes. Client contracts often require knowing which processors touch their data.
Business with high staff turnover: block unconfigured apps entirely and answer requests weekly. Every departure otherwise leaves behind connections nobody remembers approving.
Team already paying for an Enterprise edition: add Context-Aware Access on top of API controls. Device and location rules close gaps that app-level settings cannot reach.
What the Controls Will Not Catch
Revoking a token stops future access, not past collection. Anything a tool already copied stays on its servers until you request deletion under its own policy.
Google also notes that API controls do not govern Workspace Integrations, the third-party connectors used with Gemini. Blocking an app does not stop its integration, so review those settings separately.
Personal Google accounts sit outside your Admin console entirely. An employee who forwards work mail to a personal address can connect anything there.
Departures remain the moment this all gets tested. Our software offboarding checklist for a small team puts connected-app review in its proper place in the sequence.
The Short Version for Your Next Admin Session
Export the accessed apps list, trust the tools you keep, and switch unconfigured apps to the basic sign-in option. That combination blocks most accidental oversharing without disrupting anyone.
Restrict Gmail and Drive only after a week of quiet, because that step revokes untrusted tokens. Then set a calendar reminder to review pending requests and the accessed list every quarter.
App controls limit what a signed-in account can hand over, but they assume the sign-in itself is genuine. Enforcing 2-Step Verification in Google Workspace closes that gap with a rollout that avoids locking staff out.
FAQ
Can I block third-party apps in Google Workspace?
Yes. In the Admin console go to Security, then Access and data control, then API controls, and change the setting for unconfigured third-party apps. Choosing the option that blocks all third-party apps stops staff connecting any app you have not reviewed.
Will blocking third-party apps stop employees using Sign in with Google?
Only if you pick the middle option. Google offers a setting that still allows apps asking for nothing beyond name, email address and profile picture, which keeps sign-in buttons working while blocking data access.
Does blocking an app remove access it already has?
Restricting a service such as Gmail or Drive does. Google states that apps you have not trusted stop working and their tokens are revoked. Changing the setting for unconfigured apps is aimed at new connections, so review the accessed apps list as well.
How do I see which apps employees have connected to Google Workspace?
The accessed apps list in API controls shows apps users have authorized. Google notes the list updates about 48 hours after a token is granted or revoked, so very recent connections may not appear yet.
Do employees need admin approval to connect apps to Google Workspace?
Not by default. Workspace does not force admin approval, so any user can connect any app until an administrator changes the unconfigured apps setting. Users can then request access, and requests land in a review list.
Sources
- Control which apps access Google Workspace data (Google Workspace Admin Help) — checked 2026-09-30
- Control which third-party and internal apps access Google Workspace data (Google Workspace Admin Help) — checked 2026-09-30
- Protect your business with Context-Aware Access (Google Workspace Admin Help) — checked 2026-09-30
- Manage third-party apps and services connected to your Google Account (Google Account Help) — checked 2026-09-30
- Google Workspace pricing — checked 2026-09-30
- Configure how users consent to applications (Microsoft Entra ID, Microsoft Learn) — checked 2026-09-30
Some links may be affiliate links. We may earn a commission at no extra cost to you.
How this article was made: it was drafted with AI assistance from the official sources listed above, and its figures were checked against those pages on the dates shown. It is not based on personal hands-on testing.
Comments
Post a Comment