Most non-human identity compromises trace back to a short list of controls that were never checked: an unknown service account, a key with no owner, a token that never expires, a role far wider than its job, or a credential used from somewhere it never should be. This checklist turns those controls into pass or fail checks you can run against one application, one cloud account or the whole estate, with the evidence an auditor will ask for beside each one. It is written for NHI, IAM, cloud and platform security teams, and for internal audit. It is a control checklist, not a metrics review: the recurring KPIs live in the NHI Programme Health Check, and the rules the checks enforce are set out in the NHI Policy Template. For background on what counts as an NHI, start with the Non-Human Identity (NHI) Guide.
How to use this template
Copy the tables into your own tracker and replace the bracketed placeholders, such as [Organisation] and [Owner], with your own values. Pick a scope first (sections 1 and 2), then work through sections 3 to 10, marking each check Pass, Fail or Not applicable and recording the evidence you looked at. A check only passes when the evidence exists today, not when a project to create it is planned. Every Fail becomes a finding with an owner and a due date in section 11. The check IDs (INV-01, OWN-01 and so on) are stable, so you can compare runs over time and map them to your own control library. The right-hand column of each table names the risk from the OWASP Non-Human Identities Top 10 (2025) that the check addresses, which helps when explaining priorities to engineering teams.
Run the full checklist once a year per scope and after any major change, such as a cloud migration, a merger or a new CI/CD platform. Run sections 4 and 10 on their own each quarter for high-risk scopes.
1. Scope and roles
| Field | Value |
|---|---|
| Organisation | [Organisation] |
| Scope of this run | [e.g. production AWS organisation; payments platform; all CI/CD systems] |
| Identity types in scope | [Service accounts, cloud roles and service principals, API keys, OAuth apps, tokens, certificates and keys, bots, AI agents] |
| Checklist owner | [NHI or IAM lead] |
| Reviewers | [Platform owner, application owner, internal audit] |
| Approver | [CISO or delegate] |
| Run date and previous run | [Date] / [Date] |
Name AI agents explicitly in scope. Agents authenticate with the same API keys, OAuth tokens and service principals as other workloads, and they are easy to leave out because they arrive through product teams rather than infrastructure tickets. See the AI Agent Credential Lifecycle and Rotation Guide.
2. Inventory and discovery
| ID | Check | Evidence to keep | OWASP NHI risk |
|---|---|---|---|
| INV-01 | A single inventory lists every NHI in scope, with identity type, platform, environment and the system that uses it. | Inventory export dated this run | NHI1 |
| INV-02 | Discovery runs automatically against every identity source in scope: directories, each cloud account or subscription, SaaS tenants, CI/CD systems, secrets stores and certificate stores. | List of connected sources with last successful collection date | NHI1, NHI3 |
| INV-03 | The inventory records each credential attached to an identity (keys, secrets, certificates, tokens) with its creation date, expiry and last use. | Sample of 20 records showing these fields | NHI7 |
| INV-04 | New identity sources (a new cloud account, SaaS tenant or pipeline platform) are added to discovery before they go live. | Onboarding procedure and the last three new sources with dates | NHI1 |
| INV-05 | Inventory records are reconciled against the source platforms, and records that no longer exist or appear only in the source are investigated. | Last reconciliation report with differences explained | NHI1 |
| INV-06 | Identities follow a naming and tagging standard that shows owner, application and environment. | Standard document and a compliance sample | NHI8, NHI9 |
CIS Controls v8.1 Safeguard 5.5 asks for an inventory of service accounts, and NIST SP 800-53 Rev. 5 CM-8 System Component Inventory and AC-2 Account Management set the same expectation for systems in their scope. For method, see NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments, NHI Inventory Reconciliation and the Machine Identity Naming and Tagging Standard Template.
3. Ownership and accountability
| ID | Check | Evidence to keep | OWASP NHI risk |
|---|---|---|---|
| OWN-01 | Every NHI has a named human owner and a backup owner, recorded in the inventory, not only in a ticket or wiki page. | Inventory records with owner fields | NHI1 |
| OWN-02 | Owners are people with an active account in the HR-fed directory; when an owner leaves or changes role, ownership is reassigned through a defined process. | Leaver procedure step and the last three reassignments | NHI1 |
| OWN-03 | Owners attest at a set interval that each identity is still needed and its access is still right. | Last attestation campaign results with decisions | NHI1, NHI5 |
| OWN-04 | Every NHI records its business purpose and the application or service it supports. | Sample records with a purpose field | NHI9 |
| OWN-05 | Creation of a new NHI requires a request with owner, purpose, scope and expected lifetime, and is approved before it is provisioned. | Request workflow and three recent approvals | NHI5, NHI9 |
For orphaned accounts already in the estate, see How to assign owners to orphaned service accounts and the NHI Ownership Attestation Campaigns Guide.
4. Credentials, storage and rotation
| ID | Check | Evidence to keep | OWASP NHI risk |
|---|---|---|---|
| CRD-01 | Secrets are stored in an approved secrets manager or platform credential store, never in source code, plain-text configuration files, container images, tickets or chat. | Secrets manager inventory; secret scanning results for the scope | NHI2 |
| CRD-02 | Secret scanning runs on code repositories, CI logs and container images in scope, and blocks new secrets at push where the platform allows it. | Scanner coverage list and push protection settings | NHI2 |
| CRD-03 | Every static credential has a maximum lifetime set by policy, and the platform enforces an expiry where it can. | Policy clause; platform expiry settings | NHI7 |
| CRD-04 | Rotation is automated for static secrets that cannot be replaced, and each rotation is tested before the old credential is revoked. | Rotation job configuration and last successful run per credential type | NHI7 |
| CRD-05 | Short-lived or dynamic credentials replace long-lived secrets wherever the target system supports them. | List of remaining long-lived secrets with a reason for each | NHI7 |
| CRD-06 | A documented, tested procedure exists to revoke and replace any credential within hours of a suspected leak. | Playbook and the date of the last test | NHI2 |
| CRD-07 | Private keys and certificates for machine authentication are protected by a key store or hardware module, with expiry tracked. | Certificate inventory with expiry dates | NHI7 |
The OWASP Secrets Management Cheat Sheet describes the secret lifecycle as creation, rotation, revocation and expiration, recommends that rotation validates the new credential before promoting it, and notes that restarting an application does not revoke a stolen credential. NIST SP 800-53 IA-5 Authenticator Management and IA-5(7) No Embedded Unencrypted Static Authenticators cover the same ground. See the Secrets Management Guide, Credential Rotation at Scale, the Dynamic Secrets and Ephemeral Credentials Guide and the Leaked Credential Response Playbook.
5. Least privilege
| ID | Check | Evidence to keep | OWASP NHI risk |
|---|---|---|---|
| LPV-01 | No NHI holds an organisation-wide administrator, owner or equivalent role unless an approved exception with an expiry exists. | Role assignment export filtered on administrative roles; exception register | NHI5 |
| LPV-02 | Permissions are scoped to named resources (a bucket, a queue, a repository) rather than to whole accounts, projects or tenants. | Sample of 10 high-risk identities with their policies | NHI5 |
| LPV-03 | Granted permissions are compared with permissions actually used, and unused permissions are removed on a schedule. | Last unused permission report and the changes made | NHI5 |
| LPV-04 | NHI access is included in access reviews, with the owner deciding keep, reduce or remove. | Access review campaign scope and results | NHI5 |
| LPV-05 | Rights to create keys for, impersonate or assume another NHI are restricted to named administrators and pipelines. | List of principals with key creation and impersonation rights | NHI5 |
| LPV-06 | Third-party integrations (SaaS apps, OAuth apps, IDE extensions) hold only the scopes their function needs, approved before consent. | OAuth app and integration list with granted scopes | NHI3 |
LPV-05 matters because an identity that can mint keys or tokens for others can escalate silently, which ATT&CK records as Additional Cloud Credentials (T1098.001). NIST SP 800-53 AC-6 Least Privilege and CSF 2.0 PR.AA-05 apply. See the OWASP NHI Top 10 NHI5 Overprivileged NHI Guide.
6. Authentication and federation
| ID | Check | Evidence to keep | OWASP NHI risk |
|---|---|---|---|
| AUT-01 | Workloads in cloud and CI/CD authenticate with federated, short-lived tokens (for example OIDC workload identity federation) instead of stored keys where the platform supports it. | List of pipelines and workloads with their authentication method | NHI6, NHI7 |
| AUT-02 | Federation trust policies validate the token issuer, audience and subject claims, so only the intended repository, branch or workload can obtain the role. | Trust policy sample for each federated provider | NHI6 |
| AUT-03 | Deprecated or weak authentication methods for machine access (shared basic credentials, legacy protocols, unsigned tokens) have a dated retirement plan. | Register of legacy methods with target dates | NHI4 |
| AUT-04 | Service accounts cannot sign in interactively, and where the platform allows it, use is restricted to known networks or workloads. | Sign-in restriction settings; conditional access or network policy | NHI10 |
See the Cloud Workload Identity Guide and How to detect interactive logons by service accounts.
7. Environment separation, reuse and human use
| ID | Check | Evidence to keep | OWASP NHI risk |
|---|---|---|---|
| SEP-01 | Development, test, staging and production use separate NHIs and separate credentials; no production credential is present in a non-production environment. | Inventory filtered by environment; secret scanning of non-production stores | NHI8 |
| SEP-02 | Each application or service has its own NHI; one identity is not shared across unrelated workloads. | Identities used by more than one workload, from usage logs | NHI9 |
| SEP-03 | People do not use NHI credentials for manual tasks; manual and emergency actions run under named human accounts with their own privileges. | Sign-in logs for NHIs showing human patterns; break-glass procedure | NHI10 |
8. Monitoring and detection
| ID | Check | Evidence to keep | OWASP NHI risk |
|---|---|---|---|
| MON-01 | Authentication and API activity for NHIs is logged on every in-scope platform and sent to the SIEM, with retention set by policy. | Log source list with retention settings | NHI2, NHI10 |
| MON-02 | Detections exist for NHI use from new locations, networks, user agents or at unusual volumes. | Detection rule list and last test result | NHI2 |
| MON-03 | Detections exist for new keys or credentials added to an existing identity, and for changes to federation trust policies. | Detection rule list and last alert or test | NHI5, NHI6 |
| MON-04 | Alerts on NHI activity route to a team that can act, and a playbook names who revokes what. | Alert routing configuration; playbook | NHI2 |
| MON-05 | Canary or honeytoken credentials are placed where attackers look, and their use raises a high-priority alert. | Canary register and last test | NHI2 |
The OWASP Secrets Management Cheat Sheet recommends alerting when a secret is used from an unexpected IP address or user agent and treating that as a compromise. The ATT&CK techniques most relevant to these detections are Valid Accounts: Cloud Accounts (T1078.004), Steal Application Access Token (T1528), Application Access Token (T1550.001) and Credentials In Files (T1552.001). See Detection Engineering for Non-Human Identities Guide, the Service Account Behavioural Baselining Guide and the Honeytokens and Canary Credentials Guide.
9. Third-party and supply chain NHIs
| ID | Check | Evidence to keep | OWASP NHI risk |
|---|---|---|---|
| TPN-01 | Credentials and tokens issued to suppliers, SaaS integrations and managed service providers are listed with the supplier, scope and contract owner. | Third-party NHI register | NHI3 |
| TPN-02 | Supplier due diligence asks how the supplier stores, rotates and monitors the credentials you give it. | Completed questionnaire for the top suppliers by access | NHI3 |
| TPN-03 | You can revoke every credential held by a supplier within hours if the supplier reports a breach. | Revocation runbook per supplier; last exercise | NHI3 |
See Third-party NHI due diligence questions drawn from real breaches.
10. Dormancy, offboarding and decommissioning
| ID | Check | Evidence to keep | OWASP NHI risk |
|---|---|---|---|
| OFF-01 | NHIs and credentials unused for a set period (for example 90 days) are flagged, confirmed with the owner, then disabled. | Dormancy report and actions taken | NHI1 |
| OFF-02 | Decommissioning an application or service includes disabling and then deleting its NHIs and revoking every credential, not only removing the code. | Decommissioning procedure step; last three retirements | NHI1 |
| OFF-03 | Disabled identities are deleted after a holding period, and their credentials are confirmed revoked at the issuer. | Deletion log with revocation confirmation | NHI1 |
| OFF-04 | When a person leaves, credentials they created or know (shared keys, personal access tokens used by automation) are found and rotated. | Leaver checklist step and evidence for recent leavers | NHI1, NHI10 |
NIST SP 800-53 AC-2(3) Disable Accounts covers disabling accounts that are no longer required or have been inactive for a set period. See NHI Dormancy Detection and the NHI Offboarding and Decommissioning Guide.
11. Findings and sign-off
| Finding ID | Check ID | Description | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| NHICL-01 | [e.g. LPV-01] | [e.g. 4 CI service principals hold subscription owner] | [Critical / High / Medium / Low] | [Owner] | [Date] | [Open / In progress / Closed / Risk accepted] |
| NHICL-02 | [Check ID] | [Description] | [Severity] | [Owner] | [Date] | [Status] |
Suggested due dates: critical within 7 days, high within 30 days, medium within 90 days. A live credential found exposed during the review is an incident, not a finding: revoke it first. Sign-off: [Checklist owner], [Date]; approved by [Approver], [Date].
Implementation guidance
- Start narrow: run the checklist first on one high-value scope, such as the production cloud organisation or the CI/CD platform that deploys to it. A whole-estate first run produces a list of Fails nobody can own.
- Fix the order of work: inventory (section 2) and ownership (section 3) come first, because every later check needs to know what exists and who decides. Then exposed and long-lived credentials (section 4), then administrative roles (LPV-01), then the rest.
- Sample, then automate: on the first run, evidence will be manual samples. Each later run should replace a sample with a query or export, so the checklist becomes cheaper and harder to game.
- Do not break production to pass a check: disable before you delete, rotate with overlap, and remove permissions after a period of watching what is used. Keep a rollback record for every change made to close a finding.
- Feed the results into metrics: once checks pass reliably, track them as rates in the NHI Programme Health Check, and use the NHI Programme Roadmap to sequence what remains.
Small and large organisations: a small team can run sections 2 to 10 from cloud console exports and a spreadsheet in a few days, and should focus on CRD-01, LPV-01, AUT-01 and OFF-01. A large organisation will need automated discovery and a platform to hold the inventory; the NHI management platform rollout playbook covers that rollout.
Framework mapping
| Section | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 |
|---|---|---|---|
| 2. Inventory and discovery | CM-8, AC-2 | ID.AM-02, PR.AA-01 | Safeguard 5.5 |
| 3. Ownership | AC-2, IA-4 | GV.RR-02, PR.AA-01 | Control 5 |
| 4. Credentials and rotation | IA-5, IA-5(7), SC-12 | PR.AA-01, PR.DS-01 | Control 5 |
| 5. Least privilege | AC-6, AC-2 | PR.AA-05 | Control 6 |
| 6. Authentication and federation | IA-9, IA-5 | PR.AA-01, PR.AA-03 | Control 6 |
| 8. Monitoring and detection | AU-2, AU-6, SI-4 | DE.CM-03, DE.CM-09 | Control 8 |
| 9. Third parties | SA-9, SR-3 | GV.SC-07 | Control 15 |
| 10. Offboarding | AC-2(3) | PR.AA-01 | Control 5 |
Standards and references
- OWASP: Non-Human Identities Top 10 (2025)
- OWASP: Secrets Management Cheat Sheet
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- CIS: Critical Security Controls v8.1
- MITRE ATT&CK: Valid Accounts: Cloud Accounts (T1078.004)
- MITRE ATT&CK: Account Manipulation: Additional Cloud Credentials (T1098.001)
Related NHI Mgmt Group resources: NHI Policy Template · NHI Programme Health Check · Service Account Inventory Template · Top 10 NHI Risks