TL;DR: Microsoft’s warning on MFA bypass shows that adversary-in-the-middle kits, pass-the-cookie attacks, and token theft can defeat authentication when session trust is treated as durable, according to Axiad. The practical lesson is that identity control must move from one-time verification to continuous device, session, and privilege scrutiny.
NHIMG editorial — based on content published by Axiad: Microsoft's warning about how hackers are bypassing MFA
By the numbers:
- Compromised non-human identities are involved in 80% of identity breaches.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: What breaks when attackers can steal MFA session tokens?
A: MFA stops being the control point once the attacker has a valid token or cookie.
Q: Why do unmanaged devices increase the risk of MFA bypass?
A: Unmanaged devices often lack the endpoint controls needed to protect browser sessions, cookies, and local token storage.
Q: How can security teams know if session controls are working?
A: Look for shorter token reuse windows, fewer successful replays from unknown devices, and faster revocation after suspicious activity.
Practitioner guidance
- Reduce token replay windows Shorten session lifetimes for high-risk applications and privileged users, then tie renewal to fresh device and risk checks instead of passive refresh behavior.
- Block unmanaged-device access to sensitive sessions Use device-based conditional access to prevent browser sessions from unmanaged personal devices reaching privileged or finance applications, especially where cookie theft is plausible.
- Separate privileged identities from everyday accounts Move administrators into dedicated cloud-only identities and keep administrative activity away from general-use browsing and email sessions.
What's in the full article
Axiad's full blog post covers the operational detail this post intentionally leaves for the source:
- Microsoft control recommendations mapped to specific conditional access and Defender for Cloud Apps settings
- Step-by-step guidance for revoking refresh tokens and forcing reauthentication after suspected token theft
- Examples of high-risk tenant modifications that should trigger alerts in production environments
- Device-based compliance checks for workers using unmanaged personal devices
👉 Read Axiad's analysis of Microsoft's warning on MFA bypass attacks →
MFA bypass attacks and token theft: are your controls keeping up?
Explore further
Token-based MFA trust is the real failure point, not the second factor itself. The article shows that if an attacker can steal a valid session artefact, MFA has already done its job but the access model has not. That exposes a structural problem in identity governance: the programme is still treating authentication success as proof of continuing trust. Practitioners should read this as a session-governance failure, not a login failure.
A few things that frame the scale:
- Compromised non-human identities are involved in 80% of identity breaches, according to Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: Who is accountable when stolen tokens are used to change cloud settings?
A: Accountability sits with the team that owns identity policy, privileged access design, and incident response together. If token revocation, admin separation, and tenant-change monitoring are split across teams, attackers can move faster than the response model. Governance must cover the whole session lifecycle.
👉 Read our full editorial: MFA bypass attacks expose the limits of token-based trust