Why do forgotten authentication methods create persistence risk even when MFA and SSO are in place?

Why This Matters for Security Teams

Forgotten authentication methods are a persistence problem because they preserve alternate paths into an account after the primary path has been secured. MFA and SSO reduce routine login risk, but they do not automatically retire legacy password flows, backup codes, help desk resets, or secondary factors that were enabled long before the current control design. Attackers look for the weakest surviving path, not the strongest one.

This is why identity hardening has to include authentication method inventory, not just sign-in policy. NIST’s Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls both support the broader need for continuous access control, but they only help when the organisation knows every active method that can still authenticate a user or non-human identity. NHIMG’s Top 10 NHI Issues shows how often stale credentials and weak lifecycle hygiene outlast the original security project.

In practice, many security teams encounter the forgotten-method problem only after an attacker has already used an old path to regain access.

How It Works in Practice

The risk usually emerges when identity teams modernise the front door but leave older doors untouched. SSO may become the default path, while password login remains available for edge cases, a secondary factor stays enrolled on a dormant device, or recovery codes are stored and never rotated. If an attacker compromises one of those methods, they can bypass the intended control plane and persist even if the primary IdP account is reprotected.

Operationally, the fix is not “more MFA” in the abstract. It is authentication method governance: discover every enrolled method, map which ones are still allowed, and remove the ones that are redundant or no longer justified. That includes:

• Cataloguing all active login methods, recovery flows, and fallback channels.
• Disabling legacy password routes where SSO is the approved standard.
• Rotating or invalidating backup codes after use, issuance, or support-assisted recovery.
• Rechecking second factors after device replacement, role change, or prolonged inactivity.
• Reviewing admin and privileged accounts separately, because they are disproportionately targeted.

This is closely related to identity hygiene for NHIs as well as humans. NHIMG’s Ultimate Guide to NHIs - Key Challenges and Risks notes that long-lived credentials and weak rotation practices leave too many identities exposed long after the original need has passed. The same persistence pattern appears in human identity stacks when recovery options are left in place out of convenience. Where teams need a control baseline, current guidance suggests aligning this work with strong identity assurance and access review practices from NIST SP 800-53 Rev 5 Security and Privacy Controls and using continuous monitoring to detect dormant but still-valid methods. These controls tend to break down in large enterprises with multiple IdPs, locally managed apps, or inconsistent help desk processes because nobody owns the full method inventory.

Common Variations and Edge Cases

Tighter identity controls often increase support overhead, requiring organisations to balance resilience against user friction and break-glass needs. That tradeoff is real, especially in environments where contractors, legacy apps, or regulated recovery workflows still depend on alternate authentication paths.

The main edge case is not whether backup access exists, but whether it is governed. Some organisations keep a recovery path on purpose, such as emergency access for administrators or step-up authentication for high-risk transactions. Best practice is evolving here, and there is no universal standard for every exception. The safer pattern is to make exceptions time-bound, documented, and periodically reapproved, rather than permanently tolerated.

Another common variation is the blended identity estate. If SSO is centralised but local application passwords, API keys, or device-bound factors remain outside that SSO policy, an attacker may only need one forgotten method to re-enter. That is why NHIMG’s Ultimate Guide to NHIs - Why NHI Security Matters Now and the 2024 ESG Report: Managing Non-Human Identities both emphasise lifecycle visibility and revocation discipline. The lesson is straightforward: authentication methods must be treated as assets with an owner, an expiry, and a retirement path. If they are not actively governed, they become persistence mechanisms by default.

Related resources from NHI Mgmt Group

• Why do ghost logins create risk even when SSO is protected by MFA?
• Why do unmanaged SaaS apps create access risk even when SSO is in place?
• Why do collaboration platforms create compliance risk even with MFA in place?
• Why do non-human identities create more risk than many human accounts?