Getting identity automation to work is one thing. Keeping it working when apps change is another. Here's how Cerby handles both.
Disconnected applications that lack SSO, SCIM, or the APIs needed for identity management can be automated. The harder question is what happens when those applications change.
Drift management is how Cerby detects, diagnoses, and repairs connector failures caused by application changes, so lifecycle and credential management tasks can be completed. Cerby uses deterministic code to execute sensitive identity actions, AI to propose connector fixes, and engineer approval before those fixes go live.
What is drift in identity automation?
It’s Monday morning and business as usual. An offboarding request for a department sales rep went through on Friday. The identity provider marked it complete, and the governance dashboard is green across the board.
But somewhere in a marketing analytics tool the company signed up for three years ago, that rep’s account is still active. This is not due to carelessness or human error. The analytics tool recently shipped a redesign, and the “remove user” button moved from the settings page into a new admin panel. The script used to click it looked in the old spot, found nothing, and stopped.
No one was alerted, and no one knew this happened. That small yet impactful moment is what we call drift.
Why do application changes break identity automation?
Disconnected apps are apps your identity stack can’t talk to directly. They don’t support SAML or SCIM, or they don’t offer an API that does what you need. To manage access in them, an automation has to work the way a person would: log in, navigate, click, fill in a field.
That works until something in the app changes, which happens frequently. Maybe a login screen moves, or a field gets renamed. Perhaps a new verification step appears or an API starts returning something slightly different. An automation built against the old version can stop working. When that happens, authentication, authorization, and posture management automation tasks may not complete successfully.
The problem is that these apps were never built to be managed by your identity stack, so every update can break whatever automation you built around them.
How Cerby handles drift
Getting an automation to work once is one challenge. Keeping it working as the app evolves is the hard part. That’s where homegrown scripts and one-off connectors break down.
We make that our job. Drift management is how Cerby auto-heals across its connectors: we find the change, fix the connector, and finish the task.
Across Cerby customers, roughly 6,400 app changes in a year broke live automations. That works out to about 17 breaks every single day. Each one is small on its own, and together they add up to a full-time job that no one signed up for.
Of those roughly 6,400 breaks in a year, Cerby fixed every one for every affected customer. These figures come from Cerby's connector catalog and US production data (2026).
Every break caused by an app change runs through the same loop. It's detected, diagnosed, and repaired, then the original task is retried, with global support coverage behind it. Cerby's AI model identifies the change and proposes a fix, but a Cerby engineer reviews and approves it before it goes live.
How Cerby detects, repairs, and retries identity automations when an application changes. Cerby's deterministic connector carries an identity request from an IdP or IGA to an app without SAML or SCIM. If an application change causes a failure, Cerby detects it, AI analyzes the change, an engineer approves a fix, the connector is patched, and the task is automatically retried.
Why deterministic identity automation matters
Predictable actions inside your apps
The code that acts inside your apps is deterministic. Creating a user, rotating a credential, removing access: each runs through defined code, in a defined sequence, every time. AI helps figure out the fix. It doesn't improvise inside your systems. As more teams sort out how much they're willing to let AI do on its own, that line is worth drawing clearly.
AI proposes, people approve
When something breaks, Cerby's own AI model (which learns from thousands of automation runs a day) pinpoints what changed and proposes a fix. That's where the speed comes from. With AI-led remediation, fixes to app changes happen 72 times faster.
A Cerby engineer then reviews and approves every fix before it goes live, and records that approval. For anyone who answers to an auditor, that means you can show what changed, what was done about it, and who signed off.
What makes Cerby different from other ways to secure disconnected apps?
For apps without SSO, SCIM, or an API that supports the identity tasks you need, the question isn't just whether you can automate access. It's who keeps that automation working when the app changes.
Homegrown scripts and one-off connectors can automate individual tasks. But when a login flow changes, a button moves, or a field gets renamed, someone has to diagnose the failure, update the automation, and retry. That ongoing maintenance becomes the IT team's responsibility.
Some AI-driven approaches use a model to decide actions dynamically while navigating an application. Cerby's approach draws a different line: identity actions run through deterministic code, while AI identifies and proposes repairs when application changes interrupt a connector. An engineer approves each repair before deployment.
Cerby maintains the connectors as apps evolve, so your team isn't left babysitting a pile of scripts. It reaches out only when your team needs to act.
One platform watching every connector
Connectors run on CHAOS, Cerby's secure automation platform, which works across any app and any runtime. Its monitoring works the same way everywhere, so failures are fast to diagnose no matter which app they come from.
What it means for your team
Today, 79% of automation runs on Cerby finish without anyone having to touch them. They complete automatically, across more than 1,000 supported business apps. Cerby owns the repairs and reaches out only when your team needs to act.
Lior Zagury, Director of Global IT at monday.com, described what that looks like from the customer side:
“If there are some issues or any Drift, we have the visibility and the understanding that something is off-sync, and then we are just immediately doing the configuration, and it's working back on.”
Let’s take it back to your Monday morning, where everything is running business as usual. Only now, your drift is managed. An application ships a redesign, a button moves, and the offboarding task fails on its first try.
But this time, what happens next is different. The failure is caught, the change is identified, an engineer approves the fix, and the task retries and finishes without anyone on your team having to chase it. The rep’s access is removed, and the green dashboard tells the truth, just as it should.
Your apps will keep changing. And now, with Cerby, that’s just fine.
Frequently asked questions
Can Cerby automate access to apps that don't support SSO or SCIM?
Yes. Cerby works with applications that don't provide the standard identity integrations needed for access management. Its connectors can create users, remove access, and rotate credentials through defined workflows.
What happens if an app changes during employee offboarding?
A changed login flow, button, or admin page can interrupt the access-removal task. Cerby detects the failure, uses AI to propose a connector repair, has an engineer approve it, and retries the original task once the connector is fixed.
How is Cerby's approach different from maintaining custom scripts?
With a custom script, your team typically has to notice failures, investigate changes, and update the code. Cerby maintains its connectors and handles repairs as apps evolve, so that work doesn't fall back on your IT team.
Does Cerby's AI decide which identity actions to take inside an app?
No. Cerby's identity actions run through deterministic code in a defined sequence. AI is used to help diagnose connector failures and propose fixes, which an engineer reviews before they go live.