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.
Editorial analysis by NHI Mgmt Group, based on content published by Artemis Security: “MFA Worked Perfectly. That Was The Problem.”.
Key questions
Q: What breaks when MFA is satisfied through a real-time relay attack?
A: A real-time relay attack breaks the assumption that a successful MFA challenge proves the legitimate user is present.
Q: Why do login risk scores miss account takeovers that continue after sign-in?
A: Login risk scores are usually evaluated at the point of authentication, not across everything the session does afterward.
Q: How can security teams measure whether MFA is resisting abuse?
A: Teams should watch for repeated prompts, unusual registration changes, help-desk impersonation reports, and successful approvals outside normal user behaviour.
Practitioner guidance
- Prioritise phishing-resistant factors Move high-risk and privileged users to factors that are bound to origin or device, because real-time relay can satisfy password plus OTP challenges in one session.
- Monitor factor enrollment as a high-risk event Alert when a new device or security method is enrolled on an account that has no prior enrollment history, especially if the login came from anonymizing infrastructure or a new device fingerprint.
- Correlate IdP and SaaS audit logs on session ID Join sign-in events, mailbox actions, file previews, and deletion activity by shared session identifiers so you can reconstruct what the attacker did after authentication.
Bottom line: A valid MFA challenge does not guarantee the rightful user is present when the factors can be relayed in real time.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/08/2026 3:34 pm
Login risk scoring is not an identity boundary. Risk engines can flag anomalous location, device, and proxy use, but they still evaluate a login in isolation. This incident shows that a high-risk sign-in can be technically correct and operationally insufficient when factor enrollment and downstream SaaS activity are outside the same control plane. Practitioners should stop treating the login as the unit of trust and start treating the session as the governable object.
A few things that frame the scale:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
A question worth separating out:
Q: Should IAM teams rely on IdP logs alone to investigate federated compromises?
A: No. IdP logs show authentication, but the downstream SaaS platform often holds the evidence of mail access, file previews, and deletion activity. Investigations need the session identifier that crosses the boundary, plus enough telemetry from both sides to show what happened after login. Without that join, the compromise will look smaller than it was.
👉 Read our full editorial: MFA relay attacks show why login risk scoring is not enough