TL;DR
- Certifiable, ratified, and already held by many organisations: which makes it the cheapest available anchor for NHI evidence.
- About a dozen Annex A controls carry the weight, clustered in identity and access management (A.5.15 to A.5.18, A.8.2 to A.8.5), cryptography (A.8.24) and supplier relationships (A.5.19 to A.5.23).
- Every control terminates in an artefact. A control that produces no export cannot be tested and will be treated as absent.
- The Statement of Applicability is where NHI scope is silently lost, because controls are justified against a human-shaped reading.
- The recurring finding is not missing controls. It is access reviews that cover humans and silently exclude machine accounts.
Why 27001 is the cheapest anchor available
Most organisations pursuing non-human identity governance already hold ISO/IEC 27001, or are within reach of it. That matters more than the standard's technical fit: the management system machinery. Scope, risk methodology, documented information control, internal audit, management review, corrective action. Is already operating, and extending it to a new asset class is far cheaper than establishing it.
It is also the anchor a procurement team recognises. "We govern non-human identities" is unverifiable. "Our ISO/IEC 27001 scope includes machine credentials, and here is the relevant SoA extract" is checkable. See ISO/IEC 42001 for the AI-specific counterpart, and the framework comparison for how they relate.
Control-by-control mapping
This is our practical reading, not text from the standard. ISO/IEC 27001 does not name non-human identities; the mapping reflects where auditor questions land when machine credentials are in scope.
| Annex A control | Substance | NHI artefact an auditor asks for |
|---|---|---|
| A.5.9 Inventory of information and other associated assets | Know what you have | Non-human identity inventory as a dated export with owner, purpose and system reached. This is where the NHI programme formally lands. |
| A.5.15 Access control | Policy governing access | Policy that explicitly addresses non-human accounts, credential lifetime by risk tier, and exception handling |
| A.5.16 Identity management | Full lifecycle of identities | Provisioning and decommissioning records for machine identities, and evidence the retirement trigger fires |
| A.5.17 Authentication information | Allocation and management of secrets | Secrets handling: where stored, how issued, rotation records for a sampled set with timestamps |
| A.5.18 Access rights | Provision, review, revoke | Access review records including non-human accounts, with reviewer, decision and executed revocations |
| A.5.19 to A.5.23 Supplier and cloud services | Third-party risk | Register of credentials held by suppliers and of third-party OAuth grants into your estate, with scope and review date |
| A.8.2 Privileged access rights | Restrict and monitor privilege | Which machine identities hold privileged access, justification, and monitoring evidence |
| A.8.3 Information access restriction | Least privilege in practice | Granted permissions compared to permissions exercised; the diff is the finding |
| A.8.5 Secure authentication | Authentication strength | Which machine accounts authenticate with a single static factor and from where they are reachable |
| A.8.9 Configuration management | Controlled configuration | Evidence credentials are not hardcoded in configuration or images |
| A.8.24 Use of cryptography | Key management | Certificate and key inventory with algorithm, key size and expiry. See post-quantum migration. |
| A.8.15/A.8.16 Logging and monitoring | Record and detect | Logs attributing actions to a specific non-human identity, retained for the audit period |
Where scope is silently lost: the Statement of Applicability
The SoA records which Annex A controls apply and how they are implemented. It is written once, reviewed lightly thereafter, and it is where non-human identity most often falls out of scope without anyone deciding it should.
The mechanism is mundane. A.5.18 is justified with a description of the quarterly user access review. That description is accurate, the control is implemented, and it covers only human accounts, because that is what the reviewing process was built for. Nothing in the SoA is false, and machine identities are outside the certified control without a single incorrect statement being made.
The SoA test
Read your Statement of Applicability and, for each access-related control, ask: does the implementation description, as written, cover service accounts, API keys, OAuth grants and workload credentials? If it describes a process built around people, the answer is no, and you have found the gap before your auditor does. Correcting the SoA wording is cheap; being told at surveillance is not.
Four findings that recur
- Access reviews exclude non-human accounts. Near-universal, and usually a configuration decision nobody made rather than a policy gap. See auditing NHI.
- Asset inventory omits credentials. A.5.9 is satisfied with a hardware and software inventory, and the credentials that access those assets are nowhere.
- Rotation is asserted, not evidenced. "Secrets are rotated automatically" is a statement. Rotation logs for a sampled set with timestamps are evidence, and the distinction is the entire finding.
- Third-party grants are invisible. A.5.19 to A.5.23 are evidenced with supplier contracts and due-diligence records, while the OAuth grants those suppliers hold into your SaaS estate appear in no register.
What to have ready
Five artefacts cover most of what will be requested:
- A dated inventory export of non-human identities with owner, purpose, credential type and expiry.
- Access review records for the certification period showing non-human accounts in the population, with executed revocations.
- Rotation evidence for a sampled set: actual events, actual timestamps.
- A third-party grant register with scope and review dates.
- An exception register with named approver and expiry for every identity that cannot meet policy.
If a control in your SoA does not terminate in one of these or something like it, it will not survive testing regardless of how well it is described.
Frequently asked questions
Does ISO/IEC 27001 cover non-human identities?
Not by name. The standard does not use the term. Roughly a dozen Annex A controls apply in substance, clustered in identity and access management (A.5.15 to A.5.18 and A.8.2 to A.8.5), cryptography and key management (A.8.24), supplier relationships (A.5.19 to A.5.23), and asset inventory (A.5.9). The mapping is derived rather than stated, which affects how you evidence it but not whether it applies.
Where does non-human identity fall out of ISO 27001 scope?
In the Statement of Applicability. Controls such as A.5.18 on access rights get justified with a description of the quarterly user access review, which is accurate and covers only human accounts because that is what the process was built for. Nothing in the SoA is false and machine identities end up outside the certified control without anyone deciding they should. Read each access-related control's implementation description and ask whether it covers service accounts, API keys and workload credentials as written.
What is the most common NHI finding in an ISO 27001 audit?
Access reviews that cover human accounts and silently exclude non-human ones. The review process was designed for people and never extended, so service accounts, API keys, OAuth grants and workload credentials are never recertified. It is usually a configuration decision nobody made rather than a policy gap, which makes it straightforward to remediate once identified.
What evidence does an auditor want for machine identity controls?
Five artefacts cover most requests: a dated inventory export with owner, purpose, credential type and expiry; access review records for the period showing non-human accounts in the population with executed revocations; rotation evidence for a sampled set with actual timestamps rather than an assertion that rotation happens; a register of third-party OAuth grants and supplier-held credentials with scope and review dates; and an exception register with named approver and expiry.
Should we use ISO 27001 or ISO 42001 for AI agent identity?
Both, for different things. ISO/IEC 27001 is the anchor for non-human identity generally, including the service accounts, secrets and certificates that agents also depend on. ISO/IEC 42001 addresses the AI management system specifically, and is where agent-level evidence such as delegation records and human oversight lands. Organisations with 27001 already hold most of the management system machinery 42001 requires.
Would your NHI evidence hold in a certification audit?
The controls usually exist. The evidence usually does not. HumanAudit runs readiness reviews that test what you could actually produce on request, against ISO/IEC 27001, 42001 and SOC 2.