What breaks when access certification is treated as a spreadsheet exercise?

When certification is handled as a spreadsheet exercise, review quality drops, evidence becomes inconsistent, and audit trails are hard to trust. Teams spend time collecting screenshots and exports instead of identifying elevated access, unresolved violations, and risky role combinations that deserve remediation.

Why This Matters for Security Teams

access certification is meant to prove that privileges still match business need, but spreadsheet-driven reviews usually turn it into evidence collection. That shifts effort away from risk decisions and into chasing exports, screenshots, and stale owner acknowledgements. In environments with service accounts, API keys, and delegated automation, that approach misses the real question: whether the identity still needs the access at all.

NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which is why spreadsheet reviews often certify access that nobody can actually validate. The gap is worse when access is tied to secrets stored outside a controlled vault or inherited through group nesting and shared automation. Current guidance from the OWASP Non-Human Identity Top 10 points to visibility and lifecycle control as core weaknesses, not administrative details. In practice, many security teams only discover over-entitled identities after a failed audit or an incident review, rather than through a clean certification cycle.

How It Works in Practice

Effective certification starts with an inventory that is complete enough to be trusted. For NHI and privileged access reviews, that means pulling authoritative data from IAM, PAM, cloud control planes, secret stores, CI/CD tooling, and workload identity systems instead of relying on a manually maintained spreadsheet. Access should be grouped by identity type, owning service, business criticality, and whether the account is human, machine, or hybrid. The review then asks a narrower question: is this access still required, and is it appropriately constrained?

For non-human identities, the certification model should verify more than ownership. It should test whether the identity has:

• a named business or technical owner who can attest to purpose
• short-lived or rotating secrets where static credentials are not justified
• scope-limited permissions instead of broad inherited roles
• logs or telemetry that prove recent legitimate use
• a removal path if the service, integration, or workload has been retired

NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls supports this kind of evidence-based review, but the operational value comes from tying certification to remediation. That means unresolved exceptions should create tickets, access revocation should be tracked to closure, and attestations should be time-bound rather than annual paper exercises. The same logic applies to NHI risk management described in the Ultimate Guide to NHIs — Key Challenges and Risks, where hidden privilege and poor rotation drive exposure. These controls tend to break down in highly dynamic cloud estates because identities, permissions, and workload bindings change faster than review cycles can be manually reconciled.

Common Variations and Edge Cases

Tighter certification often increases operational overhead, requiring organisations to balance review depth against the risk of disrupting production services. That tradeoff is especially visible when the access being certified belongs to automation, shared integrations, or third-party support accounts.

Best practice is evolving for these edge cases. A service account used by a production pipeline may have no human owner in the usual sense, so the reviewer should validate the pipeline owner, the workload boundary, and the compensating controls around secrets rotation and monitoring. Shared admin accounts are another weak spot because a spreadsheet can name an approver, but it cannot prove which person actually used the credential or whether the credential was reused outside policy. For that reason, many programmes are moving toward continuous access review, where exceptions are rechecked whenever entitlements, workloads, or secrets change.

There is also a practical limit to any review that depends on manual attestation alone. If the organisation cannot link the identity to a workload, a ticket, or a recent access event, the certification is usually just asserting trust rather than verifying it. That is why NHI governance material from Ultimate Guide to NHIs is useful here: it reframes review quality around lifecycle evidence, not checkbox approval. Spreadsheet-based certification breaks down fastest in environments with thousands of machine identities, frequent deployments, and undocumented shared access because the data is already stale by the time the review opens.

Related resources from NHI Mgmt Group

• What breaks when access certification is treated as a yearly compliance exercise?
• What breaks when access reviews are treated as a compliance exercise only?
• What breaks when PCI DSS access control is treated as a one-time policy exercise?
• How should security teams use AI to reduce certification fatigue in access reviews?