Layoffs Are an Identity Event: The Technical Side of Mass Offboarding

By September 2026, tech layoffs had already passed the total for the whole of 2025. Layoffs.fyi counts more than 123,000 people across nearly 300 companies. The wave is not limited to tech. Banks, retailers, logistics groups and industrial companies are cutting too, and most of them cite AI-driven restructuring.

The human side of this has been covered widely. This article is about the technical side: employee offboarding at scale, and what it does to identity and access management (IAM). It starts the morning the announcement goes out and lands on the identity and security team.

A layoff is thousands of access changes squeezed into a few hours or days. A process that handles three leavers a week is suddenly asked to handle three hundred in one day. This is where identity programs break. The damage stays hidden for months.

Normal attrition hides a weak offboarding process

On a normal week, offboarding works even when it is badly designed. A manager files a ticket. The service desk disables the directory account. Someone remembers the VPN. Someone else eventually gets to the SaaS tools. The gaps are small enough to go unnoticed.

They are not small. A 2025 Wing Security study found that 63% of companies have former employees with live access to corporate data in SaaS applications. An Oomnitza survey found that 68% of organisations cannot confirm that all access was revoked when a person left. Both figures describe ordinary conditions. A mass layoff multiplies the same gaps by a hundred, on a day when the service desk is already flooded with resets and HR requests.

What access deprovisioning actually involves

“Disable the account” sounds like one step. For a typical engineer at an industrial company it is closer to a dozen:

• The directory account and single sign-on identity
• MFA tokens, hardware keys, registered phones
• VPN, ZTNA and remote access profiles
• Email, plus any mailbox rules and forwarding the person set up
• SaaS applications outside SSO, registered with a corporate email and a local password
• Cloud consoles, API keys, personal access tokens, CI/CD secrets
• Shared and service accounts the person knows the password to
• Privileged access vault entitlements and standing admin roles
• Physical badges and facility access
• In OT: engineering workstations, local accounts on PLCs and HMIs, vendor remote-access tools, jump hosts

Most organisations cannot produce this list for one person from one system. IT teams usually check three or more sources to work out what a leaver could reach. At five people a week that is manageable. At five hundred in a day it does not happen. The team disables what the directory controls and hopes the rest was federated.

Three offboarding failures that surface after a layoff

1. Orphaned accounts. The obvious one. Non-SSO SaaS logins, local accounts on servers and devices, cloud IAM users created by hand for a project. They keep working because nothing links them to the HR record. Credential abuse is still one of the leading breach vectors. Dormant accounts of former staff are a favourite entry point because nobody is watching them.

2. Orphaned ownership. Less obvious and more dangerous. Service accounts, integration keys, scheduled jobs, certificates and scripts all have an owner. After a layoff many of those owners are gone. Nobody rotates the secret because nobody knows what depends on it. Nobody disables the account because a production line or a billing run might stop. The company ends up with a growing set of privileged non-human identities that nobody is responsible for.

3. Movers, not leavers. The people who stay take over the work of the people who left. They get new roles and new approval rights, in a hurry and on top of what they already had. Old entitlements are almost never removed. Six months later one person raises purchase orders and approves them. Or the same engineer changes a SCADA configuration and signs off on the change. Segregation of duties conflicts created during a reorganisation are among the most common findings in the audits that follow.

The notice window is when the risk peaks

Insider risk is highest between the announcement and the last working day. Departing colleagues are not the problem. The problem is that incentives change and the security team is stretched at the same time. Practical measures for that window:

• Revoke privileged access on the day of notice. Standard access can stay until the last day if the business needs it. Admin rights do not need a two-week handover.
• Record and review privileged sessions of affected users.
• Do not grant new broad entitlements to anyone on the leaver list. Handover means documented transfer of ownership, not copying one person’s rights to another.
• Watch affected accounts for bulk downloads, new forwarding rules and personal cloud storage sync.

Offboarding in OT environments is harder

In industrial environments, several assumptions behind enterprise offboarding do not hold.

Shared operator accounts are common and often unavoidable on legacy systems. When a member of the shift is let go, the account cannot be disabled. The credential has to be rotated and handed to the remaining operators without ending up on a sticky note on the HMI.

Local accounts on controllers, HMIs and engineering workstations are not joined to any directory. There is no central switch. Each one is a manual change, often possible only during a maintenance window.

Third-party churn is invisible to you. Your automation vendor or integrator may be cutting staff too. The engineer who set up remote access into your plant last year may have left, and the credentials may still work on your side. Vendor access needs an expiry date and a named counterpart. The vendor’s own leaver notifications belong in the contract.

The workable answer for all three is the same: put a broker between people and OT credentials, the approach behind zero trust access for OT. A privileged access layer injects the credential into the session, rotates it afterwards and records what happened. The departing engineer never knew the current password. Offboarding then means removing one person from one system instead of touching forty devices.

A layoff-ready identity governance checklist

None of this needs a heroic response on the day. It needs design decisions made earlier. Most of them are the same decisions that make a normal day quiet.

1. HR is the single source of truth and deprovisioning is event-driven. A termination record in the HR system triggers revocation across connected systems. No ticket, no manager memory. Test it in bulk: terminate two hundred identities in a test environment and time it.
2. One query answers “what can this person reach”. An identity governance platform correlates accounts across directories, cloud, SaaS and OT into one identity. If the answer needs five systems and a spreadsheet, the leaver process will fail under load.
3. Every non-human identity has a named owner and a named successor. Service accounts, keys, certificates, automation credentials. When the owner leaves, ownership moves first and access is removed second. Secrets rotate on a schedule, not in a panic.
4. Access recertification follows every reorganisation. Within 30 days of a restructure, managers certify the entitlements of everyone who took on new responsibilities. Segregation of duties checks run before approval.
5. Shared and OT credentials have a rotation runbook tied to leaver events. The runbook names the systems, the maintenance constraints and the responsible person. It exists before it is needed.
6. Evidence is generated, not assembled. Revocation timestamps, session recordings and certification results are recorded as they happen. Gulf regulators increasingly expect this. ADGM firms report material incidents within 24 hours. Kuwait’s new national controls require a continuous asset and access inventory. DFSA operational resilience rules will ask who had access to critical services and when it was removed.

A layoff is a stress test you did not schedule

A mature identity program looks the same on a layoff day as on any other day. Dashboards green, revocations at 100%, nobody holding rights they no longer need. What separates that from a months-long cleanup is whether identity was built as a system or run as a queue of tickets.

If your organisation is restructuring, or supplies critical infrastructure to one that is, now is the time to find out which one you have.

Frequently asked questions

What is an orphaned account?

An orphaned account is a user, service or application account that stays active after its owner has left the organisation or changed roles. Nothing links it to a current HR record, so nobody reviews it, and it keeps working until someone finds it or an attacker uses it.

How fast should access be revoked when an employee is laid off?

Privileged and administrative access should be revoked on the day of notice. Standard access can stay until the last working day if the business needs it. In a mature identity program revocation is triggered automatically by the termination record in the HR system, not by a ticket.

Why is offboarding harder in OT environments?

Industrial systems often rely on shared operator accounts and local accounts on controllers and HMIs that are not connected to any directory. Credentials have to be rotated by hand, often only during maintenance windows. A privileged access broker that injects and rotates credentials removes the need for engineers to know the passwords at all.

UDV Technologies helps industrial and critical-infrastructure organisations across MENA and Southeast Asia build identity and access management programs that hold under pressure: identity governance, privileged access management and secure OT access. Talk to our team to review your leaver process before it is tested for you.