Google Workspace Less Secure Apps Retirement: Move mail clients, scanners and devices to OAuth

Google Workspace no longer accepts a username and password from third-party mail, calendar and contacts clients, so any printer, scanner, line-of-business app or old Outlook profile still built that way has either stopped working or survives on an app password. Google calls these clients "less secure apps" (LSA): anything that signs in to IMAP, POP, SMTP, CalDAV, CardDAV or Google Sync with basic authentication instead of OAuth. This guide covers the Google side only: the official timeline as Google published it, which clients and devices are affected, how to find what is left, and the three Google-documented routes for scan-to-email and application mail. It is for Google Workspace administrators, messaging teams and anyone who owns multifunction devices or apps that send mail. For the cross-vendor view of basic authentication, ROPC and app passwords, see the Legacy Authentication and ROPC Retirement Guide; the Microsoft equivalent is the Exchange Online SMTP AUTH Basic Auth Retirement guide.

This is an independent guide from NHI Mgmt Group, based on Google's public documentation as of November 2026. It is not sponsored or reviewed by Google. Product features change, so confirm settings against Google's current documentation.

Key takeaways

• The retirement is finished. Google's final update on its Workspace Updates blog states that less secure apps are no longer supported as of 1 May 2025, after a pause and two date changes; there is no setting left in the Admin console to turn them back on.
• Password sign-in to mail protocols is gone, with one exception. Password-based IMAP, POP, SMTP, CalDAV, CardDAV and Google Sync stopped working; Google's transition page names app passwords as the only remaining password-style access.
• App passwords are a bridge, not a destination. They need 2-Step Verification, are 16-digit static passcodes that bypass the second factor, are unavailable under Advanced Protection or security-key-only 2SV, and Google itself says they are not recommended.
• Scan-to-email has three supported routes. The SMTP relay service (smtp-relay.gmail.com) with IP or SMTP authentication, the Gmail SMTP server with an app password, or the restricted Gmail server (aspmx.l.google.com) for internal recipients only. The relay service is Google's recommended option for devices.
• Each surviving exception is a non-human credential. A device mailbox, relay IP allowlist entry or app password needs an owner, an inventory record and a review date, or it becomes the next forgotten credential in your tenant.

What is changing and why

A less secure app, in Google's definition, is a non-Google app or device that signs in with a Google Account username and password rather than an OAuth token. Basic authentication sends a reusable secret on every connection, cannot carry a second factor, and gives Google no way to apply its sign-in risk checks or to limit what the client can reach. A password typed into a scanner menu also tends to belong to a real user, so the device inherits that person's entire mailbox and Drive access.

OAuth fixes those problems. For mail protocols Google supports the XOAUTH2 SASL mechanism with IMAP AUTHENTICATE, POP AUTH and SMTP AUTH; the client presents an access token obtained through a normal Google sign-in (with whatever 2SV, context-aware access and session controls the tenant enforces) instead of a password. Google's developer documentation gives https://mail.google.com/ as the scope for IMAP, POP and SMTP access, with a narrower gmail.imap_admin scope reserved for service accounts using domain-wide delegation. Tokens can be revoked per app, and a password change no longer silently breaks or silently preserves dozens of embedded copies.

Personal Gmail accounts are treated differently. Google's announcement states that IMAP stays enabled for personal accounts over OAuth and they need no action; the rest of this guide is about Workspace tenants.

Official timeline and current status

All dates below come from Google's own announcement post and Workspace help pages, checked on 8 November 2026. Google moved the final date twice, and its help pages have not all been updated consistently, so the table records both.

Status at 8 November 2026: retired. Workspace accounts do not support sign-in by username and password from third-party apps or devices; OAuth is required, with app passwords as the documented exception. If you read a Google page or a third-party article that says 14 March 2025, that was the announced date before the final update moved it to 1 May 2025. Either way the change is long in effect, and anything that still authenticates today is using OAuth, an app password, or a relay path that does not use a Google password at all.

Who and what is affected

The hardest cases are usually not people. They are the shared "scanner@" or "alerts@" mailbox typed into a device in 2017, the monitoring tool that emails reports, and the finance application that polls an inbox over IMAP. These are non-human identities with a human-style credential, and each needs an owner and a lifecycle like any other machine credential. See the NHI Authentication Guide.

Finding affected systems and identities

Because the switch-off has already happened, discovery now means finding what is broken, what was quietly moved to an app password, and what was moved to an over-broad relay rule.

1. Read the sign-in record. In the Admin console, go to Reporting, Audit and investigation, User log events (or the security investigation tool if you have the Security center privilege). Google documents the login type Google Password as including sign-ins to less secure apps where they were allowed, and Exchange as token exchange such as OAuth. Note Google's caveat: sign-ins from email clients and non-browser apps are not logged there unless they come from a session considered suspicious, so the log is a partial view.
2. List Google Sync devices. Under Devices, Mobile and endpoints, Devices, filter on Type: Google Sync. Anything listed is a phone or tablet that must move to an OAuth app.
3. Inventory app passwords. Ask each user who reports a working legacy client how it signs in. Treat any account with an app password as a finding to record: which app, which device, who owns it, and whether the account is a person or a shared mailbox.
4. Read the SMTP relay settings. Under Apps, Google Workspace, Gmail, Routing, review every SMTP relay service entry: the allowed senders option, the IP ranges, whether SMTP authentication and TLS are required. Relay rules added in a hurry during the 2024 to 2025 transition are a common source of over-permissive mail paths.
5. Walk the device estate. For printers and scanners, export the configuration from the print management system or check each device's web interface for an SMTP server of smtp.gmail.com with a stored credential. Ask facilities and print vendors; they often hold the only record.
6. Search code and config. Grep repositories, configuration management and secrets stores for imap.gmail.com, smtp.gmail.com, pop.gmail.com and stored Workspace passwords. Each hit is an app that either broke or holds an app password.
7. Check helpdesk tickets. Tickets from May 2025 onwards that mention "scanner", "cannot send", "IMAP" or "password rejected" are a cheap list of what broke and how it was fixed.

The Google Workspace Audit Log Detection Guide covers the wider log set and how to stream it to a SIEM.

Migration options

People and their mail clients

For people, the answer is almost always to remove the account and add it again choosing "Sign in with Google", which uses OAuth and the tenant's normal sign-in controls. Outlook users who need a desktop client either move to a current Outlook build that supports OAuth to Google or use GWSMO. Do not issue app passwords to people as a convenience; once 2SV is enforced, an app password is a second, phishable, non-expiring way into their mailbox.

Scan-to-email and application mail

Google's "Send email from a printer, scanner, or app" page sets out three options. Values below are Google's.

Configuring the relay safely: the relay setting lives at the top-level organisation only and needs the Gmail Settings administrator privilege. Choose Only addresses in my domains or Only registered Apps users in my domains under Allowed senders, never Any addresses (not recommended). Tick Only accept mail from the specified IP addresses with the narrowest public egress ranges you can, and add Require SMTP Authentication where the device supports it, which also means Require TLS encryption on port 587. Remember that IP-only authentication trusts everything behind that address: a relay entry for a whole office NAT range lets any compromised workstation send mail as any address in your domain. Pair it with SPF, DKIM and DMARC alignment; see the SMTP Security, STARTTLS and MTA-STS Guide for transport hardening.

Decision guidance

• Device supports OAuth for Gmail: use it, with a dedicated mailbox per device class, not a person's account.
• Device supports SMTP AUTH and TLS but not OAuth: SMTP relay with IP allowlist plus SMTP authentication over TLS. Prefer this to smtp.gmail.com with an app password, because the relay can be scoped to sender domains and IPs.
• Device has a static egress IP but no TLS: SMTP relay with IP-only authentication on port 25, or the restricted server if every recipient is internal. Plan to replace the device.
• Device cannot do any of the above, or roams on dynamic IPs: app password on a dedicated, licensed device mailbox with 2SV, recorded with an owner and replacement date. This is the last resort Google documents.
• Applications you build or control: OAuth with XOAUTH2, or the Gmail API. For a server-side service, a service account with domain-wide delegation is possible but powerful; read the Google Workspace Domain-Wide Delegation Security Guide before choosing it.

Small organisations with a handful of scanners usually settle on one relay entry for the office IP and dedicated device mailboxes. Large organisations should route device and application mail through an internal relay tier that authenticates to Google once, so the Google relay entry lists a few known servers rather than every site.

Testing and rollback

1. Pilot per device model. Configure one device of each model on the new path and send to an internal and an external address. Check headers for TLS and SPF, DKIM and DMARC results.
2. Stage the relay entry. Add the narrow IP range first, test, then remove any broader temporary entry. Keep the old configuration exported so a device can be returned to its prior working state within minutes.
3. Watch bounces and limits. Device bursts can hit the 100 recipients per transaction ceiling or daily caps; test month-end batch jobs, not just a single scan.
4. Re-push mobile profiles in rings. For MDM-managed phones, push the OAuth profile to an IT ring, then a business pilot, then everyone. Rollback here means re-pushing the previous OAuth profile, not reverting to passwords.
5. Accept that there is no Google-side rollback. Password access cannot be re-enabled. The only fallback for a business-critical device is a short-lived app password on a dedicated account, logged as an exception with an expiry.

Risks of doing nothing

"Doing nothing" now means leaving the workarounds in place. The risks are concrete:

• App passwords that bypass 2SV: a stolen app password gives mail protocol access without the second factor, and Google only revokes it automatically when the account password changes. That maps to ATT&CK T1078.004 Cloud Accounts and T1114.002 Remote Email Collection.
• Open relay entries: an "Any addresses" relay rule or a wide IP range turns any foothold inside the network into a trusted phishing sender for your domain.
• Personal accounts on shared devices: a person's credential on a scanner keeps working after they move role, and breaks unpredictably when they leave.
• Shadow fixes: users who could not connect may have moved to forwarding rules or unsanctioned apps, which then sit outside your OAuth app controls. See the SaaS and OAuth App Governance Guide.

Metrics that show it is finished: number of active app passwords (target: only documented device exceptions), relay entries with "Any addresses" (target: zero), relay IP ranges wider than a /29 (target: zero or justified), devices using a person's mailbox (target: zero), and Google Sync devices listed (target: zero).

Practitioner checklist

• Record 1 May 2025 as the effective retirement date in your risk register and correct any internal page that still cites 14 March 2025 as final.
• Confirm no devices remain under Type: Google Sync in the device list.
• Inventory every app password: account, app or device, owner, business reason and review date; remove any held by a person for a desktop client.
• Move every scanner and appliance off personal accounts onto dedicated mailboxes or IP-authenticated relay.
• Set each SMTP relay entry to a domain-restricted Allowed senders option, narrow IP ranges, and SMTP authentication with TLS where the device supports it.
• Re-push all MDM mail, calendar and contacts profiles with OAuth.
• Search code and configuration for imap.gmail.com, pop.gmail.com and smtp.gmail.com with stored passwords and move them to XOAUTH2 or the relay.
• Verify SPF, DKIM and DMARC alignment for all device and application mail.
• Review Google Password login types and relay volumes monthly until the exception list is empty.

Standards and references

• Google Workspace Updates: Winding down Google Sync and Less Secure Apps support
• Google Workspace Admin Help: Transition from less secure apps to OAuth
• Google Workspace Admin Help: Send email from a printer, scanner, or app
• Google Workspace Admin Help: Route outgoing SMTP relay messages through Google
• Google Account Help: Sign in with app passwords
• Google Workspace Admin Help: User log events
• Google for Developers: OAuth 2.0 mechanism for IMAP, POP and SMTP (XOAUTH2)

Related NHI Mgmt Group resources: Legacy Authentication and ROPC Retirement Guide, Google Workspace Security Guide, Exchange Online SMTP AUTH Basic Auth Retirement, Google Workspace Audit Log Detection Guide.