The control fails because attackers can phish, relay, intercept, or fatigue the second factor, which means the login still depends on user judgment under attack. In practice, that leaves high-value accounts protected by a mechanism designed for convenience rather than adversarial resistance. For defense suppliers, that is no longer enough for sensitive access decisions.
Why SMS and Push MFA Stop Being Good Enough Under Attack
SMS and push approvals fail for the same reason: they still ask a human to make the right decision while an attacker is actively manipulating the login flow. The weakness is not just the channel, it is the trust model. If the second factor can be relayed, spoofed, intercepted, or annoyingly repeated until the user approves, the control is no longer phishing resistant.
That matters most for DIB environments because the accounts at issue usually unlock sensitive systems, vendor portals, remote access, cloud consoles, or privileged admin paths. When those accounts protect real operational authority, the authentication method has to resist adversarial pressure, not merely confirm that a phone was nearby.
SMS also adds carrier and telephony dependency, which gives attackers more paths than many teams assume. Number theft, SIM swap, SS7-style interception, and text-phishing all turn the supposedly separate factor into a recoverable secret or a relay target. Push MFA has a different failure shape, but the result is similar: it can be worn down by repeated prompts, stolen through adversary-in-the-middle phishing, or approved in error during a busy day.
For this reason, the practical break is not “MFA disappears,” but “MFA no longer proves the account holder had durable, phishing-resistant control of the login.” The system may still record a successful authentication, yet the assurance level behind that event is too weak for high-consequence access.
Where the Failure Shows Up in Real Access Paths
Once an attacker gets a primary password, a session token, or a social-engineering foothold, SMS and push often become the last obstacle rather than a strong barrier. That is why many incidents begin as credential theft and end as account takeover, internal tooling access, mailbox control, VPN entry, or cloud privilege escalation. The second factor is present, but it is no longer the deciding control.
Phishing-resistant methods change the access path because they bind the login to a cryptographic authenticator and the real relying party. By contrast, SMS codes and generic push prompts can be moved, relayed, or socially engineered outside that binding. In a compromise, the attacker is not trying to break the crypto, they are trying to exploit the human decision point or the delivery path.
This is also why legacy MFA creates a false sense of completion during security reviews. A program can say “MFA is enabled” while still leaving the organisation exposed to replay, fatigue, and downgrade attacks. The control is configured, but its resistance to active attack is not materially different from a convenience layer.
Current guidance increasingly treats phishing-resistant authentication, not any MFA, as the baseline for sensitive access. NIST’s digital identity guidance and the passwordless ecosystem both point to the same operational conclusion: if the login guards important authority, the factor has to resist interception and real-time coercion, not only password reuse.
What a Better DIB Authentication Posture Looks Like
The right design goal is to remove the attacker’s ability to interpose on the second factor. That usually means FIDO2 or passkeys for workforce access, stronger conditional access decisions for privileged paths, and tighter recovery rules so the organisation does not reintroduce weak factors through the back door. If a help desk can reset access with weak identity proofing, the strongest MFA policy in the world will still be bypassable.
For DIB programmes, the highest-value accounts should be treated differently from ordinary employee logins. Privileged admin access, remote vendor access, and high-trust systems should use phishing-resistant authentication by default, with SMS and push reserved only for low-risk fallback cases, if at all. NHIMG’s MFA Guide is a useful starting point for comparing the attack resistance of different MFA methods.
The rollout should also consider recovery, enrollment, and exception handling. A secure factor with weak recovery, broad bypasses, or unrestricted fallback channels is still weak in practice. That is especially true where contractors, third parties, and administrators all touch the same estate and where one compromised path can bridge into many systems.
Risk and Threat Considerations
SMS and push MFA create a predictable attack surface because the adversary only needs to defeat the user interaction, not the underlying account. That makes these methods attractive for phishing kits, adversary-in-the-middle relays, MFA fatigue campaigns, and prompt bombing against high-value targets.
Failure mechanism: The attacker steals or guesses the first factor, then intercepts, relays, or pressures the second factor until a valid login is produced. The control appears to work because an MFA event was logged, but the authentication step did not meaningfully resist the attack.
Impact: High-value DIB accounts can be taken over even when MFA is “enabled,” which increases the chance of remote access abuse, cloud console compromise, sensitive data exposure, and privilege escalation. That is why phishing-resistant methods are the better control for environments where login assurance has to survive an active adversary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5, CIS Controls v8, OWASP ASVS and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Covers phishing-resistant authentication and authenticator assurance for sensitive logins. |
| Recommendation — Adopt phishing-resistant authenticators for high-value access and set assurance levels by risk. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Directly governs authentication strength for workforce access that SMS and push MFA are meant to protect. |
| IA-5 — Authenticator Management | Applies to credential and authenticator lifecycle, including rotation, protection, and recovery paths. | |
| IA-9 — Service Identification and Authentication | Relevant where remote access, APIs, or non-human access paths depend on authentication strength. | |
| Recommendation — Require stronger authentication for organizational users protecting sensitive systems. Control authenticator issuance, recovery, and replacement so weak fallback paths do not bypass policy. Use stronger service and system authentication where machine or service access is involved. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Supports the need to remove weak access paths and enforce stronger sign-in controls. |
| Recommendation — Enforce stronger access rules for sensitive accounts and eliminate weak MFA exceptions. | ||
| OWASP ASVS | V6 — Authentication | Directly addresses authentication strength, phishing resistance, and factor handling for applications. |
| Recommendation — Require phishing-resistant authentication for sensitive application sign-in flows. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Fits the need to stop trusting legacy MFA alone and verify access more rigorously. |
| Recommendation — Apply stronger verification and least-privilege access decisions for sensitive sessions. | ||
Practitioner Guidance
What to prioritise: Move the most sensitive access paths first, including admins, remote access, and vendor-facing privileged accounts, because these are the places where weak MFA most quickly becomes a systemic risk. If a compromised login can reach multiple systems, it deserves phishing-resistant authentication before lower-risk populations.
What to verify: Confirm that your strongest policy is not being undermined by recovery, help desk reset, emergency bypass, or legacy auth exceptions. If a user can still authenticate through SMS after the “real” control fails, the programme has not actually changed its assurance level.
Practitioner takeaway: In a DIB context, SMS and push are acceptable only when the access decision is low consequence; for sensitive accounts, the real test is whether the factor can withstand phishing, relay, and human-pressure attacks without relying on user judgment under duress.
Related resources from NHI Mgmt Group
- What breaks when multi-factor authentication still relies on SMS codes or push approvals?
- How should security teams reduce identity risk when MFA still relies on passwords and SMS codes?
- What breaks when a CMMC programme relies on generic MFA instead of phishing-resistant authentication?
- What breaks when MFA still allows phishing and push fatigue?