Identity Intelligence

Identity Intelligence aggregates identity data across all monitored servers into unified profiles with cross-server risk scoring, behavioral baselines, and non-human identity inventory.

The pillar contains six pages accessible from the left sidebar: Identity Overview, Accounts, Groups, Non-Human Identities, SSH Keys, and Access Patterns. This page walks through each sub-section, explaining what it shows, how risk signals are surfaced, and how to interpret the data.

Identity Overview

The Identity Overview page (/identity) is the entry point to the Identity Intelligence pillar. It presents a fleet-wide view of all identities — human and service — aggregated across every monitored server.

Five metric cards appear at the top of the page, each clickable to cross-filter the identity table below:

• Total — all identities discovered across the fleet

• Human — accounts classified as human users

• Service — accounts classified as service accounts

• Dormant — accounts with no recent activity

• High Risk — accounts with a risk score of 60 or higher

Clicking a card filters the table to show only matching identities. Hold Ctrl or Cmd and click additional cards to build a multi-category selection.

The identity table is sorted by risk score in descending order by default, placing the highest-risk identities first. Each row represents a single identity aggregated across all servers where that identity appears — not a per-server row. The table supports search, paginates at 25 items per page, and offers CSV export.

Risk scoring is a cross-server composite. LinuxGuard evaluates each identity's profile — credential age, account type, access patterns, group memberships, and SSH key posture — across all servers simultaneously. A score of 60 or higher triggers the High Risk classification.

Use case: Identify your highest-risk human accounts fleet-wide, regardless of which servers they log into. A developer account with stale SSH keys, membership in a sensitive group, and recent sudo activity across five servers will surface near the top before a per-server review would flag anything.

Accounts

The Accounts page (/identity/accounts) provides a complete inventory of all accounts across the fleet in an identity-centric view. One row represents one identity, with data aggregated across all servers where that account exists — not one row per server instance.

Key columns include username, type (human or service), risk score, server count, last seen date, and status. The status column surfaces dormancy detection — accounts that have not authenticated recently appear as dormant. The table defaults to risk score descending, showing the most concerning accounts first.

Use this page to audit which accounts exist fleet-wide, verify whether expected accounts are present across the right servers, and spot accounts that have gone dormant but remain active.

Groups

The Groups page (/identity/groups) shows group memberships across the fleet with cross-server correlation. A group that exists on multiple servers appears as a single entry with a server count column rather than duplicated per-server rows.

This view is useful for identifying groups with unexpectedly broad server presence or unusual membership composition. A group appearing on 30 servers where you expected 5, or a group that has gained new members without an accompanying change ticket, becomes visible here.

Non-Human Identities

Non-Human Identities (NHI) are Linux user accounts that run automated processes rather than interactive human sessions. The agent collects cron jobs and systemd timers running on each server and associates them with the NHI account that executes them.

LinuxGuard classifies every non-human identity into one of three tiers based on origin and detection signals.

System Default accounts are created by the operating system or system packages during installation. LinuxGuard identifies them by matching the account name against a curated list of 40+ well-known OS accounts — root, daemon, www-data, systemd-network, sshd, ntp, and similar — or by UID 0, UID 65534 (the traditional nobody UID), or a home directory of /root. These accounts are expected, low-churn, and rarely change after initial provisioning. When a system default account shows unexpected credential aging or configuration changes, it signals potential system-level compromise.

Application Service accounts are created by well-known third-party software during package installation. LinuxGuard matches against a curated list of 50+ application accounts — nginx, postgres, redis, jenkins, grafana, kafka, vault, and others — combined with signals like a home directory under /var/lib/ or /var/run/ and a non-interactive shell. Package managers typically manage these accounts, so their lifecycle is usually predictable. The primary risk here is credential rotation compliance: application service accounts frequently hold SSH keys used by deployment pipelines, and stale keys in those pipelines can persist long after a rotation policy requires remediation.

Custom Service accounts are everything your organization created for specific automation purposes that does not match the system or application lists. LinuxGuard places an account in this tier when it signals "service" — a non-interactive shell, a UID in the 1–999 service range, or a name suffix like -svc, -daemon, -worker, or -agent — but has no match in the known lists. These are your homegrown automation accounts, cron runners, and pipeline service accounts. Custom Service accounts carry the highest operational risk because there is no shared knowledge base: you must verify their purpose, confirm an owner, and establish a credential lifecycle yourself.

Six metric cards appear at the top of the NHI page, cross-filtering the table:

• Total NHIs — all non-human identities across the fleet

• System Default — count of OS/system-package accounts

• Application Service — count of well-known third-party service accounts

• Custom Service — count of organization-defined automation accounts

• Unowned — NHIs with no owner assigned; shows a grace period subtitle when any newly discovered NHIs are still within their grace period before appearing as unowned

• Stale Credentials — NHIs whose SSH keys or credentials require rotation

A classification donut chart shows the proportion of System Default, Application Service, and Custom Service accounts. Clicking a segment filters the table.

The NHI table has eight columns: name, classification, risk level, server count, credential age in days, staleness (fresh, warning, or critical), owner, and last seen. Available filters include account type, risk level, owner status (yes or no), search, minimum server count, and maximum credential age.

Risk factors for NHIs are credential age, owner assignment, and grace period status. A Custom Service account with no owner, stale credentials, and high server count represents the highest-priority remediation target.

SSH Keys

The SSH Keys page (/identity/ssh-keys) provides fleet-wide visibility into all SSH keys discovered across monitored servers, with classification by algorithm strength, age, and cross-server presence.

Five metric cards appear at the top, cross-filtering the table:

• Total Keys — all SSH keys discovered fleet-wide

• User Keys — authorized_keys entries (user-type keys)

• Host Keys — server host keys

• Inactive (>90d) — keys not observed in the last 90 days

• Shared — keys whose fingerprint appears in authorized_keys on multiple server accounts

Two charts follow the metric cards: an algorithm distribution donut showing the proportion of key types across the fleet, and a key age histogram displaying how many keys fall into each age bucket with severity coloring.

Algorithm Strength

LinuxGuard classifies each SSH key by algorithm strength using NIST SP 800-57 as the basis. The grade boundaries are verified from the backend classification service:

Grade	Algorithms / Conditions	Severity Color
Critical	DSA (any size), RSA < 2048 bits	Red
Weak	RSA exactly 2048 bits, ECDSA < 384 bits (P-256), Unknown algorithm types	Orange
Acceptable	RSA 2049–4095 bits, RSA >= 4096 bits, ECDSA >= 384 bits (P-384, P-521)	Yellow
Strong	Ed25519	Green

DSA keys are Critical at any key size because the algorithm itself is considered broken. RSA at exactly 2048 bits is Weak — not Critical — because it was once the standard minimum but no longer meets current NIST guidance for new key generation. Ed25519 is the only algorithm that achieves Strong grade.

Key Age

LinuxGuard assigns each key an age bucket based on how long ago it was created:

Bucket	Age Range	Severity
Fresh	< 30 days	Info
Normal	30–90 days	Low
Aging	91–180 days	Medium
Old	181–365 days	High
Stale	> 365 days	Critical

Cross-Server Sprawl

A key is flagged as shared when the same fingerprint (SHA-256) appears in authorized_keys on multiple server accounts across the fleet. Sprawl severity scales with how many accounts the key has been authorized on:

• Low — 2 to 3 accounts

• Medium — 4 to 10 accounts

• High — more than 10 accounts

The risk of sprawl is compounding: a single compromised credential grants access to every system where that key is authorized. One leaked private key becomes a fleet-wide incident rather than an isolated one. The SSH Keys page surfaces the most broadly shared keys first, enabling targeted deprovisioning before a compromise occurs.

Orphaned Keys

An orphaned key is a key entry that remains in authorized_keys on one or more servers after the account that originally owned the key has been deleted. LinuxGuard detects orphaned keys by cross-referencing key fingerprints against the current account inventory. If a fingerprint has no matching active account as its primary owner but still appears in authorized_keys entries on other servers, the key is flagged as an orphaned candidate.

Orphaned keys represent persistent access credentials with no associated owner — a particular concern because no active account lifecycle governs their rotation or removal.

SSH Keys Table

The SSH keys table has the following columns: fingerprint (SHA-256, truncatable and copyable), key type, key size, algorithm grade, age and age bucket, posture score, primary owner, and server count. Additional fields visible in the row or detail panel include whether the key is shared (is_shared), whether it is inactive (is_inactive), and a detractor count summarizing negative posture contributors.

Default sort is by posture score ascending — the most problematic keys (lowest posture) appear first.

Available filters: key type (user or host), algorithm grade, inactive (yes or no), shared (yes or no), environment, and tag.

Access Patterns

The Access Patterns page (/identity/access-patterns) provides behavioral analytics for identities across the fleet. The page uses a four-mode state machine that administrators explicitly control — the system does not automatically advance through modes.

The four modes and what administrators see in each:

Mode	State	What Admins See
Disabled	Analytics off	"Behavioral analytics is disabled" banner
Observation	Learning baselines	Day X of Y progress bar (Z% complete); no anomalies surfaced
Shadow	Detection active, admin-visible only	Shadow alerts visible to admins; non-admins see the observation view
Active	Detection integrated into alerts	Anomalous Events count and full behavioral feed visible to all users

The mode progression is: Disabled → Observation → Shadow → Active. Administrators can also revert to Observation (pause) or disable detection entirely. Every transition to Shadow or Active requires an explicit promotion action — baselines never advance the mode automatically.

Note: Access Patterns does not surface anomalies immediately after deployment. During observation mode, LinuxGuard learns behavioral baselines for each identity. Anomaly detection only becomes active after observation mode completes and baselines are established.

Observation Period

During observation mode, LinuxGuard records behavioral patterns for each identity — sudo frequency, command categories, and SSH session timing. The page displays an observation_days_elapsed / observation_days_total progress bar with a percentage complete. The total observation period length is configurable per server group using the behavioral_sensitivity setting.

Baselines and Maturity

LinuxGuard tracks two counts: baselines_total (identities currently being tracked) and baselines_mature (baselines that have accumulated enough data to support anomaly detection). The Baseline Maturity % metric shows what proportion of tracked identities are ready. Administrators should wait for high maturity before promoting to Shadow mode — promoting too early results in higher false positive rates because immature baselines have not learned full behavioral patterns for the identities they cover.

Stat Cards

The Access Patterns page shows four stat cards whose labels change depending on the active mode:

• Identities Monitored — baselines_total with a servers_reporting count

• Anomalous Events (labeled "Behavioral Insights" in observation mode, "Shadow Alerts" in shadow mode) — mode-aware count of behavioral anomalies

• FP Rate — false positive rate with a trend indicator showing whether the rate is improving, stable, or worsening

• Days Remaining (observation mode) or Baseline Maturity % (shadow and active modes)

Activity Heatmap

The heatmap is a 7-day by 24-hour grid. Each cell shows the activity count for a specific day-of-week and hour-of-day combination. Color intensity indicates activity volume — the deepest color marks peak activity cells. An optional Z-score overlay is available per cell to highlight statistically unusual activity relative to the baseline.

Heatmap filters include: dimension (combined, SSH, sudo, or other activity types), identity (typeahead search by name), server group, and time range (30, 60, or 90 days).

Behavioral Feed

In shadow and active modes, the Behavioral Feed (InsightFeed) appears below the heatmap as a chronological list of anomalous access events. Each entry shows the identity name, anomaly type (for example, "Unusual Hour" or "Unusual Command Category"), composite score from 0 to 100, confidence level (low, medium, or high), server, and timestamp.

In active mode, entries carry severity badges (critical, high, medium, or low) at full opacity — these are live signals integrated into the alert system.

In shadow mode, severity badges are shown at 50% opacity to indicate that detection is running but signals have not yet been promoted to full alerts. Shadow mode lets administrators validate detection quality before committing to active enforcement.

---

Related: Console Overview | Zero Trust Enforcement (SUDO Policies) | Glossary | Security Architecture