An app password is a static secret that signs an app in to your account without ever asking for the second factor, so every one still in use is a hole in your MFA coverage that most inventories never record. Google, Microsoft, Apple, Zoho and, until recently, Atlassian have all offered them as a bridge for mail clients, calendar sync and devices that cannot complete a modern sign-in. The bridge has outlived its purpose in most environments, yet app passwords keep turning up on printers, old Outlook profiles, scripts and personal phones. This guide explains what an app password actually is, how the main providers differ on limits and revocation, how to find and retire them, and what to do with the few that must stay. It is written for identity and messaging administrators, security engineers and anyone deciding whether to generate one.
Key takeaways
- An app password is a deliberate MFA bypass. Microsoft's own documentation says app passwords replace the normal password so a non-browser app can bypass multifactor authentication; Google says they are not recommended and unnecessary in most cases.
- Revocation rules differ by provider, and that is where incidents hide. Google and Apple revoke all app passwords when the account password changes; Microsoft Entra ID does not, and Zoho's application-specific passwords never expire.
- Disabling creation does not disable existing ones. In Entra ID, existing app passwords keep working after you switch the setting off; only blocking legacy authentication stops them.
- Most uses now have a modern replacement. OAuth-capable mail clients, "Sign in with Google", Apple's account authorisation for iCloud data, scoped API tokens and SMTP relay services cover nearly every case that once needed an app password.
- Treat survivors as non-human credentials. An app password on a scanner or in a script is a long-lived machine secret: it needs an owner, a record, a review date and a replacement plan.
What an app password is and what it bypasses
An app password is a randomly generated secret, created by the account holder after two-step verification is turned on, that an older app enters in place of the real account password. The provider accepts it over protocols that cannot carry a second-factor challenge: IMAP, POP, SMTP AUTH, Exchange ActiveSync, CalDAV and CardDAV, plus some older desktop clients. Because the protocol only carries a username and secret, the provider has no way to prompt for a code, push or security key, so the app password is accepted on its own.
That design has three security consequences that are easy to miss:
- Single factor by construction: anyone who obtains the app password, from a device configuration page, a config file, a backup or a phishing page that asks for it, can sign in from anywhere the protocol is reachable. No second factor is ever requested.
- Outside your sign-in policy: Microsoft states that app passwords are verified by Microsoft Entra ID and bypass federation, so the on-premises identity provider is not contacted, on-premises client access control settings are not honoured, and no on-premises authentication logging is available for them.
- Long-lived and invisible: users enter an app password once per device and forget it. Few organisations record which accounts hold one, what it is used for, or when it was created.
An app password is not the same as an API token, a personal access token or an OAuth refresh token. Tokens can usually be scoped and set to expire; an app password typically carries the full mailbox or account access of the user who created it, over every legacy protocol the provider still accepts. Atlassian's move from Bitbucket Cloud app passwords to API tokens was explicitly about expiry, central visibility for administrators and modern scopes. See the Atlassian App Passwords to API Tokens.
How the main providers differ
The details below come from each provider's own help pages, checked on 11 November 2026. Limits and behaviour change, so confirm against the current page before relying on a specific number.
| Provider | Prerequisite | Format and limit | Revoked on password change? | Notable restrictions |
|---|---|---|---|---|
| Google Account | 2-Step Verification on | 16-digit passcode; created at myaccount.google.com/apppasswords | Yes, Google revokes app passwords when the account password changes | Not offered when 2SV uses only security keys, for Advanced Protection accounts, or for some work and school accounts |
| Microsoft Entra ID (work or school) | User enforced for Entra MFA; administrator must allow app passwords (off by default) | Up to 40 per user; generated, cannot be chosen | No; Microsoft says they are not automatically revoked when the password is reset, and users must delete and recreate them | Cannot perform administrative actions through non-browser apps such as PowerShell; blocked wherever basic or legacy authentication is blocked |
| Apple Account | Two-factor authentication on | Up to 25 active app-specific passwords; managed at account.apple.com under Sign-In and Security | Yes, changing or resetting the primary password revokes all of them | Some third-party apps for iCloud Mail, Calendar and Contacts can be authorised with the Apple Account instead |
| Zoho Mail | Two-factor authentication on | 12 digits; shown once only | No; Zoho states application-specific passwords never expire | Used for POP, IMAP, ActiveSync and CalDAV; revoked individually by the user |
| Atlassian Bitbucket Cloud | Not applicable | Retired in favour of scoped API tokens | Not applicable | Creation was disabled from 9 September 2025 and app passwords were scheduled to stop working in 2026; see the dedicated guide for the final schedule |
The revocation column matters most in incident response. A Google or Apple password reset cleans up app passwords automatically. A Microsoft Entra ID password reset does not, so an attacker who created an app password during a compromise can keep reading mail over a legacy protocol after the user's password has been changed, unless legacy authentication is blocked or the app passwords are deleted. With Zoho, the user (or a token revocation during reset) must remove them explicitly.
Where app passwords still turn up
| Where | Typical reason | Modern replacement |
|---|---|---|
| Multifunction printers and scanners (scan-to-email) | Device can only do SMTP AUTH with a username and password | Provider SMTP relay with IP allowlisting and TLS, OAuth if the firmware supports it, or replace the device. See the Google Workspace Less Secure Apps Retirement. |
| Old desktop mail clients | Office 2010 or earlier, Apple Mail before iOS 11 (examples Microsoft gives) | Current clients with modern authentication; Google notes iOS 11 and later do not need app passwords |
| Scripts and line-of-business apps sending mail | Developer used SMTP AUTH or IMAP with a stored secret | Graph or Gmail API with OAuth client credentials, or an SMTP relay scoped to the sending host. See the Exchange Online SMTP AUTH Basic Auth Retirement. |
| Third-party calendar and contacts apps | CalDAV or CardDAV sign-in | OAuth sign-in where offered; Apple Account authorisation for supported iCloud apps |
| Personal phones and tablets on work mail | User set up native mail before modern auth was supported | Managed mail app with modern authentication and device compliance |
| Hybrid Exchange and cached on-premises passwords | Clients that talk to both on-premises and cloud endpoints | Hybrid modern authentication; Microsoft notes app passwords fail in mixed autodiscover setups |
Finding the app passwords you already have
No provider gives a single tenant-wide report of every app password with its creation date and last use, so discovery is a combination of settings review, sign-in log analysis and asking owners.
- Check whether creation is allowed at all. In Microsoft Entra ID the setting sits under Conditional Access, Named locations, Configure MFA trusted IPs, then "Allow users to create app passwords to sign in to non-browser apps" (Authentication Policy Administrator or higher). Record its state and when it was last changed.
- Find legacy protocol sign-ins. App passwords can only be used over legacy protocols, so legacy sign-ins are the footprint. In the Entra admin centre, open Sign-in logs, add the Client App column and filter on the legacy authentication clients, on both the interactive and the User sign-ins (non-interactive) tabs, or use the "Sign-ins using legacy authentication" workbook. In Google Workspace, User log events (Reporting, Audit and investigation) record login types, but Google notes that email client sign-ins are not logged unless they look suspicious, so rely more on owner attestation and configuration search there. See the Google Workspace Audit Log Detection Guide.
- Search configuration and code. Grep repositories, configuration management and secrets stores for mail hostnames (smtp.office365.com, outlook.office365.com, smtp.gmail.com, imap.gmail.com and your provider's equivalents) and for stored mail credentials in configuration files. Each hit is either an app password or a plain password on a legacy protocol.
- Walk the device estate. Printer and scanner web consoles, NAS backup jobs, CCTV and building systems that send alerts by email. Record which mailbox each uses and how it authenticates.
- Ask account holders. A short attestation ("do you have any app passwords, and on what?") finds personal devices and forgotten clients that logs alone miss, especially where sign-ins are infrequent.
Retiring them: a phased approach
- Freeze creation. Turn off the ability to create new app passwords (the Entra ID setting above; security-key-only 2-Step Verification or Advanced Protection on Google accounts, under which Google does not offer app passwords; organisational policy for personal accounts used for work). Microsoft notes that existing app passwords keep working and users can no longer manage or delete them after this switch, so plan the next steps before you flip it.
- Inventory and assign owners. For every account and device found, record the use, the owner, the account type (person or shared mailbox) and a target replacement.
- Migrate by use case. Re-add mail accounts with modern sign-in on current clients, move devices to relay services or OAuth, rewrite scripts to use API access with a workload credential. Do one business unit or device class at a time.
- Block legacy authentication in report-only mode first. In Entra ID, create a Conditional Access policy for all users and all resources, with client apps set to Exchange ActiveSync clients and Other clients, grant Block, and start in Report-only. Exclude break-glass accounts. Review the report-only results for two to four weeks (an NHI Mgmt Group recommendation, long enough to catch monthly jobs). See the Legacy Authentication and ROPC Retirement Guide.
- Enforce, then delete. Switch the policy on. Blocking legacy authentication is the step that stops existing Entra app passwords from working. Ask users to delete remaining app passwords, and for Google and Apple accounts confirm the list at the account security page is empty.
- Roll back narrowly. If a critical device breaks, exclude that one dedicated account from the block policy with a dated exception rather than reverting the policy, and record it in the exception register.
When an app password is still the least bad option
Some devices cannot be replaced this year and support nothing but SMTP AUTH. If that is the position, constrain the credential rather than pretending it is not there.
| Situation | Preferred option | If an app password is unavoidable |
|---|---|---|
| Device on a fixed IP sending internal alerts | Provider SMTP relay restricted to that IP, TLS required | Not needed |
| Device on dynamic IPs, no OAuth, no relay | Replace the device or route through an on-premises relay that uses modern auth upstream | Dedicated, licensed device mailbox with MFA, no other access, owner and replacement date recorded |
| Person using an old mail client | Upgrade the client | Do not issue; this is the case Google and Microsoft both say does not need one |
| Script or integration | API with OAuth and a workload identity | Do not issue; treat as a secrets management finding |
| Small organisation without Conditional Access licences | Microsoft security defaults, which block legacy authentication | Same rules: dedicated account, recorded, short review cycle |
Small organisations usually have only a handful of devices and can retire every app password in a week. Large organisations should expect a long tail of scanners and vendor appliances: set a target date, publish the exception process, and report the remaining count monthly.
Where identity fits
An app password on a scanner, a NAS or in a script is a non-human credential attached to a human or shared mailbox. It should be governed like any other machine secret: stored in a secrets manager where the system can read from one, never in a shared spreadsheet, with an accountable owner and a rotation or replacement date. It also belongs in the list of accounts that are effectively excluded from MFA, which auditors increasingly ask for. See the How to Find Accounts Excluded From MFA and Conditional Access and the MFA Exception Register Template.
Detection and measurement
- Legacy protocol sign-ins: any successful sign-in over IMAP, POP, SMTP AUTH, Exchange ActiveSync or "Other clients" from an account not on the exception register should alert.
- Sign-ins after a password reset: legacy protocol activity on an Entra ID account after its password was reset during an incident is a strong signal that an app password survived. Correlate reset events with subsequent legacy sign-ins.
- Setting changes: alert on changes to the Entra app password setting and on new MFA registrations followed by legacy sign-ins. See the How to Detect MFA Method Registration Abuse.
- Unusual geography for device mailboxes: a scanner mailbox signing in from outside your network ranges is almost always compromise.
Metrics that show progress:
- Number of accounts with legacy protocol sign-ins in the last 30 days, trending to the exception count.
- Percentage of app-password exceptions with an owner, recorded use and replacement date (target 100%).
- Days since the app password creation setting was last enabled (should keep growing).
- Count of incident password resets where app passwords were also deleted or blocked (target: every Entra ID case).
- Number of devices still on SMTP AUTH with a stored secret, by business unit.
Framework mapping
| Framework | Reference | How app passwords relate |
|---|---|---|
| MITRE ATT&CK | T1078.004 Cloud Accounts | A stolen app password is a valid cloud account credential that does not need the second factor |
| MITRE ATT&CK | T1110.003 Password Spraying | Microsoft reports that over 99% of password spray attacks use legacy authentication, the only path app passwords exist on |
| MITRE ATT&CK | T1098 Account Manipulation | Creating an app password on a compromised account is a way to keep access after a reset |
| NIST SP 800-53 Rev. 5 | IA-2, IA-2(1), IA-5, AC-2 | Multi-factor authentication, authenticator management and account management for the exceptions |
| NIST CSF 2.0 | PR.AA-01, PR.AA-03 | Credentials are managed and users and services are authenticated |
| CIS Controls v8.1 | Control 5 Account Management; Control 6 Access Control Management | MFA coverage and an inventory of exceptions |
| ISO/IEC 27001:2022 Annex A | A.5.17 Authentication information; A.8.5 Secure authentication | Issuing, handling and retiring authentication secrets |
Common failure patterns
- Resetting the password and assuming the account is clean. In Entra ID, app passwords survive a reset. Delete them or block legacy authentication as part of every account compromise response.
- Turning off creation and calling it done. Existing Entra app passwords keep working until legacy authentication is blocked.
- Issuing app passwords to people as a convenience. Once a person has one, MFA on their account is optional for anyone who learns it. Google and Microsoft both point people to modern clients instead.
- Leaving exceptions without owners. A forgotten account outside MFA is exactly the kind of gap attackers look for; the Microsoft Midnight Blizzard breach began with password spraying against a legacy test tenant account that did not have MFA.
- Storing the app password on the device and nowhere else. When the device is replaced, nobody knows which mailbox it used, and the secret stays valid. Record it and revoke on decommission.
- Using a personal user's mailbox for a device. When that person leaves, the device breaks or, worse, the account is kept alive for the device. Use a dedicated mailbox.
Practitioner checklist
- Record the state of every app password setting in each identity provider and SaaS platform you run.
- Disable creation of new app passwords, after planning migration for existing users.
- Query legacy protocol sign-ins on both interactive and non-interactive logs and list every account.
- Assign an owner, use and replacement date to every remaining app password, in an exception register.
- Migrate mail clients to modern authentication and devices to relay services or OAuth.
- Block legacy authentication in report-only mode, review, then enforce, excluding only break-glass and registered exceptions.
- Add "delete app passwords and confirm legacy access is blocked" to your account compromise playbook.
- Alert on legacy sign-ins outside the register and on app password setting changes.
- Review the exception register monthly and report the count to the identity programme owner.
Standards and references
- Microsoft Learn: Enforce Microsoft Entra multifactor authentication with legacy applications using app passwords
- Google Account Help: Sign in with app passwords
- Apple Support: Sign in to apps with your Apple Account using app-specific passwords
- Zoho Mail: Two-factor authentication and application-specific passwords
- Microsoft Learn: Block legacy authentication with Conditional Access
- Microsoft Learn: Deprecation of Basic authentication in Exchange Online
- Atlassian: Bitbucket Cloud transitions to API tokens
- MITRE ATT&CK: Valid Accounts: Cloud Accounts
Related NHI Mgmt Group resources: MFA Guide · Phishing-Resistant MFA Guide · Legacy Authentication and ROPC Retirement Guide · Google Advanced Protection Program Guide · Entra Per-User MFA to Conditional Access