Identity attacks hide in legitimate sessions and approved access

At a glance

What this is: This is an analysis of how identity attacks can look legitimate at the event level while becoming risky only when context is joined across identity, device, access, and business purpose.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes all miss abuse when they rely on isolated logs instead of joined context that explains whether access was expected, justified, and appropriate.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read Offroad AI's analysis of identity attacks hidden in legitimate access

Context

Identity attacks do not always begin with a stolen password or a blocked login. In many cases, the access is valid, the session is real, and the individual action looks permitted until the surrounding identity context shows the activity was not expected, justified, or appropriate for the business purpose.

That matters for IAM and NHI programmes because traditional control points often evaluate one signal at a time. A successful login, an approved account, or a permitted download can all be true while the overall behaviour still represents misuse, account compromise, or third-party access beyond assignment.

The practical problem is context fragmentation. Identity, device, application, ticketing, vendor management, and ownership data often live in separate systems, so teams struggle to prove whether an action was legitimate work or a security event until after the damage is already visible.

Key questions

Q: How should security teams investigate a large data download from a valid account?

A: Start by joining the identity, device, session, entitlement, and business-purpose records into one case. A valid login does not prove the action was legitimate. Teams should test whether the download matched the person’s role, the device was trusted, and the access was justified by an approved assignment or ticket.

Q: Why do valid sessions still create identity risk?

A: Because session validity only proves the account authenticated successfully. It does not show whether the activity was expected, proportionate, or appropriate for the identity’s assignment. Risk increases when organisations cannot explain why the identity, device, resource, and business purpose fit together at the time of action.

Q: What do security teams get wrong about permissioned data access?

A: The common mistake is treating permissioned access as a compliance checkbox instead of an operational control. In practice, the hardest part is maintaining scope, monitoring third-party use, and revoking access quickly when risk changes. Without those controls, permissioned access can become persistent access by another name.

Q: How can organisations tell the difference between work and abuse?

A: By checking for an approved reason, trusted device, expected resource, and normal behaviour history. If those elements do not align, the team should treat the activity as suspicious even when authentication succeeded and the account still holds valid access.

Technical breakdown

Why legitimate authentication is not enough for identity risk

Authentication confirms that an identity presented acceptable proof at a point in time. It does not answer whether the action that followed was expected for that identity, on that device, against that resource, and for that business purpose. This is why modern identity investigation has to combine session data, device trust, access scope, and business context. Without that join, a large export, admin change, or new system connection can look identical across benign work, misuse, or compromise. The core technical issue is not log volume. It is the inability of isolated control planes to express intent and authorised purpose across a sequence of events.

Practical implication: correlate authentication, device, entitlement, and case or ticket context before treating an activity as normal.

How context joins turn identity events into explainable decisions

Identity context is the structured relationship between who acted, what they were allowed to do, from which device, on which resource, and under what approved business reason. In practice, that means joining IAM, IGA, endpoint, application, and ownership records into one investigative view. The point is not to replace detection with narrative. It is to make the decision explainable. When an analyst can see that a vendor account used an unmanaged device to export more records than its assignment required, the event becomes a policy and risk question rather than a raw alert.

Practical implication: build investigation workflows that resolve identity, device, purpose, and entitlement into one case view.

Why rule-based detection struggles with changing identity behaviour

Traditional rules require teams to predefine every condition that makes an action suspicious, including who the identity is, which devices are trusted, what data is sensitive, and which business exceptions are valid. That approach breaks down as roles shift, vendors rotate, and permissions drift. The better pattern is objective-driven detection, where the team states the risky behaviour in plain language and the system resolves the surrounding context dynamically. This is especially important for third-party identities, where legitimate access can still be used outside the intended assignment window.

Practical implication: use objective-based detections for context-heavy identity activity instead of trying to hard-code every exception.

Threat narrative

Attacker objective: The objective is to use valid access to move sensitive data out of the environment without triggering a conventional authentication failure.

1. Entry occurs through a legitimate sign-in by a third-party support analyst using an account that is authorised for some application access.
2. Escalation happens when the authenticated session is used to download thousands of records to an unmanaged device, expanding the impact beyond the intended assignment.
3. Impact follows when approved access is used for an unapproved bulk export, creating exposure, potential data theft, and response workload before the behaviour is understood.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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 login success, is the real control boundary. Authentication answers only whether an identity proved itself to a system. It does not prove the action was expected, justified, or proportionate to the assignment. That means identity governance has to move beyond access granted toward access used in context. Practitioners should treat this as a structural limitation of event-level IAM, not a tuning problem.

Identity context gap: This article shows that the core governance failure is not missing permission data but missing relationship data between identity, device, resource, and business purpose. A successful session can still be an illegitimate outcome if the system cannot explain why the activity was acceptable. The implication is that investigation quality now depends on context synthesis, not more alerts.

Third-party access breaks when lifecycle ownership is fragmented. Vendor accounts often sit outside the main employee lifecycle, yet they can still access sensitive data, export records, and outlive the business purpose that justified them. That makes offboarding, assignment scoping, and purpose verification central controls, not administrative chores. The practical conclusion is that third-party identity governance must be operational, not documentary.

Legitimate access, illegitimate outcome is the named governance problem here. The business may authorise the account, but it does not automatically authorise the use pattern, volume, device, or timing. This is where conventional least-privilege thinking breaks: the permission may be valid, but the outcome is not. Practitioners should recognise this as a policy and context alignment problem across IAM, IGA, and NHI oversight.

Context-aware detection is now an investigation design requirement. If the organisation cannot answer who acted, why they were expected to act, and whether the device and scope matched the assignment, then the alerting model is incomplete. Teams should assume that future identity abuse will increasingly appear as normal work until joined evidence proves otherwise.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing how slowly identity exposure is often remediated.
• That gap is explored further in 52 NHI Breaches Analysis, where recurring lifecycle failures repeatedly turn access into exposure.

What this signals

Legitimate access can no longer be treated as low-risk by default. As identity estates expand across employees, vendors, service accounts, and AI-driven workflows, the security programme needs investigation logic that explains why an action happened, not just whether the login succeeded. The operational shift is toward context-first triage, where ownership and purpose are as important as authentication.

Identity context becomes the control plane for NHI governance. When access is allowed but the device, volume, or resource does not match the assignment, the issue is no longer authentication. It is an entitlement and lifecycle problem that should feed into review, offboarding, and blast-radius reduction. Teams that still rely on isolated logs will continue to miss abuse until after data leaves the environment.

The next maturity step is to make context synthesis routine rather than exceptional. That means pairing IAM records with tickets, vendor ownership, and application telemetry so analysts can determine whether a third-party action is legitimate work or policy-violating access. For deeper lifecycle patterns, the Ultimate Guide to NHIs remains the clearest baseline.

For practitioners

• Join identity, device, and purpose data in one investigation path Create a case workflow that pulls authentication, endpoint trust, application audit, vendor assignment, and ticket data together before an analyst decides whether the activity is expected or suspicious.
• Define approved business purpose for high-risk access Require each sensitive third-party or contractor entitlement to map to a named assignment, support case, migration, or change request so investigators can test whether the action matched the reason access existed.
• Alert on context mismatch, not only on volume Treat unmanaged devices, out-of-assignment resources, and unexplained exports as primary risk signals even when the login is valid and the account is in good standing.
• Link identity reviews to downstream blast radius When reviewing a user or vendor account, also inspect what else that identity can export, change, or delete so the team understands the potential impact before the next session begins.

Key takeaways

• Identity abuse often hides inside valid sessions, so authentication alone is no longer a sufficient risk test.
• The decisive evidence is contextual, including device trust, assignment scope, business purpose, and downstream blast radius.
• Programmes that join IAM, IGA, endpoint, and ownership data will detect misuse earlier than teams that rely on isolated logs.

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.
• Legitimate access, illegitimate outcome: This is the condition where an identity uses valid credentials and approved permissions to produce an outcome the business never intended. The action may pass authentication and authorization checks, yet still represent misuse, compromise, or policy violation once device, timing, scope, and purpose are considered.
• Context-aware secret detection: Context-aware secret detection is a scanning approach that looks at how code uses a value, not just what the value looks like. It helps identify high-risk material such as signing keys, OAuth pairs, and embedded credentials that pattern matching alone can miss.
• Third-Party Identity: An identity issued to a partner, vendor, contractor, or external service that can access internal systems. These identities often sit outside normal employee governance and can become persistent trust paths if they are not reviewed, expired, and revoked on schedule.

What's in the full article

Offroad AI's full analysis covers the operational detail this post intentionally leaves for the source:

• How its investigation flow correlates identity provider, endpoint, application, and ticketing data into one case view
• Examples of plain-language detection objectives for contractor access, bulk exports, and out-of-assignment activity
• The response logic for routing cases to revocation, containment, or business-owner decisioning
• What the system surfaces about identity history, business purpose, and recommended next action

👉 Offroad AI's full post covers the context model, investigation flow, and response logic behind legitimate-access abuse

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 identity security programme, it is worth exploring.