Topic starter
12/06/2026 9:08 pm
TL;DR: Attackers are using social engineering to trick users into creating and sharing app-specific passwords, which can bypass phishing-resistant login methods and MFA while still granting mailbox access, according to Push Security. The pattern shows that modern authentication controls can be sidestepped through legacy access paths unless teams remove those paths or tightly constrain them.
Editorial analysis by NHI Mgmt Group, based on content published by Push Security: “App-Specific Password phishing: another novel way to get around passkeys and MFA”.
Key questions
Q: What breaks when app-specific passwords remain enabled in a modern auth environment?
A: The break is that a phishing-resistant primary login no longer guarantees account safety.
Q: Why do app-specific passwords increase mailbox compromise risk?
A: Because mailbox access is enough to expose contacts, calendars, and recovery signals that support impersonation and follow-on account resets.
Q: What are the signs that legacy authentication paths are being abused?
A: Look for app password creation events, unexpected use of legacy mail clients, unusual mailbox access from low-context devices or locations, and subsequent password reset attempts.
Practitioner guidance
- Remove app-specific password creation where possible Disable legacy password creation by default and only allow it for documented exceptions with explicit business justification.
- Block access to app password setup pages Use URL controls or identity policy controls to prevent users from reaching app password creation pages for common providers.
- Inventory legacy authentication paths Map every application and recovery workflow that still accepts backup credentials, then classify which ones truly require them.
Bottom line: App-specific password phishing works because a legacy credential can bypass modern authentication controls even when passkeys and MFA are in place.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
12/06/2026 11:01 pm
App-specific password phishing is a legacy access-path problem, not a passkey problem. Passkeys and MFA can be technically sound while a separately created backup credential still bypasses them. The control failure is governance over alternate authentication routes, which means identity programmes must inventory every sign-in path, not just the primary one.
A few things that frame the scale:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
A question worth separating out:
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.
👉 Read our full editorial: App-specific password phishing exposes gaps in modern auth controls
This post was modified 3 days ago by NHI Mgmt Group