Stale Identity Detection

Identify dormant accounts that exceed configured inactivity thresholds, prioritized by criticality and security tier.

Requires role: Operator or higher Related: Risk Posture Dashboard, Over-Permission Analytics, Asset Criticality, Attribute Sync Configuration

Overview

Enterprise environments accumulate stale accounts over time. Employees leave, service accounts for decommissioned applications remain active, and test machines stay joined to the domain long after their hardware is recycled. These dormant identities represent a security risk: an attacker who compromises a stale account inherits all of its standing permissions while evading detection since no legitimate user is monitoring the account for suspicious activity.

The Stale Identity Detection feature identifies and surfaces identities that have exceeded their inactivity threshold, ranked by criticality so that dormant Tier 0 accounts (Domain Admins, Enterprise Admins) are prioritized over low-privilege stale accounts. Unlike generic "last login" reports, this analysis integrates with GraphnAI's Asset Criticality Engine to ensure high-risk stale accounts appear at the top of your remediation queue.

Prerequisites

• Role: Operator or Admin
• Data sync: At least one bridge must have completed a full sync so that identity nodes exist in the graph
• Criticality evaluation: The background worker should have evaluated asset criticality at least once (this happens automatically after each sync)

Accessing the Stale Identities View

1. Log in to GraphnAI Platform with an Operator or Admin account
2. Navigate to Analysis > Stale Identities from the left navigation menu
3. The table loads automatically with default thresholds applied

Understanding the Results

Summary Cards

At the top of the view, four summary cards provide an at-a-glance overview of your stale identity posture:

Card	Description
Total Stale	The total number of identities exceeding their staleness threshold across all types
Urgent (Tier 0)	Count of stale identities classified as Tier 0 assets (Domain Admins, Enterprise Admins, critical service principals) — these require immediate attention
By Type	Breakdown showing how many stale identities exist per type (User, Computer, ServiceAccount, etc.)
By Criticality	Breakdown showing how many stale identities fall into each criticality level (CRITICAL, HIGH, MEDIUM, LOW)

Findings Table

The table displays individual stale identities with the following columns:

• Display Name: The account's friendly name (e.g., john.doe, SRV-DC01)
• Type: The identity type (User, Computer, ServiceAccount, ServicePrincipal, Device, Group, Role, Application)
• Criticality: The computed criticality level from the Asset Criticality Engine, color-coded:
  • CRITICAL (red): Tier 0 assets, critical junction nodes
  • HIGH (orange): High-value assets with broad access
  • MEDIUM (yellow): Standard production assets
  • LOW (gray): Non-production or minimal-access identities
• Last Seen: Relative time since the identity was last observed (e.g., "93 days ago") — hover for the exact date
• Stale Days: The exact number of days since the identity's LastSeen timestamp
• Priority: Visual indicator showing "Urgent" (red) for Tier 0 or CRITICAL identities, or "Normal" for all others
• Domain: The source domain or tenant for the identity

Urgent Priority Flags

Rows marked with Urgent priority have a red left border and an alert icon. These represent:

• Tier 0 assets (Domain Admins, Enterprise Admins, etc.)
• CRITICAL criticality assets flagged by the Asset Criticality Engine

These stale identities should be reviewed and remediated immediately, as their compromise could grant an attacker administrative control over your environment.

Filtering and Sorting Results

Type Filter

Use the Type dropdown to show only stale identities of a specific kind:

• All Types (default): Shows all stale identities
• User: Employee accounts, service accounts managed as users
• Computer: Domain-joined workstations and servers
• ServiceAccount: Dedicated service accounts
• ServicePrincipal: Cloud service principals (Azure AD apps, managed identities)
• Device: Mobile devices, IoT devices
• Group: Distribution groups, security groups
• Role: Azure AD roles, application roles

Min Criticality Filter

Use the Min Criticality dropdown to set a minimum criticality threshold:

• All (default): Shows stale identities at any criticality level
• LOW: Excludes nothing (all levels shown)
• MEDIUM: Excludes LOW criticality identities
• HIGH: Shows only HIGH and CRITICAL
• CRITICAL: Shows only CRITICAL identities

Sort Order

Use the Sort By dropdown to change the result ranking:

Sort Option	Behavior
Criticality (default)	Highest criticality first, then by staleness within each criticality level
Staleness	Longest-inactive identities first, then by criticality as a tiebreaker
Type	Alphabetical by type, then by criticality and staleness

The default Criticality sort ensures that dormant Tier 0 accounts and critical junctions are always at the top of the list.

Staleness Thresholds

GraphnAI uses different staleness thresholds for different identity types, reflecting their expected activity patterns:

Identity Type	Default Threshold	Rationale
User	90 days	Employees typically authenticate at least quarterly; longer absences suggest departure or disability
Computer	30 days	Workstations and servers authenticate daily; a month of inactivity indicates decommissioning or permanent offline status
ServiceAccount	180 days	Service accounts may legitimately remain idle for extended periods (e.g., quarterly batch jobs)
ServicePrincipal	180 days	Cloud service principals often have infrequent authentication patterns
Device	30 days	Mobile devices and IoT endpoints authenticate regularly when active
All Others	90 days	Groups, roles, and applications default to the standard 90-day threshold

Custom Threshold

To override these defaults for a specific analysis:

1. Enter a number of days (1-3650) in the Custom Threshold field
2. Click Apply or press Enter
3. The query re-executes with the custom threshold applied to all identity types for this session

To reset to default thresholds, clear the field and click Apply again.

TIP

Use custom thresholds during audits or investigations. For example, setting a 60-day threshold before a compliance review surfaces identities approaching the standard 90-day cutoff.

Interacting with Findings

Focusing on a Stale Identity

To inspect a stale identity in the graph:

1. Click on any row in the findings table
2. The system navigates to the Graph Explorer view with that identity focused
3. You can now see the identity's access neighborhood, outbound permissions, and inbound paths

This allows you to assess the blast radius of the stale account before deciding on remediation (e.g., "This stale service account still has WriteDacl on 15 critical servers").

Pagination

The table displays 50 findings per page by default. Use the pagination controls at the bottom to navigate:

• Chevron left: Previous page
• Chevron right: Next page
• Page indicator: Shows current page and total pages (e.g., "Page 2 of 8")

The Showing X-Y of Z label indicates which subset of total findings is currently visible.

Use Cases

Quarterly Stale Account Audit

1. Set Min Criticality to MEDIUM or higher to exclude test accounts and low-value assets
2. Sort by Criticality (default)
3. Work through the first page (50 findings), investigating each in the graph
4. For each stale account, decide whether to:
   • Disable the account (recommended first step)
   • Delete the account (after verification that no automated processes depend on it)
   • Ignore (if the account is legitimately idle, e.g., a once-per-year batch process)

Tier 0 Hygiene Check

1. Look at the Urgent (Tier 0) summary card — this should ideally be 0
2. If it's non-zero, review those accounts immediately by focusing on them in the graph
3. Stale Tier 0 accounts are the highest-priority finding in the entire platform, as they represent dormant administrative access

Pre-Audit Preparation

1. Set a Custom Threshold to 60 days (tighter than the default 90-day standard)
2. Export the findings (manual export via browser table selection for now)
3. Share the list with department heads to confirm which accounts can be deprovisioned

Service Account Cleanup

1. Set Type filter to ServiceAccount
2. Set Custom Threshold to 365 days (1 year)
3. Review the findings to identify service accounts for decommissioned applications
4. For each stale service account, check the graph to see if it still has active permissions on production resources

Troubleshooting

"No stale identities found" but I know stale accounts exist

Possible causes:

• Recent sync: If a full sync just completed, all identity LastSeen timestamps were updated to "now"
• Threshold too high: The default thresholds may be too generous for your environment. Try a custom threshold (e.g., 30 days)
• Criticality filter: Check if you have a Min Criticality filter active that's excluding findings
• Type filter: Ensure you haven't narrowed the Type filter to a category with no stale identities

Solution: Reset all filters (set Type to "All Types", Min Criticality to "All", clear Custom Threshold) and check again.

Urgent count is very high (e.g., 50+ Tier 0 stale accounts)

Possible causes:

• Incomplete criticality evaluation: The background worker may not have completed its first criticality evaluation pass yet
• Criticality rule misconfiguration: A custom criticality rule may be flagging too many accounts as Tier 0

Solution:

1. Check the worker logs to confirm it has completed at least one evaluation cycle
2. Review your criticality rules at Admin > Criticality in the sidebar to ensure Tier 0 classification is accurate
3. If the Tier 0 accounts are legitimately stale, this represents a critical security finding and should be escalated immediately

Stale identity appears in results but isn't actually stale

Possible causes:

• Sync timing: The identity may have authenticated recently but the bridge has not yet performed a delta sync to update its LastSeen timestamp
• Bridge configuration: The bridge may be performing full syncs only (no delta syncs), so LastSeen timestamps update only once per day

Solution:

1. Check the Last Seen column in the table — it shows the exact date/time the identity was last observed
2. Navigate to the Bridge detail page Sync History section to see when the last delta sync occurred
3. Trigger a manual delta sync if needed: Trigger Sync > Delta Sync

Access denied (403 Forbidden)

Cause: Your user account does not have the Operator role or higher.

Solution: Contact an Admin to grant you Operator or Admin role via Admin > User Management in the sidebar.

Best Practices

1. Run stale identity audits quarterly as part of your access review cycle
2. Prioritize Tier 0 stale accounts — these should never exist in a healthy environment
3. Use group-based thresholds — Apply custom thresholds when auditing specific identity types (e.g., 14 days for Computers during a hardware refresh)
4. Verify before deletion — Always focus on a stale identity in the graph to review its access paths before disabling or deleting it
5. Document exceptions — If a service account is legitimately idle (e.g., annual batch jobs), document this in your identity management system to avoid repeated flagging
6. Automate reporting — Generate periodic stale identity reports and send them to asset owners for review

Security Considerations

• Stale identities are attack vectors: An attacker who compromises a stale account inherits all of its permissions with minimal detection risk
• Tier 0 stale accounts are critical findings: A dormant Domain Admin account is as dangerous as an active one if compromised
• LastSeen accuracy depends on sync frequency: If bridges perform full syncs only once per day, LastSeen timestamps have a 24-hour resolution
• Deletion is permanent: Always disable accounts first and monitor for unintended breakage before deleting them

Related Documentation

• User Management & RBAC — Learn about Operator role permissions
• Entra ID Setup — Configure cloud identity synchronization