NHI Policy Template: Ownership, Credentials, Rotation and Decommissioning

Most organisations govern people through a written access policy, but their service accounts, API keys, tokens, certificates and AI agents answer to nothing more than custom and the memory of whoever created them. This template is a fill-in policy for non-human identities (NHIs): who owns them, how they are recorded, which credential types are allowed, how credentials are issued, stored, rotated and monitored, and how an identity is retired. It is written to sit beneath your information security policy and alongside your access control and password policies. Numbered statements can be cited in audits, exceptions and tickets; have the draft reviewed by security, platform engineering, risk and audit before approval. Implementation detail lives in the linked guides.

How to use this template

• Placeholders: replace text in square brackets, such as [Organisation], [NHI owner role] and [90] days, with your own terms and values. The rotation table in 4.6 is the main place you will set numbers.
• Must and should: "must" is mandatory; "should" is expected practice where a documented reason allows a different approach. Keep the distinction when you edit.
• Policy, standard, procedure: keep platform settings (vault paths, AWS SCPs, CI configuration) in standards and runbooks that cite the statement numbers.
• AI agents: section 4.9 covers agent identities as NHIs. If you have adopted the Agentic AI Security Policy Template, reference it there rather than duplicating it.

1. Purpose

This policy sets the minimum requirements for creating, owning, authenticating, authorising, monitoring and retiring non-human identities at [Organisation]. It ensures every NHI is known, owned, least privileged, uses the strongest practical credential and is removed when no longer needed, so a stolen or forgotten machine credential cannot give lasting access to [Organisation] systems or data.

2. Scope

This policy applies to every identity that authenticates to an [Organisation] system, or to a third-party system on [Organisation]'s behalf, without a person present at the time of authentication. This includes:

• Service accounts in directories (Active Directory, Microsoft Entra ID, LDAP) and local system accounts used by applications.
• Cloud identities: AWS IAM roles and users, Azure service principals and managed identities, Google Cloud service accounts, and their access keys.
• API keys, personal access tokens used by automation, OAuth clients and refresh tokens held by integrations.
• Certificates and private keys used for TLS, mutual TLS, code signing and token signing; SSH keys used by automation.
• CI/CD pipeline identities, Kubernetes service accounts, bots, RPA accounts and IoT or device identities.
• AI agents and the tools, MCP servers and integrations they authenticate to.

It applies to all employees, contractors and suppliers who create, own, operate or approve NHIs. Human user accounts are covered by [Access Control Policy] and [Password Policy].

3. Roles and responsibilities

See the NHI Ownership Guide for how to assign and sustain owners.

4. Policy statements

4.1 Inventory and classification

1. Every NHI must be recorded in the [NHI inventory] before it receives access to production systems or data.
2. Each record must hold at minimum: identifier, platform, purpose, owner, custodian, credential type and location, permissions, environment, risk tier, creation and last rotation dates.
3. Each NHI must be assigned a risk tier: Tier 1 (privileged, production data, signing keys, cross-tenant access), Tier 2 (production, non-privileged) or Tier 3 (non-production, no sensitive data).
4. [IAM team] must run automated discovery across [directories, cloud accounts, code repositories, CI/CD and SaaS tenants] at least [monthly] and reconcile results with the inventory. NHIs found outside the inventory must be assigned an owner or disabled within [14] days.

A field-by-field starting point is the Service Account Inventory Template.

4.2 Ownership

1. Every NHI must have one named NHI owner who is a current employee, and a technical custodian team. Shared mailboxes and distribution lists are not acceptable owners.
2. NHI owners must attest ownership and access at least [quarterly for Tier 1, every six months for Tier 2, annually for Tier 3].
3. When an owner leaves or changes role, ownership must be transferred as part of the [leaver and mover process] within [10] working days. An NHI with no owner after that period must be disabled.

4.3 Identity design and least privilege

1. Each workload, integration or agent must have its own identity. One NHI must not be shared across applications, and the same NHI must not be used in production and non-production environments.
2. People must not sign in interactively with an NHI. Where a person needs equivalent access, they must use their own account through [PAM solution].
3. NHIs must be granted only the permissions their documented function requires, scoped to specific resources and environments. Wildcard, owner or administrator roles for Tier 1 NHIs require [policy owner] approval.
4. NHIs must not be members of human privileged groups such as Domain Admins or Global Administrator without an approved exception.
5. Permissions should be reduced at each review using platform usage data, such as AWS IAM last accessed information.

4.4 Credential types

Owners must use the highest-preference credential type the platform supports. Choosing a lower preference requires a recorded reason in the inventory.

See the NHI Authentication Guide and the Cloud Workload Identity Guide for how each option works.

4.5 Issuance and storage

1. NHIs and their credentials must be created through [approved provisioning pipeline or request process] that writes the inventory record. Console-created credentials for Tier 1 NHIs are not permitted.
2. Static secrets must be stored only in [approved secrets manager or vault], with access to each secret restricted to the identities that need it and every read logged.
3. Secrets must not be stored in source code, repository configuration, container images, unencrypted infrastructure-as-code state, CI logs, notebooks, chat or tickets.
4. Private keys for Tier 1 certificates and token signing keys must be generated and held in [HSM or cloud KMS] and must not be exportable to developer workstations.
5. Federation trust rules (for example OIDC subject and audience conditions) must be scoped to a specific repository, branch or environment, never to a whole organisation or a wildcard.

See the Secrets Management Guide for vault patterns.

4.6 Rotation and expiry

Credentials must expire and be rotated no later than the periods below. Rotation must also happen immediately on suspected exposure, on departure of anyone who could read the secret, and when the owner changes.

1. Rotation must be automated for Tier 1 and Tier 2 credentials. Manual rotation is allowed only for Tier 3 or under an exception.
2. Rotation must issue the new credential, switch consumers, then revoke the old one; it must not leave both valid for longer than [24] hours.
3. Credentials with no expiry date must not be created where the platform supports expiry.

Use the Secrets Rotation Runbook Template to document each rotation procedure.

4.7 Monitoring and detection

1. Authentication and API activity of Tier 1 and Tier 2 NHIs must be logged to [SIEM] and retained for [12] months.
2. [Security operations] must alert on NHI use from an unexpected network or workload, interactive NHI sign-in, new credentials added to an existing identity, and permission changes to Tier 1 NHIs.
3. All code repositories, CI/CD logs and [collaboration tools] must be scanned for secrets. A detected live secret must be revoked within [4] hours for Tier 1 and [24] hours otherwise, whether or not the exposure was public.
4. NHIs with no successful authentication for [90] days must be flagged to the owner and disabled after a further [30] days unless the owner confirms the need.

4.8 Decommissioning

1. The owner must request decommissioning when the workload, integration or agent is retired or no longer needs access.
2. Decommissioning must disable the identity, revoke all credentials, tokens, OAuth grants and federation trusts, remove role assignments, delete secrets from the vault after [30] days, and update the inventory record to retired.
3. Offboarding of a person must include rotation of every secret and signing key they could read.

See the NHI Offboarding and Decommissioning Guide. The Coupang breach shows the cost of skipping 4.8.4: a former developer kept a token signing key that was never revoked or rotated after he left.

4.9 AI agent identities

1. Each AI agent must have its own NHI recorded in the inventory, with an owner, risk tier and the tools and data it may reach.
2. Agents must not use a person's credentials, session cookies or personal access tokens.
3. Agents must receive short-lived, task-scoped credentials from preference 1 or 2 in 4.4. Static keys in agent configuration, prompts or memory are prohibited.
4. Credentials reachable by an agent must be scoped to a single environment and purpose; destructive or high-impact actions must require approval enforced outside the agent.

The PocketOS database deletion is the case for 4.9.4: an AI coding agent found an account-scoped token in an unrelated file and used it to delete a production volume.

4.10 Third-party NHIs

1. OAuth grants and integrations that give third parties access to [Organisation] data must be approved by [approver] and recorded in the inventory with an internal owner.
2. Supplier contracts must require secure credential storage, rotation on request and compromise notification within [72] hours.

5. Exceptions

Exceptions must be requested by the NHI owner using [exception process], state which statement cannot be met and why, describe compensating controls (for example network restriction, extra monitoring or shorter rotation), and carry an expiry date no later than [12] months. Tier 1 exceptions are approved by [policy owner]; others by [IAM team lead]. Expired exceptions are treated as non-compliance.

6. Compliance and monitoring

[IAM team] reports these measures to [risk committee] every [quarter]:

• Percentage of discovered NHIs that are in the inventory with a current owner (target [98]%).
• Percentage of workloads using preference 1 or 2 credentials (target rising each quarter).
• Number of credentials past their rotation date, by tier (target zero for Tier 1).
• Median time to revoke a detected leaked secret.
• Number of NHIs inactive for more than [90] days.
• Ownership attestations completed on time.

Internal audit verifies compliance. Non-compliant NHIs may be disabled; staff breaches are handled under [disciplinary procedure].

ATT&CK techniques this policy is meant to blunt include T1078.004 Cloud Accounts, T1552.001 Credentials In Files and T1098.001 Additional Cloud Credentials. ISO/IEC 27001:2022 users will usually map it to Annex A 5.16 Identity management, 5.17 Authentication information and 5.18 Access rights.

7. Review and approval

• Policy owner: [name, role]
• Approved by: [approving body] on [date]
• Version: [1.0]; next review due [date, no later than 12 months from approval]
• Related documents: [Information Security Policy], [Access Control Policy], [Password Policy], [Secrets Management Standard], [Agentic AI Security Policy], [Third-Party Risk Procedure], [Incident Response Procedure]

Review early after a significant NHI incident, major platform change or regulatory change.

Implementation guidance

1. Baseline first: run discovery and build the inventory before publishing deadlines.
2. Assign owners and tiers: run one ownership campaign; disable (do not delete) unclaimed Tier 3 identities first, with a documented re-enable path as the rollback.
3. Stop the inflow: enforce 4.4 for new workloads through platform guardrails, for example blocking new long-lived cloud access keys and requiring CI/CD to use OIDC.
4. Pilot rotation: automate rotation for one Tier 1 system in a pilot, measure breakage, then extend by tier. Keep the old credential valid briefly as the rollback.
5. Turn on detection: enable secret scanning and the 4.7 alerts in monitor-only mode for [30] days, tune, then enforce revocation deadlines.
6. Measure and adjust: report section 6 metrics from the first quarter. Small organisations can start with Tier 1 and a spreadsheet; large ones should link the inventory to the CMDB and IGA platform.

The Toyota T-Connect key exposure is a reminder of why the prohibited row in 4.4 matters: a key in source code sat on public GitHub for almost five years. Use the NHI Governance Maturity Model to judge where you start, and the Service Account Security Guide for remediation.

Sources behind this template: OWASP: Non-Human Identities Top 10 2025 · NIST: SP 800-53 Rev. 5 · NIST: Cybersecurity Framework 2.0 · AWS: Security best practices in IAM · Microsoft Learn: Workload identity federation · GitHub Docs: OpenID Connect

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: NHI Ownership Guide · Secrets Management Guide · Password Policy Template · Agentic AI Security Policy Template