When the certification scope is broader than the identities that actually create risk, or narrower than the systems that issue credentials. In that case, the organisation may be certified while service accounts, keys, and tokens remain outside the day-to-day governance model. Scope discipline matters as much as control design.
Where ISO 27001 scope stops short of the identities that matter
iso 27001 can leave NHI gaps unaddressed when the ISMS scope is written around the organisation chart, a business unit, or a generic application boundary instead of the credential-issuing systems and runtime identities that actually create exposure. That is especially common when service accounts, API keys, tokens, and certificates are owned operationally but not folded into the same review, approval, and exception process as user access.
A certification scope can therefore look complete on paper while the identities that drive machine-to-machine access remain weakly governed. That mismatch is not a failure of the standard so much as a scoping failure by the organisation.
Why control design does not fix a bad boundary
ISO 27001 is strongest when the scope includes the systems, teams, and records needed to govern access end to end. If credential issuance sits in a platform team, but review lives in a separate audit cycle, the control may exist without the day-to-day operational ownership needed to keep it current. In practice, the standard can support better governance, but it does not force the organisation to include every risky non-human identity unless the scope statement and control catalogue do that work.
The same problem appears when the certification boundary is narrower than the technical environment. A team may certify the central IAM or ISMS function, yet leave cloud automation, integration accounts, or application-local secrets outside routine oversight. The result is partial assurance, not full identity governance, and ISO/IEC 27001:2022 Information Security Management can only govern what the organisation has actually brought into scope.
That is why scope discipline matters as much as control design. The most useful question is not whether the control family exists somewhere in the ISMS, but whether the identities that can authenticate, act, and persist are subject to the same governance path as other material assets.
How to spot the gap before certification becomes a false comfort
The warning sign is a split between formal certification and operational reality: identities are issued, reused, rotated, and revoked by different teams, but only some of those activities are covered by the audited scope. When that happens, the organisation may still pass surveillance while missing the accounts and secrets most likely to accumulate privilege or drift out of ownership. NHIMG’s Service Account Security Guide is useful here because service accounts often expose the exact boundary problem, they are technically critical, but administratively invisible.
Another common signal is scope wording that focuses on “systems supporting the business” without naming the credential lifecycle, source-of-truth systems, or exception handling for machine access. When that wording is vague, the control model may omit the hardest part: proving who owns the account, who can approve its use, and who can force rotation or removal when the application changes.
Teams should also watch for a mismatch between cloud or SaaS reality and the ISMS evidence set. If keys and tokens are created in one environment, used in another, and reviewed only at the policy level, the organisation may never test the controls that matter most to NHI governance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.15 — Access Control | Access control only matters here if the scoped ISMS covers the identities that actually issue access. |
| A.8.5 — Secure Authentication | Authentication gaps for service accounts and tokens create the NHI gap this question asks about. | |
| A.5.23 — Information security for use of cloud services | Cloud-hosted identity and secret systems often sit where scope boundaries get missed. | |
| Recommendation — Include all credential-issuing systems in scope and apply access controls consistently to them. Verify that non-human authenticators are governed, rotated, and reviewed inside the ISMS scope. Bring cloud credential-issuing and secret-management services into the ISMS boundary and evidence set. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle control is central when service accounts, keys, and tokens fall outside governance. |
| IA-9 — Service Identification and Authentication | Machine and service identities are the gap when ISO 27001 scope misses non-human access paths. | |
| Recommendation — Manage issuance, rotation, and revocation for all authenticators in scope. Apply service-to-service authentication controls to every machine identity that can access production. | ||
Practitioner Guidance
What to prioritise: Start with the boundary, not the control library. Map which systems issue, store, rotate, and revoke credentials, then verify that each one sits inside the governance loop with a named owner and an auditable review path.
What to verify: Confirm that service accounts, API keys, tokens, certificates, and any secret-management platform are included in the scope statement, the asset inventory, and the internal audit evidence set. If they are only mentioned in architecture diagrams, the control model is probably too weak.
Common mistake: Treating certification as proof that every access path is governed equally. A strong ISO 27001 programme can still leave material NHI exposure if the operational identity layer sits outside routine oversight or exception handling.
Practitioner takeaway: For ISO 27001, the real test is whether the scope follows the credential lifecycle and the systems that issue access, not just the business perimeter on the organisation chart.