Notifications
Clear all
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.
NHIMG editorial — based on content published by Push Security: app-specific password phishing and authentication bypass risk
By the numbers:
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions 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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
Push Security's full analysis covers the operational detail this post intentionally leaves for the source:
- How to block specific app-password creation pages for Google and Apple with browser controls
- The exact Microsoft setting path for disabling app-specific passwords in Entra
- Examples of related identity attack techniques, including consent phishing and device code phishing
- Operational guidance for finding backup login methods, ghost logins, and risky OAuth integrations
👉 Read Push Security's analysis of app-specific password phishing and bypass risk →
App-specific password phishing: are your controls really keeping up?
Explore further
12/06/2026 11:01 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: App-specific password phishing exposes gaps in modern auth controls
