NHI Security Standard Template: Technical Rules

An NHI policy states that every service account needs an owner and that credentials must be rotated, but engineers configuring a cloud role, a Kubernetes workload or a CI pipeline need the numbers: which credential type is allowed, how long it may live, what it may touch and when it must be disabled. This template is the technical standard that sits beneath an NHI policy and gives those rules for service accounts, cloud workload identities, tokens, certificates and the static keys that remain. Each rule is written so it can be checked by a configuration scan or an inventory query. It is for IAM and platform security teams, cloud and Kubernetes platform owners, and auditors who need enforceable statements. The governance layer is in the NHI Policy Template; API keys have their own API Key Management Standard Template, which this standard references rather than repeats.

How to use this template

Replace text in square brackets, such as [Organisation], [IAM Lead], [approved vault], [90 days] and [24 hours], with your own terms. Bracketed values are NHI Mgmt Group suggested defaults, not external requirements; tighten them where your platforms allow.
"Must" is mandatory. "Should" is recommended practice where a documented exception may be justified.
Cite this standard from the policy statements it implements. Section 4 below covers the same ten topics as section 4 of the NHI Policy Template, so each policy statement has a matching technical rule.
Where a platform's documentation sets a limit or a default, follow the platform and confirm the current value in its documentation. Platform examples are listed alphabetically and are examples, not endorsements.
Delete sections for platforms you do not run, but keep section 4.3 (credential hierarchy), which applies everywhere.

1. Purpose

This standard sets the minimum technical requirements for creating, authenticating, authorising, monitoring and retiring non-human identities (NHIs) at [Organisation], so that each NHI uses the strongest credential its platform supports, holds only the access it uses, and cannot outlive its purpose or its owner.

2. Scope

In scope: directory service accounts (Active Directory, Entra ID, LDAP), cloud IAM roles, service principals, managed identities and service accounts, Kubernetes service accounts, CI/CD pipeline identities, OAuth clients used by applications, SSH keys used by automation, machine and workload certificates, personal access tokens used by automation, and identities used by AI agents.
Referenced, not repeated: API keys (see the [API Key Management Standard]) and the storage and rotation mechanics of secrets (see the [Secrets Management Policy]).
Out of scope: human user accounts, except where a human uses an NHI, which section 4.3 prohibits.

3. Roles and responsibilities

Role	Responsibility under this standard
[IAM Lead]	Owns the standard, approves exceptions, publishes compliance metrics monthly
Platform owners (cloud, Kubernetes, directory, CI/CD)	Enforce rules through guardrails (organisation policies, admission control, pipeline templates); report drift
NHI owner (a named team, with a named individual as primary contact)	Requests the identity, justifies its access, completes reviews, responds to alerts, requests retirement
Security operations	Runs detections in section 4.7 and the leaked credential response
Internal audit	Tests section 6 controls annually against inventory and platform evidence

4. Standard

4.1 Inventory and registration

Every NHI must be recorded in the [NHI inventory] before it is granted any production access. Use the Service Account Inventory Template as the field list.
Mandatory fields: unique identifier, platform and tenant or account, owning team and primary contact, purpose, consuming workload, environment, credential type, privilege tier (section 4.4), creation date, last review date, next review date and planned retirement date where known.
Names and tags must follow the Machine Identity Naming and Tagging Standard Template so the owner and environment are readable from the identity itself.
The inventory must be reconciled against each platform's own list of identities at least [weekly]. Any identity found on a platform but not in the inventory must be assigned an owner within [10 working days] or disabled.

4.2 Ownership

Every NHI must have an owning team and a primary contact who is a current employee. When the primary contact leaves or moves, the owning team must name a replacement within [10 working days].
An NHI with no owner for [30 days] must be disabled, then deleted after a further [30 days] if nobody claims it. See How to assign owners to orphaned service accounts.

4.3 Credential hierarchy

Each NHI must use the highest option in this table that its platform supports. Moving down a row requires a recorded justification; the bottom row requires an approved exception.

Rank	Credential type	Examples	Rule
1	Platform-issued identity with no stored secret	AWS IAM roles for compute; Azure managed identities; Google Cloud attached service accounts; Kubernetes projected service account tokens	Default for all workloads running on the platform
2	Federated workload identity	OIDC federation from CI/CD or another cloud into AWS, Microsoft Entra or Google Cloud; SPIFFE identities	Default for workloads crossing a platform boundary
3	Short-lived certificate or token from an automated issuer	mTLS certificates from an internal CA with automated renewal; dynamic secrets from the [approved vault]	Permitted where ranks 1 and 2 are unavailable
4	Static secret with enforced expiry and rotation	Client secrets, access keys, service account keys, SSH keys, personal access tokens	Exception only; maximum lifetime in section 4.6

Platform documentation supports this order. AWS recommends that workloads use temporary credentials through IAM roles rather than long-term access keys. Google Cloud advises treating service account keys as an exception and blocking them by default with the organisation policy constraints for disabling key creation and key upload, which it states are enforced by default for organisations created on or after 3 May 2024. Microsoft describes Entra workload identity federation as a way for workloads to reach protected resources without managing secrets or certificates.
Humans must not authenticate as an NHI, and NHI credentials must not be issued to individuals for personal use. This addresses OWASP NHI10:2025 Human Use of NHI.
One NHI per workload and environment. Sharing an NHI between applications, or between production and non-production, is prohibited (OWASP NHI9:2025 NHI Reuse and NHI8:2025 Environment Isolation).

4.4 Privilege tiers and least privilege

Tier	Definition	Extra requirements	Review frequency
Tier 0	Can change identity, security or audit configuration, or hold administrator rights across a tenant, domain or cluster	[IAM Lead] approval; rank 1 or 2 credential only; network and source restrictions; alert on every use outside its expected pattern	[Quarterly]
Tier 1	Write access to production data or systems	Scoped to named resources; no wildcard actions on production resources	[Every 6 months]
Tier 2	Read-only or non-production access	Standard request process	[Annually]

Permissions must name specific actions on specific resources. Wildcard actions or resources on production must be removed or justified at the next review.
Permissions unused for [90 days], as shown by the platform's last accessed or activity data, must be removed at review. AWS, for example, provides last accessed information for this purpose and IAM Access Analyzer to generate policies from logged activity.
Default and built-in identities must not be used by workloads. In Kubernetes, pods must set a dedicated serviceAccountName, and must set automountServiceAccountToken: false when they do not call the Kubernetes API; Kubernetes documents that pods without an assigned service account receive the namespace's default one. See the Kubernetes Service Account Token Guide.
NHIs must not be members of interactive administrator groups, such as Domain Admins, and directory service accounts must be denied interactive logon. See How to find service accounts with Domain Admin rights.

4.5 Issuance and storage

New NHIs must be created through [request process], using the Service Account Request Form Template or an infrastructure-as-code pipeline that writes the inventory record.
Static credentials (rank 4) must be generated by automation directly into the [approved vault] where the platform allows it, so no person handles the value.
Credentials must never be stored in source code, container images, CI logs, tickets, chat or wiki pages. Secret scanning must run on all repositories and pipelines. Google Cloud notes that removing a committed key from a repository is not enough, because version history retains it: the key itself must be deleted.
Federation trust policies (rank 2) must restrict the external subject to a specific repository, branch, environment or workload, never an entire organisation or issuer. See the Workload Identity Federation Trust Review Checklist.

4.6 Lifetimes, rotation and expiry

Credential	Maximum lifetime or rotation	Notes
Platform-issued and federated tokens	Platform default; requested lifetimes should not exceed [1 hour]	Renewal is automatic
Kubernetes service account tokens	Projected (TokenRequest) tokens only	Kubernetes documents Secret-based tokens as not expiring or rotating and no longer recommended; they are prohibited
Workload mTLS certificates (internal CA)	[30 days], renewed automatically	Internal choice
Public TLS certificates used by services	As permitted by the CA/Browser Forum Baseline Requirements	Ballot SC-081v3 (passed April 2025) reduces maximum validity from 398 days to 47 days between March 2026 and March 2029; automate renewal now
Static secrets (rank 4)	[90 days] Tier 2; [30 days] Tier 0 and Tier 1	Enforced by expiry where the platform supports it
Personal access tokens used by automation	[90 days], with expiry set at creation	See How to set expiry policies on personal access tokens
SSH keys used by automation	[12 months], or SSH certificates of [24 hours]	Keys must be bound to a single host or command where possible

Rotation must be automated wherever the platform or vault supports it; OWASP's Secrets Management Cheat Sheet recommends automating rotation and using dynamic secrets where possible. Use the Secrets Rotation Runbook Template for the rest.
Any credential suspected of exposure must be revoked within [24 hours] (Tier 0: [4 hours]), regardless of its schedule.

4.7 Monitoring and detection

Authentication and API activity for every Tier 0 and Tier 1 NHI must be logged to the [SIEM] and kept for [12 months].
Security operations must alert on at least: interactive logon by a service account; use from a new country, network or autonomous system; use of a credential after its owner flagged it for retirement; creation of a new static key on an identity that previously had none; and permission changes on Tier 0 identities.
Credential access in the vault must be audit logged, recording who requested it and when, in logs protected from tampering, in line with OWASP guidance.
Detection content should follow the Detection Engineering for Non-Human Identities Guide.

4.8 Dormancy and decommissioning

An NHI with no successful authentication for [90 days] must be disabled after owner notification, and deleted after a further [30 days].
When an application is retired, all its NHIs, credentials, federation trusts, role assignments and certificates must be removed in the same change. This addresses OWASP NHI1:2025 Improper Offboarding. See the NHI Offboarding and Decommissioning Guide.

4.9 AI agent identities

Each AI agent must have its own NHI, registered under this standard, and must not reuse an application's or a person's credentials.
Agent identities must be Tier 1 or Tier 2. Any agent action requiring Tier 0 rights must go through a separate approval step. See AI Agent Service Accounts vs On-Behalf-Of Access.

4.10 Third-party NHIs

NHIs created for vendors, SaaS integrations and OAuth applications must be inventoried with the vendor named as a dependency and an internal owner, and reviewed on the same tier schedule (OWASP NHI3:2025 Vulnerable Third-Party NHI).
Cross-account or cross-tenant trust granted to a third party must be restricted to the vendor's specific identifiers and, where the platform offers it, a unique external identifier per customer.

5. Exceptions

Exceptions must be requested through [exception process], state the rule, the reason, compensating controls and an expiry date no later than [12 months].
Tier 0 exceptions require approval by the [CISO]. Expired exceptions are treated as non-compliance.

6. Compliance and monitoring

Measure	Source	Target
NHIs in inventory with a current owner	Inventory reconciliation	[100%]
Workloads on rank 1 or 2 credentials	Platform credential reports	[90% within 12 months]
Static secrets past maximum lifetime	Vault and platform key age reports	[0]
Tier 0 NHIs reviewed on schedule	Access review records	[100%]
Dormant NHIs (90 days) still enabled	Last authentication data	[0]
Median time to revoke an exposed credential	Incident records	[under 24 hours]

Platform owners must enforce rules with preventive guardrails where available, such as organisation policies, Kubernetes admission policies and pipeline templates, and run detective scans where they are not.

7. Review and approval

The [IAM Lead] reviews this standard at least [annually] and after any major platform change or NHI-related incident. Approved by [CISO] on [date]. Version [1.0].

Implementation guidance

Start with the inventory and the credential hierarchy: measuring how many workloads sit on rank 4 credentials gives the migration backlog and the headline metric. See Workload Identity Federation vs Static Cloud Keys.
Apply guardrails before clean-up: blocking new static keys and default service account use stops the backlog growing while existing identities are migrated.
Roll out in tier order: Tier 0 first, then production write identities, then the rest. Disable before deleting, and keep a [30 day] rollback window for disabled identities.
Pilot lifetimes: introduce new maximum lifetimes in audit mode for one cycle, report breaches to owners, then enforce.
Small organisations: keep the three tiers but merge the owner and platform roles; the hierarchy and lifetimes still apply.

Framework mapping

Framework	Reference	Standard sections
NIST SP 800-53 Rev. 5	AC-2 Account Management; IA-4 Identifier Management; IA-5 Authenticator Management; IA-9 Service Identification and Authentication; AC-6 Least Privilege; SC-17 Public Key Infrastructure Certificates	4.1 to 4.8
NIST CSF 2.0	PR.AA-01 (identities and credentials for services are managed); PR.AA-05 (least privilege and separation of duties)	4.3, 4.4
OWASP Non-Human Identities Top 10 (2025)	NHI1 Improper Offboarding; NHI2 Secret Leakage; NHI3 Vulnerable Third-Party NHI; NHI5 Overprivileged NHI; NHI7 Long-Lived Secrets; NHI8 Environment Isolation; NHI9 NHI Reuse; NHI10 Human Use of NHI	4.3 to 4.10

NHI Security Standard Template: Technical Rules for Service Accounts, Keys and Tokens