NHI Ownership RACI Template for Service Accounts

Service accounts, API keys and certificates go unrotated and unreviewed when every team assumes another team owns them. Platform engineering builds the vault, the application team writes the code that uses the secret, IAM runs the access review and security answers the leak alert, yet none of them is clearly accountable for a given credential. This template is a fill-in RACI matrix that settles who does what across the non-human identity (NHI) lifecycle: inventory, creation, secrets, certificates, reviews, leavers, incidents and decommissioning. It is for IAM leads, platform and cloud engineering managers, CISOs and GRC teams who need a signed-off split of duties, not another policy. The reasons ownership matters are covered in the NHI Ownership Guide; the rules themselves belong in the NHI Policy Template.

How to use this template

Replace placeholders: text in square brackets, such as [Organisation], [IAM lead] and [quarterly], is for your own role titles and values. Use roles in the matrix, never personal names; names go in the contact list in section 2.
Read the codes as: R = Responsible (does the work, may be several roles), A = Accountable (owns the outcome and signs off, exactly one role), C = Consulted (asked before the decision), I = Informed (told after).
Keep one A per row: two A entries means nobody is accountable. A row with no R will not be done.
Separate the two owners: this template uses a business owner (why the NHI exists and what risk is accepted) and a technical owner (how it is built and kept healthy). In small teams one person may hold both; record that explicitly rather than leaving a column blank.
Tailor per NHI type: sections 5 and 6 split secrets from certificates because the work is done by different teams in most organisations. Delete rows that do not apply to you, such as an internal PKI if every certificate comes from a public CA through automation.
"Must" and "should": "must" is mandatory; "should" is expected practice where a documented exception may apply.

1. Purpose and scope

1.1 This matrix assigns responsibility and accountability for every non-human identity at [Organisation], so that no NHI exists without a named owner and no lifecycle task falls between teams.

1.2 It covers:

directory service accounts (Active Directory, Microsoft Entra ID, LDAP), including gMSAs and local accounts used by applications;
cloud identities: AWS IAM roles and users, Azure service principals and managed identities, Google Cloud service accounts, and their keys;
API keys, OAuth clients and refresh tokens held by integrations, and personal access tokens used by automation;
certificates and private keys for TLS, mutual TLS, code signing and token signing, and SSH keys used by automation;
CI/CD pipeline identities, Kubernetes service accounts, bots, RPA accounts and AI agents that hold credentials.

1.3 It applies to employees, contractors and suppliers who create, operate or approve NHIs. Where an activity is outsourced, the supplier may hold an R, but the A must stay with an [Organisation] role.

1.4 Owner of this document: [IAM lead]. Approver: [CISO] on behalf of [Security Governance Committee].

2. Roles

2.1 The codes below are the matrix columns in sections 3 to 9. Each role must have a named primary and deputy in the contact list at [location], reviewed every [quarter].

Code	Role	Typical holder	What the role decides
BO	Business owner	[Head of the business service or product the NHI supports]	Whether the NHI should exist, what access it needs, which residual risk is accepted
TO	Technical owner	[Application or service team lead]	How the NHI is configured, where its credential lives, how it is rotated and tested
PLT	Platform and cloud engineering	[Head of Platform Engineering]	Approved patterns: vault, workload identity federation, IaC modules, guardrails
IAM	IAM or NHI governance team	[IAM lead]	Inventory, ownership records, credential standards, reviews and attestation campaigns
PKI	PKI and certificate services	[PKI service owner]	Certificate authorities, issuance policy, certificate inventory and renewal tooling
SOC	Security operations	[SOC manager or MSSP]	Detection of NHI misuse and secret leaks, first response
CISO	Chief Information Security Officer	[CISO]	Exceptions above tolerance, escalation of unresolved ownership disputes
GRC	Risk and compliance	[Head of GRC]	Risk register entries, evidence for audit, exception records

2.2 The BO and TO must be named individuals who are current employees. A team mailbox or distribution list may be recorded as a contact but must not be the owner. Each NHI must also have a backup technical owner.

3. Inventory and ownership assignment

Activity	BO	TO	PLT	IAM	PKI	SOC	CISO	GRC
Run automated discovery across directories, cloud, code, CI/CD and SaaS			R	A	R	C
Maintain the NHI inventory record (purpose, owners, credential type, tier)	C	R		A	R			I
Assign a risk tier to each NHI	C	R		A				C
Confirm ownership of a discovered, unowned NHI	A	R	C	R
Resolve an ownership dispute between teams	C	C	C	R			A	I

3.1 NHIs found by discovery that are not in the inventory must have a confirmed BO and TO within [14] days, or follow section 8.

3.2 IAM is accountable for the inventory being complete; the TO is responsible for each record being accurate. Do not merge these: a central team cannot know why an integration exists.

4. Creation and provisioning

Activity	BO	TO	PLT	IAM	PKI	CISO	GRC
Request a new NHI with purpose, owners and required access	A	R		I
Approve access for a Tier 1 (privileged or production data) NHI	A	C		R		C
Provide approved provisioning patterns and IaC modules that require owner tags		C	A/R	C	C
Create the NHI through the approved pattern	I	A/R	R	I
Choose the credential type (federation first, static secret by exception)		A	C	R	C
Approve an exception to use a long-lived static secret	C	R	C	C		A	R

4.1 PLT must make the compliant route the easy route: modules and templates that refuse to create an identity without BO, TO and purpose tags.

5. Secrets: API keys, tokens and passwords

Activity	BO	TO	PLT	IAM	SOC	CISO	GRC
Operate the secrets manager and its access policies		I	A/R	C	I
Store each secret in the approved vault path and restrict who can read it		A/R	C	C
Set the rotation interval for a secret class		C	C	A/R		I	C
Rotate a secret on schedule and test the consuming application	I	A/R	R	I
Scan code, images and CI logs for exposed secrets		I	R	C	A/R
Track rotation compliance and report overdue secrets	I	I		A/R		I	I

5.1 The TO is accountable for each secret's rotation because only the TO can test that the application still works afterwards. PLT is accountable for the platform that makes rotation possible.

6. Certificates and keys

Activity	BO	TO	PLT	IAM	PKI	SOC	CISO	GRC
Set certificate policy: approved CAs, key types, maximum validity		C	C	C	A/R		I	C
Maintain the certificate inventory with an owner per certificate		R		C	A/R
Request, install and renew a TLS or mTLS certificate	I	A/R	R		C
Generate and protect code-signing and token-signing keys in HSM or KMS	C	R	R		A		I
Alert on certificates nearing expiry		I			A/R	I
Revoke a certificate after key compromise	I	R	C		A/R	C	I

6.1 Expiry alerts must go to the TO named in the certificate inventory, not to a generic PKI queue. See the Machine Identity, PKI and Certificate Lifecycle Guide.

7. Access review and least privilege

Activity	BO	TO	PLT	IAM	GRC
Schedule and run NHI attestation campaigns	I	I		A/R	I
Attest that the NHI is still needed and correctly owned	A/R	R		C
Attest that permissions match the documented function	C	A/R		C
Supply usage data (last used, permissions exercised)		I	R	A/R
Remove unused permissions found in review	I	A/R	R	C
Keep review evidence for audit				R	A

7.1 Review frequency is set in the [NHI Policy]: for example [quarterly] for Tier 1, [six-monthly] for Tier 2 and [annually] for Tier 3. See the NHI Ownership Attestation Campaigns Guide and How to Run an Access Review for Service Accounts.

8. Movers, leavers and orphaned NHIs

Activity	BO	TO	PLT	IAM	PKI	SOC	CISO	GRC
Detect that an owner has left or moved (HR feed)				A/R
Transfer ownership to the backup owner or a new owner	A	R		R
Rotate credentials the leaver could have known	I	A/R	R	C	R
Flag NHIs with no valid owner after [10] working days				A/R		I	I	I
Restrict or disable an unclaimed NHI, with a rollback note	I	C	R	A/R		I

8.1 Disable before delete. An unclaimed NHI must first lose privilege or be disabled for [30] days; only if nothing breaks does it move to section 10. See How to assign owners to orphaned service accounts.

9. Leak, misuse and compromise

Activity	BO	TO	PLT	IAM	PKI	SOC	CISO
Triage a secret leak or anomalous NHI activity alert		C		C		A/R
Revoke or rotate the affected credential	I	R	R	R	R	A	I
Accept service impact from emergency revocation	A	C				C	C
Find every other secret exposed in the same leak and rotate it	I	R	R	R	R	A
Confirm old credentials no longer authenticate		R		R		A

9.1 The SOC is pre-authorised to revoke any NHI credential when a leak is confirmed, without waiting for the BO. The BO is informed and decides on service restoration, not on whether to revoke.

9.2 Rotation after an incident must cover every credential in scope, not only the one that was abused. In the Cloudflare Thanksgiving breach, one service token and three service account credentials were skipped during rotation because they were wrongly believed to be unused. In the Internet Archive breach, API tokens found in stolen source code were still valid weeks later.

10. Decommissioning

Activity	BO	TO	PLT	IAM	PKI	GRC
Decide the NHI is no longer needed	A	R		C
Revoke credentials, remove role assignments and delete the identity	I	A/R	R	R	R
Revoke and remove associated certificates		R			A/R
Close the inventory record and keep the history		R		A/R		I

10.1 Identifiers of deleted NHIs should not be reused for [a defined period], so logs remain attributable (NIST SP 800-53 IA-4).

11. Review and approval

11.1 This matrix must be reviewed at least every [12] months, after any incident involving an NHI, and after a reorganisation that moves platform, application or IAM teams.

11.2 Approved by: [name, role, date]. Next review due: [date].

Implementation guidance

Rollout steps

Start with Tier 1. Fill the matrix for privileged NHIs, production data access and signing keys first. These are where a missing owner costs most.
Use the role titles you have. If there is no separate PKI team, merge PKI into PLT and say so in section 2. A column for a role nobody holds fails at the first expiry.
Check the rules. One A per row, at least one R per row, no role with an A but no authority to act, and no column that is only C and I.
Walk it through with each role holder. Agree every A one to one. Disagreement between platform and application teams over rotation is common; settle it here, not during an outage.
Test it with a tabletop. Use a leaked API key belonging to a departed engineer's integration. Check whether discovery, ownership transfer, revocation and rotation happen as the matrix says.
Wire it into tooling. Make BO and TO mandatory fields in the inventory and in IaC tags, and route review tasks and expiry alerts to them automatically.
Roll back if needed. Keep the previous approved version. If a change causes confusion in an exercise or incident, revert until the review is complete.

Common failure patterns

Central team as owner: IAM is recorded as owner of every service account, so reviews are rubber-stamped by people who cannot say why the account exists.
Creator as owner: the engineer who ran the script is recorded, then leaves. OWASP lists Improper Offboarding as NHI1 in its Non-Human Identities Top 10 for 2025.
Platform accountable for rotation: PLT runs the vault and is held responsible for every secret in it, but cannot test the applications that break when a secret changes, so rotation is postponed.
Certificates with no TO: expiry alerts go to a shared PKI mailbox and nobody acts until the service fails.
No pre-authorisation for revocation: the SOC waits for an owner's approval to revoke a leaked key while the key is in use.

Framework mapping

Framework	Reference	What this template supports
NIST CSF 2.0	GV.RR-02	Roles, responsibilities and authorities established, communicated, understood and enforced
NIST CSF 2.0	PR.AA-01, PR.AA-05	Identities and credentials for services managed; access permissions reviewed with least privilege
NIST CSF 2.0	ID.AM-08	Assets managed throughout their life cycles (sections 4 and 10)
NIST SP 800-53 Rev. 5	AC-2	Account managers assigned, approvals for account creation, review and alignment with termination and transfer
NIST SP 800-53 Rev. 5	IA-4, IA-5	Authorised assignment of service identifiers; authenticator management
NIST SP 800-53 Rev. 5	SC-12, SC-17	Key management and PKI certificates (section 6)
ISO/IEC 27001:2022	A.5.2, A.5.16, A.5.17, A.5.18	Roles and responsibilities; identity management; authentication information; access rights
OWASP NHI Top 10 2025	NHI1, NHI7	Improper Offboarding; Long-Lived Secrets

NHI Ownership RACI: Fill-in Matrix for Service Accounts, Secrets and Certificates