Ownership should sit with the business or technical team that can validate the identity’s purpose and accept the risk of continued access, with IAM or IGA providing the control framework. If the reviewer cannot explain why the identity exists, the attestation model is too detached from operations.
Where NHI attestation ownership belongs
Ownership belongs with the team that can answer the two operational questions that matter most: what the identity is for, and whether that purpose still justifies access. In practice that is usually the application owner, service owner, platform team, or another technical business owner, with IAM or IGA defining the review process and evidence standard. NHI Ownership and Accountability Guide
That division keeps attestation close to the system that uses the identity. If the reviewer cannot explain the workload, integration, or business function behind the account, the review becomes box-ticking instead of a risk decision. IAM can coordinate and enforce the control, but it should not be the sole owner of the judgment on continued need.
Why IAM should not own the decision alone
IAM teams are well placed to run the control, define cadence, collect evidence, and flag overdue reviews. They are not usually the best authority on whether a service account, API credential, or workload identity is still required in production. That decision depends on system context, change ownership, and whether the access is still aligned to an active service, integration, or environment. IAM and IGA Basics
The practical failure mode is centralisation without context. When attestation sits too far from the business or technical owner, reviewers tend to approve by default, rely on stale ticket history, or treat unknown identities as someone else’s problem. Keeping the decision with the closest accountable owner improves the quality of the review and makes exceptions easier to challenge.
For NHI programmes, the best model is usually a split one: IAM or IGA runs the governance workflow, while the owning team confirms purpose, validates ongoing need, and accepts or rejects continued access. The result is stronger accountability, fewer orphaned identities, and a cleaner line between control operation and operational judgement. Ultimate Guide to NHIs
What good attestation ownership looks like in practice
A workable ownership model names a primary owner, a backup owner, and the system or service scope they are responsible for. The attestation request should show enough context for that owner to decide, including the identity name, intended use, last activity, privilege level, and downstream systems affected. Identity Security Programme Guide
Where identities support production workloads or cross-team integrations, ownership should usually stay with the team that can fix the dependency if access is no longer valid. That is the team best placed to answer whether the identity can be rotated, removed, narrowed, or left in place. For shared platforms, the platform team may own the control, but each consuming application or service owner should still own the attestation response for their own scope.
Auditability matters here as much as ownership. A strong model preserves who approved what, on what basis, and with what exception path if the reviewer needed to defer. That makes later recertification faster and gives security teams a defensible record when access is challenged or investigated. Ultimate Guide to NHIs
Risk and Threat Considerations
When attestation ownership is detached from the team that understands the identity’s purpose, stale access tends to survive longer than it should. The risk is not only overprivilege, it is also false confidence: a completed review can look compliant while no one has actually confirmed why the identity still exists. Ultimate Guide to NHIs
Failure mechanism: central IAM ownership turns attestation into an administrative check, so approvals are made without enough system context to detect obsolete integrations, shared use, or access that outlived the service it supports.
Impact: dormant or excessive NHI access persists, expanding blast radius for misuse, compromise, or laterally moving activity, while the programme records a review that does not actually reflect operational reality.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | NHI attestation is an access review and ownership control problem. |
| Recommendation — Assign accountable owners and review account access on a recurring cadence. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Attestation confirms continued need for accounts and their ongoing authorization. |
| AU-6 — Audit Review, Analysis, and Reporting | Attestation needs evidence and traceable approvals for later review. | |
| Recommendation — Review account necessity, assign owners, and remove accounts that no longer have a valid purpose. Retain review evidence and analyze exceptions, overrides, and overdue certifications. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Ownership decisions govern who can retain access and under what conditions. |
| A.5.18 — Access rights | NHI attestation is a periodic decision about continuing access rights. | |
| Recommendation — Define access ownership and approval authority for ongoing account use. Recertify access rights and revoke those no longer justified. | ||
Practitioner Guidance
What to verify: Make sure every attestation item has a named owner who can explain the identity’s function, the service or application it supports, and the consequence of removing it. If that owner cannot answer, the item needs reassignment or remediation, not approval.
Decision rule: If the account is tied to a specific workload, integration, or platform service, route the attestation to that owning team and require IAM to validate process and evidence only. If the account is genuinely cross-functional or ownerless, treat it as an exception and force a separate remediation path.
Practitioner takeaway: The best ownership model puts the access decision closest to the operational truth, while IAM keeps the review disciplined, repeatable, and auditable.