App-specific password phishing exposes gaps in modern auth controls

At a glance

What this is: This is an analysis of app-specific password phishing and how attackers use it to bypass stronger login methods by exploiting legacy access workflows.

Why it matters: It matters because identity teams can harden primary authentication and still leave alternative login paths open, creating a practical bypass for NHI, autonomous, and human identity governance.

By the numbers:

• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations.
• 17 minutes.

👉 Read Push Security's analysis of app-specific password phishing and bypass risk

Context

App-specific passwords are a legacy access method that lets a user sign in to older applications without the platform's standard modern authentication workflow. In identity terms, they create an alternate credential path that can bypass the protections teams assume are covering the account, even when phishing-resistant methods such as passkeys are in place.

The security problem is not that the primary authentication stack failed. The problem is that an additional login path remained available and could be socially engineered into use. For identity programmes, that is a governance issue across human identity, not just an authentication design issue, because the control gap sits in the exception path rather than the default path.

Key questions

Q: How should security teams handle app-specific passwords when they use passkeys or MFA?

A: Treat app-specific passwords as a separate authentication path that must be explicitly governed. If the account can still create or use them, phishing-resistant login is not complete. Security teams should disable the feature where possible, restrict exceptions, and verify that alternate sign-in methods cannot be used to bypass stronger controls.

Q: Why do app-specific passwords create risk even when they are limited to legacy apps?

A: Because limited scope does not mean limited impact. A mailbox or mail client often contains enough trust relationships to support impersonation, password resets, and broader account compromise. The risk is the downstream identity abuse that starts from a credential with seemingly narrow permissions.

Q: What should teams get wrong less often about phishing-resistant authentication?

A: They should stop assuming that passkeys or enforced MFA close every door. Those controls protect the preferred sign-in flow, but they do not remove backup methods, recovery routes, or app passwords unless teams govern them directly. The full authentication surface has to be reviewed, not just the primary login screen.

Q: Who is accountable when alternate login methods are left enabled after stronger authentication is deployed?

A: Accountability sits with the identity team, application owners, and governance function together. The issue is not simply user behaviour. It is whether the organisation allowed an exception path to remain active after declaring a stronger authentication standard. That gap should be reviewed under identity policy and access governance.

Technical breakdown

App-specific passwords as an authentication bypass path

App-specific passwords are a compensating control for legacy applications that cannot use modern authentication such as OAuth-based sign-in or interactive MFA. They are issued by the identity provider, then used like a normal password for a narrow set of application permissions. That makes them structurally different from a primary password, but not inherently safer once an attacker persuades a user to disclose one. The key weakness is that the ASP becomes a reusable credential that lives outside the main login ceremony, so phishing-resistant methods on the primary account no longer protect the alternate path.

Practical implication: treat every alternate sign-in method as part of the authentication attack surface, not as a harmless exception.

Why phishing-resistant authentication can still be bypassed

Passkeys, WebAuthn, and enforced MFA protect the interactive authentication flow, but they do not automatically disable all other access paths bound to the same account. If an application password is still permitted, an attacker can move around the stronger login step by inducing the user to create or share that password. This is why the attack is effective without malware or a fake login page. The user is manipulated into performing the privileged action for the attacker, and the account remains technically protected by modern auth while practically exposed through legacy access.

Practical implication: validate that phishing-resistant authentication is enforced everywhere an account can authenticate, not only at the main sign-in page.

Mailbox access expands the blast radius beyond the initial login

An ASP often does not grant full account takeover, but email, contacts, and calendar access are enough for follow-on abuse. Attackers can monitor correspondence, impersonate the user, and trigger password reset or MFA reset workflows against other services. That makes the initial credential theft an entry point to wider identity compromise, especially when mailbox trust is used downstream for recovery or approval. In practice, the real impact is lateral movement through identity trust relationships, not just reading mail.

Practical implication: protect email recovery and delegated access paths as if they were high-value privilege routes.

Threat narrative

Attacker objective: The objective is persistent mailbox access that can be leveraged for impersonation, identity reset abuse, and wider account compromise.

1. Entry occurs when the attacker convinces the victim to create and share an app-specific password for a legacy application.
2. Escalation follows when that password is used to sign in to the mailbox or mail client without triggering the primary account's phishing-resistant checks.
3. Impact comes when the attacker uses email access to impersonate the victim and pivot into password resets, MFA resets, or additional account compromise.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

App-specific passwords are an exception-path governance problem, not a primary-authentication problem. Organisations can harden SSO, enforce passkeys, and still leave a legacy credential path open for social engineering. That means the control failure sits in account lifecycle and authentication exceptions, not in the main login flow. Practitioners should treat any permitted alternate login method as a separately governed identity path.

The real issue is authentication downgrade through user action. The attacker does not need to defeat MFA if the user can be persuaded to create a credential that bypasses it. That is a human identity trust failure wrapped around a technical control. The implication is that identity governance has to cover user-permitted exceptions as first-class risk objects, not as convenience features.

Legacy access paths create identity blast radius beyond their intended scope. Even when an ASP is limited to mail access, it can become the starting point for password reset abuse, impersonation, and secondary compromise. In identity terms, the blast radius is defined by downstream trust relationships, not by the narrow permission set on the credential itself. Practitioners should map where alternate credentials can trigger recovery, delegation, or session expansion.

Phishing-resistant authentication does not equal phishing-resistant account architecture. Passkeys and MFA reduce exposure at the primary gate, but they do not solve the presence of backup methods, app passwords, or other downgrade paths. That is why identity programmes need to review the full authentication surface, including every path a user can still use when the preferred method is unavailable. The practitioner conclusion is simple: if the exception path exists, it must be governed like a privilege path.

From our research:

• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, according to The State of Non-Human Identity Security.
• In the same research, 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which shows how often identity teams lose sight of alternate access paths before attackers exploit them.
• That visibility gap is why teams should pair alternate-path governance with deeper lifecycle controls, as explored in Ultimate Guide to NHIs , Key Challenges and Risks.

What this signals

Legacy access paths are the part of identity architecture most likely to survive modernisation efforts. Teams often close the obvious MFA gap and leave backup methods, recovery routes, and app passwords untouched. That creates a governance asymmetry where the strongest controls protect the most visible path, while the weakest controls remain available for social engineering.

The practical next step is to inventory every alternate authentication method and decide whether it is still justified. Where it is retained, it should be monitored like a privileged exception path rather than treated as a convenience feature. Where it is not needed, removal is cleaner than detection, especially when the attack path is driven by user persuasion rather than malware.

With 1.5 out of 10 organisations highly confident in securing NHIs, according to The State of Non-Human Identity Security, identity governance still struggles with non-primary credential paths. The same discipline that governs machine credentials has to extend to human exception paths, because attackers increasingly target the weakest permitted method rather than the strongest mandated one.

For practitioners

• Disable app-specific passwords where the platform allows it Remove ASP creation from default policy, then confirm users cannot re-enable it through delegated admin paths or conditional access exceptions.
• Inventory every alternate login path Map backup credentials, legacy mail access, recovery options, and non-browser sign-in methods for each workforce identity so exception paths are visible.
• Block access to app password creation pages Use web controls to deny access to known ASP creation pages for Google and Apple and alert on attempts to reach those URLs.
• Review mailbox-driven reset and recovery routes Test whether email access can trigger password resets, MFA resets, or account recovery on downstream services and restrict those flows where possible.
• Add detections for credential creation and anomalous mail access Correlate new app-password creation events, unusual mailbox logins, and subsequent identity recovery activity into a single investigation path.

Key takeaways

• App-specific passwords create an alternate authentication path that can bypass phishing-resistant login controls if the exception remains enabled.
• The impact is broader than mailbox access alone because email trust can be used for impersonation, resets, and downstream account compromise.
• The most effective defence is to remove or tightly govern alternate login methods, then monitor recovery and credential-creation activity as privilege events.

Key terms

• App-specific password: An app-specific password is a secondary credential issued for legacy applications that cannot use the primary modern authentication flow. It usually bypasses interactive MFA on sign-in, so it must be governed as a separate access path with its own lifecycle, logging, and removal policy.
• Authentication downgrade: Authentication downgrade is the use of a weaker or alternative login path to bypass the stronger method an organisation expects to be used. In practice, the user is not breaking the rules so much as being manipulated into selecting an exception that the identity programme failed to close.
• Alternate login path: An alternate login path is any non-primary route into an account, such as backup credentials, app passwords, recovery options, or legacy sign-in methods. These paths often survive modern authentication rollouts and become the real target for attackers who can no longer attack the default flow directly.
• Identity blast radius: Identity blast radius is the amount of downstream access, recovery power, and impersonation capability that becomes available after one identity is compromised. It is defined less by the initial credential and more by the trust relationships, reset mechanisms, and delegated access that credential can reach.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Push Security: app-specific password phishing and authentication bypass risk. Read the original.