What KPMG’s Report Found
KPMG’s 2026 cybersecurity survey, drawing on responses from security leaders across 22 countries, identified non-human identities (NHIs) as the top unresolved security problem facing organisations today. The finding is not about technology gaps — most organisations have identity and access management programmes. It is about a governance gap: NHIs have proliferated to a scale that existing programmes were not designed to address, without the audit visibility or lifecycle management controls that apply to human user accounts.
The numbers are significant. Research cited in the report suggests that enterprise environments now contain an average of 45 non-human identities for every human identity. In technology companies and financial institutions with extensive automation and third-party integrations, that ratio reaches 100:1 or higher. Every one of those non-human identities represents a potential access path that an attacker can exploit — and unlike compromised user credentials, a compromised machine credential often has no MFA, no session-based expiry, and no behaviour baseline to trigger anomaly detection.
What Non-Human Identities Actually Are
The category is broader than most board briefings acknowledge. NHIs include:
- API keys and tokens: Static credentials issued to applications, scripts, and third-party services for system-to-system authentication. Frequently over-privileged, rarely rotated, often stored in code repositories or configuration files.
- Service accounts: Human-created accounts used by applications and automated processes to authenticate to directories, databases, and internal systems. Often accumulate privileges over time as application requirements expand.
- Cloud IAM service identities: Cloud-native identities attached to compute resources (AWS IAM roles on EC2, GCP service accounts on compute instances, Azure managed identities) that provide access to cloud APIs and services.
- CI/CD pipeline credentials: Secrets used by automated build, test, and deployment pipelines to access source code repositories, cloud environments, and production infrastructure. High-privilege by necessity and difficult to scope narrowly.
- OAuth service tokens: Long-lived tokens issued to third-party SaaS integrations. When a vendor is granted access to email, calendar, or CRM data via OAuth, the resulting token persists indefinitely unless explicitly revoked.
Why This Is a Board-Level Issue
The Lapsus$ and Scattered Spider intrusions — which resulted in significant data breaches at multiple major technology and financial services firms — both exploited NHI credentials as pivotal elements of the attack chain. In the MGM Resorts intrusion attributed to Scattered Spider, the group social-engineered their way to Okta admin credentials, then used over-privileged service account access to move laterally across cloud infrastructure. The human identity was the initial vector; the NHI credentials were what made the breach destructive.
Three factors make NHIs a board-level governance issue rather than a purely technical one:
1. Regulatory exposure. NIS2, DORA, and the SEC’s cyber disclosure rules all require organisations to demonstrate that access controls are proportionate to risk. An inventory showing 50,000 unaudited API keys with no rotation policy is a compliance exposure that regulators can act on. Under DORA’s Article 9 requirements, financial entities must maintain access controls that include non-human user privileges. Under NIS2 Article 21, essential entities must implement “access control policies” — a requirement that has been interpreted by national supervisory authorities to include machine identities.
2. Supply chain liability. NHIs are frequently issued to third-party vendors and SaaS integrations. When a vendor is breached — as has occurred repeatedly in supply chain attacks targeting managed service providers and SaaS platforms — the attacker inherits whatever access the vendor’s credentials provide. The organisation that issued those credentials bears responsibility for the resulting exposure under most contractual and regulatory frameworks.
3. Incident response cost. When NHI credentials are compromised, rotating them across all dependent systems is complex and operationally disruptive. Unlike resetting a human user’s password, rotating a service account or API key requires identifying all systems that depend on it, coordinating updates across potentially hundreds of integrations, and verifying that nothing broke in the process. Organisations that lack a current NHI inventory cannot complete this rotation efficiently — and the breach timeline expands accordingly.
The Governance Gap
Mature human identity governance programmes include automated joiner-mover-leaver processes, regular access reviews, MFA enforcement, and session management. Very few organisations have equivalent governance for NHIs. The typical state:
- No centralised inventory of all NHIs and their access rights
- No automated detection of NHIs with excessive privileges
- No defined lifecycle: NHIs created for a project are not consistently deprovisioned when the project ends
- No rotation policy for static secrets (API keys often remain unchanged for years)
- No behaviour baseline to detect unusual activity from a compromised machine credential
What Good Looks Like
For the board briefing, the CISO should be able to answer three questions:
Do we know what NHIs we have? A complete NHI inventory — across cloud IAM, on-premises directories, CI/CD pipelines, and third-party integrations — is the foundation. This should include the access rights each NHI holds and when it was last used. NHIs that have not authenticated in the past 90 days are candidates for immediate revocation.
Do we rotate secrets systematically? Static API keys and service account credentials should have a defined maximum lifetime (typically 90 days for high-privilege credentials) and an automated rotation process. Credentials stored in code repositories should be detected and invalidated immediately — tools like GitHub Secret Scanning and AWS Secrets Manager can automate detection of exposed secrets.
What happens when a vendor is breached? The organisation should be able to enumerate, within hours, all NHIs issued to a given vendor or integration, assess their access rights, and revoke them selectively if the vendor reports a compromise. This requires the inventory and the revocation workflow to exist before the incident.
Immediate Actions for CISOs
- Commission an NHI inventory as a discrete project if one does not exist. Cloud infrastructure platforms (AWS IAM Access Analyzer, Azure Entra ID, GCP IAM recommender) provide the starting point; consolidation across all environments is the gap.
- Establish a rotation SLA for all static secrets. 90 days for production API keys; 30 days for CI/CD secrets. Automate rotation using secrets management tooling (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) rather than relying on manual processes.
- Incorporate NHI coverage into your next board cyber report. Most board reports focus on human identity controls and MFA adoption rates. Adding NHI inventory completeness, rotation compliance, and third-party credential exposure as metrics gives the board the full picture.
The 45:1 ratio of NHIs to human identities means that identity security programmes focused primarily on human users are, by definition, covering less than 3% of the identity attack surface. Boards that understand this ratio will ask the right questions. CISOs should get there first.