What do security teams get wrong about spreadsheet-based access certifications?

Why This Matters for Security Teams

Spreadsheet-based access certifications often look efficient because they are familiar, cheap, and easy to distribute. The real risk is that familiarity hides weak decision quality: reviewers see account names, not business context, inherited access, or the actual meaning of an entitlement. That gap turns certification into a record-keeping exercise instead of a control. NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts, which helps explain why review packages are often incomplete before the spreadsheet even opens.

For human identities, a reviewer may at least infer whether a person still belongs in a role. For NHIs, service accounts, API keys, and OAuth grants rarely map cleanly to a job title, so a checkbox review cannot reliably determine legitimacy. The problem is not the spreadsheet format itself, but the lack of structured entitlement data, consistent decision rules, and automated remediation paths. Guidance from the OWASP Non-Human Identity Top 10 and NHI Management Group’s Ultimate Guide to NHIs both point to the same operational reality: if entitlement context is poor, review quality will be poor too. In practice, many security teams discover certification failure only after an access path has already been abused, not during the review cycle.

How It Works in Practice

Effective certification starts before the reviewer sees a spreadsheet. The access inventory needs to be normalized so each line item includes owner, purpose, system, sensitivity, last used date, upstream dependencies, and expiry information where available. Without that context, reviewers are forced to guess, and guessing is not governance. Current best practice is to route only exceptions to human approvers, while machine-detectable issues such as stale accounts, duplicate grants, and expired tokens are remediated automatically.

For NHI access, this means treating the review as a control over workload identity rather than as a proxy for human job accountability. Teams should combine source-of-truth inventory, policy-as-code, and just-in-time revocation workflows so that a certification failure actually removes access. The NIST SP 800-53 Rev 5 Security and Privacy Controls supports access review discipline, but implementation is stronger when paired with NHI-specific guidance such as 52 NHI Breaches Analysis, which shows how poor visibility and excessive privilege turn routine access paths into incident pathways.

• Standardise entitlement labels so reviewers can see what the access actually does.
• Pre-populate decision criteria, such as owner confirmed, still needed, least privilege, or remove.
• Separate human-owned accounts from machine identities, because the approval logic is different.
• Auto-close low-risk, low-context items only when policy and telemetry support the decision.
• Escalate exceptions that involve privileged access, third-party exposure, or inactive credentials.

These controls tend to break down in environments with hundreds of SaaS integrations and delegated OAuth grants because ownership and business purpose are often unclear.

Common Variations and Edge Cases

Tighter certification workflows often increase operational overhead, requiring organisations to balance reviewer fatigue against the need for defensible decisions. That tradeoff becomes sharper for service accounts, shared integrations, and vendor-managed access, where there is no universal standard for how much context is enough. Current guidance suggests that the review model should match the identity type: human entitlements can be reviewed by manager and system owner, while NHIs often need technical ownership, runtime evidence, and expiry enforcement.

The most common edge case is a spreadsheet that contains technically accurate data but still produces bad outcomes because the reviewer cannot judge usage. A dormant account may be safe to remove, but an infrequently used integration may be business critical. Likewise, a privileged API key may look harmless if it is labeled generically, even though it can write production data. NHI Management Group research notes that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which is why review quality must be tied to credential lifecycle, not just attestation. The control fails when the team can verify who clicked approve but cannot prove the access decision was informed.

Related resources from NHI Mgmt Group

• What do security teams get wrong about role-based and attribute-based access control in large environments?
• What do security teams get wrong about access control when they focus only on login authentication?
• What do security teams get wrong about SSH logging for privileged access?
• What do security teams get wrong about role-based logic in policy-based authorization?