In modern workplaces, Conditional Access (CA) policies are the backbone of Microsoft 365 security. By applying rules that require multifactor authentication (MFA), compliant devices, or secure locations, organizations significantly reduce unauthorized access to sensitive data. However, a major blind spot emerges when employees (or attackers) use Unmanaged Google Doc accounts with your company’s domain, to log into approved third-party apps secured with Microsoft 365 SSO. This loophole allows them to bypass the CA policies designed to safeguard corporate assets.

This blog highlights why these Google doc accounts pose a threat, how they allow users to sidestep Microsoft 365 security, and the safeguards you can implement.

We’ve named this vulnerability the “G-Door”.

Blog by: Jeremy Pot

---

---

1. The Core Threat: How Google Accounts Undermine M365 Security

a) Circumventing M365 Conditional Access and Device Compliance

By creating Google Doc accounts using a corporate domain (e.g., [email protected]), users or attackers bypass Microsoft 365 Conditional Access (CA) policies entirely. This means no MFA, no device posture checks, and no geolocation restrictions. Anyone can log in from unpatched or unauthorized devices—evading the security controls you thought were mandatory.

Although users won’t be able to access Microsoft 365 applications and data, they will be able to access files on Google Docs, and possibly login to third-party applications allowing “Sign in with Google.”.

b) User Activity & Compliance Violation

When Google accounts are used, they won’t appear in M365 Admin Center logs. This lack of visibility hinders incident response, making it difficult to spot anomalies such as suspicious sign-in locations or repeated failed login attempts. And data access and storage aren’t tracked, audited, or controlled under official M365 policies.

c) Data Exposure

Sensitive information may be stored, transferred and shared to and from Google Drives, and any documents created in Google Docs under unmanaged accounts won’t be subject to your organization’s DLP or AIP policies. Consequently, corporate data remains beyond the reach of your established data protection measures and legal requirements, increasing the risk of accidental or malicious disclosure.

d) Persistent Access after account compromise

Another significant risk emerges if attackers compromise a user’s Microsoft 365 account. They can leverage that access to create a personal Google Doc account tied to the same corporate email address, effectively establishing a separate identity to access third-party applications. Even if the compromised M365 credentials are later revoked, the attackers could maintain persistent access to those apps via the newly created Google account.

e) Inadequate Offboarding

Offboarding in M365 typically revokes access to all data and federated third-party applications. However, if an employee’s corporate email was ever tied to an unmanaged Google account, they may retain unauthorized access to connected apps or data repositories.

f) Unrestricted Third-Party Signups

A Google account linked to your company domain can be used to register for any external service that supports “Sign in with Google.” Even if your M365 tenant enforces strict controls for new applications, a personal Google identity can circumvent your approved software list entirely.

g) Erosion of Entra Group-Based Access Controls

Many organizations configure access to third-party apps based on Entra (Azure AD) group memberships. But if a user logs in with an unmanaged Google Workspace account using your domain, those group checks can be bypassed. The third-party app may not validate the group, see @yourcompany.com as valid and inadvertently grant access—ignoring the specific Entra group memberships you intended to enforce.

---

---

2. How Users Can Sign Up for Personal Google Accounts and a Free Google Docs Essentials Starter Plan with Your Domain

One of the overlooked risks to corporate security is how easily users can create personal Google accounts using their company email addresses. In addition, they can even sign up for the free Google Docs Essentials Starter plan under your domain—all without requiring any admin approval from your organization. Here’s how that can happen:

For a personal Google account:

1. Go to the Google Docs page.
2. Click Sign in (not the “Docs for work” option).
3. Choose Create account and select For my personal use.
4. Enter your personal details (name, date of birth, etc.).
5. On the “Choose how you’ll sign in” screen, select Use your email address instead of creating a Gmail address.
6. Input your company email address (e.g., [email protected]) to complete the account setup.

For a free “business” Google Docs Essentials Starter plan:

1. Navigate to the Google Docs Essentials Starter Signup Page.
2. Enter your company domain (e.g., yourcompany.com).
3. Complete the sign-up form for the free Essentials Starter.
4. Instantly spin up a “business” workspace under your organization’s domain—with no IT or admin knowledge.

In either scenario, users end up with an unmanaged Google identity (personal or “starter workspace”) associated with your domain. This identity can then be used to access Google services like Docs, Sheets, Drive, and third-party apps via “Sign in with Google”—bypassing your Microsoft 365 Conditional Access and Data Protection policies.

---

---

3. Mitigation Strategies

a) Claim a Business Google Workspace & Register All Aliases

If there are currently employees using personal Google doc accounts, or applications in your environment that are vulnerable to G-Door sign-in, registering all users in a managed Google Workspace is highly recommended.

• Verify Your Domain: Ensure you have claimed your domain with Google Workspace.
• Manage personal accounts: Regularly check and onboard employees who’ve signed up with their business email address.
• Create Accounts or Aliases for Each Corporate Email: Proactively set up or reserve every legitimate alias under the official Google Workspace environment. This step prevents anyone from using @yourcompany.com as a personal account outside your control.
• Enable Entra ID SSO: Connect Google Workspace to your Entra ID environment, to ensure a unified compliant login experience across both environments.
• Google Application Registrations: Configure policies and review application registrations, to prevent unapproved access to applications.

These actions should prevent most serious security risks. Larger companies could look into Entra ID Google Account Provisioning, although alias provisioning is currently not yet supported.

Companies that chose to not allow users to sign in with google workspace, could disable all accounts in Google Workspace, while still preventing employees to sign up with personal accounts.

Sources:
* Find and add unmanaged users – Google Workspace Admin Help
* Control which third-party & internal apps access Google Workspace data
* Setting up SSO – Google Workspace Admin Help
* Microsoft Entra ID (formerly Azure AD) user provisioning and single sign-on  |  Cloud Architecture Center  |  Google Cloud
* Tutorial: Configure G Suite for automatic user provisioning with Microsoft Entra ID – Microsoft Entra ID | Microsoft Learn

b) Reevaluate Corporate Application Authentication Settings.

If your corporate applications allow general sign-ins—where multi-tenant applications from identity providers can be used—and do not support tenant-specific SSO registration (i.e., only users from your authorized tenant can sign in), you introduce a significant security gap. This means anyone with a matching email domain from a supported IDP, could potentially access the app, bypassing your established Conditional Access rules and security controls.

• General Application Sign-Ins:
  • Accept logins from multi-tenant applications from identity providers from any user claiming the correct domain.
  • Offer little to no tenant isolation, increasing the risk of unauthorized access.
• Tenant-Specific Application Sign-Ins:
  • Restrict authentication to a single, verified tenant (e.g., your organization’s Azure AD).
  • Requires manual creation of app registrations in your Entra ID environment to be configured in your third-party application.
  • Ensure that only users with direct access to your tenant can gain access, enabling more granular control and visibility over who is using the app.

Given these differences, consider reclassifying applications that don’t support tenant-specific SSO, or explore alternative solutions that align with your security requirements. Ensuring all apps and services adhere to your organization’s identity and access management standards is critical for maintaining a strong security posture.

c) Disable IDPs and enable MFA for third-party applications

If possible, disable “Sign in with Google” and other unmanaged IDPs for third-party applications currently in use. If you cannot completely block it, restrict access within the application, and ensure that new, possible personal google accounts, do not automatically have access to data. Where possible, enable additional MFA within the application, to be verified after SSO login.

d) Block Google Workspace Verification Emails via Exchange Rules

A practical way to hinder unauthorized personal or “free” Google Workspace signups under your corporate domain is to block the verification emails altogether. By configuring Exchange mail flow rules to intercept messages from [email protected] with the subject line “Verify your email address,” you effectively prevent these emails from ever reaching end users. Without the verification link, users (or attackers) are unable to complete the Google Workspace registration process using your corporate domain.

e) Configure Azure Sentinel for Unified Monitoring of Entra ID and Google Workspace

Should you choose to allow employees to use Google Workspace Doc Accounts, it will be vital to have visibility into your organization’s Google Workspace activities. This can be accomplished with Azure Sentinel, which allows you to centralize and correlate authentication events, file sharing activities, and other critical indicators from both Entra ID (Azure AD) and Google Workspace into a single pane of glass. By consolidating data from these platforms, Azure Sentinel provides a unified view that enhances your ability to detect, investigate, and respond to security threats more effectively, ensuring streamlined monitoring across your Microsoft 365 and Google environments.

f) Employee Awareness & Training

Educate employees on the security risks and compliance issues associated with using Google accounts. Explain how “Sign in with Google” can bypass Conditional Access by avoiding MFA and device checks. Clearly define acceptable methods for accessing and storing corporate data, ensuring everyone follows approved security protocols. By raising awareness and understanding, you can minimize breaches and enhance your organization’s overall security.

g) Revamp Offboarding

Enhance your offboarding procedures by thoroughly checking for any personal Google accounts associated with the employee’s corporate email. If you identify unmanaged Google logins, ensure that these accounts are disabled or deleted before the employee departs. Additionally, disable all third-party application accounts linked to the employee, avoid relying solely on SSO mechanisms to prevent authentication, as unmanaged identity providers could still successfully authenticate the user.

---

---

Final Thoughts

Microsoft 365 Device Management and Conditional Access policies are crucial for safeguarding your organization against unauthorized access. Yet, Google accounts tied to your domain can serve as a backdoor around these very controls—unless you proactively manage and reserve those aliases in an official business Workspace.

This blog focusses on Google, if you are serious about security, extend your attention to any identity provider that allows authentication with company email addresses, and train your workforce on the potential risks of misusing unmanaged accounts.

On the positive side, using Google Workspace Essentials, a free version, in addition to Microsoft 365 does provide an increased user experience, as not all websites support Microsoft SSO logins. The risk is low if it’s managed properly.

Our message to Google:
While organizations can—and should—take proactive measures to secure their environments, and educate their workforce, it is essential that you provide stronger guardrails to prevent unauthorized usage of company domains for personal and workspace accounts. We urge you to implement better default restrictions on domain-based sign-ups, and more robust domain verification. These enhancements would go a long way toward closing this security loophole. Cybersecurity is a shared responsibility, and your role is critical to safeguarding corporate data.

Our message to ISVs:
While integrating third-party Identity Providers (IDPs) like Google Workspace can enhance user convenience and streamline authentication processes, it also introduces potential security vulnerabilities. It is essential not to blindly trust any new sign-in claims from these IDPs. Instead, implement robust verification mechanisms to ensure that each authentication attempt is legitimate and intended by the user, and IT department. Additionally, provide the capability to disable certain IDPs at tenant level to maintain tighter control over who can access your applications.

---

---