When Identity Breaks, Everything Breaks: monday.com’s Lessons in Identity Resilience

Identity Is Plumbing

Lior's favorite analogy for identity is plumbing. When it works, nobody gives it a second thought. When it breaks, everyone feels it at once.

That's exactly what makes identity failures so tricky. Users don't report that the identity layer has failed. They report that the app they need won't load. So the first challenge in the monday.com incident wasn't recovery at all. It was figuring out what had actually happened.

Muli sees the same pattern across the companies Acsense works with. What looks like a dozen separate application outages is often a single identity problem rippling across the business. Misdiagnose it, and you burn precious time chasing the wrong fix.

How long can your business keep running if identity stops working?

You Can't Put It Back If You Don't Know What Changed

The instinct in any incident is to "just put everything back." But that isn't a recovery plan if nobody can say precisely what changed. To recover cleanly, monday.com's team needed answers to five questions:

1. What changed?
2. When did it change?
3. Which policies and objects were affected?
4. What did the environment look like before?
5. Which nearby changes were legitimate?

This is where configuration history earns its keep.

And during an outage, time is the whole game. Muli ties this directly to Recovery Time Objective (RTO). Most infrastructure teams have defined RTOs for databases, applications and storage. Identity is usually the blind spot.

When Acsense asks a new customer for its identity RTO, the honest answer is often that nobody has set one. An incident tends to fix that very quickly.

Recovery Is a Process, Not a Button

The second thing monday.com changed was the human side of recovery. Who needs to be in the room? Who has the authority to roll something back? Which systems come back first? Who owns each application? Who do you call when the restore doesn't behave as expected?

These questions are easy to answer on a calm Tuesday morning and painful to answer mid-outage. So Lior's team built a detailed playbook around them.

Crucially, they don't treat it as a document to write once and file away. Contacts change. Roles change. Applications and account managers change. The environment never stops moving, and the playbook has to move with it.

That's why monday.com runs regular drills. People behave differently when hundreds of users are waiting and leadership wants an ETA. A drill surfaces the gaps while the stakes are still low. As Lior sees it, that's the difference between having documentation and actually being ready.

A process nobody has practiced is still just an assumption.

Double the People, Triple the Work

When Lior and Muli first met several years ago, monday.com was a much smaller company with a far simpler identity environment. IT controlled which applications got connected, how provisioning worked and who made changes. There were fewer moving parts.

That world is fading fast. Employees now build their own applications. Teams spin up new SaaS services on their own. APIs are everywhere, automation reshapes environments continuously, and AI agents have joined the mix. Lior summed up the effect on his team in five words:

"Double the people, triple the work."

Lior Zaguri, Global IT Director, monday.com

Yet the core problem hasn't changed. Whether a change comes from an administrator, a script, an integration or an agent, the team still has to know what changed and whether the result is what the organization intended. What's different is the speed and the sheer volume of ways identity configuration can shift.

Agents Are Already Part of the Workforce

For Lior, AI agents aren't a future problem. They're here now. monday.com runs thousands of agents across the organization, alongside roughly 2,500 employees.

Both humans and agents need access to systems to do their jobs, but their risk profiles differ. Agents act through credentials and permissions, which makes identity governance more important, not less.

And as Muli pointed out, blocking the next risky action is only half the job. If a person, script or agent has already changed your identity configuration, you still need to understand what changed and whether it should stay.

A successful API call proves the operation went through. It doesn't prove the result is what the business wanted.

That's where the conversation shifts from recovery to assurance: after all these changes, is our identity environment still in the state we intended?

Passing an Audit Isn't the Same as Staying Secure

As a public company, monday.com lives with audits, controls and reviews. But an audit is a snapshot. It tells you what was true on the day it happened, and the environment keeps moving the moment the auditors leave.

People get promoted and switch teams. Application owners change. New permissions get granted. Temporary exceptions quietly become permanent. So the real operational question isn't "Did we pass the audit?" It's "Does our live configuration still match what we approved?"

Continuous Drift Detection

When a critical configuration changes, the team should see it, understand whether it was intentional and decide what happens next. Sometimes the right move is to restore the earlier state. Sometimes the change is legitimate, and the new state should become the baseline. What matters is that someone knows the difference.

This is the next frontier Acsense and monday.com are tackling together: bringing recovery, configuration history and continuous assurance closer together. The goal isn't to let software make every call automatically. It's to avoid discovering months later that your environment has quietly drifted away from what you thought you'd approved.

Lior's Advice to Other Identity Teams

By the end of the session, everything came back to three principles.

1. Have a Process

   Write down what will actually happen during an identity incident. Who gets called? Who makes the recovery decision? Which applications come back first? What does success look like? Don't assume the answers will be obvious once the outage starts.

2. Train the People Who Will Run It

   A recovery plan that's never been exercised isn't really a plan. Run the scenario. Let people make mistakes while it's still a drill. Find the missing phone number, the forgotten dependency and the fuzzy ownership before the business is waiting on you.

3. Use Technology That Supports the Process

   When something changes, your team should be able to see exactly what happened, compare it to the previous state and have a fast path back.

The Question That Comes Next

The goal isn't to eliminate every identity incident. That's unrealistic. The goal is to make sure the first time your team seriously thinks about recovery isn't while the whole company is locked out.

Identity is invisible when it works. Your preparation for when it doesn't shouldn't be.

Resilience is planning, not reacting.