Your Okta baseline was solid on day one. Is it still?
When you finish a new Okta deployment, the configuration is exactly as it should be. Policies are set correctly. Network zones are defined. Authenticators are configured. The security baseline your best engineers designed, reviewed, and approved is in place.
Then time passes.
A few months in, a client's IT contact adjusts a policy setting—they had a good reason at the time, and they didn't realize it affected something downstream. Your team adds a temporary exception to address a single issue, but doesn't get around to removing it. A new engineer at your MSP creates a group with a slightly different name than your standard, and now you have two groups doing similar things. Nothing dramatic. Just the normal accumulation of small changes that happens in any live environment.
This kind of configuration drift isn't unique to Okta — it's a reality across any platform with broad reach and deep configurability. But Okta configuration drift has particular consequences for MSPs, because the policies and settings you configure are the access controls your clients depend on every day. And when you're managing a portfolio of client orgs, small deviations can quietly multiply across your entire customer base.
That's where delivering Okta through ZeroTek, and managing it with ZeroConfig, makes a meaningful difference.
Drift isn't just a co-management problem
Co-managed environments—where clients have some level of admin access to their own Okta tenant—are the most obvious setting for configuration drift. A technically capable client admin makes a change that seems reasonable in isolation but conflicts with the intended policy structure. It's not malicious. It's just the natural result of two parties sharing access to the same system without perfect alignment.
But drift happens in fully-managed environments too. Engineers turn over. Institutional knowledge walks out the door. Exceptions get made during incidents and never cleaned up. Features get enabled experimentally and forgotten. A configuration that was carefully designed and correctly deployed can diverge from the intended baseline over months and years without anyone making a single dramatic mistake.
The problem is that small deviations in identity configuration can have real consequences. A policy that's been inadvertently weakened might allow access from locations or under conditions that weren't intended. A group that's been renamed or misconfigured might mean that users aren't getting the right policies applied. Access controls that looked tight on day one may have quietly developed gaps.
Confirming your baseline used to be slow
Before ZeroConfig, verifying whether an Okta tenant still matched your intended configuration was a meaningful project. You'd need to go through each policy, each setting, and each configuration component—manually comparing what's there to what should be there. For a properly configured org, that review could take 45–60 minutes per tenant. Across a portfolio of clients, that's not something you can do on a regular cadence without dedicating real staff time to it.
The result, in practice, was that many MSPs checked for drift reactively—when something surfaced as a problem—rather than proactively.
What ZeroConfig does about it
ZeroConfig includes a Report mode that compares any Okta org's current configuration against the assigned ZeroConfig template and shows you exactly where each org matches or deviates. It covers the components your template manages, including groups, network zones, authenticators, policies, and Okta ThreatInsight settings.
For Mantle Group, that review now takes about two minutes: "It's immediately obvious whether changes occurred—and exactly where they were made compared to the assigned configuration."
Element Technologies clocked the improvement at 22x faster to identify configuration drift.
When you find drift, you have options. You can review the deviation and decide it's intentional—a client-specific adjustment that should stay in place (in which case you might create a client-specific template to reflect it). Or you can run ZeroConfig in Report and Modify mode, which pushes your baseline configuration back to the org, documents exactly what changed, and gives you a clear before-and-after view of what was remediated.
That last point matters for client communication. As Element's Jeff Regan put it: "Transparency with our clients is really important around here. So we really like that ZeroConfig makes it so easy to show clients exactly what's changing before we make the changes."
Consistency is what makes everything else work
The case for staying on top of configuration drift isn't just about catching mistakes. It's about the operational value of consistency across your client base.
When your tenants are consistently configured, automations you build for one client can run across all of them. Your engineers don't have to treat each tenant as a separate puzzle. And when something does need to change—a policy update your security team has decided to apply broadly—you can do it efficiently rather than working through each tenant individually.
ZeroConfig won't catch every possible change to an Okta org—it covers the specific components that templates manage. But for the core identity configuration that defines the baseline security standard for how your clients' access controls work—or for any other configuration you define as a standard for any number of Okta orgs—it gives you a fast, reliable way to know where you stand.
If you'd like to see it in action, book a discovery call and we'll walk you through it.