Much of the access to your organisation's systems is held by software rather than people, and few boards are told who owns it, what it can reach or when it was last checked. Service accounts, API keys, OAuth tokens, certificates, cloud roles, automation bots and now AI agents are all non-human identities (NHIs). Attackers target these credentials because they work silently, are rarely protected by multi-factor authentication and often grant more access than any single employee. This briefing is for directors, executive teams and the CISOs who report to them. It explains NHI risk in business terms, why it now sits with the board, the questions to ask, what good looks like, where to invest, which metrics to request and a 90-day plan.
The risk in one paragraph
Every application, integration, pipeline and AI agent that connects to another system does so with a credential. Those credentials are created by developers, cloud platforms and suppliers, usually without the joiner and leaver controls that apply to staff. Many never expire, hold far more access than their task needs, are copied into code and configuration files, and outlive the project or contract that created them. When one is stolen, the attacker inherits trusted access that looks like normal system traffic, so it can go unnoticed for months. The size of the damage is set by three things the board can ask about: how much access the credential holds, how long it stays valid, and whether anyone owns it.
Why this is a board-level issue now
- Stolen machine credentials are behind major incidents. In the Storm-0558 intrusion, attackers used tokens "signed by a key Microsoft had created in 2016" to read the mailboxes "of 22 organizations and over 500 individuals around the world". The US Cyber Safety Review Board found the intrusion "was preventable and should never have occurred" and that Microsoft's "security culture was inadequate and requires an overhaul" (CSRB report, March 2024; see our Storm-0558 analysis). That is a board finding about culture, not a technical footnote.
- Cleanup after one breach often misses machine credentials. At Cloudflare, four credentials left unrotated after the Okta breach let a nation-state attacker in (Cloudflare breach). At the US Treasury, a stolen API key held by a supplier led to a major incident (BeyondTrust breach).
- Your suppliers hold your keys. Every SaaS integration you approve receives tokens into your data. Stolen OAuth tokens from one chatbot integration opened hundreds of Salesforce tenants (Salesloft Drift breach). Yet only 14% of UK businesses reviewed the cyber risks posed by their immediate suppliers, rising to 45% of large businesses (DSIT Cyber Security Breaches Survey 2025).
- AI agents multiply the problem. Each agent that acts on your systems is a new non-human identity, often given broad access to be useful. Our Board and CISO Briefing on agentic AI covers that risk in detail.
- Regulators expect boards to oversee cyber risk, and NHIs are part of it. The obligations below do not mention NHIs by name, but they make directors answerable for the access controls that NHIs bypass when unmanaged.
| Rule or code | What it expects of the board | Why NHI risk is in scope |
|---|---|---|
| US SEC cybersecurity disclosure rules (adopted 26 July 2023) | Regulation S-K Item 106 requires listed companies to describe "the board of directors' oversight of risks from cybersecurity threats"; Form 8-K Item 1.05 disclosure is "generally" due four business days after an incident is judged material (SEC) | A stolen key or token is a common route to a material incident; the board must be able to describe how that risk is overseen. See the SEC Cybersecurity Disclosure Rules Guide. |
| EU NIS2 Directive (EU) 2022/2555, Article 20 | Management bodies of essential and important entities must approve the cyber security risk-management measures, oversee their implementation and can be held liable for infringements; members must follow training (EUR-Lex) | Article 21 measures include access control and asset management, which cover service accounts, keys and certificates. See the NIS2 Directive Guide. |
| UK Cyber Governance Code of Practice (DSIT and NCSC, 8 April 2025) | A.2 senior ownership of cyber risks; A.3 a defined cyber risk appetite; A.4 supplier risk; E.2 formal reporting at least quarterly with metrics and tolerances (GOV.UK) | NHI inventory, ownership and credential age are measurable and fit the quarterly reporting the Code asks for. |
Board engagement is falling, not rising: only 27% of UK businesses had a board member with explicit responsibility for cyber security in 2025, down from 38% in 2021, although the figure is 66% for large businesses (DSIT Cyber Security Breaches Survey 2025).
Five questions for the board to ask
- How many non-human identities do we have, and what share has a named owner? A credible answer is a number from a maintained inventory across cloud, SaaS, code repositories and on-premises directories, not an estimate. Unowned identities are the ones nobody reviews or switches off.
- Which of them could cause a material incident if stolen today? Ask for the list of NHIs with administrative or production data access, and how that list has changed since last quarter.
- How old are our oldest credentials, and why do they still work? Long-lived keys and passwords are the ones attackers find in code and logs. The answer should be a policy maximum, with exceptions approved and dated.
- Which suppliers and integrations hold tokens into our systems, and could we revoke them in an hour? Third-party access is part of supplier risk, and the revocation route must be known before an incident, not discovered during one.
- When did we last test our response to a leaked key or token? Rotating a credential without breaking the business takes practice. Ask for the date of the last exercise, the time it took and what was learned.
What good looks like
The OWASP Non-Human Identities Top 10 (2025) names the ten most common NHI weaknesses. Good practice addresses each of them, and the board can ask for evidence rather than assurance.
| Area | Good practice | Evidence to request | OWASP NHI risk addressed |
|---|---|---|---|
| Visibility and ownership | One inventory of NHIs with a named human owner and business purpose for each; unowned identities are disabled | Inventory coverage and ownership percentage | NHI1 Improper Offboarding |
| Secrets handling | No credentials in code, tickets or chat; secrets held in a managed vault; leaks detected and revoked quickly | Open secret leak findings and time to revoke | NHI2 Secret Leakage |
| Least privilege | Each NHI holds only the access its task needs; administrative rights are rare and justified | Count of NHIs with admin or broad access, trended | NHI5 Overprivileged NHI |
| Credential lifetime | Short-lived, automatically issued credentials where platforms allow; a maximum age for the rest | Percentage of credentials past the maximum age | NHI7 Long-Lived Secrets |
| Strong authentication | Workload identity federation and certificates in place of shared passwords and static keys | Share of NHIs still using passwords or static keys | NHI4 Insecure Authentication; NHI6 Insecure Cloud Deployment Configurations |
| Separation | One identity per workload and environment; staff never log in as a service account | Shared or reused identities found; human sign-ins to service accounts | NHI8 Environment Isolation; NHI9 NHI Reuse; NHI10 Human Use of NHI |
| Third parties | Supplier integrations approved, scoped, reviewed and revocable; access ends with the contract | Supplier tokens without a sponsor or review date | NHI3 Vulnerable Third-Party NHI |
Setting risk appetite. The UK Code's action A.3 asks boards to define and communicate cyber risk appetite. For NHIs that can be stated in plain, testable terms, for example: no production credential older than [90 days] without an approved exception; no leaked secret left valid for more than [24 hours] after discovery; no supplier token without a named internal sponsor; and no AI agent in production without its own identity and an owner. The thresholds are the board's choice; the point is that each one can be measured and reported.
Where to invest first
- Discovery and ownership: build the inventory and assign an owner to every NHI. It is the precondition for everything else. Start from the Service Account Inventory Template and the NHI Ownership Guide.
- Remove the worst exposure: revoke unused credentials, strip administrative rights that are not needed and move secrets out of code into a managed vault. See the Secrets Management Guide.
- Shorten credential lifetimes: replace static keys with short-lived, automatically issued credentials on cloud and CI/CD platforms, which removes whole classes of leak. See the Workload Identity Federation Guide.
- Govern supplier and SaaS access: review OAuth grants and third-party integrations, and give each one a sponsor and an expiry. See the SaaS and OAuth App Governance Guide.
- Detection and response: alert on NHIs used from unusual places or for unusual actions, and rehearse revocation. See the Leaked Credential Response Playbook.
Most of this extends the identity and access management programme the organisation already funds. The cost driver is usually people time for discovery and ownership, not new tooling; a larger organisation with several clouds and hundreds of SaaS integrations will need automated discovery, while a smaller one can start with platform-native reports and a spreadsheet.
Metrics to track
- Number of NHIs discovered, and the percentage with a named owner (target: all).
- Number of NHIs with administrative or broad production access, trended quarter on quarter.
- Percentage of credentials older than the policy maximum, and the number of approved exceptions.
- Percentage of workloads using short-lived credentials rather than static keys.
- Median time from discovery of a leaked secret to its revocation.
- Supplier and SaaS integrations with access to sensitive data, and the percentage reviewed in the last 12 months.
- Maturity level on the NHI Governance Maturity Model (Ad hoc, Developing, Defined, Managed, Optimised) against the agreed target.
Ask for these in the quarterly cyber report, with tolerances, as the UK Code's action E.2 describes. A trend matters more than a single figure.
A 90-day plan for the CISO
- Days 1 to 30: run discovery across cloud accounts, the identity provider, SaaS OAuth grants, CI/CD platforms and code repositories; scan repositories for exposed secrets; brief the executive team on the size of the estate and the top ten riskiest identities.
- Days 31 to 60: assign owners; revoke unused and leaked credentials; remove unneeded administrative rights from the highest-risk NHIs; agree an NHI policy covering ownership, maximum credential age and supplier access; propose risk appetite statements to the board.
- Days 61 to 90: start moving priority workloads to short-lived credentials; put supplier integrations under review with sponsors and expiry dates; run a tabletop exercise on a leaked production key; baseline maturity and present the first quarterly NHI metrics with a 12-month target.
How NHI Mgmt Group can help
NHI Mgmt Group is an independent authority on non-human identity. Directors and security leaders can start with the Ultimate Guide to NHIs and the Top 10 NHI Issues, and measure their position with the NHI Governance Maturity Model. We provide independent NHI maturity and risk assessments, business case development, programme initiation and board briefings. Our NHI Foundation Level Training Course builds NHI knowledge across security, IAM and engineering teams. Contact us to arrange a briefing.
Related NHI Mgmt Group resources: Ultimate Guide to NHIs · NHI Lifecycle Management Guide · Board Cyber Risk Reporting Guide · Human vs Non-Human Identity · Service Account Security Guide