Google App Passwords Not Available? The Six Account States

You followed the guide, opened Security settings, and the page simply is not there. Google app passwords not available is not one problem - it is six different account states that all present as the same absence, and the guides that end with "click App passwords" never tell you what to do when there is nothing to click.

Below is the full state list, ordered by how often each turns out to be the answer, with the specific unlock for every one. Work top to bottom; most people are done by state two.

First, use the door that skips the menus

Before diagnosing, try the direct address: myaccount.google.com/apppasswords. Google has reshuffled the Security page repeatedly, and on many accounts the App passwords entry no longer appears in any menu even when the page itself exists and works. Typing "app passwords" into the search bar at the top of the Google Account page reaches the same place.

If the direct URL loads a working page - diagnosis over, it was a menu problem, and you can bookmark the URL and move on. If it redirects you back to the Security overview or shows a message that the setting is unavailable, continue.

State one: 2-Step Verification is off

The single most common cause. The app-passwords feature is built on top of 2-Step Verification; without 2SV the page does not exist for your account at all.

The unlock: Google Account, Security, 2-Step Verification, and complete enrollment with any second factor. Return to the direct URL afterward - the page typically appears immediately.

One wrinkle: enrolling in 2SV and then disabling it again removes the page again, and revokes every app password created in between. Accounts that flip 2SV off for convenience discover this as every connected mail client failing at once.

State two: a Workspace admin turned them off

On company and school domains, administrators control whether app passwords exist. If policy disables them, no user on the domain sees the page regardless of their 2SV state - and Google shows the user no explanation, just absence.

The unlock: an admin, in Admin console under Security and Authentication settings, permitting app passwords (the control lives with the less-secure-apps and 2SV policy cluster). If you are the admin of a small Workspace, this is a two-minute change; if you are not, it is a conversation, and the admin may reasonably prefer to offer you the SMTP relay or an OAuth-capable tool instead - both legitimate answers to the underlying need.

State three: Advanced Protection

Accounts enrolled in Google's Advanced Protection Program cannot create app passwords, by explicit design - the program's core promise is closing every non-phishing-resistant door, and a static 16-character mail credential is exactly that.

The unlock: there is none inside the program. Either the account leaves Advanced Protection (a real security downgrade that deserves thought, not a reflex), or the workload moves to something OAuth-capable, or the sending moves to infrastructure with its own credentials - a relay or sending platform - which is usually the right answer anyway for anything automated.

State four: passkey-only sign-in

Accounts set up to sign in exclusively with passkeys - increasingly common since Google made passkeys the default prompt - can lack an account password entirely, and some of the password-derived machinery, app passwords included, goes missing with it.

The unlock: add a password back to the account (Security, then Password), keep 2SV on, and revisit the direct URL. The account keeps its passkeys; the password's existence is what restores eligibility.

State five: managed and supervised account types

Education tenants, child accounts under Family Link supervision, and some tightly managed enterprise configurations withhold the page through their own policy layers, independent of anything the user toggles.

The unlock: policy-side, where one exists at all. For school and child accounts, often nothing the end user can do; the practical answer is using software that supports OAuth sign-in, which these accounts usually permit.

State six: the page exists but creation fails

Rarer and stranger: the page loads, but creating a password errors out or the new code never works. This cluster is usually transient state - a security hold on the account, a recent password change still propagating, session weirdness.

The unlock: resolve any pending security prompts on the account (the red banners in Security), sign fully out and back in, and try again from a clean browser session. If the account recently changed passwords, remember that the change revoked all previous app passwords - the failing credential may simply be an old one still cached in an app.

If the answer is "you can't": what to use instead

Two of the six states end with app passwords genuinely unavailable, and that is not a dead end for the underlying task. For mail clients, every modern one signs in to Google with OAuth - the Add Account flow, not the manual server settings. For devices and scripts on a Workspace domain, the SMTP relay authenticates by registered IP or its own credentials without touching anyone's mailbox. And for application or bulk sending, a dedicated platform with scoped API keys was always the better geometry - a key that can only send, cannot read, and rotates without touching your Google account is a smaller thing to protect than any mailbox credential.

The page being missing feels like a bug the first time. Read as a state machine, it is Google telling you which door your account is supposed to use - and once you know the six states, the diagnosis takes under five minutes flat.

Frequently asked questions

Why are app passwords not showing in my Google account?

The six causes, in order of likelihood: 2-Step Verification is off, a Workspace admin disabled them, the account is in Advanced Protection, it signs in with passkeys only and has no password, it is a managed or supervised account type, or a transient security hold. The direct URL myaccount.google.com/apppasswords also bypasses menu changes that merely hide the entry.

Do I need 2-Step Verification for Google app passwords?

Yes, absolutely. The app-passwords page does not exist until 2SV is enabled, and disabling 2SV later removes the page again and revokes every app password you had created.

How do Workspace admins enable app passwords for users?

In the Admin console under Security and Authentication settings, the policy that governs app passwords can be turned on per organizational unit. Until an admin does, no user on the domain sees the page regardless of their own settings.

What should I use if my account can never have app passwords?

OAuth sign-in for mail clients, the Workspace SMTP relay for devices and servers, and scoped API keys on a sending platform for application email. All three avoid static mailbox credentials entirely, which is why locked-down accounts push you toward them.