NHI Discovery ​

Find non-human identities (service accounts, service principals, managed identities and app registrations) and triage their credentials, owners and risky settings.

Requires role: Operator (dashboard card, inventory, presets, Select Fire) / Admin (NHI naming patterns)

Related: Identity Inventory | Asset Criticality Engine | Risk Posture Dashboard | Select Fire | Telemetry Enrichment | Attribute Sync Configuration

Overview ​

Non-human identities (NHIs) are the accounts that software uses: Active Directory service accounts, group managed service accounts, Entra ID service principals, app registrations and managed identities. In most enterprises they outnumber people. Attackers favor them: they hold standing permissions, their credentials often never expire, and often nobody owns them.

GraphnAI treats them as identities in their own right:

  • Classified at sync. The LDAP sync recognizes group and standalone managed service accounts and puts them on the Service accounts tab. A user account with a service principal name (SPN), or with a name that matches an NHI pattern, becomes a service account too.
  • Credential expiry kept. The Entra ID sync keeps the expiry date of every credential on each service principal and app registration.
  • Owners recorded. The registered owners of each Entra service principal and app registration are stored, so you can find the ones with none.
  • Five criticality rules mark risky delegation settings, Kerberoastable and AS-REP roastable accounts, and multi-tenant apps HIGH.
  • Five inventory presets narrow the table to the NHI problems that matter most.
  • A dashboard card shows NHI counts and credential expiry.
  • Naming patterns you add cover your own service account naming conventions.
  • Telemetry confirmation (licensed): observed sign-ins can confirm that an identity is a service account.

What Counts as an NHI ​

GraphnAI uses several signals to classify an identity as non-human. The NHI evidence column in the inventory shows which signals applied, so you can see why an identity is there.

IdentityHow it's recognizedNotes
gMSA (group managed service account)LDAP objectClass msDS-GroupManagedServiceAccountA service account, with the gMSA evidence badge
sMSA (standalone managed service account)LDAP objectClass msDS-ManagedServiceAccountA service account, with the sMSA evidence badge
AD user with an SPNA user with a non-empty servicePrincipalNameMoved from user to service account, with the original type kept for audit. SPN evidence badge.
Pattern-matched accountA user or service account whose display name matches an NHI naming patternA matching user becomes a service account, with the original type kept for audit. Name pattern evidence badge.
Entra service principalSynced from Entra IDEvery service principal is an NHI. It's on the Service principals tab.
Entra app registrationSynced from Entra IDEvery app registration is an NHI. It's on the Applications tab.
Managed identityA service principal of the ManagedIdentity typeOn the Service principals tab

Entra service principals and app registrations are NHIs by type, so their NHI evidence cell shows a dash.

Classification Confidence ​

The NHI evidence cell ends with a confidence level that says how sure the classification is:

ConfidenceMeaningSet by
LowThe name matched a naming pattern, and nothing structural confirms itA pattern match only. Treat it as a candidate and check it before you act.
MediumA structural attribute confirms it: an SPN, or the gMSA or sMSA object classMost on-premises service accounts
HighTelemetry shows the identity signs in the way a service does. Needs the telemetry license.Observed behavior

The highest signal wins. An identity that matches a naming pattern and carries an SPN shows Medium. Telemetry raises it to High.

Note: A pattern-only identity (Low) may be a person's account whose name happens to match. Check the NHI evidence badges before you act.

Prerequisites ​

  • Role: Operator or Admin for the dashboard card, the inventory, the presets and Select Fire. Admin to manage NHI naming patterns.
  • Data: At least one successful sync from an LDAP bridge (for on-premises service accounts) or Entra ID (for service principals and app registrations). Classification runs during the sync, with nothing to start by hand.
  • Entra ID permissions: Application.Read.All covers service principals, app registrations and their owners. The NHI: Consent for all users preset also needs Directory.Read.All. See Entra ID Setup.
  • Telemetry (optional): Licensed, active telemetry is needed for High confidence. Without it, confidence stops at Medium.

NHI Dashboard Card ​

Select Dashboard in the sidebar and scroll to the Non-human identities card, after Platform Health. Its Inventory link opens the Service accounts tab of the Identity Inventory.

The card has two parts.

Counts by Type ​

Five counters show how many identities of each NHI type you have, across every domain and tenant. Select a counter to open that type's tab in the Identity Inventory.

CounterWhat it counts
Service accountsgMSAs, sMSAs, and users reclassified as service accounts during the LDAP sync
Service principalsEvery Entra service principal, managed identities included
ApplicationsEntra app registrations
DevicesEntra ID devices
ComputersActive Directory computer accounts, domain controllers included. A hybrid-joined machine appears both here and under Devices.

Credential Expiry Distribution ​

Credential expiry distribution is a bar chart of service principals and app registrations by how long their earliest valid credential has left:

BarMeaning
< 30dExpires within 30 days. Rotate it now.
30-90dExpires in 30 to 90 days. Plan the rotation.
90-365dExpires in 90 to 365 days. A healthy rotation window.
> 365dValid for a year or more. Review the rotation practice. Microsoft's own service principals often show multi-year expiries here.
ExpiredEvery credential has expired.
Never expiresAt least one credential has no expiry date. The highest risk.

An identity with any credential that never expires counts under Never expires, whatever its other credentials say.

Never expires matters most. A credential with no expiry stays valid indefinitely if it's ever exposed. Review these identities first.

To see which NHIs carry the most risk, use Top Findings at the top of the dashboard. It ranks every identity type, NHIs included.

NHI Inventory Filters ​

The Identity Inventory has five presets for NHI triage, under Non-human identities in the Filters list.

  1. Select Identity Inventory in the sidebar.
  2. Select the Service accounts, Service principals or Applications tab.
  3. Select Filters, then an NHI preset.
PresetIconWhat it shows
NHI: OrphanedPerson with a minus signService principals and app registrations with no registered owner. AD service accounts never match, because AD has no registered owner for a service account.
NHI: Stale credentialClockService principals and app registrations with an expired credential, a credential that never expires, or a credential that expires within 365 days
NHI: KerberoastableKeyService accounts with an SPN and a password that never expires, that aren't managed service accounts or limited to DES
NHI: Multi-tenantGlobeService principals and app registrations for apps your tenant publishes for other organizations to sign in to. Microsoft's own apps are left out.
NHI: Consent for all usersWarning triangleService principals and app registrations with an OAuth2 permission grant consented on behalf of every user in the tenant (the AllPrincipals consent type)

Each preset shows how many identities on the current tab match, counted after each sync. The presets appear on every tab, but they only match NHI types, so their counts read 0 on the Users tab.

Where to start: Take NHI: Kerberoastable and NHI: Consent for all users first: they're open attack paths. Then use NHI: Stale credential to shorten how long a stolen credential stays useful. Use NHI: Orphaned for a cleanup pass that gives every service principal and app registration an owner.

New Inventory Columns for Service Accounts and Service Principals ​

The Service accounts, Service principals and Applications tabs add these columns:

ColumnDescription
Credential expiresDays until the earliest credential expires. Green under 90 days (healthy rotation), orange from 90 days, and red at a year or more ("N days, long-lived"). Expired and Never expires are red. Microsoft's own service principals often run for years. A dash means no credentials were synced.
OwnerThe first registered owner, cut at 20 characters, with "+N" when there are more. Hover for the full list. A dash means no owner. Not on the Service accounts tab, because AD has no registered owner for a service account.
NHI evidenceWhy the identity counts as an NHI: Name pattern (gray), SPN, gMSA or sMSA (blue), or Telemetry (green), followed by the confidence, such as "Medium confidence".

Understanding NHI Criticality Rules ​

Five built-in rules set an identity's criticality to HIGH at each evaluation. They're listed with the other system rules in Admin > Classification Rules, on the Criticality tab under System rules. You can't delete or turn them off.

RuleConditionWhy it matters
Unconstrained delegation (NHI)trustedForDelegation is setThe account receives the Kerberos TGTs of users who sign in to it. Whoever controls it can act as those users, and can reach Domain Admin.
Constrained delegation with protocol transition (NHI)trustedToAuthForDelegation is setThe account can get tickets as any user to the services it may delegate to (S4U2Self, S4U2Proxy), without their credentials.
AS-REP roastable (NHI)dontRequirePreauth is setAnyone can request data they can crack offline for the account's password, without signing in.
Kerberoastable service account (NHI)An SPN and a password that never expires, and not a gMSA, an sMSA or DES-onlyIts service tickets can be cracked offline. Managed service accounts are left out because their passwords are managed for them.
Multi-tenant app published by your tenant (NHI)An app your tenant publishes for any organization to sign in toAccounts from any tenant can sign in to it, which widens who can attack it. Microsoft's own apps are left out.

The rules apply to every identity that carries the setting, user accounts included.

A HIGH NHI raises the Criticality gap risk factor of every identity that holds permissions on it.

To see which service accounts the rules marked, select the Service accounts tab in the Identity Inventory and sort Criticality from highest to lowest.

Configuring NHI Naming Patterns ​

Requires role: Admin

On-premises environments often have service accounts with no SPN, from before gMSAs, that still follow a naming convention (for example, a xyz_svc_ prefix). NHI naming patterns extend classification to them without waiting for a move to gMSA.

Select Admin > Classification Rules in the sidebar, then the NHI patterns tab. The page reads "Regexes that flag identity display names as service accounts. Changes take effect on the next directory sync."

Built-in System Patterns ​

Three built-in patterns cover the most common conventions. They're on the Built-in tab, and you can't delete, change or turn them off:

  • Prefix (weight High): names that start with svc, sa, srv, service, app, daemon or bot, followed by a dash, underscore or dot. The regex is (?i)^(svc|sa|srv|service|app|daemon|bot)[-_.].
  • Suffix (weight High): names that end with a dash, underscore or dot, then svc, sa, service, srv or app, with optional digits. The regex is (?i)[-_.](svc|sa|service|srv|app)\d*$.
  • Contains "service" (weight Low): names that contain service anywhere. The regex is (?i)service.

The third pattern is broad on purpose, and it matches people's accounts with "service" in their display name. Like any pattern match, it makes a matching user a service account, with Low confidence. Check the NHI evidence badges before you act on a Low-confidence finding.

A pattern's weight is recorded with it. It doesn't change the classification or the confidence today.

Adding a Customer Pattern ​

  1. Select Add pattern at the top right.

  2. In Regex, enter a regular expression for your naming convention. It's checked as you type, and an invalid one shows "Not a valid regular expression." with the reason.

    Regex tips: Anchor the pattern to the start or end of the name where you can (^prod_sa_ rather than prod_sa), so it doesn't match people's accounts. Patterns match the display name in lowercase. The server uses RE2 syntax, so it refuses lookaheads, lookbehinds and backreferences when you preview or save.

  3. Choose a Weight: Low, Medium (the default) or High.

  4. Optionally, add a Description (optional) that explains the convention. It appears in the pattern table.

  5. Select Preview match count. It shows how many identities match and up to three example names, for example "47 identities such as xyz_svc_sql01, xyz_svc_backup, xyz_svc_exchange". It counts users and service accounts whose display name matches, including ones already flagged.

  6. Select Add pattern to save.

The pattern applies from the next directory sync. A delta sync applies it only to the objects that changed, so run a full sync to apply it to every identity.

Deleting a Customer Pattern ​

On the Custom tab, select the trash icon on the pattern's row, then select Delete in the Delete pattern dialog. Identities the pattern already flagged keep that flag. The pattern stops applying at the next sync.

There's no way to remove the NHI classification from a single identity today. A manual criticality override changes only the identity's criticality.

Telemetry-Corroborated Classification ​

Requires: the telemetry license feature. Operators and Admins see the result.

When telemetry is licensed and active, the analysis after each sync checks the Windows sign-in types recorded on each identity's sessions. If an identity has enough sign-ins over a long enough period, and the large majority are service or batch sign-ins, GraphnAI:

  • Classifies it as a service account
  • Adds Telemetry to its NHI evidence
  • Raises its confidence to High

The result shows in the inventory after the next sync.

This helps in two ways:

  1. It separates real service accounts from false matches. A pattern-matched account that people sign in to interactively doesn't reach the bar.
  2. It confirms a classification without a manual review. An identity that signs in only as a service, over a long period, is almost certainly not a person.

It looks at every identity with recorded sessions, including ones with no pattern or attribute evidence and ones already at Medium.

To see whether telemetry contributes in your environment, look for the green Telemetry badge in the NHI evidence column.

NHI Remediation with Select Fire ​

Requires role: Operator

Rows on the Service accounts, Service principals and Applications tabs have a Select Fire (lightning) button, and so does the identity's flyout. For these identities, Select Fire opens with a Flagged service account hint: "Pick which permissions to revoke below." Under "Also consider", it suggests Disable identity and Revoke active sessions.

Nothing is selected for you. Choose the actions in the Preview step, then simulate or generate a script. Select Fire also needs the remediation license.

For the full workflow, including blast radius simulation and script generation, see the Select Fire guide.

How NHI Data Flows Through the Platform ​

This explains when changes appear, and why some columns may be empty right after a first sync.

On-Premises (LDAP / Active Directory) ​

  1. Sync: The LDAP bridge collects gMSA and sMSA objects in a query of their own. User objects with an SPN become service accounts. Then naming patterns are applied to users and service accounts.
  2. Kerberoastable flag: The Kerberoastable setting is worked out during the sync. The Kerberoastable rule and preset read it.
  3. Criticality: The analysis after the sync evaluates the five NHI rules. The criticality badge updates when it finishes.
  4. Analysis: The preset counts and the dashboard card are computed.

Entra ID ​

  1. Sync: GraphnAI reads service principals and app registrations from Microsoft Graph. Each credential's expiry date is kept. A credential with no expiry date, or one that can't be read, counts as never expiring.
  2. Owners: The registered owners of each service principal are read and recorded.
  3. OAuth2 consent type: Each OAuth2 permission grant keeps its consent type (for all users, or for one user). The NHI: Consent for all users preset reads it.
  4. Criticality and analysis: As for on-premises, steps 3 and 4.

When Data Becomes Visible ​

SurfaceData available after
Service accounts, Service principals and Applications tabsThe sync finishes
Credential expires columnThe Entra ID sync finishes
Owner columnThe Entra ID sync finishes, owner lookup included
NHI evidence columnThe sync finishes
Criticality badge (NHI rules)The analysis after the sync evaluates criticality
Dashboard cardThe analysis after the sync finishes
Preset countsThe analysis after the sync finishes
Telemetry evidenceThe sync after the analysis that classified it (licensed)

Troubleshooting ​

Service accounts are missing from the Service accounts tab ​

Most likely causes:

  1. No full sync since classification changed. Classification runs during a sync, so identities collected earlier keep their old type. Select Bridges, open the bridge, and select Full sync. Wait for it to finish.
  2. Your domain controllers don't return gMSA objects. Some hardened domain controllers restrict reading msDS-GroupManagedServiceAccount objects. If that query fails, the sync fails with an error. Check the bridge's sync history, and ask your AD administrator to confirm read access to gMSA objects.
  3. No accounts qualify. If all your service accounts are gMSAs or dedicated service account objects, and none is a user with an SPN, nothing is reclassified. That's correct.

Credential expires shows a dash for every Entra service principal ​

Cause: The Entra ID sync hasn't run since the credentials were added, or the service principals have no credentials registered.

Steps:

  1. Select Admin > Identity Providers, then Sync now on the tenant.
  2. When the sync finishes, refresh the inventory. If the column still shows a dash, check in the Entra admin center that the service principal has credentials.
  3. App registrations with only federated credentials (workload identity federation) have no key or password credentials. A dash is correct for them.

Owner shows a dash for service principals or app registrations that have owners ​

Cause: The owner lookup failed for those service principals or app registrations during the Entra ID sync, so they were saved with no owners.

Steps:

  1. Confirm the app registration the tenant uses has the Application.Read.All application permission, with admin consent.
  2. An Admin with server log access can look for warnings that start with "ListOwners".
  3. Run the Entra ID sync again.

NHI preset counts are zero ​

Cause: You're on a tab with no NHIs, or the analysis after the sync hasn't finished.

Steps:

  1. Select the Service accounts, Service principals or Applications tab. The counts follow the tab.
  2. Run a full sync. The analysis runs after each sync.
  3. If the Identity Inventory shows "Analysis didn't finish. Some numbers below may be missing or out of date.", run the sync again from Bridges. An Admin with server log access can look for "Post-sync analytics completed".

The preview count shows far more matches than expected ​

Cause: The regex is too broad and matches people's accounts. A pattern with no anchor (svc matches "svc" anywhere in a name) is the usual reason.

Steps:

  1. Read the example names under the count. They usually show the problem.
  2. Anchor the pattern to the start of the name (^), and use separators where they fit.
  3. Preview again until the count and the examples look right, then save.

A pattern-matched identity isn't an NHI ​

Cause: The naming convention is too broad, and the account belongs to a person.

Resolution: Narrow or delete your custom pattern so it stops matching. Identities it already flagged keep the flag, and there's no way to clear it for a single identity today. A manual criticality override changes only that identity's criticality.

Telemetry badges don't appear, though telemetry is active ​

Cause: Telemetry isn't licensed, the identities don't have enough sign-in history yet, or their sign-ins mix interactive and service types.

Steps:

  1. Select Admin > License and check that Telemetry is among the licensed features.
  2. Select Admin > Telemetry and check that events are arriving (Events (24h) above zero).
  3. Wait for more history. The classifier needs a minimum number of sign-ins over a minimum period, and runs in the analysis after each sync.

Best Practices ​

  1. Take Kerberoastable accounts first. Anyone with a domain account can attack them. Select NHI: Kerberoastable, sort by criticality, and work down the list. For each account, confirm it's still needed and move it to a gMSA if you can. Until then, give it a long, random password that rotates often.

  2. Remove non-expiring credentials from Entra service principals. Each one in Never expires stays valid indefinitely. Select NHI: Stale credential, sort Credential expires, and take the "Never expires" rows first. Work with the application owners to set an expiry and a rotation schedule.

  3. Give every service principal and app registration an owner. NHI: Orphaned lists identities nobody is accountable for: not their behavior, their rotation or their retirement. Owners are the starting point for any access review. Add owners in the Entra admin center, and the next sync picks them up.

  4. Review multi-tenant apps before you add patterns. If you expect some multi-tenant apps, select NHI: Multi-tenant first to build a list of known ones. Then look at the unexpected entries: an internal app set up as multi-tenant by mistake is common.

  5. Add naming patterns sparingly. The built-in patterns cover the common conventions. Add your own only for a convention they miss. Anchor it with ^, and check the preview count before you save.

  6. Sync after you change patterns. Patterns apply at the next sync, and fully only after a full sync. Run one after you save, so the classification is current for your next review.

  7. Check who can reach a HIGH NHI. The NHI rules raise the criticality gap of every identity with permissions on a HIGH NHI. Open the NHI's Reach (in) % graph in the inventory to see who can reach it.