Identity attacks do not always begin with stolen passwords, failed authentication, or blocked access. Sometimes every individual action looks legitimate until the identity, device, activity, permissions, and business purpose are examined together.
Consider this scenario.
A third-party support analyst signs in with a legitimate account and downloads thousands of sensitive customer records to an unmanaged device.
Authentication succeeds. The account is active. The user has permission to access the application. No vulnerability is exploited, and no security control blocks the download.
Viewed separately, each system sees only part of the activity:
- The identity provider sees a successful login.
- The application sees an authenticated user accessing data available to the account.
- The network sees a connection to an approved service.
- The endpoint platform has no agent telemetry from the unmanaged device.
Nothing appears obviously malicious.
Then the broader context comes together.
The user works for an external vendor. Their assignment requires access to a small number of customer records not a bulk export. The device has never been approved by the organization. No migration, support case, legal request, project, or ticket explains why thousands of records needed to leave the application.
The business authorized the access.
It did not authorize this use of it.
That difference is where serious identity risk often hides.
Legitimate access can still lead to an illegitimate outcome
Security teams have traditionally looked for attacks that begin with a visible failure.
A stolen password. An MFA bypass. A vulnerability that provides access to a restricted system. A privilege escalation that grants an identity permissions it should never have received.
Those risks still matter. But identity attacks do not always begin with an obviously malicious action.
They can operate through legitimate identities, valid sessions, and previously approved permissions.
A compromised employee account can behave during normal working hours. A malicious OAuth application can use scopes that an administrator previously approved. A contractor can retain access after the business need has changed. An administrator can weaken a security control through a trusted session. An employee can misuse access that is legitimately required for their role.
In each case, the system may permit the individual action.
The security question is no longer only:
Was the action allowed?
It is also:
Was it expected, justified, and appropriate for this identity, using this device, against this resource, at this time, and for this business purpose?
Answering that question requires much more than an authentication log or application event.
One event can have several explanations
A large download of customer data is not automatically an attack.
It could be part of an approved migration, a legal request, an investigation, a customer support process, or another legitimate business activity.
The same action could also represent:
- A compromised account
- Insider misuse
- A vendor operating outside its assignment
- An unauthorized export
- Data theft in progress
Excessive permissions may have made the download possible, but they do not explain why it happened.
The event alone cannot tell the security team which explanation is correct.
The same problem appears across other types of identity activity.
A new administrator account could be part of legitimate onboarding—or an attacker establishing persistence.
A privileged policy change could be an approved emergency response—or an attempt to weaken security controls.
A service account accessing a new system could reflect a planned integration—or stolen credentials being used to expand access.
The action matters.
The surrounding identity context determines the risk.
Identity detection is now a context problem
The information needed to understand identity activity is usually distributed across the organization.
The identity provider records how the user authenticated.
The application’s audit logs may show what action was performed.
The endpoint platform may know whether a device is managed and healthy.
The identity governance system may explain why access was originally approved.
HR, procurement, or vendor management may know the person’s relationship with the organization.
The ticketing system may contain an approved project, support case, or change request.
The business owner understands what the identity is actually expected to do.
No single source tells the whole story.
To investigate the download properly, a security analyst needs to answer several connected questions:
Identity: Who is the user, and what is their relationship with the organization?
Access: Which permissions does the account hold, and why were they granted?
Device and session: Where did the activity originate, and is the device trusted?
Resource: What information was accessed, and how sensitive is it?
Behavior: Is this activity consistent with the identity’s role and previous activity?
Business purpose: Is there an approved assignment, ticket, project, or owner that explains the action?
Blast radius: What else can the identity access, export, change, or delete?
Connecting these signals is more than event correlation.
It requires understanding the relationships between identities, permissions, resources, activity, ownership, and business purpose.
That is the identity context Offroad agents build.
Offroad connects relevant information across identity providers, applications, devices, permissions, policies, tickets, ownership records, and activity.
Instead of stopping at:
Large download detected.
The investigation should explain:
- Who performed the action
- Which account, device, and session were involved
- What information was accessed
- Why the activity appears expected or unjustified
- Which evidence supports that conclusion
- What else the identity can access
- What the potential impact could be
- What should happen next
The objective is not to claim certainty about intent when the available evidence does not support it.
The objective is to determine whether the activity is expected, suspicious, policy-violating, or likely connected to account compromise—and make the reasoning clear.
Describe the risk, not every correlation rule
Most security teams already know the identity activity they care about.
Tell me when a contractor downloads sensitive information to an unmanaged device.
Watch for administrators exporting customer data without an approved project.
Alert me when a third-party identity accesses systems unrelated to its assignment.
An experienced analyst immediately understands these objectives.
Turning them into reliable detections across a changing environment is much harder.
A traditional rule requires the team to define every condition in advance:
- Which identities are contractors?
- Which devices are managed?
- Which applications and resources are in scope?
- Which data is considered sensitive?
- What volume is unusual?
- Which projects, tickets, or owners create valid exceptions?
- What should happen when some information is missing?
The rule must then remain accurate as employees change roles, vendors rotate, permissions drift, new systems are introduced, and business processes evolve.
Offroad allows security teams to describe the identity activity and risk they care about in plain language.
The agents translate that objective into the relevant identities, systems, context, and investigation steps. As relevant telemetry becomes available, they gather the available evidence, evaluate whether the behavior has a valid business explanation, and present the reasoning behind the conclusion.
The security team defines what it wants to protect.
The agents perform the investigation required to determine whether the activity represents legitimate work or meaningful risk.
Detection should lead directly to action
Finding suspicious activity is only the first step.
The system must also determine what should happen next.
When the evidence strongly indicates that a compromised contractor account is exporting sensitive data, the appropriate response may be to revoke the session, temporarily disable the account, restrict access, or contain the activity.
When the evidence remains incomplete, the right next step may be to request a decision from the employee or business owner responsible for the vendor relationship.
But that person should not receive a contextless alert that says:
Suspicious download detected.
They should receive the completed investigation:
- Who performed the action
- Which identity and session were involved
- What information was accessed
- Why the behavior appears unjustified
- Whether the device was trusted
- What other access the identity holds
- What the potential impact could be
- Which response is recommended
Depending on the evidence and the organization’s policies, Offroad can recommend the next step, involve the appropriate owner for approval, or drive the response through the connected system.
The goal is not to remove people from every decision.
It is to stop forcing them to reconstruct the entire story manually while the risk continues.
This is the model we are building at Offroad.
Identity attacks can hide behind legitimate accounts, valid sessions, and technically permitted actions.
Finding them requires understanding the full identity context—not just the event—and moving from that understanding to the right response.
The download was permitted.
The full story showed why it should never have happened.
