Incident Response
Cross-app
SOC Analyst

Reconstruct the access change timeline for any incident in seconds, without log archaeology

Quick summary: Manually piecing together a timeline of identity modifications during a breach requires teams to parse mismatched timestamps and siloed logs across dozens of separate tools. Connecting Oleria Trustfusion, an AI-native identity security platform, solves this friction point by instantly building a cross-system access change timeline—correlating hidden privilege escalations, unmapped accounts, and disabled MFA methods into a single, queryable forensic record.

Outcome

Security investigators gain a complete, cross-system timeline of every access change affecting an implicated identity in any investigation period — new roles granted, group memberships added, authentication methods changed, local accounts created, permission escalations made — surfaced as a structured, correlated record without querying individual audit logs in each platform. What currently takes one to three hours of cross-system log reconstruction takes seconds from Trustfusion.

Understanding what changed before an incident is how investigators determine whether the compromise involved credential theft, privilege escalation, insider action, or supply chain access. The access change timeline is the evidence layer beneath the behavioral signals — and Trustfusion makes it available at investigation speed, not reconstruction speed.

Why the timeline matters:  A user account with a self-granted Snowflake privilege escalation three weeks before an incident, a local AWS IAM user created outside the IDP two weeks before, and an MFA method removed one week before — each of these changes is individually unremarkable in its own system's audit log. Correlated across systems on a single timeline, they are a pattern that changes the entire investigation hypothesis.

Why this is hard without Oleria

Access change history is the most fragmented data category in enterprise identity. Every system records its own changes in its own log format, with its own retention window, queryable only through its own interface. Cross-system correlation does not exist natively.

·     Each system's change log is siloed and differently structured.  Okta's system log, Entra ID's audit log, Salesforce's setup audit trail, GitHub's organization audit log, and Snowflake's access history each use different schemas, different timestamp formats, and different actor identification methods. Correlating them into a single timeline requires a custom ETL process that most security teams do not have.

·     Log retention windows vary and are often short.  Entra ID's audit log retains 30 days for free tenants and 90 days for premium. Okta's system log varies by plan. Salesforce's setup audit trail defaults to 180 days. GitHub's org audit log is 180 days. When an incident has a long dwell time — weeks to months — the relevant changes may have already aged out of native logs in some systems while still present in others.

·     Actor identification does not match across systems.  The user who made a change appears as a display name in one system, a UPN in another, a user object ID in a third, and a username with no domain in a fourth. Correlating "who made this change" across systems without a pre-built identity correlation layer requires manual lookup for each record.

·     Out-of-workflow changes have no corresponding ticket.  The most investigation-relevant changes — a self-granted privilege escalation, a local account created outside the IDP, an MFA method silently removed — are precisely the changes that do not have a corresponding ITSM ticket. They appear only in system audit logs, which investigators must know to query and know how to read.

What Oleria delivers

The Access Graph ingests and timestamps every access change across every connected system — continuously, not reactively. When an investigation begins, the cross-system change timeline is a query, not a reconstruction project.

Cross-system access change history in a single query.

For any identity, Trustfusion returns every access change across all connected systems in any specified time window — role grants, group membership modifications, account creations, authentication method changes, permission modifications — correlated to the same canonical identity record regardless of how the actor is identified in each source system's log.

Pre-incident state reconstruction at exact timestamp.

he Access Graph stores access states with validity timestamps. Investigators can query the graph as of the exact date and time of the incident — returning what access the identity held at the moment of compromise, not the current state after containment actions have modified it. This historical precision is critical for accurate blast radius assessment and regulatory breach reporting.

Out-of-workflow change flagging.

Access changes that occurred outside a formal provisioning workflow — no corresponding ITSM ticket, no HR event trigger, provisioning method inconsistent with standard patterns — are flagged in the change timeline. Self-granted privilege escalations, manually created local accounts, and unexplained group membership additions are surfaced as anomalous change events within the investigation context.

Cross-identity change pattern detection.

Investigators can expand the timeline query to other identities — finding all accounts that received similar access grants in the same period, or all accounts that had MFA methods removed in the weeks before the incident. This cross-identity view surfaces patterns that single-identity investigation misses.

Continuous retention independent of source system log windows.

Trustfusion retains the access change record for a configurable period aligned with compliance and investigation requirements — independently of the retention windows in individual source systems. Changes that have aged out of a native audit log remain queryable in Trustfusion within the configured retention window.

Outcomes at a glance

Seconds
Timeline construction
All apps
Connected systems in scope
Exact time
Pre-incident state query

How it works

Stage 1. Continuous Event Ingestion:  Oleria connectors pull access change events from every connected system continuously — role modifications, group membership changes, account creations, authentication method updates, and permission grants — timestamped as they occur. No reactive log export is required when an incident is declared; the change history is already assembled.

Stage 2. Identity Graph Correlation:  The investigator specifies the implicated identity and the investigation time window — "show me all access changes for this identity in the 60 days before November 14." Trustfusion queries the Access Graph's timestamped change record, correlates changes across all connected systems to the canonical identity, and returns a structured timeline.

Stage 3. Timeline & Pathway Analysis:   The timeline shows each change with: date and time, the system where it occurred, the nature of the change (role granted, group added, account created, MFA method removed), the provisioning method (IDP workflow, direct admin action, self-service, no ticket found), and whether the change is flagged as anomalous relative to normal provisioning patterns for that identity and system.

Stage 4. Evidence Export & Remediation:  From the investigation timeline: open the source record for any change event, compare to ITSM ticket data, export the timeline as structured evidence for regulatory reporting, or use the pre-incident access state as the basis for a containment scope that reverts to the last-known-good entitlement profile.

What good looks like

▸  Cross-system change timeline construction:  Manual reconstruction from individual audit logs (1–3 hours, incomplete, misses out-of-IDP-scope changes) → single query returning correlated cross-system timeline for any identity and any investigation period in seconds.

▸  Pre-incident access state:  Reconstructed approximately from provisioning records and tickets (often incomplete) → queried directly from the Access Graph as of the exact incident timestamp, including the current state of every entitlement at that moment.

▸  Out-of-workflow change detection:  Found by chance in individual system logs or not found at all → surfaced automatically as anomalous change events in the timeline, with the provisioning context that explains why they are flagged.

▸  Investigation dwell time coverage:  Limited by shortest retention window across source systems → covered by Trustfusion's configurable retention period, independent of individual system log windows.

Is an out-of-workflow tenant adjustment silently hiding inside your audit trails?

When an attacker quietly grants themselves privileges weeks before striking, finding that single entry across disconnected application logs becomes nearly impossible under active breach pressure. Benchmark your detection capabilities before the next alert fires—take our Identity Security Assessment to evaluate your current architectures, reduce your identity incident response blast radius, and map your maturity journey leveraging our industry-backed maturity model.

Take our Identity Security Assessment

Frequently Asked Questions

How far back does Oleria's access change history go?

Access state history and change records are retained for a configurable period aligned with the organization's investigation and compliance requirements. Standard retention is designed to cover typical threat dwell times — the weeks to months between initial compromise and detection. This retention is independent of source system log windows, so changes that have aged out of a native IDP or SaaS audit log remain queryable in Trustfusion within the configured retention window.

How is Oleria's access change history different from querying the Entra ID or Okta audit log?

IDP audit logs record changes within the IDP only — they do not capture changes made directly in SaaS applications, cloud IAM, or out-of-IDP-scope accounts. Trustfusion captures changes across all connected systems and correlates them to a single identity record. It also flags out-of-workflow changes that would appear as unremarkable entries in individual system logs but are anomalous when seen in cross-system context.

Can Oleria detect when a privilege was self-granted or granted without a ticket?

Yes. Trustfusion records the provisioning method for each access change — whether it was made through an IDP provisioning workflow, a direct admin action, a self-service request, or with no corresponding ITSM ticket. Changes with no ticket correlation in high-privilege roles or sensitive applications are flagged as anomalous in the investigation timeline and surfaced as findings for investigator review.

How does Oleria reconstruct access state at a specific point in time?

The Access Graph stores every access state with validity timestamps — when each entitlement became active and, when applicable, when it was superseded. A point-in-time query specifies a timestamp and Trustfusion returns the graph state as it existed at that moment — every entitlement that was active, for every identity, as of that exact date and time. No reconstruction from log events is required; the historical state is stored directly.

Can we query the change timeline for multiple identities simultaneously?

Yes. Trustfusion supports cross-identity queries that are essential for scope expansion during investigations. From a primary implicated identity, investigators can query all other accounts that received similar access grants in the same period, all accounts that had MFA methods removed in the investigation window, or all accounts that share the same group memberships as the compromised identity. This surfaces lateral movement patterns and potential co-compromised accounts.

Related articles
This is some text inside of a div block.

Reconstruct the Access Change Timeline for Any Incident — Without Log Archaeology

Read more