Notifications
Clear all
Topic starter
11/06/2026 10:54 pm
TL;DR: NHIs are now explicitly in scope for major regulatory and audit frameworks, and Cerbos argues that teams must prove inventory, ownership, rotation, least privilege, and loggability rather than treat machine identities as engineering leftovers. That shifts NHI governance from optional hardening to audit evidence, where unmanaged access becomes a compliance failure as much as a security one.
NHIMG editorial — based on content published by Cerbos: NHI compliance across major regulatory frameworks
By the numbers:
- 15% are confident in their ability to secure, to fully address risks, and only 15% are confident in their ability to secure NHIs.
Questions worth separating out
Q: What breaks when NHIs are not inventoried and owned properly?
A: When NHIs are not inventoried and owned properly, security and compliance teams lose the ability to explain who created access, why it exists, and when it should be removed.
Q: Why do machine identities increase audit and compliance risk?
A: Machine identities increase audit and compliance risk because they often operate outside the governance processes built for people.
Q: How can organisations tell whether NHI governance is actually working?
A: NHI governance is working when every machine identity has an owner, a purpose, a minimum-necessary entitlement, and evidence of rotation and review.
Practitioner guidance
- Build a complete NHI inventory with owners and business purpose. Record creation source, owner, purpose, last use, and entitlement for every service account, workload identity, and application account.
- Eliminate shared and hardcoded machine credentials. Move secrets into managed vaults, enforce rotation, and remove credentials from scripts, config files, and image layers.
- Tie each NHI to attributable logging. Ensure logs show the machine identity, the action taken, the target system, and the policy or entitlement that allowed it.
What's in the full article
Cerbos's full article covers the operational detail this post intentionally leaves for the source:
- Framework-by-framework clause mapping for PCI DSS, DORA, NIS2, ISO 27001, and SOC 2
- Audit evidence examples for inventory, ownership, rotation, and logging controls
- Practitioner guidance on documenting NHI lifecycle controls for compliance reviews
- Control-by-control checklists for machine identities in regulated environments
👉 Read Cerbos's guide to NHI compliance across major regulatory frameworks →
NHI compliance and audit readiness: what IAM teams must prove?
Explore further
12/06/2026 7:19 am
Compliance has become the practical forcing function for NHI governance. Cerbos is right to frame machine identities as an audit problem because regulators are asking for evidence that most identity programmes still cannot produce cleanly. Inventory, ownership, and attribution are no longer back-office details. They are the minimum evidence needed to show that NHIs are part of the control environment. Practitioners should treat compliance as the test that exposes whether NHI governance exists at all.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- 59.8% of organisations see value in a solution that simplifies non-human access management and introduces dynamic ephemeral credentials, according to The 2024 Non-Human Identity Security Report.
A question worth separating out:
Q: Who is accountable when a machine identity causes a compliance incident?
A: Accountability should sit with the business owner of the identity, not only with the team that created it or the system that used it. If the identity can access regulated data, then security, engineering, and governance all need assigned responsibilities. Without that split, organisations end up blaming tooling for what is actually a lifecycle failure.
👉 Read our full editorial: NHI compliance now sits inside audit and regulatory scope
