Subscribe to the Non-Human & AI Identity Journal
Home FAQ Governance, Ownership & Risk What breaks when reviews only cover one application…
Governance, Ownership & Risk

What breaks when reviews only cover one application at a time?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated July 24, 2026 Domain: Governance, Ownership & Risk

Cross-application risk stays hidden. A permission that looks acceptable in one system can become dangerous when combined with access elsewhere in the process. That is especially true for ERP, SaaS, cloud, and infrastructure workflows, where the harmful condition is created by the combination, not any single entitlement.

Why This Matters for Security Teams

Single-application reviews can look clean while the broader workflow is already unsafe. The risk is not just excess privilege inside one system, but the path created when ERP, SaaS, cloud, and infrastructure permissions are combined across steps. NHI Management Group notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, which makes cross-application exposure a much larger problem than one-off access exceptions. The issue is structural, not administrative.

Security teams often miss this because app owners review entitlements in isolation, while attackers and automation chains see the whole process. A service account, API key, or agent can move from one tool to another without any single review looking obviously wrong. That is why the Ultimate Guide to NHIs emphasises visibility, lifecycle control, and Zero Trust alignment, rather than narrow point-in-time approvals. The same pattern shows up in the NIST Cybersecurity Framework 2.0, where risk treatment depends on understanding system context, not just local permission states. In practice, many security teams encounter toxic privilege combinations only after a workflow has already been abused, rather than through intentional review.

How It Works in Practice

Effective review processes need to evaluate the effective access path, not just the entitlement list for one application. That means mapping what a given NHI, service account, or agent can do across multiple systems, then asking whether the sequence of actions creates a dangerous outcome. A permission to read invoices in one SaaS platform may be harmless alone, but becomes high risk if the same identity can trigger exports, write to storage, and call infrastructure APIs elsewhere.

In practice, teams should build reviews around workflows and trust relationships:

  • Trace identities across ERP, SaaS, cloud, CI/CD, and infrastructure tools.
  • Identify where a single NHI can combine read, write, and execution privileges across systems.
  • Review privilege chains, not just individual roles.
  • Include service accounts, API keys, tokens, and automated agents in the same review scope.
  • Reassess access when integrations, data flows, or automation logic change.

This is where NHIs become especially difficult to govern. The Ultimate Guide to NHIs highlights how widespread excessive privilege and weak visibility are, which means isolated reviews tend to miss the very identities most likely to be chained together. Current guidance suggests using a CSF-style risk lens, like the NIST Cybersecurity Framework 2.0, to connect identity governance with data flows, system interactions, and operational dependencies. These controls tend to break down when organisations cannot inventory all machine identities across SaaS and cloud integrations because the review scope stops at the application boundary.

Common Variations and Edge Cases

Tighter cross-application review often increases operational overhead, requiring organisations to balance stronger risk detection against slower approval cycles. That tradeoff is real, especially where thousands of entitlements change through automation or where business teams depend on fast integration delivery. Best practice is evolving, and there is no universal standard for how deep every review must go.

Some environments justify lighter sampling, but only when compensating controls are strong. For example, centralised identity platforms, policy-as-code, and strong logging can reduce the burden of manual cross-system review. However, isolated application reviews are especially weak in ERP-to-SaaS-to-cloud chains, because toxic combinations often emerge only when entitlements are joined across platforms. The practical test is whether a reviewer can answer, “What can this identity do end-to-end?” rather than “Does this role look acceptable here?” If that answer is unknown, the review process is already incomplete.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-04Cross-application entitlement chaining is a core non-human identity governance gap.
NIST CSF 2.0PR.AC-4Least privilege fails when access is judged per app instead of across the workflow.
NIST AI RMFGOVERNAutonomous workflows require governance that understands system-wide risk, not local approvals.
NIST Zero Trust (SP 800-207)4.1Zero Trust requires continuous verification across resources, not per-app trust assumptions.
CSA MAESTROMulti-step service and agent workflows need cross-domain security orchestration.

Inventory NHI permissions end-to-end and review toxic combinations across all connected systems.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on July 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org