Crogl’s knowledge graph turns identity pivots into operational memory

At a glance

What this is: This is an analysis of how a knowledge graph can preserve cross-system identity relationships so investigators can move from one relevant system to the next without relying on tribal memory.

Why it matters: It matters because IAM, NHI, and security operations teams all depend on accurate identity correlation across disconnected systems, and weak pivots slow both human analysts and autonomous investigation workflows.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Crogl's analysis of knowledge graph pivots for security investigations

Context

Identity investigations often fail because the same entity appears under different field names across tools, not because the underlying event data is absent. A person may be a userPrincipalName in one system, a reporter.emailAddress in another, and an email address in a third, which makes pivoting a governance and correlation problem as much as an analysis problem.

That challenge grows as organisations split telemetry across SIEM, ticketing, endpoint, identity, cloud, and custom systems. For security teams, the real issue is not whether a platform can store more data, but whether it can preserve trustworthy relationships across systems without forcing a full centralisation project first.

This is where identity correlation becomes operational memory. The question for practitioners is whether investigation tooling can retain the mapping logic humans currently remember, and whether that logic remains auditable as schemas, sources, and workflows change.

Key questions

Q: How should security teams reduce manual pivoting across identity and security tools?

A: They should standardise authoritative identity fields, document cross-system synonyms, and require investigation tooling to preserve the evidence behind each learned mapping. The goal is not to centralise everything, but to make the next query obvious, defensible, and repeatable across shifts and teams.

Q: Why does cross-system identity correlation fail in practice?

A: It usually fails because the same person or asset is represented differently in each platform, and teams rely on human memory to bridge the gaps. When schemas change or analysts rotate, the mapping disappears unless it has been captured as governed operational context.

Q: How do teams know whether a knowledge graph is actually improving investigations?

A: Look for shorter time to the next relevant source, fewer dead-end queries, and more consistent investigation paths across analysts. A useful graph makes pivots repeatable and auditable, not just visually connected.

Q: What is the difference between a search layer and an investigation graph?

A: A search layer helps you find records, while an investigation graph helps you understand which identity or system to query next and why. The graph becomes valuable when it preserves relationship evidence and supports the analyst's reasoning, not when it simply returns more results.

Technical breakdown

Cross-system identity resolution and field mapping

The core mechanism is identity resolution across heterogeneous schemas. A single person or asset may appear with different field names, casing, or identifiers in ticketing, identity, endpoint, cloud, and SIEM tools. A useful graph does not merely index those fields. It learns candidate correspondences, validates value overlap, and stores the relationship as reusable context for later investigation. That makes the graph closer to operational metadata than to a threat-intelligence feed.

Practical implication: teams should define which identity fields are authoritative in each system before they rely on automated pivots.

Evidence-backed relationship learning

A graph that learns relationships from live systems must separate plausible from meaningful. Shared values alone are not enough, because an email-like string, hash, or identifier can appear in unrelated records. The stronger approach is to require representative samples, semantic validation, and persisted evidence for each learned edge. That creates an auditable record of why one field maps to another and reduces the risk of invented correlations inside investigative workflows.

Practical implication: practitioners should demand evidence trails for learned mappings, not just graph visualisations.

Investigation workflow without full data centralisation

The architectural point is that cross-system investigation can work without moving every dataset into one repository. Some organisations prefer lake-first normalisation, while others preserve source context in native systems. A knowledge graph can sit above either model if connectors can query the source systems and retain enough evidence locally to support the learned relationships. The value is not replacing the SIEM or data lake, but reducing the cost of the next pivot.

Practical implication: security teams should treat the graph as an investigation layer, not a replacement for source-of-truth platforms.

NHI Mgmt Group analysis

Identity correlation is now a governance control, not just an analytics convenience. When analysts cannot reliably connect the same identity across identity providers, ticketing, endpoint, cloud, and security tools, they lose investigative continuity. That turns schema ownership, field mapping, and auditability into first-class identity controls. Practitioners should treat cross-system identity resolution as part of the identity programme, not as an informal SOC workaround.

Operational memory is the scarce asset this category is trying to preserve. The article reflects a common enterprise reality: only a few experienced analysts know where the next useful pivot lives, and that knowledge does not scale across shifts or teams. A persistent graph can reduce dependence on tribal memory, but only if the learned relationships remain explainable and removable. The implication is that identity context must be managed like any other governed security asset.

The named concept here is identity pivot persistence. This is the ability to retain the next useful investigative step across systems, shifts, and changing schemas. Without it, each new incident forces teams to rediscover the same cross-system relationships from scratch. Practitioners should recognise pivot persistence as a measurable capability of the investigation layer, not as an abstract AI feature.

Cross-system investigation should be judged by evidentiary trust, not by graph density. More nodes and edges do not automatically improve security outcomes if the relationships are unverified or stale. A graph is only useful when it keeps evidence attached to the learned relationship and preserves an audit trail as the environment changes. Identity teams should measure whether the investigation path is more defensible, not merely more connected.

From our research:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• Follow Ultimate Guide to NHIs , What are Non-Human Identities to ground identity mapping in a common model before expanding cross-system investigation.

What this signals

Identity pivot persistence: investigation tooling is moving toward preserving the exact cross-system step an analyst would normally memorise, and that changes how teams evaluate search, SIEM augmentation, and case management. If the pivot is not explainable and reusable, the workflow still depends on human tribal memory.

As identity estates span more systems, the cost of a missed pivot grows faster than the cost of another dashboard. Teams should expect vendors to compete less on raw discovery and more on whether they can maintain trustworthy relationships between identities, endpoints, tickets, and cloud principals.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, the broader lesson is that identity context is fragmented by design. That makes governed correlation a programme capability, not just a SOC convenience.

For practitioners

• Map authoritative identity fields before automating pivots Document which systems own user, account, device, and asset identifiers, then define the canonical field names and acceptable synonyms used across connectors. This reduces false pivots and helps analysts understand when a relationship is structural versus coincidental.
• Require evidence for every learned relationship Insist that any automated mapping between fields retains representative samples, validation logic, and an audit trail. If the relationship cannot be explained after the fact, it should not be allowed to drive investigations.
• Test the graph against live investigations, not clean demos Use real tickets, identity records, endpoint telemetry, and cloud events to see whether the system can move from one relevant source to the next without manual rediscovery. The goal is faster decision-making under realistic noise, not a polished visualisation.
• Keep source systems as the evidence anchor Use the graph to surface the next best query, but preserve the original telemetry in the system that generated it. That keeps the graph from becoming a brittle substitute for source-of-truth data and helps preserve governance boundaries.

Key takeaways

• The main problem is not missing data, but missing identity context across systems.
• Cross-system pivots become more valuable when they are evidence-backed, auditable, and reusable across analysts.
• Security teams should govern identity correlation as a core investigation control, not as an informal workaround.

Key terms

• Identity correlation: Identity correlation is the process of linking multiple account records to one governed subject. It lets IAM and IGA teams understand that separate usernames, principals, or emails may belong to the same employee or workload, which is essential for access review, offboarding, and entitlement analysis.
• Investigation Graph: An investigation graph is a governed relationship layer that helps analysts move from one relevant system or field to the next. It is not just a visual map, but a persistent record of trusted links, evidence, and context that supports repeatable security investigations across tools.
• Operational Memory: Operational memory is the retained state an AI system uses to shape later decisions, including prior actions, analyst feedback, and incident outcomes. In security workflows, it becomes a governance issue because remembered state can influence future authority, not just future output.
• Pivot Persistence: Pivot persistence is the ability to preserve the next useful investigative step even when schemas, sources, or analysts change. In practice, it means the workflow does not reset every time an incident crosses tool boundaries, because the relationship history remains available and auditable.

What's in the full article

Crogl's full blog covers the operational detail this post intentionally leaves for the source:

• How the connector-based learning cycle validates field relationships before they become reusable investigation context.
• How Crogl handles representative samples, evidence retention, and auditable relationship history in customer environments.
• How the graph behaves in lake-first, source-first, on-premises, private-cloud, and air-gapped deployments.
• How investigators can run a live investigation to see which pivots the graph surfaces in practice.

👉 Crogl's full blog explains how learned relationships, evidence retention, and investigation pivots work in practice.

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.