What breaks when access relationships are only reviewed through spreadsheet exports?

Why This Matters for Security Teams

Spreadsheet-driven access reviews are useful for counting entitlements, but they are a poor instrument for judging real risk. They flatten identity relationships into rows and columns, which hides shared accounts, inherited access, approval chains, SoD conflicts, and cross-system dependencies. That is exactly where privilege creep, toxic combinations, and unauthorised pathways survive review.

This matters even more for NHIs because service accounts, API keys, and automation principals rarely behave like humans. Their access is often distributed across CI/CD, cloud platforms, data systems, and messaging tools, so a spreadsheet can appear clean while the effective blast radius stays large. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which explains why manual review so often misses the real control problem.

OWASP also warns that non-human identities are frequently over-privileged and under-governed in practice, not because teams ignore them, but because the review method is too shallow for the architecture. In practice, many security teams encounter privilege escalation only after an incident or audit finding, rather than through intentional access certification.

How It Works in Practice

effective access review starts by replacing the spreadsheet export with relationship-aware inventory. The review should show what the identity is, where it is used, who owns it, what systems it can reach, and whether those paths are still required. That means joining IAM data with cloud permissions, application roles, secrets inventory, ticketing records, and ownership metadata. For NHIs, the question is not only “who has access” but “what can this identity do if it is chained with other systems?”

Current guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s 52 NHI Breaches Analysis points to recurring failure modes: stale service accounts, shared credentials, weak ownership, and invisible privilege inheritance. A practical review process should therefore validate:

• Direct and indirect entitlements, including group membership and inherited roles.
• Ownership and business purpose for each account or key.
• Separation of duties conflicts across payment, deployment, and admin workflows.
• Last-used evidence, rotation status, and dormant credentials.
• Cross-system reach, especially where one identity can trigger another workflow or approval.

For high-value paths, review evidence should be backed by policy-as-code or graph-based entitlement analysis, not copied into a spreadsheet for manual interpretation. That enables reviewers to see toxic combinations, standing privilege, and unresolved exceptions in context. These controls tend to break down when identity data is fragmented across legacy directories, cloud accounts, and third-party SaaS because no single export contains the full relationship graph.

Common Variations and Edge Cases

Tighter review often increases operational overhead, requiring organisations to balance visibility against review fatigue and remediation capacity. That tradeoff is real, especially in environments with thousands of service accounts or heavy automation. Current guidance suggests that monthly spreadsheet reviews may be acceptable for low-risk, low-change populations, but they are rarely sufficient for privileged NHIs or production workloads.

There is no universal standard for how much relational context must be included, but best practice is evolving toward evidence that shows ownership, dependency, and effective privilege, not just entitlement lists. This is particularly important when a single NHI is reused across teams, when break-glass accounts exist, or when an API key is embedded in CI/CD and then referenced by multiple deployment jobs.

Some teams try to compensate with approvals alone, but approvals do not expose hidden dependency chains or stale access paths. Others rely on quarterly recertification, which can miss short-lived privilege spikes and newly created connections between systems. The safer pattern is continuous entitlement review for high-risk identities, plus targeted certification for shared accounts, privileged automation, and accounts that can approve, move, or delete sensitive data.

Related resources from NHI Mgmt Group

• What breaks when third-party access is not reviewed continuously?
• What breaks when third-party SaaS access is never reviewed?
• What breaks when cloud access tools cannot see all delegated identities?
• What breaks when license renewal is disconnected from access ownership?