The standard never says non-human identity, and five Annex A controls land on them anyway. The gap worth knowing about is that none of them anticipated an identity that chooses its own next action.
Published Last reviewed
The standard is deliberately technology-neutral, which is why these apply cleanly. The work is evidence, not interpretation.
The access control policy, provisioning, privileged access and the review and removal of access rights. None of these says human, and a service account that nobody reviews is a finding under any of them.
The full lifecycle of identities. For machine identities this is the control that is hardest to evidence, because most organisations have no creation or removal process for them at all.
How secrets are issued, stored and changed. Static API keys with no rotation sit directly under this one, and a vault satisfies the storage half while leaving the rotation half open.
Security in supplier agreements and service delivery monitoring. An OAuth grant to a vendor AI tool is a supplier relationship holding your data, whether or not it went through procurement.
Restriction of privileged access rights and of access to information. This pair is where agent reach belongs, because it is about what an identity can get to rather than what it was assigned.
The third column is the usual gap, and it is the same gap in most organisations.
| What an auditor asks | What satisfies it | Where teams come up short |
|---|---|---|
| Who owns this identity? | A named person in a system of record. | A team name, or nobody. |
| What is it allowed to do? | Direct permissions and assumable roles. | Only the direct permissions are listed. |
| When was that last reviewed? | A dated review with a decision. | A policy saying reviews happen. |
| How is it revoked? | A tested procedure, with evidence. | A procedure nobody has run. |
| How are its secrets rotated? | Rotation dates, or short-lived credentials. | A vault, with no rotation. |
Step one is not paperwork. Without it the other three produce evidence that does not survive a question.
Every other control depends on it. Review, revocation and approval all need somebody who can answer, and without that the evidence cannot exist.
A.8.2 is about what the identity can reach. Listing assigned roles without the roles they can assume understates it, and an auditor who asks one follow-up question will find that out.
A procedure nobody has run is not a control. Revoke something in a controlled way, record what broke, and keep that record.
The standard does not cover identities that choose their own actions. Rather than pretending it does, name it as a risk with the compensating controls you actually use.
Short answers on iso 27001 and non-human identities.
Not by name, and yes in substance. The access control, identity management, authentication information and supplier relationship controls in Annex A are written technology-neutrally, so a service account or an API key falls under them exactly as a staff account does.
Something a reviewer can inspect rather than a policy: the identity owner, its approved purpose, its effective access including roles it can assume, the date of the last review, and a revocation procedure that has actually been tested.
No. This page describes how the controls land on machine identities, which is the part a security team acts on. Scope, applicability and what your specific auditor expects are questions for your lead auditor and your counsel.
The pages that belong to the same picture.
Book a demo and we walk through the access paths in an environment like yours.