Skip to main content
Applies to BloodHound Enterprise only Privilege Zones help organizations expand Identity Attack Path Management beyond the default Tier Zero view. Tier Zero is the natural starting point because it contains the identities, systems, and permissions that can control the broader environment. Once a team begins reducing paths to Tier Zero, the next question is usually straightforward: what should we protect next? That answer varies by organization. For one customer, the next priority may be Tier One administrative systems. For another, it may be a clinical application, a payment environment, a production deployment repository, an endpoint management platform, or a business-unit-owned infrastructure boundary. Privilege Zones give teams a way to define those priorities and analyze attack paths into them. A zone can represent:
  • A traditional administrative tier
  • A critical application
  • A regulated environment
  • A business unit
  • A platform team
  • A source code boundary
  • An endpoint management boundary
  • A technology control plane
Some zones become durable parts of an organization’s operating model. Others support a specific campaign, audit response, or focused investigation. Teams do not need a perfect model before starting. Many organizations begin with known groups, object IDs, OUs, naming conventions, asset metadata, or simple Cypher queries. They use the results to validate assumptions, find unexpected control paths, and refine the zone over time.
Treat Privilege Zones as living documents. Revisit and refine them as your environment changes, ownership becomes clearer, and your Attack Path Management program matures.

​
When to use this approach

  • Your organization has started reducing Tier Zero attack paths
  • Your team wants to expand Attack Path Management to additional critical systems
  • You need to organize remediation around business priorities, ownership boundaries, or regulatory scope
  • You want a repeatable model for deciding what to protect next
  • You are adding OpenGraph-connected technologies and need to define which assets deserve focused analysis

​
Example progression

  1. Start with Tier Zero and reduce the highest-impact attack paths.
  2. Define a Tier One zone around administrative systems or critical infrastructure.
  3. Define a zone around a specific business-critical application or regulated system.
  4. Use labels or zones to map ownership across business units or platform teams.
  5. Add OpenGraph-connected technologies, such as GitHub, Jamf, Okta, or cloud platforms.
  6. Use zones to understand inherited risk across identity systems, endpoint management platforms, source code systems, and cloud environments.

​
Practical starting questions

  • What system would create the most business impact if compromised?
  • What systems are subject to regulatory, audit, or compliance scrutiny?
  • What administrative boundary do we need to validate after Tier Zero?
  • Which application owners need visibility into inherited identity risk?
  • Which business unit or platform team owns remediation?
  • Which source code repositories, workflows, or endpoint management systems can influence production?
  • What existing structure can help us build a first version of the zone?

​
Starter Cypher queries

These example Cypher queries help you identify candidate objects for zones and labels during discovery, trials, and early implementation.
Review and tune these queries before using them as production Privilege Zone rules.

​
Broad discovery by naming pattern

​
Key takeaway

Privilege Zones give teams a repeatable way to decide what to protect after Tier Zero and to keep expanding Attack Path Management as the environment matures.