Less Secure App access (LSA in Google’s documentation, “less secure apps” in the account UI, “google application password” in older third-party guides) named the authentication path that let any SMTP, IMAP, or POP client sign in to Gmail using the account’s plain username and password. Outlook profiles, Thunderbird installations, backend scripts, and contact-form plugins all used it. It was the only path for clients that could not implement OAuth.
The path closed in two stages. Google removed LSA from consumer Google Accounts on 30 May 2022: “From May 30, 2022, Google no longer supports the use of third-party apps or devices which ask you to sign in to your Google Account using only your username and password” (
Less secure apps & your Google Account). Google Workspace kept LSA running longer. The original cutoff announced in 2023 was 30 September 2024 (
Workspace Updates blog); that rollout was paused in October 2024, resumed in January 2025, and then delayed a second time; final shutdown was 1 May 2025: “Starting May 1, 2025, Google Workspace accounts no longer support less secure apps, third-party apps, or devices that ask you to sign in to your Google Account with your username and password” (
Control access to less secure apps).
This page defines the vocabulary and the mental model: what LSA was, what replaces it, and which replacement fits which use case. The execution recipe for the most common WordPress replacement (generating an App Password and pasting it into a mailer plugin) lives in Gmail App Passwords for WordPress SMTP. The decision between App Passwords and OAuth lives in Gmail OAuth vs. App Passwords. This is the reference.
The three replacement paths
OAuth 2.0
OAuth replaces the account password with a short-lived access token and a long-lived refresh token, both scoped to the consenting application. The user grants consent once through a browser; the client stores the refresh token and exchanges it for fresh access tokens whenever it needs to send mail. OAuth tokens survive account-password rotations; the silent-failure pattern that breaks App-Password setups after a rotation does not apply.
OAuth is Google’s preferred replacement; the Workspace admin console’s migration guide defaults to it. The cost is implementation: the client must support OAuth 2.0 with the Gmail SMTP scope (https://mail.google.com/). Headless servers and CLI-only environments use the Authorization Code flow with refresh tokens; the consent step runs once, interactively, against a desktop browser, and the resulting refresh token is then used non-interactively forever. The walkthrough is in How to get OAuth 2.0 credentials on Google.
App Passwords
App Passwords are 16-character credentials that authenticate against Gmail’s SMTP, IMAP, and POP endpoints exactly the way the account password used to but bypass the 2-Step Verification challenge at the client. They survive the LSA shutdown because they are not LSA: the authentication transcript still presents a username and a token, but the token is generated and managed inside Google’s account-security system rather than being the account password.
Four conditions hide the App Passwords screen rather than emitting a useful error: the account does not have 2-Step Verification enabled; 2SV is configured with security keys only; the account is enrolled in Google’s Advanced Protection Program; or the account is a Workspace account, in which case App Password availability is admin-controlled and security-key-only 2SV enforcement removes the option for every user in the organisation (how 2SV works with legacy apps). The first three are user-fixable. The fourth is the admin’s decision. App Passwords are also revoked every time the Google Account password is rotated; the silent-failure pattern: SMTP that worked for months stops on the day of a routine security event.
Switch sending provider
The third replacement leaves Gmail’s relay infrastructure entirely. A transactional sending service (Postmark, Brevo, SMTP2GO, Amazon SES, Mailgun, the rest of the sending-service catalogue) accepts the message via its own SMTP host or API, authenticates against the sender’s own DNS records, and delivers to the recipient.
Three situations point here: the integration is locked to plain-password and cannot be changed; the sending volume exceeds Gmail’s caps (500/day on consumer accounts, 2,000/day on Workspace); or the operator needs dedicated control of deliverability infrastructure independent of Google’s relay.
Decision triage by use case
| Use case | Path |
|---|---|
| Third-party desktop/mobile client (Outlook, Thunderbird, Apple Mail) | OAuth via the built-in “Add Google account” flow; App Password if the client is too old to support it |
| Script or backend service | OAuth (Authorization Code flow + stored refresh token); App Password if the password-rotation risk is acceptable |
| Google Workspace administrator managing legacy integrations | Depends on 2SV enforcement policy; security-key-only enforcement removes App Passwords org-wide |
| WordPress operator with a mailer plugin | App Password via the plugin’s “Other SMTP” mailer, or OAuth via its dedicated “Gmail” mailer |
Third-party desktop and mobile email clients: current versions of Outlook, Thunderbird, and Apple Mail all support the OAuth “Add Google account” flow and configure it automatically. If a profile is stuck on an older client that does not, App Passwords are the path; the username is the full Gmail address and the password is the 16-character code, against smtp.gmail.com:587 or :465.
Scripts and backend services: OAuth with the Authorization Code flow and a stored refresh token is the durable answer; the consent step runs once on any machine with a browser, the refresh token transfers to the server, and the server uses it indefinitely. App Passwords are the lighter setup for environments where the password-rotation failure mode is acceptable.
Google Workspace administrators: the admin chooses whether App Passwords are available to the organisation through the 2SV enforcement policy. Security-key-only enforcement removes App Passwords for every user as a side effect; admins who need to allow App Passwords for legacy integrations must permit a non-security-key 2SV method alongside. There is no separate LSA toggle to re-enable; the path is gone for everyone.
WordPress operators: the major mailer plugins (WP Mail SMTP, FluentSMTP, Post SMTP) offer both replacements. Their native “Gmail” and “Google Workspace” mailers are OAuth integrations. Their “Other SMTP” mailer accepts an App Password as the credential against smtp.gmail.com. The execution recipe is the Gmail App Passwords for WordPress SMTP walkthrough; the OAuth-vs-App-Password decision is in Gmail OAuth vs. App Passwords.
When none of the three fits
A configuration that needs plain-password SMTP authentication, against a server that signs and authenticates outbound mail for the sender’s own domain, points away from Gmail and toward the dedicated sending services. The sending-service catalogue covers the providers that operate at the WordPress operator’s scale.