Subscribe to the Non-Human & AI Identity Journal

Why do layoffs increase insider-risk exposure in SaaS environments?

Layoffs compress the time available for review while increasing the chance that long-lived permissions, delegated access, and unmanaged tools are missed. Employees may also have accumulated access across business-managed and self-service apps. The result is a wider residual-access window that can be accidental or malicious.

Why This Matters for Security Teams

Layoffs are not just an HR event. They are a security stress test that compresses review cycles, increases exception handling, and exposes weak spots in entitlement hygiene. In SaaS environments, employees often accumulate access through approvals, app integrations, and self-service tools that were never fully documented. When access changes are rushed, teams miss long-lived tokens, delegated admin rights, and shadow apps. That is why residual access becomes both a compliance issue and an insider-risk issue. NHI governance is often the missing layer, especially when secrets and service accounts outlive the employee who created or used them. The scope of the problem is consistent with Ultimate Guide to NHIs — Why NHI Security Matters Now, which notes that 97% of NHIs carry excessive privileges. That matters because one overlooked API key can preserve access after a badge is deactivated. Current guidance from NIST Cybersecurity Framework 2.0 still applies, but it must be operationalised against identities that do not appear in the employee directory. In practice, many security teams encounter the real exposure only after a termination has already happened, rather than through intentional pre-layoff review.

How It Works in Practice

Layoffs widen insider-risk exposure because the usual offboarding sequence rarely covers every identity path a person has touched. Human accounts may be disabled quickly, but SaaS tenants, OAuth grants, API keys, shared automation accounts, and device-bound secrets often remain live. If those credentials were stored in code, chat, CI/CD tooling, or personal password managers, the organisation may not even know they exist. The best practice is to treat employee offboarding as an identity inventory event, not just an HR checklist.

Security teams should start by mapping where access actually lives, then revoke in layers: business apps, delegated admin roles, connected apps, then secrets and service accounts. This is where Guide to the Secret Sprawl Challenge is relevant, because sprawl makes residual access hard to see and slower to remove. Use the access review to identify long-lived tokens, non-rotated secrets, and unmanaged integrations. Then validate whether each entitlement is tied to a person, a workload, or a third party. If it is tied to a person, it should usually be removed or reissued; if it is tied to a workload, it should be re-owned and rotated. Research such as the The 52 NHI breaches Report shows why this matters: NHI exposure is a recurring breach path, not an edge case. External reporting also reinforces that compromised identities are frequently used as the foothold for broader abuse, as described in the Anthropic — first AI-orchestrated cyber espionage campaign report.

  • Inventory SaaS entitlements, OAuth grants, and delegated admin access before the termination date.
  • Rotate or revoke secrets, tokens, and API keys that were created, approved, or used by the departing employee.
  • Check for shadow IT and self-service apps outside the central IAM process.
  • Confirm that service accounts and automation jobs have a clear owner after any employee departure.

These controls tend to break down in high-growth SaaS stacks because app sprawl, automation, and decentralized admin rights make identity ownership ambiguous.

Common Variations and Edge Cases

Tighter offboarding often increases operational overhead, so organisations have to balance speed against completeness. That tradeoff is unavoidable when access has spread across many SaaS apps, departments, and contractors. Best practice is evolving, but there is no universal standard for how much pre-termination monitoring is enough, especially when legal, HR, and security timelines differ. A practical control set should therefore distinguish between revoking human access, reassigning workload access, and retiring secrets that were never meant to be human-owned.

Contractors and shared service teams create the hardest edge cases. A user may leave, but the underlying integration remains business-critical, so the organisation must preserve function while removing personal control. In those cases, JIT re-issuance and explicit ownership transfer are safer than leaving inherited access in place. Similarly, some apps do not support granular revocation, which means teams may need to reset the upstream secret or disable the integration entirely. That is why BeyondTrust API key breach and Salesloft OAuth token breach are useful references: they show how trusted tokens can outlive normal access controls. Organisations that already follow zero trust should still assume that termination events expose hidden access paths unless secrets, grants, and automation are explicitly revalidated.

For teams using zero trust language, the practical takeaway is simple: remove standing access, verify workload ownership, and rotate anything that cannot be cleanly reassigned. Layoffs make that discipline urgent because the window between termination and full credential cleanup is where accidental exposure turns into insider-risk.

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 Covers secret rotation and revocation after access changes.
NIST CSF 2.0 PR.AC-4 Least-privilege access review fits layoff-driven entitlement cleanup.
NIST AI RMF Governance helps define accountability for automated access paths.

Assign owners for workloads and secrets so autonomous access is reviewed and controlled.