Sep 29, 2026 · Andrius

What happens in Okta when you delete a group (we tested it)

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.