Most service accounts were created by someone who has since moved on, and once nobody owns an account nobody rotates it, reviews its rights or notices when it is misused. This page is the working procedure for giving every ownerless service account a named, confirmed owner: build the orphan list, gather creator and consumer evidence from Active Directory, Microsoft Entra ID, AWS and Google Cloud, score it, run a claim round with a deadline, record the owner where tools and auditors can read it, and contain what nobody claims without breaking production. It is for identity, IAM and platform teams running a clean-up, and for auditors checking one. For what an owner is accountable for, see the NHI Ownership Guide; for how orphans are defined and found by correlation, see Orphaned and Dormant Accounts. This page does the assignment work in between.
This is an independent guide from NHI Mgmt Group, based on Microsoft, AWS and Google Cloud public documentation as checked in November 2026. Confirm settings and retention periods against current vendor documentation.
Key takeaways
- The creator is evidence, not the answer. The person who created an account is often the wrong owner today. Weight current consumers (which application, host or pipeline uses it) above historical creators.
- Creation logs expire fast. AWS CloudTrail event history covers 90 days and Microsoft Entra audit logs keep 7 days on Free and 30 days on P1 or P2. For older accounts you will rely on consumer evidence and archives, so start the evidence collection before anything else.
- Owner means a person plus a team. Record an accountable individual and an owning team or cost centre, so the next leaver does not orphan the account again.
- Record ownership where it lives and where it is read. Use the platform's native field where one exists (Entra application owners, AWS tags) and the inventory for everything else. Active Directory's
managedByattribute is not defined for the user class, which most AD service accounts use. - Unclaimed does not mean unused. Disable in stages with a documented re-enable path, never delete on the first pass.
When you need this
- An inventory or audit shows service accounts with no owner, or a departed owner. Typical sources are an IGA aggregation, an AD export, or the inventory built in How to Build a service account inventory from active directory.
- You need to rotate or reduce privilege and cannot find who to ask. Rotation without an owner turns into an outage.
- An access review keeps returning "unknown". Reviews without owners are rubber stamps. See How to Run an Access Review for Service Accounts.
Before you start
| Item | What you need |
|---|---|
| Orphan list | Every service account, application identity and IAM role with no owner, or an owner who has left or moved, from the inventory |
| Authoritative people data | An HR or worker extract with status, manager and team, to test whether a recorded owner is still valid |
| Application register | A CMDB or application catalogue mapping applications and hosts to owning teams |
| Log access | Read access to domain controller security logs or your SIEM, Entra audit logs, CloudTrail (event history and any trail archive) and Google Cloud audit logs |
| Mandate | A sponsor (usually the CISO or head of IT) who has approved the claim deadline and the disable step, in writing |
| Ownership record format | Agreed fields: owner, owning team, purpose, consuming system, review date. See the Service Account Inventory Template |
Step-by-step
- Build and triage the orphan list. Sort by risk, not alphabetically: privileged group membership, cloud administrator rights and interactive sign-in capability first. Accounts with Domain Admin rights deserve their own track; see How to find service accounts with Domain Admin rights.
- Collect creator evidence while logs still exist. Use the sources in the table below. Export the results into the inventory now, because the native retention windows are short.
- Collect consumer evidence. Find where the account is actually used: hosts, applications, pipelines and code. This is the strongest signal of the current owner.
- Score each candidate owner. Combine the signals (see scoring below) and pick the most likely owning team, then the person in that team.
- Run the claim round. Send each candidate team the account, its evidence and a short form: confirm ownership, nominate the right team, or confirm it is not needed. Set a deadline (two to four weeks is typical) and escalate non-responses to the team's manager after the first reminder.
- Record the confirmed owner in the inventory and in the platform's native field where one exists (second table below). Record who confirmed and when.
- Contain the unclaimed. Reduce privilege or disable, with a re-enable path, then decommission after a quiet period. See the containment section.
- Prevent new orphans. Require an owner at creation and transfer ownership in the leaver process, so the list does not grow back.
Where to find creator and consumer evidence
| Platform | Creator evidence | Consumer evidence | Limits |
|---|---|---|---|
| Active Directory | Event ID 4720 "A user account was created" on domain controllers (Subject Account Name and Logon ID identify who created it; requires Audit User Account Management); the whenCreated attribute dates it | Event ID 4624 with logon type 5 (service) on member servers shows where it runs; event 4769 Kerberos service ticket requests show clients using an SPN; services, scheduled tasks and IIS application pools configured with the account | 4720 survives only as long as your SIEM or log archive keeps it; most estates have no record for accounts older than that |
| Microsoft Entra ID | Audit log entries for adding an application or service principal, with the initiating user or app | Service principal sign-in logs showing resources accessed; the application's existing owners list; API permissions consented | Audit and sign-in logs keep 7 days on Free, 30 days on P1 and P2, unless archived to storage or a SIEM |
| AWS | aws cloudtrail lookup-events --lookup-attributes AttributeKey=ResourceName,AttributeValue=<user-or-role-name> for CreateUser, CreateRole or CreateAccessKey; check userIdentity of the result | RoleLastUsed and access key last-used data; CloudTrail events by AccessKeyId show source IPs and services; which stack, account or pipeline references the ARN | Event history: management events from the last 90 days, current region only, one lookup attribute per call; older history needs a trail archive or CloudTrail Lake |
| Google Cloud | Logs Explorer filter protoPayload.methodName="google.iam.admin.v1.CreateServiceAccount" (Admin Activity audit log); the principal in the entry is the creator | Service account usage and key usage data; which workloads attach the account; impersonation bindings | Admin Activity logs sit in the project's _Required bucket; confirm its retention period for your organisation |
| Code and pipelines | Commit author who first added the account name or ARN | Repositories, CI variables and infrastructure code that reference it; code owners files for those paths | Search tokens of the account name, not secret values |
For Windows services specifically, see How to find Windows services running as domain accounts. For GCP impersonation evidence, see How to Audit GCP Service Account Impersonation Rights.
Scoring the evidence
| Signal | Weight | Why |
|---|---|---|
| Consuming application or host owned by a team in the CMDB | High | Reflects who depends on the account today |
| Code owners of the repository or pipeline that references it | High | Names a current team with change rights |
| Existing native owner field (Entra owner, AWS tag) naming a current employee | Medium to high | Often right, but may be stale |
| Cloud account, subscription or project owner | Medium | A sound fallback for routing, rarely the true owner |
| Creator from audit logs, still employed | Medium | Knows the history; may have changed team |
| Naming convention or description text | Low | Useful hint, often outdated |
Two agreeing high signals justify sending a confirm-only request. One medium signal justifies a "is this yours?" request. No signal means the account goes to the cloud account or platform owner for a decision, and into the containment track in parallel.
Recording the owner where it lasts
| Platform | Native place to record ownership | Notes |
|---|---|---|
| Active Directory user-based service accounts | The inventory, plus a consistent text attribute if you must keep it on the object | managedBy is a single-valued DN attribute defined for classes such as Computer, Group and Organizational-Unit, not User. Agree one attribute and format if you also store owner text on the object, and keep the inventory authoritative |
| AD groups and computer-derived objects | managedBy (distinguished name of the managing user) | Points to a person, so it must be updated in the leaver process |
| Microsoft Entra applications and service principals | The owners collection: POST /applications/{id}/owners/$ref with "@odata.id": "https://graph.microsoft.com/v1.0/directoryObjects/{id}" | Owners can be users or service principals. Least-privileged delegated roles include Application Administrator and Cloud Application Administrator. Remember that Entra owners can manage the app's credentials, so add owners deliberately |
| AWS IAM users and roles | Tags such as owner, owner-team and purpose | Follow your tagging standard; tags can feed reports and attribute-based conditions |
| Google Cloud service accounts | The inventory, plus the service account description | Keep the description short and structured (team, purpose, ticket) |
Whatever the platform, the inventory is the record of truth and the native field is the copy that tools and reviewers see. Use the Machine Identity Naming and Tagging Standard Template to fix the field names once.
Containing what nobody claims
- Announce the date. After the claim deadline, publish the list of accounts to be disabled and the date, through change management.
- Reduce before you disable where the account is privileged: remove it from admin groups or detach broad policies first, and watch for failures for a week.
- Disable, do not delete. Disable the AD account, deactivate AWS access keys (
aws iam update-access-key --status Inactive), disable the Entra service principal or Google Cloud service account. Record the exact re-enable step against each account. - Watch for breakage. Alert on authentication failures for the disabled accounts (AD failed logons, CloudTrail
InvalidClientTokenIdor access denied for the key, Entra sign-in failures). A failure is your owner: whoever comes asking is the consumer. - Decommission after the quiet period. If nothing breaks through a full business cycle (often 30 to 90 days, longer for quarter-end or year-end jobs), delete the account and close the inventory record.
Rollback: re-enable the account or key using the recorded step, assign the person who raised the incident as provisional owner, and give them the claim form with a short deadline. Entra applications that are soft deleted can be restored for a limited period, and Microsoft's own guidance for unused apps is to soft delete, wait 15 days, then permanently delete.
Decisions for small and large organisations
| Question | Small organisation | Large organisation |
|---|---|---|
| Who runs the claim round | The IT or identity lead, by direct conversation | An IGA campaign or ticket workflow routed by CMDB team |
| Owner of last resort | Head of IT | The owner of the cloud account, subscription, project or application platform |
| Where ownership lives | A spreadsheet inventory plus native fields | IGA or CMDB as system of record, synchronised to native fields |
| Disable timing | Faster, because dependencies are known | Staged by risk tier, with change advisory approval |
Choose an individual owner plus team over a team-only owner: a team mailbox does not attest, and a person without a team becomes the next orphan. Choose consumer-based ownership over creator-based when the two disagree, because the consumer bears the outage risk and controls the change.
Common failure patterns
- Assigning the creator by default. The account lands with someone who no longer works on the system and approves every review without looking.
- Using the platform team as owner for everything. Owner of last resort is a routing step, not a final answer; a platform team cannot judge an application's need.
- Waiting for logs that are already gone. Teams plan to check creation logs later and find the 30 or 90 day window has passed.
- Deleting on the first pass. An unclaimed account that runs a quarterly job fails months later, with no rollback.
- Leaving unclaimed accounts enabled indefinitely. The Colonial Pipeline attack began with one unused VPN account; unused accounts with valid credentials are exactly what attackers look for.
- Not fixing the leaver process. Ownership decays again at the next reorganisation unless leavers and movers transfer their accounts. See the Joiner-Mover-Leaver Guide.
Detection and measurement
- New accounts without owners: alert on AD event 4720, CloudTrail
CreateUserandCreateRole, and Google CloudCreateServiceAccountwhere the inventory has no owner within an agreed number of days. - Owner leaves: a daily join of the inventory against HR leavers flags accounts whose owner is no longer active.
- Disabled-account activity: any authentication attempt by a disabled orphan is either a hidden dependency or misuse; investigate both.
| Metric | Target |
|---|---|
| Service accounts with a confirmed, current owner | 100 percent of privileged accounts; over 95 percent overall |
| Median days from orphan detection to confirmed owner or disable | Under 30 days |
| Claim round response rate before escalation | Rising quarter on quarter |
| Accounts re-enabled after disable (hidden dependencies found) | Tracked; each one gets an owner |
| Accounts whose owner left without transfer | Zero older than 14 days |
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-2 Account Management; AC-2(3) Disable Accounts; PS-4 Personnel Termination; CM-8 System Component Inventory | Account owners and lifecycle, disabling unneeded accounts, transfer at termination, inventory |
| NIST CSF 2.0 | PR.AA-01; GV.RR-02; ID.AM-02 | Managed identities and credentials, assigned responsibilities, inventory of services and systems |
| MITRE ATT&CK | T1078.002 Domain Accounts; T1078.004 Cloud Accounts | Abuse of valid but unwatched accounts |
| OWASP NHI Top 10 2025 | NHI1 Improper Offboarding | Identities left active after their owner or purpose is gone |
Practitioner checklist
- Get written sponsor approval for the claim deadline and the disable step.
- Export creator evidence from AD, Entra, CloudTrail and Google Cloud before retention windows close.
- Collect consumer evidence: hosts, services, pipelines, code references.
- Score candidates and send confirm or claim requests with a deadline.
- Record an individual owner and an owning team in the inventory and native fields.
- Reduce privilege, then disable unclaimed accounts with a recorded re-enable step.
- Alert on activity from disabled orphans and assign whoever surfaces.
- Delete only after a full business cycle without dependency.
- Add owner-at-creation and leaver transfer rules so new orphans stop appearing.
Standards and references
- Microsoft: 4720(S) A user account was created
- Microsoft: Managed-By attribute
- Microsoft Graph: Add owner to an application
- Microsoft Entra: Data retention
- AWS: Viewing recent management events with the AWS CLI
- Google Cloud: IAM audit logging
- NIST: SP 800-53 Rev. 5
- OWASP: Non-Human Identities Top 10
Related NHI Mgmt Group resources: NHI Ownership Attestation Campaigns Guide · Service Account Security Guide · How to Run an Access Review for Service Accounts · Ownership for Orphaned and Abandoned AI Agents