Almost every non-human identity problem traces back to one missing fact: who owns it? Without an owner, nobody reviews a service account's privileges, rotates an API key, answers an alert or decides when an integration should be switched off. Owners leave, teams reorganise and applications change hands, while the service accounts, keys, OAuth apps, certificates and AI agents they created keep running. This guide explains why ownership fails for NHIs, what an owner is accountable for, how to assign owners at creation and recover them for existing identities, how to handle orphans safely and how to measure coverage. It is written for IAM and identity governance teams, platform and cloud engineers, application owners and the risk and audit functions that rely on ownership records.
Key takeaways
- Ownership is the control that enables every other control. Reviews, rotation, incident response and decommissioning all need a named person who can decide and act.
- Separate accountability from administration. A business owner (or sponsor) answers for why the identity exists; a technical owner answers for how it is configured; a backup covers absence. Microsoft Entra Agent ID builds the same split into AI agent identities.
- Capture ownership at creation and enforce it in code. Templates, tag policies and request forms that refuse to create an identity without an owner, purpose and review date are cheaper than finding owners later.
- Tie ownership to joiner-mover-leaver events. OWASP's NHI1 Improper Offboarding exists largely because NHIs outlive the people who created them; the Coupang and Cloudflare incidents show the cost.
- Orphans get a deadline, not a debate. Reassign, notify, restrict, disable, then decommission, always disabling before deleting so a hidden dependency can be restored.
Why ownership fails for NHIs
Human accounts have a natural owner: the person who uses them, managed by HR events. Non-human identities have none of that by default.
- Creation is decentralised: developers, platform teams, SaaS admins, low-code builders and now AI agents all create identities, often with no record of who did or why.
- Creators are not owners: in Microsoft Entra ID, the user who registers an application is automatically its owner, but Microsoft notes that in most other scenarios ownership of an enterprise application is not assigned by default.
- Organisational change: reorganisations and staff turnover leave NHIs attached to departed people or dissolved teams.
- Shared use: one identity used by several applications (OWASP NHI9 NHI Reuse) has no single owner, so nobody feels responsible.
- Unclear knowledge transfer: OWASP describes a developer leaving after building a business-critical application; ownership moves to a new team, but nobody understands that it relies on an access key, which "remains active and unnoticed".
- Volume: NHIs far outnumber people, so manual assignment and spreadsheet tracking do not scale.
The industry data is consistent. OWASP's NHI1 page cites a Cloud Security Alliance NHI report in which orphaned identities were the cause of NHI-related security incidents 32% of the time, and 51% of organisations had no formal process to offboard or revoke long-lived API keys. See the Human vs Non-Human Identity overview.
Incidents show the cost. In the Coupang Breach 2025, The Record reports that a former employee who had developed the company's alternative authentication system stole its signing key before leaving at the end of 2024, then used it to access data for millions of accounts; Coupang says he took the key while still employed. In the Cloudflare Thanksgiving Breach 2023, Cloudflare failed to rotate one service token and three service accounts after the Okta compromise because "mistakenly it was believed they were unused".
What an owner is accountable for
| Role | Accountable for | Typical holder | Must not be |
|---|---|---|---|
| Business owner (sponsor) | Why the NHI exists; approving its access; accepting its risk; deciding when it is no longer needed | Application or product owner, service manager | A shared mailbox or a departed employee |
| Technical owner | Configuration, credentials, rotation, dependencies, alert and incident response | Engineer or platform team lead for the consuming workload | The only person who knows the secret |
| Backup owner | Covering absence and taking over when the primary owner leaves | Another member of the owning team | The same person as the primary |
| Owning team | Continuity: a stable contact even when individuals change | Team or cost centre recorded in the CMDB | A substitute for named individuals |
Ownership should be held by named individuals, backed by a team, rather than by a team alone: a team mailbox cannot approve a review. Microsoft recommends at least two owners for enterprise applications where possible and using the serviceManagementReference property to point to the team record in your asset or service management database, "even if an individual leaves". Remember that ownership is itself a privilege: Microsoft warns that an application can have more permissions than its owner, so an owner can act beyond their own rights by impersonating the application. Keep owner lists short and review them.
Assigning owners at creation
The cheapest moment to record ownership is before the identity exists. Define a minimum record and make creation fail without it.
| Field | Why | Where it is required |
|---|---|---|
| Business owner and technical owner | Who decides and who acts | Microsoft's service account guidance lists "Owner: The person accountable for maintaining the account" |
| Purpose and consuming application | Lets a reviewer judge need | CIS Safeguard 5.5 requires purpose in the service account inventory |
| Owning department or team | Continuity when individuals change | CIS Safeguard 5.5 requires department owner |
| Review date and expected lifetime | Forces recertification | CIS 5.5 requires review date; Microsoft adds anticipated lifetime and periodic attestation |
| Permission scope and risk rating | Prioritises reviews | Microsoft lists permission scopes and risk profile |
| Credential type and location | Rotation and leaver handling | Secrets manager reference, never the secret itself |
- Request forms: require owner, backup owner, purpose and review date for every new service account, API key, OAuth app, certificate or AI agent.
- Infrastructure as code: modules and platform templates that refuse to create identities without owner tags. See the Infrastructure as Code Security Guide.
- Cloud policy: AWS IAM can use the
aws:RequestTagcondition key to control which tags are passed when a resource is created, and AWS Organizations tag policies can enforce tag values on specified resource types. Google Cloud recommends a naming convention and using a service account's description field for "a contact person, links to relevant documentation, or other notes". - Naming: prefixes such as
svc-(Microsoft) orvm-andwlif-(Google Cloud) make service accounts findable. - Code ownership: a GitHub
CODEOWNERSfile defines who is responsible for code and can require their approval for changes, which links identity definitions in code to an accountable team.
See the Service Account Inventory Template.
Finding owners for existing NHIs
For the backlog, no single signal is reliable. Combine several, score confidence and ask the most likely owner to confirm.
| Signal | Source | Reliability and caveat |
|---|---|---|
| Creator | Audit logs, object metadata, app registration owner | Good lead, but creators move on; Microsoft notes audit log retention limits |
| Consuming workload | Authentication logs, host or IP, workload identity bindings | Strong: the application owner in the CMDB is usually the right business owner |
| Code references | Repositories, CI variables, CODEOWNERS | Strong for technical ownership |
| Tags, names, descriptions | Cloud tags, naming prefixes, description fields | Only as good as past discipline |
| Last change or rotation | Change records, secrets manager history | Shows who maintains it, not who is accountable |
| Account, subscription or project owner | Cloud organisation hierarchy | Fallback only: too broad to be the final owner |
| Delegated role holders | Roles and administrators assigned to the app | Microsoft suggests checking these for ownerless apps |
Route high-confidence matches to the candidate to accept; route low-confidence ones to the account or application owner to reassign. Record who confirmed and when, so the next review starts from evidence. See the Identity Data Quality Guide and the Service Account Security Guide.
Keeping ownership current
NIST SP 800-53 AC-2 requires organisations to assign account managers, notify them when accounts are no longer required or users are terminated or transferred, and "align account management processes with personnel termination and transfer processes". Apply that to NHI owners as well as to users.
- Leavers: when an owner leaves, reassign their NHIs automatically to the backup owner or their manager, with a deadline to confirm. OWASP recommends reviewing all NHIs associated with departing employees, transferring ownership where still needed and rotating any credentials the person had access to. See the Joiner-Mover-Leaver Guide.
- Movers: when an owner changes role, prompt them to hand over NHIs that belong to their old area.
- Reorganisations: reassign in bulk using application-to-team mappings.
- Periodic attestation: CIS Safeguard 5.5 calls for service account reviews at least quarterly; owners confirm ownership, need and privilege. See the Access Reviews Guide.
- Secrets tied to people: when someone who could read a secret leaves, rotate it. The Coupang key and Okta's support service account, whose password had been saved to an employee's personal Google profile, show why. See the Secrets Rotation Runbook Template.
Ownership for AI agents
AI agents act with delegated authority, can be created quickly by business users and may spawn other agents, so ownership is even more important than for service accounts. Record ownership in the agent registry before any credential is issued, and give each agent:
- A business sponsor accountable for its purpose, access and retention. Microsoft Entra Agent ID requires at least one sponsor for each agent identity and describes sponsors as business representatives who decide on renewal, extension or removal, without technical admin access.
- Technical owners who handle configuration and credentials; Entra allows several owners for backup coverage.
- A succession rule: Microsoft says sponsorship "should be maintained to ensure succession when an employee who's a sponsor moves or leaves".
- An incident role: sponsors can judge whether agent behaviour is expected and authorise suspension or permission changes.
- An expiry date and review cycle, so experimental agents do not become permanent.
See the Agentic AI Identity Guide, the Identity Governance for AI Agents Guide and the Shadow AI Discovery Guide.
Handling orphaned NHIs
An orphaned NHI is one whose owner is missing, departed or unconfirmed. Treat it as a risk with a deadline. The timings below are examples; set your own in policy and shorten them for privileged identities.
- Flag NHIs whose owner is missing, departed or unconfirmed, prioritising privileged and externally reachable ones.
- Attempt automatic reassignment using the signals above.
- Notify the likely team with a deadline to claim (for example 14 days).
- Restrict: if unclaimed, reduce privilege or rotate the credential and hold it in escrow, with a documented rollback path.
- Disable: if still unclaimed, disable the identity and watch for failures.
- Decommission after a defined quiet period (for example 30 to 90 days) with no breakage or claims.
Disabling before deleting matters. Google Cloud explains that if you delete a service account and create a new one with the same name, it gets a different identity and none of the original IAM bindings apply, whereas a disabled account can be re-enabled with its bindings intact. Orphans are also a favoured attack route: in the Microsoft Midnight Blizzard Breach 2024, Microsoft reports that the attackers compromised a legacy non-production test tenant account without MFA, then a legacy test OAuth application "that had elevated access to the Microsoft corporate environment". See the SaaS and OAuth App Governance Guide.
Measuring ownership
| Metric | What it shows | Target direction |
|---|---|---|
| NHIs with a valid, current owner, by type and platform | Overall coverage | Up |
| Privileged NHIs with a valid owner and backup | Coverage where it matters most | Up, to 100% |
| NHIs owned by departed staff, and median days to reassign | Strength of the leaver process | Down |
| New NHIs created without required ownership fields | Whether creation controls work | Down, towards zero |
| Ownership attestations completed on time | Owner engagement | Up |
| Orphaned NHIs disabled or decommissioned per quarter | Backlog reduction | Up while a backlog exists |
| AI agents with a sponsor and expiry date | Agent governance | Up, to 100% |
See the Identity Security Metrics Guide.
Framework mapping
This is an indicative NHI Mgmt Group alignment, not an official mapping. Control IDs were checked against NIST CSWP 29 (CSF 2.0), the NIST SP 800-53 Rev. 5 OSCAL catalogue, the CIS Controls assessment specification and a published ISO/IEC 27001:2022 Annex A list.
| Ownership practice | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 | OWASP NHI Top 10 |
|---|---|---|---|---|---|
| Defined owner roles and accountability | GV.RR-02 | AC-2 (b) | A.5.2 | 5 | NHI1 |
| Inventory with owner, purpose, review date | ID.AM-02, PR.AA-01 | CM-8, CM-8(4) | A.5.9, A.5.16 | 5 | NHI1 |
| Lifecycle and leaver handling | ID.AM-08 | AC-2 (h), AC-2 (l), PS-4, PS-5 | A.5.18, A.6.5 | 5, 6 | NHI1 |
| Periodic attestation of need and privilege | PR.AA-05 | AC-2 (j), AC-6(7) | A.5.18 | 5, 6 | NHI5 |
| Orphan disablement and decommissioning | PR.AA-01 | AC-2(3) | A.5.18 | 5 | NHI1 |
| Credential rotation on owner change | PR.AA-01 | IA-5, AC-2 (k) | A.5.17 | 5 | NHI7 |
CM-8(4) Accountability Information is the closest single control: it asks for a way to identify the individuals "responsible and accountable for administering" components. See the NHI Governance Maturity Model.
Common failure patterns
- Team-only ownership: the owner field says "Platform Team", so every review and alert goes to a queue that nobody is accountable for.
- Creator equals owner, forever: ownership is never revisited after the creator moves on, so the record points to a departed account.
- Offboarding that stops at the person: the leaver's user account is disabled but the keys, tokens and signing material they could read stay valid, as in the Coupang case.
- "Believed unused" without evidence: credentials are skipped during rotation because nobody owns the question; Cloudflare's attackers got in through exactly those.
- Test and legacy identities outside governance: non-production apps with production reach, as in Midnight Blizzard.
- Deleting orphans immediately: a quiet dependency breaks, the identity is recreated with broader rights and loses its history.
- Agents created by anyone, owned by no one: low-code and copilot agents built in business teams without a sponsor or expiry date.
Implementation roadmap
| Phase | Actions | Exit criteria |
|---|---|---|
| First 30 days | Agree owner roles and the minimum record; publish the policy; inventory privileged NHIs and find owners for them first; connect HR leaver events to an NHI ownership report | Every privileged NHI has a confirmed owner and backup |
| Days 31 to 90 | Enforce owner tags in IaC templates and request forms; run signal-based owner discovery for the rest; start the orphan workflow; include ownership in quarterly reviews | No new NHI created without ownership fields; orphan backlog measured and falling |
| Days 91 to 180 | Automate reassignment on leaver and mover events; rotate secrets on owner change; require sponsors and expiry dates for AI agents; report ownership metrics to risk committees | Ownership coverage above agreed target; leaver reassignment within policy time |
Practitioner checklist
- Define business, technical and backup owner roles for NHIs and AI agents.
- Set a minimum ownership record: owners, purpose, team, review date, scope, credential location.
- Require owners at creation and enforce it in templates, tag policies and request forms.
- Find owners for existing NHIs using several signals, privileged identities first, then confirm.
- Link NHI ownership to HR joiner-mover-leaver events and reassign automatically.
- Rotate secrets a departing owner could access.
- Include ownership confirmation in quarterly service account reviews.
- Run a documented orphan process: reassign, notify, restrict, disable, decommission.
- Disable before deleting, with a rollback path.
- Give every AI agent a sponsor, owners and an expiry date.
- Track ownership coverage and leaver reassignment time as key metrics.
Standards and references
- OWASP: Non-Human Identities Top 10 (2025)
- OWASP: NHI1:2025 Improper Offboarding
- NIST: Cybersecurity Framework (CSF) 2.0
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
- CIS: Controls Assessment Specification, Safeguard 5.5 Inventory of Service Accounts
- Microsoft Learn: Introduction to Active Directory service accounts
- Microsoft Learn: Overview of enterprise application ownership in Microsoft Entra ID
- Microsoft Learn: Owners, sponsors and managers in Microsoft Entra Agent ID
- Google Cloud: Best practices for using service accounts securely
- AWS: Tag policies in AWS Organizations
- GitHub Docs: About code owners
Related NHI Mgmt Group resources: NHI Lifecycle Management Guide · Service Account Security Guide · NHI Governance Maturity Model · Ultimate Guide to Non-Human Identities