Service Account and Non-Human Identity Policy Template

A non-human identity (NHI) policy sets the rules for every identity that is not a person: service accounts, service principals, API keys, OAuth applications and their tokens, CI/CD credentials, certificates, workload identities and AI agents. The core rules are that each one has a named human owner, uses the shortest-lived credential the platform supports, is recorded in an inventory, and is removed when its purpose ends. This template maps each rule to the OWASP Non-Human Identities Top 10 (2025) risk it addresses and to NIST SP 800-53 Rev. 5 controls.

How to use this template

1. Run discovery first: export service principals and app registrations from the IdP, IAM roles and access keys from each cloud, OAuth grants from your main SaaS apps, tokens from code hosting and CI, and secrets from your vaults. Populate the inventory (section 4) from that, not from memory.
2. Set the lifetimes in section 3 to what your platforms can do today, and record a target for each.
3. Fill the [bracketed fields] and adopt the policy under your IAM policy, section 4.7.
4. Expect to find credentials with no owner. Section 7 says what to do with them.

Owner: [ ] | Approved: [date] | Review: every [12] months

1. Scope and definitions

This policy covers:

2. Ownership and approval

1. Every NHI must have a named human owner and a backup owner, both current employees, recorded in the inventory. (NIST AC-2(b) assign account managers; ISO 5.16 Identity management)
2. When an owner leaves or changes role, ownership must be reassigned as part of the leaver or mover process before their own access is removed. (OWASP NHI1 Improper Offboarding)
3. Creating an NHI with [admin, production data, cross-tenant] permissions requires approval from [security].
4. Permissions must be the minimum the workload needs, scoped to specific resources, and reviewed every [6] months. Wildcard permissions require an exception. (OWASP NHI5 Overprivileged NHI; NIST AC-6)
5. Third-party OAuth apps and integrations must be approved before connection, and their scopes recorded. (OWASP NHI3 Vulnerable Third-Party NHI)

3. Credential types and maximum lifetimes

Use the first option the platform supports. Each step down needs a reason in the inventory.

Rules:

1. Secrets must be stored in [vault] and injected at runtime. Secrets must not be committed to code, images, tickets or chat, and must not be embedded unencrypted. (NIST IA-5(7); OWASP NHI2 Secret Leakage)
2. Long-lived secrets must have an expiry set at creation. (OWASP NHI7 Long-Lived Secrets)
3. Service-to-service authentication must use a standard, current method (OAuth client credentials with private key JWT or mTLS, workload identity federation). Deprecated or unauthenticated methods are not allowed. (OWASP NHI4 Insecure Authentication; NIST IA-9 Service Identification and Authentication)

Guidance: see secrets management, API key rotation automation and workload identity 101.

4. Inventory

Each NHI must be recorded with at least these fields. (NIST AC-2(a), AC-2(d); ISO 5.9 Inventory of information and other associated assets)

Inventory rules:

1. Reconcile the inventory against discovery exports every [month]. Anything found that is not in the inventory is treated as unowned (section 7).
2. Credentials for production must differ from those in non-production, and non-production NHIs must have no access to production. (OWASP NHI8 Environment Isolation)
3. One NHI per workload. Reusing a credential across applications is not allowed. (OWASP NHI9 NHI Reuse)

5. Use and monitoring

1. People must not sign in as an NHI or use an NHI credential for manual work. Interactive sign-in must be blocked where the platform allows. (OWASP NHI10 Human Use of NHI)
2. NHI sign-ins and API calls must be logged and sent to [SIEM].
3. Alerts must fire on: use from an unexpected network or region, use after the owner's departure, new permissions granted, a new credential added to an existing app registration, and a sudden rise in data read. (NIST AC-2(12) Account Monitoring for Atypical Usage)
4. Where the IdP supports it, apply conditional access to workload identities, for example restricting service principals to known networks. Service principals are not covered by policies scoped to users. See the conditional access worksheet.
5. Cloud configuration that exposes NHIs (public storage tokens, metadata service access, overly broad trust policies) is checked by [CSPM / CIEM tool]. (OWASP NHI6 Insecure Cloud Deployment Configurations)

6. Rotation and response

1. Rotate on schedule (section 3), when an owner with access to the secret leaves, and immediately when a secret may be exposed.
2. When a provider you integrate with reports a breach, rotate every credential that provider held or could reach, and confirm the old ones are revoked. Do not wait for proof of misuse.
3. Rotation must be tested in non-production and automated where possible (secrets rotation).

Guidance: rule 2 is the lesson of Cloudflare's 2023 intrusion, where one access token and three service account credentials from the Okta support breach had not been rotated. The tj-actions/changed-files compromise printed CI secrets into public workflow logs, which is why pipeline secrets need the same rotation plan as production ones.

7. Unowned and dormant NHIs

1. An NHI with no current owner is assigned to [owning team lead] for 30 days. If no owner accepts it, it is disabled, then deleted after [30] more days without a business complaint.
2. An NHI unused for [90 days] is disabled after notice to the owner. (NIST AC-2(3) Disable Accounts)

8. Decommissioning

When the workload is retired or the integration removed:

• Revoke and delete all credentials (secrets, certificates, keys, tokens, refresh tokens).
• Remove role assignments and OAuth grants in every system, not only the IdP.
• Disable, then delete, the identity after [__ days].
• Remove secrets from the vault and from CI variables.
• Update the inventory with the decommission date and keep the record [__ years].

OWASP NHI Top 10 coverage

NIST SP 800-53 Rev. 5 controls cited: AC-2 Account Management, AC-2(3) Disable Accounts, AC-2(12) Account Monitoring for Atypical Usage, AC-6 Least Privilege, IA-5(7) No Embedded Unencrypted Static Authenticators, IA-9 Service Identification and Authentication (catalog).

Related

• What is a non-human identity and non-human identity security
• Machine identity management guide
• Securing AI agent identities
• Static API key abuse, secrets in repositories and CI, refresh token abuse
• Fan-out breach and the Identity Breach Report 2026