Because the risk is not just whether users have a second factor, but whether the factor can withstand real-world phishing and interception attempts. Defense suppliers often handle sensitive DoW information, so the authentication standard becomes part of their trust posture. If the factor can be replayed or coerced, the access decision is still weak.
Why phishing-resistant MFA changes the risk calculation
For defense suppliers, the question is not whether a second factor exists, but whether the factor survives real phishing, relay, and interception attempts. Generic MFA coverage can still leave a path open if the attacker can trick the user, replay a code, or harvest a session after sign-in. Defense work raises the stakes because authenticated access can expose sensitive DoW-related information and trusted supplier systems.
Phishing-resistant methods change the control from “extra step” to “proof tied to the intended destination and device or cryptographic authenticator.” That matters because the failure mode is different: code-based MFA can be bypassed through social engineering, while phishing-resistant MFA is designed to break the attacker’s ability to reuse what they stole.
That distinction is why NIST SP 800-63 Digital Identity Guidelines treats authenticator strength and phishing resistance as part of assurance, not just convenience.
What defense suppliers are really protecting
In this context, MFA is part of trust posture, not just login hygiene. A supplier may use the same identity platform as any other enterprise, but the exposure profile is different when the account can reach export-controlled programs, engineering data, contract systems, supplier portals, or admin consoles that support national security work. The practical question is whether the authentication method resists the most common access paths attackers use against high-value targets.
Defense suppliers also tend to have broader trust chains than a generic business. Remote access, third-party support, federated sign-in, and privileged administration can all become pivot points if MFA is weak or replayable. A token that protects ordinary corporate access may still fail against adversary-in-the-middle phishing, push fatigue, or session theft.
That is why guidance such as the MFA Guide and the Passwordless and Passkeys Guide is useful here, because both focus on methods that block common phishing and relay patterns rather than merely adding another checkbox to account policy.
Real-world breaches show the difference. Twilio’s 2022 SMS phishing case and CitrixBleed exploitation both illustrate that a factor can exist and still fail to stop compromise when the attack targets the authentication flow itself or the session that follows it.
Why generic MFA coverage can be too weak for supplier environments
Generic MFA coverage often measures adoption, not resistance. An organisation can report high MFA enrollment while still relying on SMS, OTP codes, push approval, or weak recovery paths that attackers can abuse. For defense suppliers, that gap matters because the most likely attack is often not brute-force login, but phishing for the factor, coercing approval, or stealing the session after authentication.
The operational issue is that generic MFA tends to flatten different controls into one metric. That makes it hard to distinguish between a control that is merely present and one that is resilient under active attack. A supplier with “100% MFA” may still be exposed if privileged users, remote access portals, or recovery workflows accept replayable factors or fallback methods.
Supplier environments also need to think about account recovery, help desk resets, and federation. Those paths are often the soft underbelly of an otherwise strong login policy, especially when attackers target support staff or exploit legacy accounts. In other words, the MFA method must be judged together with the recovery and exception paths, not in isolation.
The lesson from incidents such as Microsoft Midnight Blizzard breach and Change Healthcare breach 2024 is that weak or absent phishing resistance can turn a routine login into a high-impact compromise.
Risk and Threat Considerations
Defense suppliers are attractive targets because a single successful login can expose sensitive programs, trusted communications, or administrative access. Attackers do not need to defeat every account, they need to find one weak factor, one fallback path, or one user who can be phished into approving access.
Failure mechanism: The control fails when the factor can be relayed, replayed, approved under pressure, or bypassed through session theft, recovery abuse, or legacy authentication.
Impact: A compromised supplier account can enable data theft, privilege escalation, lateral movement, or trust abuse that reaches beyond the original user and into protected partner systems.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant authentication and assurance levels directly govern this exact access question. |
| Recommendation — Use assurance levels to require phishing-resistant authenticators for sensitive supplier access. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Defense supplier workforce access depends on strong user authentication controls. |
| IA-5 — Authenticator Management | The question turns on whether the factor can be phished, replayed, or recovered unsafely. | |
| IA-9 — Identification and Authentication (Service and Non-Organizational Users) | Supplier ecosystems often include federated, service, and external access paths. | |
| Recommendation — Enforce strong user authentication for supplier systems and privileged access. Manage authenticator lifecycle and remove weak or replayable factors from critical access. Apply phishing-resistant authentication requirements to external and service access paths. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The issue is about controlling access paths that survive phishing and interception. |
| Recommendation — Limit authentication methods and remove weak login paths for sensitive accounts. | ||
Practitioner Guidance
What to prioritise: For defense suppliers, prioritise phishing-resistant MFA for any account that can access sensitive programs, admin functions, remote access, or federated SSO. Treat SMS, voice, and push-only approval as transition states, not end states, for high-value access.
What to verify: Verify the full authentication path, including enrollment, recovery, help desk reset, step-up authentication, and exception handling. If any of those paths still accept replayable factors or weak fallback methods, the overall assurance level remains weaker than the headline MFA policy suggests.
Practitioner takeaway: The control question is not “do users have MFA,” but “can an attacker still turn the sign-in flow into access.” For defense suppliers, only phishing-resistant methods materially answer that question.
Related resources from NHI Mgmt Group
- Why do phishing-resistant controls matter more than generic MFA in regulated finance?
- Why do phishing-resistant MFA methods matter if attackers can still get in?
- Why do identity recovery workflows matter as much as phishing-resistant MFA?
- Why does phishing-resistant authentication matter more than traditional MFA for PCI DSS compliance in high-risk environments?
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 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org