Non-Human Identities: The Attack Surface You Might Be Ignoring

Security programs focus heavily on human identities — MFA enforcement, privileged access reviews, phishing resistance. But in most organizations, non-human identities (NHIs) outnumber humans by a factor of 10 to 1. Service accounts running in Azure Automation. API keys issued to a third-party integration that was deprecated six months ago. OAuth tokens granted to an app that no developer can name. Each of these is a potential entry point — and most of them are not managed with anything like the rigor applied to human accounts.

What Is an NHI?

A Non-Human Identity is any credential or authentication token used by a system, application, or automated process rather than a person. In Microsoft environments, NHIs commonly include:

• Azure Automation account managed identities — system-assigned or user-assigned identities that authenticate to Azure services without stored credentials
• App registration service principals — the server-side identities used by registered applications to access Graph API, Exchange, and other M365 services
• TATER API keys — SHA-256 hashed keys issued for runbook authentication and MCP server access
• OAuth delegated tokens — user-consent grants to third-party apps that persist after the user who granted them has left the organization
• Functional mailboxes and service accounts — shared mailboxes used by automation tools that accumulate permissions over time

TATER NHI Inventory

The NHI module in TATER Security (Security → Non-Human Identities) provides a structured inventory of all NHIs in your organization. Each record captures the identity type, associated system, permission scope, owner, rotation date, and expiry date. The inventory is queryable, filterable by type and risk level, and linked to the compliance controls that govern NHI management in your active frameworks.

Inventory records are created manually, by importing from Azure (via the Entra ID integration scanner), or by the MCP server when an AI agent discovers credential references during a compliance review. Every NHI record participates in the standard TATER audit trail — creation, modification, and review events are all logged.

Risk Signals

The NHI module surfaces four categories of risk signal automatically:

• Expiring credentials — certificates, secrets, and API keys with expiry dates within 90 days appear in the TATER calendar as upcoming events
• Overprivileged identities — service principals with more Graph permissions than their documented purpose requires
• Orphaned credentials — NHIs associated with decommissioned applications or departed users
• Unrotated long-lived credentials — credentials that have not been rotated within the organization's policy window

"An API key issued for a pilot project that ran for 90 days and was never revoked is as dangerous as a compromised user account — and far less likely to appear on anyone's radar."

Connecting NHI to Compliance Controls

CIS Microsoft 365 Foundations Benchmark and CISA SCuBA both include controls governing service principal permissions, app registration restrictions, and credential management. TATER maps NHI inventory records to the specific controls they satisfy — so an auditor asking for evidence of service account lifecycle management gets a direct link to the inventory record and its associated audit history, not a spreadsheet.

MCP Integration

The TATER MCP server can read and write NHI inventory records. An AI agent performing a periodic access review can enumerate all NHIs, flag those with upcoming expiry, create tasks in TATER Ops for credential rotation, and document the review in TATERpedia — all in a single automated session. The session is fully audited with via: 'mcp' attribution so the access review evidence is automatically generated as a byproduct of doing the work.