On August 22, 2026, a threat actor convinced a ReliaQuest employee to enter a password into a fake single sign-on page and approve an MFA push.
The login worked.
The attacker received a brief session on the identity dashboard. But the session had view-only access. Attempts to open applications were denied because the device did not meet ReliaQuest’s trust requirements. ReliaQuest then terminated the sessions, expired the password, and reset every authentication factor.
According to ReliaQuest’s public incident account, no business application, customer data, additional identity, or persistence was reached.
That is what breach containment looks like in an identity-first environment.
The employee was deceived. The password and MFA approval were not enough to protect the identity provider session. Yet one successful authentication did not become broad access to everything connected to the identity provider.
The lesson is not that identity security failed. The lesson is that authentication must not be the last enforcement point.
An IdP Session Is Not A Trust Zone
The familiar enterprise pattern is simple:
user -> identity provider -> application launcher -> many applications
It is efficient. It can also recreate the flat network inside the identity layer.
If a valid IdP session automatically opens email, file storage, CRM, source code, ticketing, cloud consoles, and administrative tools, the organization has replaced one trusted internal network with one trusted identity session.
The attacker’s lateral movement path is no longer subnet to subnet. It is application to application.
NIST SP 800-207 explicitly rejects this model. Access to one resource must not automatically grant access to another. Access should be evaluated per session, with the least privileges needed, using identity, device state, resource policy, behavior, and environmental context.
The identity provider can establish who authenticated and how. It cannot make every downstream resource equally safe to access.
Each application still needs its own policy decision.
Microsegmentation Has To Follow The Session
Microsegmentation is often described as an east-west network control. That is necessary, but it is incomplete for modern SaaS and identity architectures.
A user can move laterally without sending one SMB packet. A valid session can cross from the identity dashboard into email, from email into document storage, from document storage into a password vault, and from there into cloud administration.
The segmentation policy therefore has to cover both network reach and application reach.
For each high-value application, define:
- which identities and roles may request access;
- which managed device states are acceptable;
- which authentication strength and freshness are required;
- which source networks, locations, or private access paths are valid;
- which actions are allowed inside the application;
- whether the application accepts a general IdP session or requires a fresh policy decision;
- which risk signals terminate or restrict an active session.
This creates small trust domains around resources instead of one large trust domain behind SSO.
CISA’s Microsegmentation in Zero Trust guidance describes microsegmentation as a way to reduce attack surface, limit lateral movement, and improve visibility across smaller groups of resources. The same goal applies when the movement path is a federation assertion, access token, browser session, or application launch.
Device Trust Is A Containment Control
ReliaQuest says the attacker had valid credentials, an approved MFA push, and a temporary identity session. Application access was still denied because the requests came from a device that did not meet policy.
This is an important distinction.
Device trust is not a decorative score added after login. It is a resource-access condition. A managed, healthy, expected device can receive one policy outcome. An unknown browser using the same identity can receive another.
For high-value resources, device policy should verify more than enrollment:
- the device is registered to the organization;
- its management and security agents are active;
- required security configuration is present;
- the operating system and browser meet policy;
- disk encryption and endpoint protection are healthy;
- the device identity is cryptographically bound where supported;
- the request matches an expected user, device, application, and network combination.
Device trust does not prove that the user is honest or the endpoint is clean. It removes a common attack path: taking a stolen session from an attacker-controlled device directly into business applications.
It also gives defenders a precise containment lever. They can deny the unknown device without disabling an entire network or application.
MFA Success Must Not End The Decision
MFA reduces credential-only attacks. It does not make every approved event legitimate.
In the ReliaQuest case, the attacker used phone impersonation, a lookalike domain, a fake SSO page, and MFA push abuse. The employee approved the prompt. The authentication event was technically successful and operationally hostile.
That is why downstream controls must evaluate context after MFA:
- Authentication method. Was the factor phishing-resistant, or could it be relayed or socially approved?
- Device state. Is the endpoint managed, healthy, and expected for this identity?
- Resource sensitivity. Does this application hold customer data, security operations, source code, secrets, or administrative authority?
- Session behavior. Is the user launching many applications, enrolling a new authenticator, changing recovery settings, or requesting unusual data immediately after login?
- Access path. Is the request using the normal private access route, region, browser, and device combination?
The policy response does not have to be binary. A suspicious but authenticated session can be limited to low-risk functions, forced through fresh phishing-resistant authentication, blocked from sensitive applications, or terminated entirely.
Sessions Need Their Own Incident Response
A password reset is not always enough.
NIST SP 800-63B-4’s session-management guidance notes that access and refresh tokens can remain valid after the user’s authentication session has ended. It also explains that sessions at an identity provider and sessions at relying applications are managed independently. Ending the IdP session does not automatically prove that every application session is gone.
A compromised-session playbook should therefore include:
- terminate the IdP session;
- revoke application sessions and refresh tokens;
- expire or rotate the password where relevant;
- reset compromised authentication factors;
- remove unauthorized factor enrollment and recovery changes;
- revoke OAuth grants or application consent created during the window;
- inspect every application launch and token issuance after the suspicious event;
- check for mailbox rules, API keys, access-key creation, delegated access, and persistence;
- temporarily narrow the identity’s permitted resources until investigation is complete.
NIST also describes session monitoring as the ongoing evaluation of usage, timing, device, geolocation, and IP characteristics. When fraud is suspected, the relying party should be able to reauthenticate or terminate the session.
That response path should be tested before an incident. If the SOC can disable an account but cannot identify and revoke the sessions created across connected SaaS applications, containment is incomplete.
Test The Post-Login Blast Radius
Most identity exercises stop after proving that an attacker can or cannot log in.
The better test begins after login.
Use a controlled account and an unmanaged test device, then answer:
- Which applications appear in the launcher?
- Which applications open without a new policy check?
- Can the session reach email, files, source code, support systems, or cloud consoles?
- Can it enroll another factor or change recovery settings?
- Can it create OAuth consent, API tokens, forwarding rules, or delegated access?
- Does access change when device health, location, authentication strength, or risk changes?
- Can defenders revoke the IdP session and every downstream application session quickly?
- Do the network controls prevent direct access to application backends that should be reachable only through approved access paths?
The result is a practical blast-radius map for a compromised identity.
NIST SP 1800-35 documents 19 Zero Trust example implementations across on-premises and multi-cloud environments. The useful architectural point is that Zero Trust combines identity governance, policy enforcement, microsegmentation, and resource-level access. No single login control carries the whole design.
Design For The Valid Hostile Session
Phishing-resistant authentication should be the default for privileged and high-value access. Push-based MFA should not be treated as equivalent. User training still matters. Fast detection still matters.
But the architecture should assume that an attacker will eventually obtain a session that looks valid at the identity provider.
Then ask what that session can actually do.
Can it access every connected application? Can it switch from identity to data to administration? Can it operate from an unmanaged device? Can it create persistence? Can the SOC terminate every downstream session, or only the one visible in the IdP?
ReliaQuest’s account shows the value of making a successful login a small incident instead of a broad one.
Authentication answered the first question. Device trust, application policy, session response, and containment answered the questions that mattered next.
The login worked.
The breach path did not.
Sources
- ReliaQuest: A Social Engineering Attempt Against ReliaQuest - What We Found
- SecurityWeek: ReliaQuest Confirms ShinyHunters Hack, but Says Impact Was Limited
- NIST SP 800-207: Zero Trust Architecture
- NIST SP 800-63B-4: Session Management
- NIST SP 1800-35: Implementing a Zero Trust Architecture
- CISA: Microsegmentation in Zero Trust, Part One
This article was generated with the assistance of AI and reviewed by the author.
