Subscribe to the Non-Human & AI Identity Journal

Why do shared spreadsheets and browser sessions create identity risk?

Because they often hold credentials without the controls that identity teams rely on for review and revocation. A spreadsheet or browser session can become an unofficial access system, especially when teams reuse it across projects or contractors. That creates hidden standing access and weak accountability when the relationship changes.

Why This Matters for Security Teams

Shared spreadsheets and browser sessions become identity risk because they bypass the controls that identity and security teams depend on: ownership, lifecycle management, revocation, and auditability. A credential pasted into a sheet or left in a logged-in browser profile can function as standing access long after the original task ends. That turns a convenience layer into an unofficial identity system with weak accountability and no clean offboarding path.

This is not a theoretical issue. NHIMG’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, while 96% store secrets outside secrets managers in vulnerable locations. That pattern maps directly to spreadsheets, shared docs, browser profiles, and ad hoc session reuse. The result is hidden access that survives employee exits, contractor rotation, and project handoffs. Current guidance from the NIST Cybersecurity Framework 2.0 still points teams toward governance, asset visibility, and access control, but the practical gap is that these storage habits often sit outside formal identity tooling.

In practice, many security teams discover the risk only after a credential leak, a contractor offboarding event, or an incident review exposes how many people had implicit access all along.

How It Works in Practice

The core problem is that spreadsheets and browser sessions preserve access in a way that is easy for people to share and hard for systems to govern. A browser profile may retain active cookies, saved passwords, or session tokens. A spreadsheet may contain API keys, recovery codes, or links to shared accounts. None of these artefacts are lifecycle-managed identities, but they still confer access to infrastructure, SaaS tools, and administrative consoles.

Security teams should treat these artefacts as shadow identity containers. That means inventorying where secrets and active sessions live, then replacing them with controlled alternatives such as secrets managers, single sign-on, and short-lived credentials. The Top 10 NHI Issues research highlights how often secrets are stored outside approved systems, which is the same failure mode that makes shared spreadsheets so dangerous. For browser-based access, session controls should be tied to device trust, user context, and rapid revocation when employment or contract status changes. For secrets, best practice is to issue them just in time, keep them ephemeral where possible, and revoke them automatically after the task finishes.

  • Replace spreadsheet-stored credentials with managed secrets and scoped access records.
  • Use browser session timeouts, conditional access, and admin revocation for shared workstations.
  • Separate approval for access from the storage location of the credential itself.
  • Log who can see, copy, or export a shared sheet, not just who created it.

For programmatic access, the safest pattern is to move toward workload identity and short-lived tokens rather than copying reusable secrets into collaboration tools. That makes revocation possible and reduces the blast radius when a browser session or document is exposed. These controls tend to break down in contractor-heavy environments because access changes faster than the spreadsheet or browser profile can be reviewed.

Common Variations and Edge Cases

Tighter control over shared access often increases operational friction, so organisations have to balance speed against traceability. Some teams accept shared sheets for low-risk coordination, but current guidance suggests that any file containing credentials, recovery codes, or admin links should be treated as a high-risk identity artefact rather than a normal collaboration document.

There is no universal standard for this yet, especially for browser session handling across remote support, shared kiosks, and managed service provider workflows. In those cases, the safest approach is to minimise persistence: use dedicated work profiles, isolate support sessions, and revoke access immediately after the task ends. The 52 NHI Breaches Analysis is useful here because it shows how often weak secret handling and poor revocation become incident multipliers rather than isolated hygiene issues.

Shared spreadsheets also become especially risky when they are used as a handoff mechanism between teams. Once a sheet starts acting like an access register, it needs the same discipline as any identity system: ownership, review cadence, expiry, and removal. Without that, the document outlives the access relationship and turns temporary convenience into persistent exposure.

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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-03 Shared sheets and sessions often expose credentials that need rotation and revocation.
NIST CSF 2.0 PR.AC-4 Implicit access in shared sessions weakens least-privilege and access enforcement.
NIST AI RMF Identity sprawl in shared tooling is a governance and accountability risk.

Find every credential stored in collaboration tools and replace it with managed, short-lived secrets.