When an attacker overcomes multifactor authentication, it’s far from game over.
An August 2026 social engineering attack against cybersecurity company ReliaQuest let an attacker authenticate with genuine employee credentials. The attacker built a fake ReliaQuest login page, then phoned an employee, posed as company security staff, and talked them into entering their password and approving an MFA push. That gave the attacker a working, authenticated session.
Even so, the attacker could not reach a single ReliaQuest application. A valid login was not enough. Reaching the applications required a company-managed device, and the attacker was working from their own machine. Authentication had been fully defeated, and that was as far as the attacker could go.
MFA establishes who you are. It should not, on its own, decide what you or an attacker can reach.
How the attacker beat authentication
ReliaQuest said the August 22 attack began with a lookalike domain and a fake company SSO page. The attacker called several employees, impersonated a named member of the security team, and tried to direct them to the phishing site.
One employee entered a password and approved a push notification. ReliaQuest said this gave the attacker a brief, view-only session on its identity dashboard.
The method closely resembles activity ReliaQuest has documented around ShinyHunters and related social engineering campaigns: phone-guided phishing, convincing SSO impersonation, captured credentials, MFA abuse, and rapid attempts to turn a compromised identity into SaaS access.
At this point, telling users to recognize phishing is no longer a useful control. The employee has already been deceived. The password has already been captured. MFA has already been approved.
The relevant question becomes what the infrastructure does with the authenticated session.
Device context as an authorization boundary
ReliaQuest said the attacker repeatedly attempted to move from the identity dashboard into company applications. Those attempts were denied because access required a ReliaQuest-managed device.
According to the company, no business applications or systems were accessed, and no customer data was reached.
This is where the incident becomes useful for network and IT managers. MFA remained valuable because it still stopped anyone with only a password. But the environment did not assume that passing MFA made the session trustworthy.
Device trust added a separate access decision based on the endpoint presenting the authenticated identity. Depending on the environment, that decision can rely on device certificates, endpoint enrollment, management status, compliance information, or other attributes.
The underlying mechanism varies, whether based on certificates, MDM enrollment, or compliance state, but the outcome must remain identical: reproducing a user’s credentials should never grant the access rights of a trusted endpoint.
The same mistake appears elsewhere in network architecture. NetworkTigers has examined how devices can inherit access because of where they sit on the network rather than because anyone deliberately trusted them. An identity system can create the equivalent problem when an authenticated session inherits broad application access simply because the identity provider accepted it.
SSO makes the distinction more important
Centralized identity makes access easier to administer, but it also increases the value of a successfully compromised session.
A single SSO identity can provide routes into email, file storage, CRM systems, collaboration platforms, administrative tools, and other cloud services. That is why current social engineering campaigns concentrate on identity providers rather than trying to compromise every application separately.
If each downstream application accepts the identity provider’s decision without considering the device or access context, compromising the SSO session can collapse several access boundaries at once.
ReliaQuest’s environment behaved differently. The identity session existed, but downstream access still required another condition the attacker had not met.
Phishing-resistant MFA should make the initial authentication harder to defeat. Device-based controls solve a different problem by limiting the account’s value if authentication is defeated.
Where device trust breaks down
Device trust is not a single setting. It has to be enforced on every application and every access route into it. Turn it on everywhere and an unmanaged device is refused everywhere. The danger is the routes where it was never turned on.
Those gaps are normal. Some SaaS applications enforce the device check; others still accept a plain browser login. An admin tool set up before the policy existed may never have had it applied. A temporary migration exception gets left in place. Contractors and newly acquired teams connect from equipment the company does not manage yet.
On any of those routes, an unmanaged device gets through, not because it defeated the check, but because nothing on that route checks. That is the gap: applications the policy never reached.
Threat actors do not waste time cracking the most secure path; they sweep for the single unmanaged exception that grants a foothold.
IT teams therefore need to know where device requirements actually apply. That means identifying applications that still allow unmanaged access, administrative services with weaker policies, and exceptions created during migrations or troubleshooting that were never removed.
This is the same operational problem behind temporary network exceptions that quietly become permanent infrastructure. A bypass can begin as a reasonable response to an immediate problem and remain long after anyone remembers why it exists.
Trust also depends on how a new device is enrolled
The control has another dependency: the process that turns an unknown device into a trusted one.
ReliaQuest described the broader attack playbook as including rapid attempts to enroll a new authenticator after the initial identity compromise. Its response to the August incident included terminating the attacker’s sessions, expiring the affected password, and resetting authentication factors.
That matters because enrollment and recovery can undermine strong access policy.
If an attacker who controls an authenticated session can register another factor or trusted endpoint with little additional verification, the attacker can convert temporary access into something more durable. The same problem appears during self-service password resets (SSPR), passkey registration flows, or when a help desk approves a new device using evidence the attacker already possesses.
Joint NSA and CISA identity guidance specifically warns that allowing a user to enroll a new authenticator based only on a password severely undermines MFA.
Device trust is therefore not just an endpoint configuration. The enrollment process, recovery procedure, and help desk workflow all determine whether the control survives an account compromise.
Test what happens after the attacker gets through MFA
The ReliaQuest incident suggests a more useful way to review identity access than simply checking whether MFA is enabled.
Assume an attacker already has a valid employee session on an unmanaged device, then map what the session can reach.
Email may enforce device requirements while another SaaS application does not. A VPN may reject unmanaged endpoints while browser-accessible services accept them. Administrative systems may apply stricter controls than ordinary applications, or they may rely on the same authentication decision.
Those differences define the real impact of an identity compromise.
They are particularly easy to miss in hybrid environments where access decisions span identity, cloud, endpoint, application, and network systems. Every individual control can be correctly configured while the complete access path still contains an exception.
The ReliaQuest attack got far enough to make that boundary visible. The attacker successfully obtained an authenticated identity session, but the environment did not confuse that success with permission to access everything the employee could reach.
MFA should block most attempts to compromise an account. When an attacker eventually gains access to working credentials, the rest of the access architecture has to limit what that account can reach.
Sources
- ReliaQuest: A social engineering attempt against ReliaQuest: What we found
- ReliaQuest: ShinyHunters fast-tracks SaaS access with subdomain impersonation
- NSA and CISA: Identity and access management recommended best practices for administrators
About NetworkTigers
NetworkTigers is the leader in the secondary market for Grade A, seller-refurbished networking equipment. Founded in January 1996 as Andover Consulting Group, the company originally built and re-architected data centers for Fortune 500 firms. Today, NetworkTigers provides consulting and network equipment to global government agencies, Fortune 2000 companies, and healthcare companies. Visit www.networktigers.com
