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

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.

Why This Matters for Security Teams

App-specific passwords are not a minor usability feature. They create an alternate authentication path that can bypass passkey or MFA improvements if they remain enabled on the same account. That matters because phishing-resistant login only protects the path that is actually enforced. If a legacy password path is still available, the account can remain reachable through weaker controls, recovery flows, or overlooked exceptions.

Security teams should treat this as an identity governance problem, not just an authentication setting. The practical risk is that organisations often believe they have completed a passkey or MFA rollout while old sign-in methods continue to exist in parallel. That gap is visible in broader NHI and credential governance failures, including the patterns described in Ultimate Guide to NHIs and the attack lessons captured in Microsoft Midnight Blizzard breach. Current guidance from NIST Cybersecurity Framework 2.0 supports reducing exposed authentication paths and continuously validating access controls. In practice, many security teams discover app-specific password exposure only after a user or administrator has already used the fallback path to bypass the stronger login they thought was in place.

How It Works in Practice

The first step is to inventory where app-specific passwords exist, who can create them, and which services still accept them. That includes email clients, older mobile apps, scanner integrations, legacy desktop software, and automation tools that were never updated for modern authentication. If the identity provider allows it, disable app-specific passwords globally. If business constraints require exceptions, restrict them to tightly scoped accounts and document the approval path.

Then align the control to the authentication policy itself. A passkey or MFA rollout is only complete when alternate sign-in methods are also evaluated. Teams should verify whether recovery codes, fallback passwords, legacy IMAP or SMTP auth, and device-based exceptions can still bypass the intended control. Where possible, require phishing-resistant authentication at the policy layer and prevent users from self-enabling weaker methods.

A practical operating model is:

• identify every app or workflow that still depends on legacy authentication
• block app-specific password creation by default
• allow exceptions only for named business services with expiry dates
• monitor authentication logs for legacy protocol use and unusual fallback access
• review whether password-based recovery undermines the stronger login path

This is also where broader NHI discipline matters. The same governance that reduces standing secrets and uncontrolled access in modern identity programs applies here, as reflected in The State of Non-Human Identity Security. In environments with older email protocols, shared admin consoles, or externally managed SaaS apps, these controls tend to break down because the application cannot yet consume passkeys and the organisation leaves the fallback path enabled as a permanent exception.

Common Variations and Edge Cases

Tighter authentication control often increases operational friction, so organisations have to balance user convenience against the risk of maintaining a shadow login path. That tradeoff is especially visible when a critical app cannot support modern methods, or when a third-party service still requires a generated password for API or mail access.

There is no universal standard for this yet, but current guidance suggests treating each exception as a temporary compatibility issue rather than a tolerated control gap. For high-risk accounts, use separate administrative identities, short exception windows, and explicit review dates. For lower-risk users, remove legacy methods entirely and provide a supported replacement path instead of preserving old behavior indefinitely.

Edge cases include shared mailboxes, service accounts masquerading as user accounts, and vendor-managed integrations that are not ready for passkeys. In those cases, the right question is not whether app-specific passwords are convenient, but whether they are still necessary and whether their use is constrained enough to preserve the intent of MFA. If the answer is unclear, the policy is already too loose.

Related resources from NHI Mgmt Group

• How should security teams choose between passwords, tokens, certificates, and biometrics?
• How should security teams authenticate AI agents in enterprise environments?
• How should security teams implement Client ID Metadata Documents?
• How should security teams handle stolen OAuth tokens when MFA is already in place?