Why do SMS codes and push notifications create identity risk?

Because they can be phished, intercepted, or coerced through social engineering and MFA fatigue. They prove that a second step happened, but not that the authenticator is resistant to an attacker who can manipulate the user or the session.

Why This Matters for Security Teams

SMS codes and push approvals are often treated as “good enough” because they add a second step, but that step can still be manipulated. Modern identity attacks target the user, the device, and the session at the same time, so the issue is not simply whether a code or tap occurred. It is whether the authenticator resists phishing, interception, and coercion under real attack conditions. The NIST Cybersecurity Framework 2.0 is useful here because it pushes teams toward risk-informed identity controls rather than checkbox MFA.

NHI Management Group research shows that identity compromise rarely stays isolated: the 52 NHI Breaches Analysis and the Ultimate Guide to NHIs both underline how often attackers exploit weak identity assurance once they are inside the trust boundary. The same pattern applies to human authentication when the factor is easy to socially engineer. In practice, many security teams encounter abuse of SMS and push not through formal penetration testing, but only after an account takeover or help desk escalation has already occurred.

How It Works in Practice

SMS and push factors create risk because they authenticate a transaction, not necessarily a trustworthy actor. SMS can be intercepted through SIM swap, call forwarding abuse, compromised messaging channels, or malware on the endpoint. Push notifications can be approved accidentally, exhausted through MFA fatigue, or accepted under pressure during a convincing phishing session. In both cases, the attacker does not need to defeat the factor cryptographically if they can redirect, replay, or coerce the human who receives it.

Security teams reduce this risk by moving from simple second-step verification toward stronger, phishing-resistant authentication and tighter session controls. Current guidance suggests the following hierarchy:

• Prefer phishing-resistant authenticators such as passkeys, FIDO2, or certificate-based methods for high-risk access.
• Tie approval to device posture, session context, and risk signals rather than a blind tap or six-digit code.
• Use step-up checks only for sensitive actions, not as the sole gate for every login.
• Limit recovery paths, because SMS-based fallback often becomes the easiest attack route.

For organizations managing large identity estates, this is the same control logic NHI teams use when they replace long-lived secrets with short-lived credentials and policy-driven access. The Ultimate Guide to NHIs — Key Challenges and Risks shows why weak lifecycle management keeps identities exploitable long after the original issue is known. The operational lesson is simple: if an attacker can influence the user experience, then “approval” is not the same as “assurance.” These controls tend to break down in environments that still rely on SMS fallback for workforce recovery and legacy push MFA for privileged access, because those flows preserve the easiest path for takeover.

Common Variations and Edge Cases

Tighter authentication often increases friction and support overhead, so organisations have to balance stronger assurance against user disruption and recovery complexity. That tradeoff is real, especially in distributed workforces, frontline operations, and regulated environments where device management is uneven.

Best practice is evolving, but a few edge cases are clear. SMS may still be used as a low-assurance recovery option in limited contexts, yet it should not be the primary factor for privileged, financial, or administrative access. Push can also be acceptable when paired with number matching, device binding, and strong conditional access, but those additions reduce rather than eliminate risk. There is no universal standard that makes plain push approval resistant to MFA fatigue by itself.

Teams should also distinguish between authentication strength and account recovery strength. A strong login factor is undermined if password reset, help desk verification, or mobile number change processes are weak. The Top 10 NHI Issues and The 2024 ESG Report: Managing Non-Human Identities reinforce a broader identity principle: weak lifecycle controls create persistent exposure, even when the front door looks secure. In mature environments, the safest interpretation is that SMS and basic push are convenience mechanisms, not high-assurance proof of identity.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?
• Why do collaboration tools create such a large secrets risk?