Modeling Okta in BloodHound Enterprise to uncover cross-platform identity risk

Introduction

Identity is no longer confined to a single system. In modern environments, identity spans multiple platforms: Active Directory, Okta, Entra, GitHub, and others; each operating within its own environment, with its own model for authentication and access. These systems are connected through federation, synchronization, and single sign-on. Each connection serves a legitimate purpose, enabling organizations to manage identity centrally while extending access across platforms.

But these connections also introduce something else.

They create relationships between systems that are seldom evaluated as a whole. These relationships are implicit, distributed across teams, and not well understood in aggregate. They don’t exist cleanly within any one platform; they emerge in the gaps between them. Those gaps are where attackers can operate with the least visibility, and where risk is least understood.

Why Okta Matters

Okta sits at the center of many modern identity architectures, but it is often misunderstood from a security perspective. It is typically treated as a control plane, an identity provider responsible for authentication and policy enforcement. And while that is true, it is only part of the picture. In reality, Okta functions as a translation layer for identity, taking identity from one environment and projecting it into another. Through federation, directory synchronization, and SSO, Okta connects upstream identity sources to downstream applications. It rarely creates identity; it propagates it. 

This introduces a form of nested dependency. The security of a downstream platform is no longer determined solely by its own configuration, but by the systems that supply and mediate its identity.

The security of a platform cannot be understood in isolation; it must be understood in the context of the platforms on which it depends.

In many environments, this creates situations where an identity that appears low-privileged in one system corresponds to a highly privileged identity in another. From an attacker’s perspective, the boundaries between platforms don’t matter; only how access accumulates across them. Privilege is not tied to a single environment; it is accumulated across them.

How These Paths Emerge

In practice, these relationships rarely present themselves as a single, obvious chain. They are distributed across platforms, environments, and teams, each with its own perspective on identity and access.

Consider a typical scenario. An organization uses Active Directory as an upstream identity source, federated into an Okta environment. That Okta environment is then used to provide single sign-on into a set of downstream applications. In some cases, those relationships extend further, to additional identity providers or even to other Okta environments through cross-tenant configurations.

From the perspective of any one platform, this architecture appears straightforward. Each system is performing its intended role: identities are managed, authentication is enforced, and access is granted according to defined policies. What is not immediately visible is how these relationships compose. And more importantly, how often they do.

A user may authenticate in one environment, be represented in another, and ultimately gain access in a third. The identity itself remains consistent, but its context and its level of control change as it moves between platforms. What appears as a normal user in one environment may correspond to a highly privileged identity in another.

These transitions are often difficult to reason about in isolation, because no single system contains the full picture. Instead, they exist across platform boundaries, where identity is translated, trust is extended, and access is ultimately realized.

Making This Concrete

To make this concept more tangible, consider a common pattern we observe across diverse enterprise environments, regardless of size or industry.

This security issue is not a single, catastrophic misconfiguration, but an emergent risk from accumulated organizational normalcy. It stems from a collection of seemingly rational, individually justifiable security, operational, or business decisions made over time by separate teams. When these “safe” decisions, such as relaxed permissions, exceptions, legacy dependencies, and network gaps, compound, they unintentionally create an expansive, hard-to-untangle attack surface that no single entity is responsible for.

At first glance, nothing about this looks unusual.

Cynthia, a DevOps engineer, requires broad access to multiple organizational repositories to manage core infrastructure, deploy IaC changes, configure CI/CD pipelines, and diagnose issues. This extensive access is normal and expected for her role, facilitating a holistic approach to infrastructure management. In GitHub, this access is granted via teams and roles and is considered standard operational procedure, raising no immediate red flags.

However, looking at GitHub alone doesn’t tell the full story. When we bring Okta into view, we see that Cynthia’s GitHub access is federated through Okta.

At this point, the focus shifts from what she can access to the dependencies of that access. However, looking only at Okta, a critical access and authentication layer, is insufficient. Okta rarely acts as the sole source of identity truth. To truly define an identity, like Cynthia’s, one must examine the upstream systems that feed data into Okta.

In most enterprises, Okta acts as a transit layer or service provider, not the primary source of identity. Core identity data (username, groups, employee ID, status) is synchronized or federated from authoritative upstream stores, typically Microsoft Active Directory (AD), Entra ID, or HR systems like Workday (the initial system of record). Therefore, an Okta identity, such as Cynthia’s, is a derivative representation that is automatically provisioned and updated based on the state of her upstream record.

This distinction is crucial, shifting security focus from the immediate Okta console to the underlying infrastructure. The vulnerability is no longer just what an Okta session can access, but what that access depends on. For instance, compromising an upstream Active Directory account will likely replicate changes to the Okta identity, granting an attacker control over all Okta-protected applications. This interdependence moves the security conversation from a siloed application view to a holistic infrastructure perspective.

The focus shifts again from simply listing Cynthia’s access permissions to proactively mapping the likely path an attacker would take to compromise her digital identity, moving from a static list to a dynamic, adversarial simulation.

In the enterprise, this translates to the attacker’s single high-priority objective: compromising her Active Directory (AD) account. Given AD’s pervasiveness, control of this account grants an authenticated foothold, a master key to her resources (email, file shares, applications), and enables lateral movement.

The security team’s critical inquiry is not if the account can be compromised, but how difficult the attack is. Realistically, the barrier to compromising an AD account is often low. Factors like weak passwords, lack of MFA on AD or high-value services, and phishing exposure all contribute to a low security threshold, making this account an easily obtainable, prime target.

Upon further inspection, Cynthia’s account faces a surprisingly high risk.

The Domain Users group has a path to Cynthia’s User account. This means any Active Directory compromise can extend to Cynthia’s account, not because she’s a target, but because the system’s design inherently provides a path for propagation.


Modern identity relationships (federation, directory sync, SSO) are rarely managed by a single team, a characteristic of enterprise IT. For instance, GitHub’s security is separate from the Active Directory or IAM administrator responsible for the core identity provider. Each team has specialized knowledge.
However, attackers treat this entire ecosystem as one target, ignoring administrative boundaries. They exploit the very connections (federation links, sync pipelines, SSO) IT teams use for efficiency. The most critical attack pathways for initial access and lateral movement often lie in the overlooked gaps between these disparate platforms, where control shifts between administrative domains.


The investigation reveals that Cynthia’s seemingly routine access now poses an alarming security risk. Her privileges are significant, extending to sensitive infrastructure and a critical SIEM API key, the compromise of which could effectively blind the security team. Crucially, this threat is not an isolated incident but a systemic vulnerability rooted in the organization’s interconnected identity and access management (IAM) architecture.

This web of upstream relationships and inherited permissions creates numerous attack paths, not just through Cynthia, but also through other identities. This complex access model, intended for efficiency, has become an emergent property of systematic risk, necessitating a fundamental re-evaluation of IAM policies across the entire digital infrastructure.

Nothing in this chain is inherently misconfigured: a DevOps engineer has broad repository access, GitHub integrates with Okta, and Okta integrates with Active Directory. Each decision makes sense in isolation, but identity risk doesn’t come from individual decisions—it comes from how those decisions compose. A path now exists from any compromised Active Directory user to sensitive GitHub infrastructure.

Modeling Okta in the Attack Graph

Understanding these relationships requires more than platform-level visibility. It requires modeling how identity, access, and control flow between systems. With Okta support in BloodHound Enterprise, these relationships can now be represented directly in the attack graph. Okta environments are modeled alongside other identity platforms to capture how identities are created, transformed, and used across systems.

This includes:

• Users and groups within Okta environments
• Applications and SSO relationships to downstream platforms
• Federation and synchronization with upstream identity sources
• Cross-tenant relationships, such as Org2Org configurations

These are not simply configuration details. They are the mechanisms through which control is established and propagated. Individually, these relationships describe configuration. When combined, they describe attack paths. Attack paths are not defined by any single relationship, but by how relationships compose. In many cases, the most important questions are not about access within a platform, but about how that access can be reached from somewhere else.

• How does control of an Active Directory identity propagate into Okta?
• How does control of Okta propagate into downstream applications?
• Where do these relationships create unintended paths to sensitive resources?

By modeling Okta alongside other platforms, these questions can be answered within a single system.

Conclusion

As identity systems evolve, the boundaries between platforms become less meaningful from a security perspective. The result is a growing class of exposure driven by nested security dependencies, in which the compromise of one system can propagate to many others. Attackers do not need to break every system. They only need to follow the path that already exists. In modern identity environments, the most important attack paths are not within platforms; they are between them.

Part of the new BloodHound Enterprise Launch

With OpenGraph extensions in the new BloodHound Enterprise, we are extending attack path analysis beyond traditional directories into the broader identity landscape that organizations actually depend on. Support for Okta highlights a critical shift in how identity risk must be understood. Okta is not just a control plane; it is a transit hub that translates identity between systems and propagates access across environments. By modeling these relationships directly in the graph, we expose how control in one system can manifest as privilege in another. This reveals real paths, real dependencies, and real objectives worth protecting. The systems that matter most to modern security teams do not live in isolation, and neither does identity risk. BloodHound must model how these systems compose.

Get started

The new BloodHound Enterprise platform is generally available and includes privilege zones, along with the three new OpenGraph extensions announced today: GitHub, Okta, and Jamf. The OpenGraph extensions, including Okta, are in early access. Click here to join our program. We would love to work with you to help implement it and understand how it helps in your specific environment.