DRIUS Blog
Product updates and security notes
Short, practical updates on reliability, security, and product improvements for identity teams.
Oct 21, 2026 · Andrius
Every time I talk to another Okta admin about backups, I hear the same thing: "We don't need backups, we have the System Log."
I get it. The System Log is great. When something breaks, it's the first place I look. But after years of running Okta, I've learned the hard way that the log tells you what happened. It doesn't give you back what you lost.
What the System Log is good at
If someone deletes a group, changes a policy or edits a network zone, the log will usually tell you:
- what kind of change it was
- who made it (or which API token or app)
- when it happened
That's the starting point for every investigation, and nothing replaces it.
What it can't do
1. It doesn't hold the "before" picture
For most configuration changes, the log records that a policy or rule changed, not the full settings it had before. If someone edits a sign-on policy rule, you know it was touched. You don't get back the exact conditions, factors and session settings it had yesterday.
2. Deleted objects take their connections with them
Delete a group and you lose more than the group: its members, and its place in your rules and policies. Okta even sets affected rules to INACTIVE (we tested this). Rebuilding means piecing together memberships and references from scattered log events, as long as they're still within your log retention window.
3. A recreated object isn't the same object
Rebuild a group with the same name and Okta gives it a new ID. Anything that pointed at the old one won't point at the new one.
4. It doesn't tell you what's safe to put back
The log can't answer the questions that matter during a fix: If I put this back, what else changes? Is something else depending on it? Will I overwrite something a colleague fixed this morning?
What a configuration backup adds
That's the gap we built DRIUS to fill. DRIUS takes regular snapshots of your Okta configuration, so when something changes you have the before picture, not just the fact that something happened.
And before anything is written back, you see a review of exactly what will change: what gets created or updated, what's in Okta now next to what's in the backup, plain-English risk warnings, and the order things need to happen in. Nothing changes in Okta until you approve it. (More on how DRIUS restores.)
Use both
This isn't logs vs. backups. You need both:
- The System Log tells you who changed what, and when.
- A configuration backup lets you see exactly what it looked like before, and put it back safely.
If you've ever spent a Friday afternoon rebuilding a group from screenshots and memory, you already know which one you were missing.
DRIUS is in early access for Okta admins. If you'd like to try it on a sandbox or preview org, get in touch at drius.io.
Sep 29, 2026 · Andrius
While building DRIUS I spent a lot of time deleting things in a test Okta org on purpose. The most surprising one was groups. Deleting a group does more than most admins expect, and some of it happens quietly.
Here's what we saw in our sandbox.
1. The group is gone for good
There's no recycle bin for groups in Okta. Once it's deleted, it's deleted. The old admin URL for the group just returns a not-found page.
2. If you recreate it, it's a different group
You can create a new group with the exact same name, but Okta gives it a new ID. Anything that pointed at the old group by ID, policy rules, app assignments, scripts, doesn't know about the new one. Same name, different group as far as Okta is concerned.
3. Okta removes it from your policy rules
If the deleted group was used in a policy rule, for example an app sign-on rule that applied to that group, Okta takes it out of the rule for you.
4. And then deactivates the rule
This is the one that catches people. After removing the group, Okta sets that rule to INACTIVE. The policy itself still shows ACTIVE, so at a glance everything looks fine. But the rule that used to apply to those people isn't running anymore, and they fall through to whatever rule comes next.
Depending on how your policies are set up, that could mean a different MFA requirement, or a different access decision, for a whole group of people. Nobody gets an alert about it.
One thing we haven't tested yet
What if the deleted group was only in a rule's exclude list? Does Okta deactivate that rule too, or does the exclusion just get smaller, which would quietly widen who the rule applies to? We're going to test it, and I'll update this post when we do. If you already know, I'd like to hear from you.
How DRIUS handles it
This is the scenario we used to test DRIUS restore end to end:
- If you try to restore just the policy, DRIUS refuses and tells you the group no longer exists in Okta and needs to be restored first. It doesn't write anything.
- Restoring the group recreates it and adds the members back from the backup. You see how many were expected and how many were added.
- Restoring the policy afterwards points the rule at the new group ID, and tells you it did, with the old and new IDs.
- DRIUS warns you that the rule is still INACTIVE. For now, reactivating it is a manual step in Okta, on purpose: turning access rules back on is something you should decide, not something a tool should do behind your back.
The takeaway
Before you delete a group in Okta, check where it's used in your policies. And if you've deleted groups recently, it's worth looking at your rules for anything sitting at INACTIVE that you didn't turn off yourself.
If you want a safety net for this kind of thing, DRIUS is in early access at drius.io.
Sep 15, 2026 · Andrius
Every Okta admin I've talked to asks some version of the same question about restore tools: "What is this actually going to do to my production org?"
It's a fair question. A restore is a write. If the tool gets it wrong, you've turned one problem into two. So we built restore in DRIUS around one rule: nothing gets written to Okta until you've seen exactly what will change and approved it.
What you see before a restore
When you pick something to restore, a group, a policy, a network zone, DRIUS builds a plan first. For every field that would change, you see three things side by side: the field, what's in Okta right now, and what's in the backup.
The plan also calls out the changes that deserve a second look, like a rule that denies access, a network zone change, a new object being created, or members being removed from a group. Those don't get buried in a long list.
If nothing would change, the plan tells you that too, and there's nothing to approve.
Okta gets checked three times
Okta doesn't stand still while you're reading a plan. Someone else on your team might be making changes at the same moment. So DRIUS reads your live Okta three times during one restore:
- When the plan opens, so you see the current state.
- When you click Queue restore, to make sure nothing changed while you were reviewing.
- Right before the write, as a last check.
If Okta changed at any point, DRIUS stops and shows you a fresh plan. It won't apply a plan you approved against an Okta that no longer looks like that.
All three checks are reads. We have a test that runs every kind of restore plan and confirms that every request DRIUS sends to Okta during the preview is a read. If someone ever accidentally added a write to the preview code, that test fails.
Big restores get split, not half-done
Okta's rate limits are real, especially on smaller orgs. If a plan would take too long to build or too many API calls, DRIUS doesn't push through and leave you with a partial picture. It tells you the restore is too large to review at once and asks you to split it into smaller pieces.
Removing group members is opt-in
By default, restoring a group adds back the members who were in the backup. It doesn't remove anyone who's been added since. Removing people from groups can lock them out of apps, so that's not something a tool should do quietly.
If you do want the group to match the backup exactly, you can tick "also remove members not in the backup." Before anything happens, you see the names of the people who would be removed. It's off by default, only owners and admins can use it, and every removal is recorded in the audit log.
Why this matters
A backup is only as good as your confidence in restoring from it. If you're nervous about what restore will do, you'll put it off until things are already bad. The goal is that clicking restore in DRIUS feels boring: you see the plan, it matches what you expected, you approve it.
If you run Okta and want to try it on your sandbox org, request early access at drius.io.
Dec 27, 2025
We shipped improvements that make onboarding new customers faster and more reliable, while introducing new tenant-admin security controls aligned with common compliance expectations.
Highlights
- Improved onboarding flow: faster setup for new tenants with fewer manual steps and more consistent configuration.
- Tenant security policies: admins can enforce security requirements at the tenant level, including step-up verification for sensitive actions.
- Network controls (higher tiers): optional IP-based access restrictions for admin access.
- Session protections (higher tiers): configurable session lifetime and idle timeouts.
- Auditability: expanded logging around sensitive security and administrative actions.
These changes strengthen the platform's operational reliability and security posture without adding friction for everyday use.
We're building DRIUS the way security teams expect software to behave: policy-driven, enforceable controls, auditability, and repeatable operations.
