NIST for non-human identities: governing machine access end to end

When a NIST assessment reaches your non-human identities, it comes down to an export: the package of records you hand the assessor showing that every machine account was authorized, scoped, and audited. For service accounts, CI runners, and agents, that package is usually thin. The accounts exist, their access is broad because narrowing it was never anyone's job, and the audit records, where they exist at all, are scattered across the systems each identity touched. The assessor's request, show me account management and audit coverage for these machine identities, lands on a pile of partial logs.

Governing non-human identities for NIST means being able to produce that export on demand. This post frames the controls around the package the auditor actually reviews.

What goes in the NIST export for machine identities

NIST 800-53 does not exempt non-human accounts. AC-2 covers account management for every identity, service accounts included. AC-6 expects least privilege regardless of whether a person or a process holds the credential. AU-12 expects audit records generated by the system for the access that occurred. The export the assessor reviews is the concrete form of those controls: an inventory of machine identities, the scope each one carries, and the audit trail of what each one reached.

Why the export comes back incomplete

The records that should fill the export live in different systems. Identity sits in one place, scope in scattered policy, audit in per-system logs, and masking nowhere. A machine identity slips through the seams between them, so assembling the export becomes a manual reconstruction every assessment cycle. Each system did its job, but no single one can show account management and audit coverage end to end.

One access path, one export

The fix is to make the connection to the resource the place where the controls are enforced, so the export comes from one source. hoop.dev is built to that shape. It is an open-source Layer 7 access gateway that proxies connections to infrastructure such as databases, Kubernetes, and internal services, and it applies the same account, scope, and audit controls to a machine identity that you would demand of a human one.

On that path, every machine identity authenticates as a named principal, access is scoped just-in-time to the task, and each session is recorded at the command level where the identity cannot rewrite it. The export stops being a reconstruction and becomes a query against one record. Read how hoop.dev records each connection, and to try it, route a service account through hoop.dev.

Take a CI runner that deploys nightly and needs read access to a config database. Instead of a long-lived credential with broad reach, it connects through hoop.dev under its own identity, scoped to the one database for the length of the job, with every statement recorded. When the assessor asks what that runner did last quarter, the answer is a filter on one audit stream, not a hunt across machines. The same record covers AC-2 for the account and AU-12 for its activity.

What the assessor sees

The difference is coherence. One source shows the identity inventory for AC-2, the scope for AC-6, and the audit records for AU-12, for every non-human access. hoop.dev does not hold a NIST certification, because NIST 800-53 is a framework you align to rather than a badge a tool carries. It generates the evidence for NIST, continuously and per identity, so the export already exists when the assessment starts. The model is open for inspection at hoop.dev.

FAQ

Is hoop.dev NIST certified?

No tool holds a NIST certification, and it would not change much if one did, because hoop.dev is self-hosted. It runs in your own infrastructure and never stores your data on a hoop.dev-operated service, so it does not become a separate system the assessment has to cover. hoop.dev generates the account and audit evidence your NIST 800-53 program presents for machine identities.

Does NIST 800-53 really cover service accounts?

Yes. AC-2 account management applies to all accounts, including non-human ones, so service accounts and agents fall under the same authorization, least-privilege, and audit expectations as human users.

hoop.dev is open source, so you can see exactly how machine access is governed and recorded at the hoop.dev repository on GitHub.