Look for shared secrets, OTP dependence, push fatigue risks, and exceptions for privileged users. If the strongest methods are not required on the most sensitive paths, the programme is likely describing resilience it does not actually enforce.
What “phishing resistant” should actually prove
Phishing resistance is not a label for using MFA in general. It means the strongest authentication methods are bound to the legitimate origin or device in a way that makes common phishing paths, such as OTP relay, credential replay, and consent trickery, fail in practice. When a programme relies on reusable secrets, it is still depending on a factor that an attacker can forward or steal, rather than one that resists phishing.
A useful sanity check is whether the method still works when the user is being actively proxied through a fake login flow. Methods such as passkeys and FIDO2 security keys are designed to make that much harder, while shared secrets, one-time codes, and weak recovery steps remain vulnerable to interception or social engineering. The programme should be judged by its weakest enforced path, not its strongest marketing statement. NIST SP 800-63 Digital Identity Guidelines gives the clearest current reference point for phishing-resistant authenticator design.
Signs the control is weaker than the claim
The most obvious warning sign is dependence on shared secrets or OTPs as the primary fallback. If users can still sign in with passwords plus OTP, SMS codes, or app-generated codes, then the programme is still exposed to relay, fatigue, and token theft. Another warning sign is exception handling that quietly preserves weaker methods for admins, help desk recovery, or “temporary” access that never really expires.
Policy language matters less than enforcement. If the strongest method is optional, if step-up authentication is only applied on some apps, or if legacy protocols remain enabled for privileged users, the programme is not truly phishing resistant end to end. That is exactly where organisations tend to inherit risk from the gap between stated intent and actual authentication paths. MFA Guide and Passwordless and Passkeys Guide both help distinguish resistant methods from weaker MFA variants.
A second sign is recovery design. If account reset, device re-enrolment, or help desk verification can be completed with knowledge-based checks, email links, or OTP-based callbacks, an attacker will often target recovery instead of the primary login. In other words, a phishing-resistant front door can still be undermined by a non-resistant side door. Workforce Identity Security Guide is useful where the real issue is not just sign-in, but the full lifecycle around resets and session control.
How to test whether the programme is enforced, not aspirational
Start by testing the highest-value paths first: privileged users, remote access, IdP administration, and recovery flows. If those paths still allow passwords, OTPs, SMS, push approvals, or exception-based bypasses, the programme is signalling convenience over resistance. The question is not whether a strong method exists somewhere in the estate, but whether it is mandatory where the blast radius is largest.
Then inspect whether the environment still accepts attacks that a phishing-resistant design should block. Push fatigue, OTP relay, token theft, and session hijacking are all signs that the control boundary is softer than advertised. If the design can be defeated by user prompts that an adversary can manipulate, then the programme is still relying on user judgment under pressure rather than cryptographic origin binding. CitrixBleed exploitation 2023 shows why session and token security matter alongside login method choice.
Finally, check whether the strongest method is consistently required during enrollment, recovery, and reauthentication, not just initial login. Programs often look strong in architecture diagrams but become weak in exception handling, migration coexistence, or admin carve-outs. If the most sensitive accounts still have a weaker path, the programme is describing assurance it does not truly enforce. Microsoft Midnight Blizzard breach is a reminder that legacy or exempted accounts can become the real weak point.
Risk and Threat Considerations
A programme that only appears phishing resistant creates a false sense of assurance. Attackers do not need to break the strongest factor if they can use recovery, exceptions, or weaker fallback methods to obtain access. The practical risk is that teams will overestimate resistance while the authentication estate still allows credential theft, OTP relay, push fatigue, and privileged-path compromise.
Failure mechanism: the organisation preserves at least one phishing-friendly path, such as shared secrets, OTPs, legacy auth, or weak recovery, and attackers target that path instead of the primary factor.
Impact: account takeover can still occur, especially on privileged or remote access paths, and the programme’s claims will not match its actual blast-radius reduction.
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, OWASP ASVS and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines phishing-resistant authenticator expectations for sign-in assurance. |
| Recommendation — Use phishing-resistant authenticators for sensitive access and verify fallback paths do not weaken assurance. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The question is about whether organizational-user authentication is truly enforced. |
| IA-5 — Authenticator Management | The answer hinges on shared secrets, OTPs, recovery, and authenticator strength. | |
| Recommendation — Enforce strong user authentication on sensitive paths and remove weaker fallback options. Manage authenticators so weak or reusable secrets cannot satisfy high-risk access. | ||
| OWASP ASVS | V6 — Authentication | Phishing resistance depends on robust authentication and resistant factor design. |
| V7 — Session Management | Token theft and session hijacking can defeat otherwise strong login methods. | |
| Recommendation — Verify authentication flows, recovery, and fallback methods block phishing-prone sign-in paths. Protect sessions so a strong login method is not undone by token replay or hijacking. | ||
| CIS Controls v8 | CIS-5 — Account Management | Exception handling and privileged-user carve-outs are central to the question. |
| Recommendation — Eliminate weak account exceptions and enforce strong authentication for privileged access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Phishing resistance is an access-control outcome tied to enforced authentication paths. |
| A.8.5 — Secure authentication | The programme’s claim depends on secure authentication mechanisms, not merely MFA. | |
| Recommendation — Apply access-control policy so sensitive paths cannot fall back to weaker sign-in methods. Require secure authentication methods that resist interception, replay, and relay attacks. | ||
Practitioner Guidance
What to verify: confirm that privileged access, remote access, admin consoles, and recovery flows require the strongest method by default, not by exception. If any of those paths still permit OTP, push, or password-based fallback, treat the programme as partially resistant at best.
Decision rule: if a user can be phished into approving access, relaying a code, or completing recovery with only knowledge-based checks, then the control should be treated as vulnerable and re-scoped. If the method is cryptographically bound to origin and device, the programme is far closer to the resistance claim.
Practitioner takeaway: phishing resistance is proven by enforced weakest-path removal, not by the presence of one strong login option in the stack.
Related resources from NHI Mgmt Group
- What are the signs that an organisation is falling behind on phishing resistant authentication?
- How should security teams prioritise phishing-resistant authentication in a zero trust programme?
- What are the signs that mobile authentication policy is still too weak for phishing-resistant access?
- What breaks when a CMMC programme relies on generic MFA instead of phishing-resistant authentication?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org