Less Secure Apps is gone — what to do when your printer can't email anymore

What "Less Secure Apps" actually meant

Less Secure Apps was Google's label for any client that connected to Gmail using a plain username and password — no OAuth 2.0, no token exchange, just credentials passed directly over IMAP, POP3, or SMTP. The clients that used this path were largely designed in the 1990s and early 2000s, before OAuth existed as a standard.

The label was technically accurate. Basic auth has no token rotation, so a stolen password is a full account takeover — no time limit, no scope restriction. It has no MFA support, so your two-step verification policy is silently bypassed for any app using this path. There is no scope limitation either: a client authenticating via basic auth gets full access to everything in the account, not just the mailbox it needs. And the credentials are fully phishable — a credential-stuffing attack or a single leaked password spreadsheet is all it takes.

Every modern security framework treats basic auth as an unacceptable risk for this reason. The deprecation was not a surprise for anyone following the threat landscape.

The deprecation timeline

Google announced the end of Less Secure Apps access in 2019 — giving organizations several years to migrate. For personal Gmail accounts, basic auth was turned off on May 30, 2022. Workspace (paid) accounts kept the admin toggle longer, but Google removed it entirely in June 2024.

As of today, there is no toggle to flip. The option is gone from the Admin Console. No Workspace account — regardless of tier, age, or admin configuration — can re-enable basic auth access for any client. This is not a policy that can be requested as an exception. The infrastructure no longer supports it.

If you are reading this because a system just started throwing authentication errors, the timeline explains why. The system likely worked for years, coasted through the 2022 personal-Gmail cutoff without being touched, and finally hit the wall when the Workspace toggle was removed.

What actually broke when LSA went away

The error message is usually "Authentication failed" or "Username and password not accepted," sometimes accompanied by a link to a Google help article about Less Secure Apps that now leads to documentation explaining why the feature no longer exists. The systems generating this error fall into predictable categories.

• Multifunction printers and copiers — Xerox, Canon, Ricoh, Sharp, and Konica Minolta devices configured to scan-to-email via SMTP submission. This is the most common ticket we see. The device has had the same SMTP config for a decade and nobody thought to update it.
• Legacy CRM, ERP, and accounting software — notification emails, invoice delivery, and alert emails sent through Gmail SMTP with hardcoded credentials. Often configured by whoever set up the software years ago and not documented anywhere.
• Backup and monitoring scripts — shell scripts or Python scripts running on a cron schedule that email nightly reports. smtp.gmail.com on port 587, username and password in a config file or environment variable.
• Older desktop email clients — pre-2019 versions of Outlook, older versions of Thunderbird, Mac Mail on macOS versions from before OAuth support was standard. Any client that never prompted users to re-authenticate through a browser flow.
• Marketing and automation tools — third-party tools that were integrated using Gmail credentials directly rather than through the Gmail API or an OAuth-scoped service account.

In each case, the system was working fine until June 2024. Then it stopped. The error is the same; the fix depends entirely on which category the system falls into.

The three migration paths

There is no single answer. The right migration path depends on what the system is and what it actually needs to do.

OAuth 2.0

This is the correct long-term answer for any modern application that supports it. The app registers a client ID in Google Cloud Console, the user (or an admin, for service accounts) grants scoped consent, and the app receives refresh tokens that rotate automatically. Access can be scoped narrowly — read-only, specific labels, send-only — rather than full account access. Revocation is per-app rather than requiring a password change. Most major SaaS platforms already support this; check the vendor's authentication documentation before assuming they don't.

App Passwords

For clients that genuinely cannot speak OAuth — older printers, niche line-of-business apps with no update path — Google provides App Passwords as a compatibility shim. An App Password is a 16-character, single-use password generated per device under the user's account at Manage your Google Account → Security → App passwords. The account must have 2-Step Verification enabled before this option appears.

App Passwords are limited but functional. The client uses the App Password instead of the account password. If the device is compromised, you revoke that specific App Password without touching the account password or other devices. This is meaningfully better than plain basic auth, but it is still a static credential — it does not rotate unless you regenerate it manually.

SMTP Relay Service

For high-volume server-to-server email — system notifications, transactional sends, scripted reports — the right answer is Google Workspace's SMTP Relay Service, not a per-user account. Configured at the domain level in Admin Console under Apps → Google Workspace → Gmail → Routing → SMTP relay service, it allows sending from specific IP ranges or authenticated users through Google's infrastructure. It does not count against per-user send limits. It does not require a user account's credentials in a script. It is the correct architecture for anything sending mail at scale from a server.

How to find what's still using LSA in your environment

Before you can fix anything, you need a complete list of affected systems. Most organizations discover these one at a time as they break, which is a slow and reactive way to work through a migration. A structured audit is faster.

• Admin Console audit logs: Go to Admin Console → Reporting → Audit and investigation → User log events. Filter for Login failure events. Look for repeated failures from the same source IP address — that pattern almost always indicates a service account or device, not a human failing a password attempt.
• Gmail routing audit: Admin Console → Apps → Google Workspace → Gmail → Routing. Review any IPs in your inbound or outbound mail gateway configuration to understand what is sending mail through your domain.
• Facilities and IT asset inventory: Talk to the facilities or office management team. Printers and copiers are the single most common LSA breakage point, and they are rarely tracked in IT systems. Pull a list of every MFP on the network and physically check its scan-to-email configuration.
• Server-side script audit: Check scheduled tasks on Windows servers and cron jobs on Linux systems. Search script directories for smtp.gmail.com or password= — those strings in a script file almost certainly indicate a hardcoded SMTP credential that will break.

Document what you find: system name, owner, what email function it performs, and which migration path applies. That list becomes your migration project plan.

What to do for each system you find

Once you have the inventory, the remediation decision for each system is straightforward.

• Printer or MFP: Create a dedicated Google account for the device (e.g., printer-floor3@yourdomain.com), enable 2-Step Verification on it, generate an App Password, and update the device's SMTP configuration. The better long-term answer is to switch to the SMTP Relay Service and configure the device's IP — then the account credential is removed from the equation entirely.
• Line-of-business application: Check the vendor's documentation for OAuth support first. If the vendor supports OAuth and your version is recent enough, migrate. If the app has no OAuth path and cannot be updated, use an App Password on a dedicated service account.
• Server scripts: Use the SMTP Relay Service. Do not use App Passwords for production scripts — they are static credentials sitting in config files and they do not rotate. SMTP Relay with IP allowlisting is the correct architecture here.
• User email clients: Any desktop or mobile client released after approximately 2020 supports OAuth. Remove the account from the client and re-add it. The first sign-in will redirect to a Google login page and complete the OAuth flow automatically. No special configuration required.

The security upside

Basic auth is genuinely indefensible in 2026. A phished password is a complete account compromise — no MFA stands between the attacker and the inbox. There is no audit trail of what the app accessed or when. There is no way to revoke access for a single device without changing the user's password across every device they use. The access scope is always full, regardless of what the app actually needs.

Every major breach report from the past decade has a basic-auth story in it. Credential stuffing, password spraying, and supply-chain attacks against apps storing plaintext passwords all rely on basic auth being available somewhere in the authentication surface. Removing it closes that path entirely.

The migration is operationally annoying — mainly because the affected systems are old, poorly documented, and owned by departments that don't think of themselves as IT stakeholders. But the end state is materially better. Per-device App Passwords mean a compromised printer credential doesn't expose the entire account. OAuth scopes mean an integrated app can only read what it needs. SMTP Relay means scripts aren't running with a user's full identity attached.

Bottom line

If you have systems throwing "Authentication failed" errors and this is the first time you're hearing about Less Secure Apps, OAuth, App Passwords, or SMTP Relay — you are not alone. The printer-stops-scanning-to-email scenario is the most common first symptom for SMBs hitting this cutoff, and it shows up six to eighteen months after Google pulled the toggle because most organizations don't notice until the device breaks in a way that disrupts a workflow.

The playbook is: audit (login failure events, routing config, printers, scripts), classify each system as OAuth-capable / App Password candidate / SMTP Relay candidate, then migrate in priority order. Budget two to four weeks of elapsed time for an organization with a mixed legacy environment. There is nothing to turn back on. The path forward is the migration.