Notifications
Clear all
Topic starter
11/08/2026 3:24 pm
TL;DR: A real-time relay let an attacker satisfy MFA, enroll their own device, and hide evidence by deleting alert emails, while Okta, Entra, and the SIEM each saw only fragments, according to Artemis Security. The incident shows that login assurance, factor enrollment, and cross-source correlation must be treated as one identity control plane.
NHIMG editorial — based on content published by Artemis Security: a real-time relay attack that bypassed MFA and enabled persistent account takeover
By the numbers:
- 365., attacker used the same session to preview four other employees’ documents inside Microsoft 365.
Questions worth separating out
Q: How should organisations reduce MFA-related account takeover risk?
A: Start by replacing the weakest factors on the highest-risk accounts, then remove recovery paths that depend on shared secrets or easily intercepted delivery channels.
Q: Why do successful MFA challenges still lead to compromise in real-world attacks?
A: Because many attacks do not defeat MFA, they replay it.
Q: What should organisations watch for after a new MFA factor is enrolled?
A: Watch for first-time factor enrollment on accounts that have no prior enrollment history, especially when it follows impossible travel, proxy use, or device anomalies.
Practitioner guidance
- Require phishing-resistant second factors for high-value accounts Move accounts that can reach email, identity admin, finance, or source-code systems to FIDO2 or equivalent phishing-resistant methods.
- Alert on factor enrollment as a high-risk identity event Create detections for first-time device enrollment, method activation, and factor replacement when they occur after a high-risk sign-in or from anonymizing infrastructure.
- Correlate IdP and SaaS logs on shared session IDs Join Okta, Microsoft 365, email, and file audit trails on the session ID that survives federation so investigation can reconstruct what the attacker did after authentication.
What's in the full article
Artemis Security's full article covers the operational detail this post intentionally leaves for the source:
- The exact Okta and Microsoft 365 audit fields that tied the login, factor enrollment, and mailbox activity to one session
- The step-by-step investigation sequence used to reconstruct the intrusion from fragmented logs
- The specific deletion pattern used to remove Okta security notifications from the victim’s mailbox
- The detection workflow Artemis used to separate a valid login from a confirmed account takeover
👉 Read Artemis Security's analysis of the MFA relay takeover and cross-source detection →
MFA relay attacks and factor enrollment: are your controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
11/08/2026 3:34 pm
Real-time MFA relay attacks expose a trust gap, not a broken authentication standard. The account was challenged and the challenge worked, but the attacker controlled both factors in real time. That means the failure is not simple MFA absence. It is the assumption that a successful challenge proves user presence and authentic intent. Practitioners should treat relay resistance as a separate governance requirement, not as a side effect of MFA adoption.
A few things that frame the scale:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37%.
A question worth separating out:
Q: Who is accountable when an attacker abuses a valid session to access mail and files?
A: Accountability sits across the identity provider, the downstream application, and the organisation that operates them. The authentication platform may have challenged correctly, but the business still owns factor lifecycle, log correlation, and notification protection. Under most governance models, that makes this an identity control failure, not just an application incident.
👉 Read our full editorial: MFA relay attacks show why login risk scoring is not enough
