Most organisations cannot answer three questions about a service account during an incident: who owns it, what it can reach, and what breaks if its credential is rotated. This template gives you a ready-to-adopt service account inventory: the fields every record needs, allowed values for privilege, credential type and risk, discovery sources for Active Directory, Microsoft Entra ID, AWS, Google Cloud, Kubernetes and SaaS, ownership rules, a risk score and a review cadence. It meets the CIS Controls requirement for an inventory of service accounts and works as a spreadsheet, a CMDB record type or the schema for an NHI platform. It is for IAM, cloud and security teams building or cleaning up a service account register. For the wider controls around service accounts, see the Service Account Security Guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [IAM team] and [90 days], with your own teams, systems and thresholds.
- Section 3 is the record. Each field becomes a spreadsheet column or a CMDB attribute; fields marked "Required" must be filled before a record is marked complete.
- Start with the discovery sources in section 5, load the results, then work through ownership (section 7) and risk (section 8). Do not wait for a perfect inventory before starting reviews.
- The register covers service accounts first and is built to extend to every non-human identity. For what an NHI inventory must cover across the whole estate, see the Ultimate Guide to NHIs.
1. Purpose and scope
This standard establishes a single, centralised service account inventory (the "NHI register") for [Organisation]. It exists so that every account used by software has a known owner, purpose, privilege level and credential, is reviewed on a schedule, and is removed when no longer needed. It implements CIS Controls Safeguard 5.5, which states: "The inventory, at a minimum, must contain department owner, review date, and purpose", and NIST SP 800-53 AC-2 (Account Management) and CM-8 (System Component Inventory).
In scope are all accounts and credentials used by applications, scripts, services, pipelines and agents rather than people:
- Active Directory user accounts used as service accounts, standalone and group managed service accounts (sMSA, gMSA) and computer accounts used to run services.
- Microsoft Entra ID app registrations, service principals and managed identities.
- AWS IAM users with access keys and IAM roles; Google Cloud service accounts and their keys; Azure service principals with role assignments.
- Kubernetes service accounts and token Secrets.
- SaaS integration users, API users, connected apps and OAuth clients; database and local operating system accounts used by applications.
- API keys, personal access tokens used by automation, SSH keys and certificates that authenticate a workload, and AI agents.
2. Roles and responsibilities
| Role | Responsibilities |
|---|---|
| [IAM team] (register owner) | Owns this standard and the register; runs discovery; reconciles findings; reports metrics |
| Business owner | The person or department accountable for the account's purpose and continued need; attests at each review |
| Technical owner | Knows how the account is used and where its credential lives; performs rotation and decommissioning |
| Deputy owner | Covers when the technical owner is absent or leaves; becomes owner on transfer |
| Platform administrators | Provide discovery exports from AD, Entra ID, AWS, Google Cloud, Kubernetes and SaaS; block creation outside the request process |
| [Security operations] | Uses the register during incidents; alerts on activity by accounts not in the register |
3. Inventory record: required fields
Microsoft's guidance for governing on-premises service accounts lists the minimum data to obtain: owner, purpose, permissions (scopes), CMDB links, risk and lifetime. The record below extends that with credential and review data. Use the field names as spreadsheet column headers.
| Field | Description | Example | Status |
|---|---|---|---|
| nhi_id | Unique register identifier | NHI-000412 | Required |
| account_name | Name or identifier on the platform (UPN, ARN, email, client ID) | svc-payroll-sync | Required |
| platform | System of record for the identity | Active Directory [corp.example] | Required |
| identity_type | Value from section 4 | AD user as service account | Required |
| purpose | What the account does, in one sentence | Reads HR database nightly and writes payroll export | Required (CIS 5.5) |
| business_owner | Accountable person and department | [Name], Payroll | Required (CIS 5.5) |
| technical_owner / deputy_owner | Named individuals, not a mailbox | [Name] / [Name] | Required |
| consuming_systems | Applications, hosts, pipelines or CMDB items that use the credential | payroll-app01, payroll-app02 | Required |
| environment | Production, staging, development, test | Production | Required |
| privilege_tier | Value from section 4 | Tier 1 | Required |
| permissions_summary | Roles, groups, scopes or policies granted | HR-DB-Reader; share \\files\payroll (modify) | Required |
| credential_type | Value from section 4 | Password | Required |
| credential_location | Where the secret is stored | [Secrets manager] path /payroll/sync | Required |
| credential_last_rotated / credential_expiry | Dates | 2026-07-01 / none | Required |
| interactive_logon | Denied, allowed, unknown | Denied | Required |
| last_used | Last authentication from platform data | 2026-10-17 | Required |
| risk_score | From section 8 | 14 (High) | Required |
| review_date / next_review | Last attestation and when the next one is due | 2026-09-30 / 2026-12-31 | Required (CIS 5.5) |
| expected_lifetime | Permanent, until a date, or until a project ends | Until payroll migration [2027-06] | Recommended |
| discovery_source | How the record was found | AD SPN query, 2026-08 | Recommended |
| status | Active, under review, disabled, decommissioned | Active | Required |
4. Allowed values
| Field | Allowed values |
|---|---|
| identity_type | AD user as service account; gMSA; sMSA; computer account; Entra app registration or service principal; Entra managed identity; AWS IAM user; AWS IAM role; Google Cloud service account; Kubernetes service account; SaaS integration user; OAuth client; database account; local OS account; AI agent |
| privilege_tier | Tier 0: can control identity infrastructure (domain, identity provider, federation, cloud organisation admin). Tier 1: administrative over production systems or sensitive data. Tier 2: scoped read or write to specific resources |
| credential_type | Platform-managed (gMSA, managed identity, IAM role, attached service account, workload identity federation); certificate; client secret; access key or service account key; password; API key or token; SSH key |
| environment | Production; staging; development; test; shared (flag for remediation) |
| status | Active; under review; orphaned; disabled; decommissioned |
Any account whose privilege_tier is Tier 0 or Tier 1 forms the privileged NHI inventory, a filtered view that gets the shortest review cycle and is the first to be checked during an incident.
5. Discovery sources by platform
Use this as the service account discovery template: run each source, record the date and the count, and load every result into the register as "under review" until an owner confirms it.
| Platform | Discovery source | Fields it fills |
|---|---|---|
| Active Directory | Get-ADServiceAccount -Filter * for managed service accounts; user accounts with a servicePrincipalName, PasswordNeverExpires set, a naming prefix such as svc-, or no interactive logons; members of service groups; accounts running Windows services and scheduled tasks on servers | account_name, permissions (group membership), credential_last_rotated (pwdLastSet), last_used (lastLogonTimestamp) |
| Microsoft Entra ID | Get-MgServicePrincipal -All (or az ad sp list); app registrations with their passwordCredentials and keyCredentials end dates; managed identities; service principal sign-in logs | credential_type, credential_expiry, last_used, permissions (app roles, directory roles, Azure RBAC) |
| AWS | IAM credential report (CSV, regenerated at most once every four hours) for users and access keys; role last used data; IAM Access Analyzer unused access findings for unused roles, keys and permissions across the organisation | credential_last_rotated (access_key_1_last_rotated), last_used (access_key_1_last_used_date), status |
| Google Cloud | gcloud iam service-accounts list per project; user-managed keys per service account; service account insights (subtype SERVICE_ACCOUNT_USAGE) for accounts not authenticated in the past 90 days | credential_type, last_used, permissions (IAM bindings) |
| Kubernetes | kubectl get serviceaccounts -A; RoleBindings and ClusterRoleBindings that reference service accounts; Secrets of type kubernetes.io/service-account-token (legacy long-lived tokens); pods running as the default service account | permissions, credential_type, consuming_systems |
| SaaS | Admin console lists of integration and API users, connected apps and OAuth grants in [CRM], [ITSM], [code repository] and [collaboration suite] | identity_type, permissions (scopes), business_owner |
| Code, CI/CD and secrets stores | Secrets manager inventories, CI/CD variables, configuration files and connection strings, secret scanning results | credential_location, consuming_systems |
Two platform caveats affect completeness. The AWS credential report covers only passwords, the first two access keys per user, MFA devices and signing certificates; it excludes service-specific credentials such as Amazon Bedrock long-term API keys, which need the ListServiceSpecificCredentials API. Google Cloud notes that requests authenticated with API keys bound to a service account are not recorded in usage, so such an account can be reported as unused when it is not. For platform detail see the Group Managed Service Accounts (gMSA) Guide, the Azure RBAC and Service Principals Guide and the Kubernetes NHI Security Guide.
6. Hidden and privileged NHIs
Platform exports miss accounts that are not obviously service accounts. A hidden NHI inventory pass must also check:
- Human accounts used by software: named user accounts that authenticate from servers on a fixed schedule, or whose password is in a script. Record them as service accounts and plan their replacement (OWASP NHI10:2025 Human Use of NHI covers the reverse case).
- Computer accounts running services: Microsoft notes that with a computer account "you can't determine which service on the computer is using that account", so record the host and every service on it.
- Shared accounts: one credential used by several applications. Record each consumer and flag the record for splitting (OWASP NHI9:2025 NHI Reuse).
- Credentials in code and pipelines: keys found by secret scanning that map to an account not yet in the register.
- Third-party and vendor accounts: integration users created for a supplier, and OAuth apps granted by users. See the SaaS and OAuth App Governance Guide.
For privileged NHIs, flag any account in Domain Admins, Enterprise Admins or other privileged AD groups, with Entra directory roles or high-privilege Microsoft Graph application permissions, with Owner or Contributor at subscription or management group scope, with AWS administrator or wildcard policies, with Google Cloud Owner or Editor at project or organisation level, or with a Kubernetes ClusterRoleBinding to cluster-admin. Microsoft is direct about AD: "Service accounts shouldn't be members of any privileged groups".
7. Ownership and orphaned accounts
- Every record must have a business owner and a technical owner within [30 days] of discovery. Use creation metadata, the requester in the change or ticket system, the consuming application's owner in the CMDB, and recent sign-in sources to find a candidate.
- Owners must be named people. A team mailbox may be added as a contact but cannot attest.
- When an owner leaves or changes role, the joiner-mover-leaver process transfers ownership to the deputy or line manager before the leaver's account is disabled. See the Joiner-Mover-Leaver Guide.
- A record with no owner after [30 days] is marked orphaned. Orphaned accounts are restricted (logon limited or permissions reduced), then disabled after [14 days] notice to the consuming application owners, then deleted after [90 days] disabled if nothing breaks.
The Okta support system breach shows what an unmanaged service account costs: its credential had been saved in a personal browser profile. Ownership rules are covered in depth in the NHI Ownership Guide.
8. Risk scoring
Score each record by adding the points below. This is an example model; adjust weights to your environment and keep the formula in the register so scores can be recomputed.
| Factor | 0 points | 2 points | 4 points |
|---|---|---|---|
| Privilege tier | Tier 2 | Tier 1 | Tier 0 |
| Credential type | Platform-managed | Certificate or vaulted secret rotated within policy | Static password, key or token, unrotated or in code |
| Credential age | Under [90 days] | [90 days] to [1 year] | Over [1 year] or no expiry |
| Ownership | Owner and deputy confirmed | Owner only | Orphaned |
| Exposure | Internal only | Used from CI/CD or a third party | Usable from the internet with no network restriction |
| Activity | Used as expected | Unused for [90 days] | Interactive logon or unexpected source seen |
Bands: 0 to 6 Low, 7 to 12 Medium, 13 and above High. A Tier 0 account is High regardless of score.
9. Review cadence and attestation
| Risk band | Owner attestation | What the owner confirms |
|---|---|---|
| High and all Tier 0 | [Quarterly], at minimum | Still needed; purpose correct; permissions still required; credential rotated; no interactive use |
| Medium | [Quarterly] | As above |
| Low | [Six-monthly] | Still needed; owner and consumers correct |
CIS sets the floor: service account reviews "on a recurring schedule at a minimum quarterly, or more frequently", and its assessment specification fails the safeguard if the last review is more than three months old. If you adopt a longer cycle for low-risk accounts, record the reason as a risk acceptance. An account the owner does not attest by the deadline moves to "under review" and is escalated to the owner's manager. See the Access Reviews Guide.
10. Lifecycle events that update the register
- Request: new service accounts are created only through [request process], which writes the record before the credential is issued.
- Change: new permissions, new consumers or a change of owner update the record within [5 business days].
- Rotation: each rotation updates credential_last_rotated; failed rotations raise a ticket to the technical owner.
- Decommissioning: follow Microsoft's sequence: remove permissions and monitoring, check sign-ins of related accounts, prevent sign-in, confirm nothing breaks, hold disabled for [policy period], then delete the account and its credentials. Set status to decommissioned; keep the record for [audit retention period].
Improper offboarding is the first risk in the OWASP Non-Human Identities Top 10 (NHI1:2025). The full lifecycle is covered in the NHI Lifecycle Management Guide.
11. NHI inventory checklist and data quality metrics
- Every in-scope platform in section 5 has a dated discovery run in the last [90 days].
- Every Tier 0 and Tier 1 account has an owner, a deputy and a review in the last quarter.
- No production account has a shared environment value or a credential in code.
- Activity by an account not in the register raises an alert to [security operations].
Report these metrics monthly to [CISO]:
- Coverage: accounts discovered on platforms that are in the register, as a percentage (target 100%).
- Completeness: records with all required fields, matching the CIS assessment measure of accounts with complete information.
- Accuracy: accounts on platforms that should be disabled or removed, divided by current accounts, as CIS measures it.
- Ownership: percentage of records with a confirmed owner; count of orphaned accounts.
- Review currency: percentage of records reviewed within their cadence.
- Credential posture: percentage of records using platform-managed credentials; count of credentials over [1 year] old.
12. Framework mapping
| Template section | CIS Controls | NIST SP 800-53 Rev. 5 | OWASP NHI Top 10 (2025) |
|---|---|---|---|
| 3 to 5 Record and discovery | 5.1 Inventory of Accounts; 5.5 Inventory of Service Accounts | AC-2, CM-8 | NHI1 Improper Offboarding |
| 6 Hidden and privileged NHIs | 5.4 Restrict Administrator Privileges to Dedicated Administrator Accounts | AC-6 | NHI5 Overprivileged NHI, NHI9 NHI Reuse, NHI10 Human Use of NHI |
| 7 Ownership and orphans | 5.3 Disable Dormant Accounts | AC-2, AC-2(3) | NHI1 |
| 8 Risk (credential fields) | 5.2 Use Unique Passwords | IA-5 | NHI7 Long-Lived Secrets |
| 9 and 10 Review and lifecycle | 5.5; 5.6 Centralize Account Management | AC-2 | NHI1 |
Implementation guidance
- Weeks 1 to 2, pick the store: a spreadsheet works for a few hundred accounts and one team. Above that, or across several clouds, use a CMDB record type or an NHI management platform that pulls from the platforms directly; a service account inventory spreadsheet goes stale within a quarter once nobody owns its updates. Keep the section 3 field names either way so data can move.
- Weeks 2 to 6, discover and load: run section 5 for production first, Tier 0 platforms first (AD, Entra ID, cloud organisation admin). Load everything as "under review".
- Weeks 4 to 10, assign owners: work through records by risk score. Use "scream tests" only after notice: restrict, wait, then disable, never delete as the first step.
- Weeks 8 to 12, first review cycle: send attestations for High records, record outcomes, and remove what owners reject.
- Ongoing, close the front door: block creation outside the request process, alert on unregistered accounts, and re-run discovery on the cadence in section 11.
Small and large organisations: a small organisation with one directory and one cloud can run this in a spreadsheet owned by one person, with quarterly reviews in a meeting. A large organisation should automate discovery and attestation, integrate the register with the IGA or ITSM platform, and assign platform teams as data stewards for their sections. For rollback, every disablement in the cleanup must be reversible for the hold period: record the original state (groups, permissions, credential location) before changing anything.
Common failure patterns
- Inventory without owners: a list of 5,000 accounts with no accountable person changes nothing.
- Directory-only scope: AD is inventoried but cloud keys, service principals and SaaS integration users are not.
- Last-used data treated as proof: platform usage data has blind spots, so "unused" accounts are deleted and a quarterly job fails.
- One-off cleanups: the register is built for an audit and never updated, so it is wrong within months.
- Credentials outliving the person who knew them: in the Coupang breach, a former engineer's unrevoked signing key exposed 33.7 million accounts.
Standards and references
- CIS: Controls Assessment Specification, Safeguard 5.5 Establish and Maintain an Inventory of Service Accounts
- CIS: Critical Security Control 5 Account Management
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations
- OWASP: Non-Human Identities Top 10
- Microsoft Learn: Govern on-premises service accounts
- Microsoft Learn: Securing service principals in Microsoft Entra ID
- AWS: IAM credential reports
- Google Cloud: Service account insights
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Service Account Security Guide · Ultimate Guide to NHIs · NHI Ownership Guide · NHI Lifecycle Management Guide · NHI Governance Maturity Model