Asset Criticality Engine

Automatically classify every identity in your environment by risk level — from standard users to Tier 0 assets — and surface hidden privileged accounts that inherit administrative access through group membership.

Requires role: Operator (viewing rules and criticality) / Admin (setting manual overrides and managing rules) Related: Risk Posture Dashboard | Stale Identity Detection | Over-Permission Analytics

---

Overview

The Asset Criticality Engine continuously evaluates every identity in your graph and assigns it one of four security criticality levels: Low, Medium, High, or Critical. This classification happens automatically after every sync, so your criticality data stays current as your environment changes.

Two problems drive this feature. First, manually tagging thousands of identities is error-prone and drifts out of date the moment group memberships change. Second, attackers frequently exploit accounts that appear ordinary on the surface but have gained administrative access through a chain of nested group memberships — sometimes called "shadow admins." The criticality engine detects both obvious Tier 0 assets (Domain Admins, Enterprise Admins, Domain Controllers) and those hidden privileged accounts by following group membership paths up to ten hops deep.

Criticality data feeds into every risk analysis feature on the platform:

• The Risk Posture Dashboard uses criticality to weight its composite risk score and flag Tier 0 hygiene issues
• Stale Identity Detection sorts dormant accounts by criticality so you remediate the most dangerous ones first
• Critical Junction analysis uses criticality tiers to identify which accounts bridge low-privilege and high-privilege zones

---

Prerequisites

• Role: Operator or higher to view rules and criticality levels; Admin to create or delete custom rules and set manual overrides
• Data: At least one successful identity sync from an LDAP/Active Directory bridge or Entra ID provider
• Worker: The background worker runs automatically in standard deployments — it runs evaluation after each sync and on a configurable schedule

The worker runs automatically in standard deployments. If criticality levels appear missing or stale, check that the worker process is running. See the Troubleshooting section.

---

How Criticality Levels Work

Every identity in the graph receives one of four criticality levels:

Level	Color in Graph	Meaning
CRITICAL	Red	Tier 0 assets: highest-privilege groups, domain controllers, PKI infrastructure, and specific Entra ID roles that can take over a tenant
HIGH	Orange	Privileged operators, sensitive assets, and accounts that have inherited administrative access through group membership (Shadow Tier 0)
MEDIUM	Yellow	Standard production infrastructure or business-data assets
LOW	Default	Standard users and regular assets with no elevated privilege

What is Tier 0?

"Tier 0" is a designation for assets that have direct control over your identity infrastructure. If an attacker compromises a Tier 0 account, they typically gain the ability to control your entire domain or cloud tenant. The criticality engine automatically classifies Tier 0 assets as CRITICAL — no manual tagging required.

What is a Shadow Tier 0 account?

A Shadow Tier 0 account is one that has effective administrative access but isn't obviously named or labeled as privileged. For example:

• A contractor account that someone added to the "Backup Operators" group (itself a Tier 0 group)
• A service account that is a member of a custom group, which is a member of Domain Admins
• An account that inherited administrative access through five levels of nested group membership

The engine traces group membership chains up to ten hops and marks these accounts as HIGH criticality with a "Shadow Tier 0" label. They appear in the graph with that badge so you can investigate the membership path.

---

Built-In Classification Rules

The engine ships with 46 built-in rules that cover Active Directory and Entra ID environments. These rules are seeded automatically and cannot be deleted (though individual rules can be disabled).

Active Directory: Tier 0 Groups (17 rules)

The following Active Directory groups are classified as CRITICAL. Classification is based on the group's well-known identifier (RID), so it works correctly regardless of the group's display name or domain.

Group	Identifier
Domain Admins	RID 512
Domain Controllers	RID 516
Cert Publishers	RID 517
Schema Admins	RID 518
Enterprise Admins	RID 519
Group Policy Creator Owners	RID 520
Read-only Domain Controllers	RID 521
Cloneable Controllers	RID 522
Administrators (built-in)	RID 544
Power Users	RID 547
Account Operators	RID 548
Server Operators	RID 549
Print Operators	RID 550
Backup Operators	RID 551
Replicators	RID 552
Distributed COM Users	RID 562
Cryptographic Operators	RID 569

Entra ID: Tier 0 Roles (9 rules)

The following Entra ID roles are classified as CRITICAL:

• Global Administrator
• Application Administrator
• Cloud Application Administrator
• Conditional Access Administrator
• Hybrid Identity Administrator
• Partner Tier2 Support
• Privileged Authentication Administrator
• Privileged Role Administrator
• Security Administrator

Entra ID: High Privilege Roles (20 rules)

An additional 20 Entra ID roles that Microsoft designates as privileged (but below the Tier 0 threshold) are classified as HIGH. These include User Administrator, Intune Administrator, Helpdesk Administrator, Password Administrator, Security Reader, Security Operator, Global Reader, Cloud Device Administrator, Authentication Administrator, Directory Writers, and others.

Shadow Tier 0 Propagation Rule

A single built-in rule called "Shadow Tier 0 Propagation" traverses group membership chains from every CRITICAL asset. Any account that is a direct or nested member of a CRITICAL group (up to 10 hops) is classified as HIGH and labeled "Shadow Tier 0."

The engine handles large environments safely: it skips traversal into "Domain Users" (the group that every domain user belongs to) and "Domain Computers" to prevent runaway classification that would tag millions of accounts.

---

Viewing Criticality in the Graph

After the worker has completed at least one evaluation cycle, criticality levels appear throughout the platform:

1. Navigate to Graph Explorer from the left menu
2. Nodes are color-coded by criticality level (red = CRITICAL, orange = HIGH, yellow = MEDIUM, default = LOW)
3. Click any node to open its detail panel — the criticality level and tier assignment are shown in the Properties section
4. Shadow Tier 0 accounts display a "Shadow Tier 0" badge in the detail panel

---

Managing Criticality Rules

Navigate to Admin > Criticality Rules in the sidebar to view all classification rules. The page shows summary cards for total, system, and custom rule counts, followed by a tabbed view.

The System Rules tab lists all built-in rules. System rules are marked with a lock icon and cannot be deleted.

The Custom Rules tab lists rules you have created. Admin users see a Create Rule button and delete controls for each custom rule.

Each rule displays its name, match type (SID Match, ID Match, Name Regex, or Graph Traversal), target criticality level, enabled status, and description. Click any column header to sort the table.

Creating a Custom Rule

Requires role: Admin

You can create custom rules to classify environment-specific assets. Navigate to the Custom Rules tab and click Create Rule to open the rule creation dialog.

Three rule types are available for custom rules:

Rule Type	Matches By	Example Use Case
NAME_REGEX	Regular expression on the account's display name	Flag all accounts starting with svc-prod- as HIGH
ID_MATCH	An exact GUID or source identifier	Classify a specific application service principal
SID_MATCH	A Windows SID's relative identifier	Classify accounts in a custom built-in group

Name Pattern Rules

Name patterns are matched case-insensitively against the account's display name. Use standard regular expression syntax:

Pattern	Matches
^db-prod-.*	Any name starting with db-prod-
.*-svc$	Any name ending with -svc
`(admin	root
^CEO.*	Names starting with "CEO"

Invalid regex patterns are rejected at creation time with an error — they will not crash the engine.

After creating a rule, it takes effect on the next evaluation cycle (within 60 seconds by default).

---

Manual Overrides

Requires role: Admin

Manual overrides let you set the criticality level for a specific asset directly, bypassing the automatic rule evaluation. This is useful for:

• Temporarily elevating a service account that is undergoing a sensitive operation (e.g., a migration that temporarily holds broad permissions)
• Downgrading a test account that accidentally matched a name pattern rule
• Marking an executive device as CRITICAL to ensure it receives heightened scrutiny

An override always takes priority over every rule, including built-in system rules. The override remains active until it expires (if you set an expiration date) or until you delete it manually.

Override Expiration

If you set an expiresAt timestamp, the override is automatically removed at the start of the next evaluation cycle after the expiration time passes. You do not need to delete it manually. This is useful for time-bounded exceptions — for example, elevating an account's criticality during an incident investigation and having it automatically revert afterward.

---

How Evaluation Works

Understanding the evaluation cycle helps you predict when changes will take effect and interpret the results you see in the graph.

Evaluation Cycle

The background worker runs a full evaluation on a 60-second ticker (configurable) or immediately after a sync trigger. Each cycle:

1. Reset: All assets are reset to LOW criticality (unless they have an active manual override)
2. Apply rules: Rules are applied in ascending order — Medium rules run first, then High, then Critical. This ensures that a CRITICAL rule always wins over a High rule on the same account
3. Propagate: The engine traverses group membership chains from every CRITICAL asset, marking nested members as HIGH (Shadow Tier 0)
4. Cleanup: Expired manual overrides are removed automatically at the start of each cycle

The result is that the most specific, highest-severity rule always determines an account's final criticality level.

Domain Scoping

When a sync completes for a specific domain, the evaluation runs scoped to that domain. Active Directory rules (RID-based) are applied only to AD domains. Entra ID rules (role-based) are applied only to Entra ID tenants. Rules for one environment type are automatically skipped when evaluating the other, preventing cross-contamination.

---

How Criticality Feeds Into Other Features

Risk Posture Dashboard

The Risk Posture Dashboard uses criticality data in two ways:

• Tier 0 Exposure Score: Counts how many Tier 0 (CRITICAL) assets have stale or over-permissioned findings. A single stale Domain Admin produces a high Tier 0 score because the metric is percentage-based within that tier.
• Top Findings: CRITICAL and HIGH findings are surfaced in the top-5 table, with Tier 0 findings always appearing first regardless of count.

Stale Identity Detection

Stale identity analysis sorts its findings by criticality. An account flagged as CRITICAL that has not been seen for 90 days appears at the very top of the stale identities list as an "Urgent" priority finding. This integration ensures you spend remediation time on the dormant accounts that pose the most risk.

Critical Junction Analysis

The junction analysis uses criticality tiers to identify which accounts connect low-privilege and high-privilege zones. Only accounts with Tier 0 (CRITICAL) assignments contribute to the "high-privilege zone" definition — so accurate criticality classification directly determines whether the junction analysis finds real attack paths.

---

Troubleshooting

Criticality levels are missing or all show as LOW

Most likely cause: The background worker has not completed its first evaluation cycle.

Steps to resolve:

1. Check that the worker process is running (docker ps or check your process list for the worker container)
2. Review worker logs for messages like "starting criticality evaluation" and "completed rule application"
3. Wait up to 60 seconds, then refresh the graph view

A known Domain Admin account is not showing as CRITICAL

Possible causes:

• The account's domain has not been synced yet — navigate to Bridges in the sidebar and confirm a sync has completed for that domain
• The account is not a direct member of the Domain Admins group (it may be a primary group member — check the primaryGroupID attribute in the account's properties in the graph)
• A manual override exists that is setting a different level

Attempting to delete a system rule returns an error

This is expected behavior. Built-in rules cannot be deleted. They protect the baseline Tier 0 classification for your environment. If you need to exclude a specific group from CRITICAL classification, set a manual override on the individual account instead.

A Shadow Tier 0 account appears but the membership path seems wrong

The Shadow Tier 0 label is applied based on group membership edges in the graph. If a membership path looks incorrect:

1. Focus on the account in the Graph Explorer and review its group memberships
2. Check if the account has a primaryGroupID attribute — primary group membership is handled separately from explicit MemberOf edges and is applied via the account's primaryGroupID field
3. Verify that your bridge configuration is syncing group membership edges correctly — navigate to the Bridge detail page Sync History section and check for errors

An override I set is not reflected in the graph

Overrides take effect on the next evaluation cycle. After setting an override, wait up to 60 seconds for the worker to run its next cycle. If the graph still shows the old level after two minutes, check the worker logs for errors.

---

Best Practices

1. Review Shadow Tier 0 accounts immediately after first sync — These accounts hold Tier 0-equivalent access that may be unknown to your security team. Click through them in the graph to understand the membership paths.

2. Keep custom rules narrow — A name-pattern rule like .*admin.* will match far more accounts than intended. Use anchored patterns (^prod-admin-.*) and test them on your data before relying on them for risk scoring.

3. Use expiring overrides for temporary exceptions — When you need to override criticality for an incident or migration, set an expiresAt timestamp so the override cleans itself up automatically rather than lingering indefinitely.

4. Audit your overrides periodically — Review all active overrides regularly. Any override without an expiration should have a documented justification.

5. Pair criticality with stale identity analysis — A CRITICAL account that has not been used in 90 days is the highest-priority finding in the platform. Run both analyses together regularly.

6. Do not rely solely on display names for Tier 0 detection — The built-in AD rules match by well-known group identifiers (RIDs), not by name. An attacker who renames "Domain Admins" to something innocuous cannot evade these rules. Your custom rules should use ID_MATCH or SID_MATCH wherever possible rather than NAME_REGEX for Tier 0-equivalent groups.