Identity attacks hide in legitimate sessions and approved access

At a glance

What this is: This is an analysis of how legitimate identity activity can still produce illegitimate outcomes when security teams only see isolated signals instead of the full identity context.

Why it matters: It matters because IAM, PAM, NHI, and identity governance teams need to distinguish allowed access from justified access, especially when third-party users, unmanaged devices, and approved sessions are involved.

Context

Identity attacks are not always visible at the moment of login. A successful authentication, an approved permission, and a healthy application event can still produce a harmful outcome if the surrounding identity context shows the action was not expected, justified, or authorised for that business purpose.

The article’s central problem is a governance gap across identity, device, resource, and purpose. Security teams need to know not just whether access was granted, but whether the activity fits the identity’s role, the device posture, and the approved work being done.

This is especially relevant where third-party access, unmanaged endpoints, and broad application permissions intersect. In that environment, the security failure is often not a blocked login but a permitted action that should have been treated as out of context.

Key questions

Q: How should security teams handle low-risk suspicious logins without creating unnecessary friction for legitimate users?

A: Treat low-risk logins as a monitoring opportunity rather than an automatic lockout. Let the session proceed, but notify the user with useful context such as location and device so they can confirm whether the activity was theirs. This keeps legitimate access smooth while still giving the account holder a fast way to spot an abnormal login and respond before the risk escalates.

Q: Why can approved access still become a security incident?

A: Approved access can become risky when the action exceeds the business purpose that justified it. A contractor may have permission to view records but not to export thousands of them, especially from an unmanaged device. The risk comes from misuse of valid access, not only from stolen credentials or failed authentication.

Q: What are the signs that identity activity is out of context?

A: Common signs include bulk downloads without a matching ticket, access from unmanaged or untrusted devices, activity that does not fit the role history, and sensitive actions with no approved project or owner. Those signals do not prove compromise on their own, but they indicate that the event needs contextual review rather than simple log inspection.

Q: What should teams do when a vendor account accesses more data than expected?

A: They should compare the access against the vendor’s current assignment, the device used, the data sensitivity, and the session history. If the work cannot be tied to an approved business purpose, the team should contain the session, review the entitlement path, and involve the account owner or business sponsor for decision-making.

Technical breakdown

Why legitimate sessions can still produce malicious outcomes

A valid session only proves that authentication succeeded and the application accepted the account. It does not prove that the action was justified, timely, or appropriate for the business purpose. That is why identity attacks can sit inside normal-looking activity such as a contractor export, an administrator change, or a vendor support action. When controls only evaluate login state, they miss the relationship between identity, device, access scope, and intended work. The real technical gap is context stitching across control planes, not the absence of a login event.

Practical implication: build detections that evaluate session legitimacy together with device trust, entitlement scope, and business purpose.

How identity, device, and purpose data change the risk decision

The identity provider, application audit trail, endpoint telemetry, identity governance records, and ticketing systems each contain a different part of the story. None of them alone can explain whether a large download or privilege use is expected. The technical challenge is correlating identity attributes with device posture, resource sensitivity, and approved change records quickly enough to drive an action. This is less about finding a single malicious indicator and more about resolving competing explanations for the same event.

Practical implication: join IAM, endpoint, application, and workflow data before you rely on alert volume or event content alone.

Why permitted activity can still exceed authorised business use

Traditional access control answers whether an identity can do something. It does not answer whether it should do it in the current context. That distinction matters when a third-party user retains access after scope changes, when an administrator uses a trusted session to weaken controls, or when a service account reaches an unexpected system. In each case the action may be technically allowed while still representing misuse, overreach, or compromise. The technical failure is a control model that stops at permission and never evaluates purpose.

Practical implication: pair entitlement review with purpose-based validation for high-risk access paths and export actions.

Threat narrative

Attacker objective: The objective is to turn legitimate access into an illegitimate outcome while remaining inside the boundaries of allowed authentication and permissions.

1. Entry occurs through a legitimate account and approved session rather than a stolen password or exploit.
2. Credential or session abuse is not obvious because the activity is technically permitted by the application and identity provider.
3. Escalation happens when the actor uses valid access to perform an out-of-scope bulk download or control change.
4. Impact is the exposure of data or security posture change that the business never authorised for that identity and purpose.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Context, not authentication, is now the decisive control plane: identity attacks increasingly succeed by staying inside allowed access while violating business intent. This means the old question of whether login succeeded is insufficient for governance. Practitioners need to treat purpose, device trust, and resource sensitivity as first-class identity signals, not post-hoc investigation details.

Permitted action is not authorised use: this article exposes a governance blind spot where access approval is mistaken for behavioural approval. A contractor can remain within assigned permissions and still create unacceptable exposure if the work is outside scope or the device is unmanaged. The implication is that entitlement models must be read alongside expected activity, not in isolation.

Legitimate sessions create identity blast radius when ownership is unclear: once an approved session can reach data, exports, admin functions, or other sensitive actions, the real risk is not the login event but what the identity can still do before anyone notices. That makes ownership, business purpose, and exception handling core controls in IAM and IGA, not supporting records.

Identity context stitching is the new control requirement for third-party access: the article’s strongest signal is that vendor identities, unmanaged devices, and accepted permissions can combine into a blind spot that traditional point controls miss. Identity context stitching: the act of correlating identity, device, resource, and purpose into one decision layer. Without that, response teams will keep reconstructing intent after the fact instead of detecting misuse in time.

Workflow-assisted investigation is becoming part of identity governance: when evidence is incomplete, teams still need a defensible path from detection to owner review, containment, or escalation. The operational point is not to automate every decision, but to ensure that human review receives a completed context package rather than a raw event. That changes how identity programmes are measured.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Third-Party, B2B and Contractor Access Guide

What this signals

Identity context stitching: security teams will need a single decision layer that combines identity, device, resource sensitivity, and business purpose before they can trust an access event. Without that stitching, investigations will keep over-reading authentication logs and under-reading the reason the access existed in the first place.

Third-party access is the sharpest edge of this problem because approved permissions often outlive the work that justified them. That makes entitlement review, assignment tracking, and unmanaged device detection part of the same governance problem rather than separate control domains.

For practitioners

• Correlate identity, device, and purpose before escalating Require investigations to combine account ownership, device trust, application event, and business justification before a download or privilege event is labelled suspicious.
• Tighten third-party access to approved assignments Review contractor and vendor accounts against current tickets, projects, and support cases so access does not outlive the work that justified it.
• Flag unmanaged devices during sensitive access Treat unmanaged endpoints as a material risk signal when they are used to reach customer records, administrative actions, or export functions.
• Require purpose validation for bulk export activity Add a decision point for large downloads and other high-impact actions so security and business owners can confirm the access matches the stated work.

Key takeaways

• Identity attacks can succeed without breaking authentication if the action itself is still inside an allowed session.
• The critical evidence is whether the activity matches the identity’s role, device posture, and approved business purpose.
• Teams reduce exposure by correlating access context before they treat a permitted action as legitimate.

Key terms

• Identity context: The entitlement, ownership, and purpose information that explains why an action occurred and whether it was expected. For security operations, identity context turns raw alerts into decisions by showing which human or non-human identity acted and what it was allowed to do.
• Purpose-Based Access: An access model that allows or denies AI use based on why the request is being made, not only who the requester is. It is more precise than role alone because it can combine identity, data labels, and request context to control sensitive AI interactions at runtime.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.