Contractor Conversion Leaves Live ERP Access

There are two independent causes, and they need different fixes.

Cause 1 - membership source. ERP access comes only from Finance-App-Users, but that group has two kinds of member:

• Rule-added members. Okta re-evaluates a rule when the user's profile changes or the rule is edited, not on a schedule. For the 114 rule-added users, the department value now flows from AD, but the vendor CSV keeps re-asserting department=Contractor for up to 72 hours, so the rule keeps matching.
• Manually added members. The 6 users added by an admin during the Q4 project are a separate problem: Okta group rules never remove members that a human added by hand. Their membership survives every rule run until someone removes it explicitly.

Cause 2 - session persistence. Removing a group membership does not terminate a live SAML session at the ERP. Okta ends its own session; the service provider keeps its own cookie until its own timeout. Access can therefore outlive the fix by one full SP session lifetime, which is exactly what the journal entry shows.

Confirming evidence. Query eventType eq "group.user_membership.remove" for the 120 across the conversion window. No events means no rule has fired. Open the group and check the membership source column to separate rule-added from admin-added users. Then look for user.session.end and user.authentication.sso events after the conversion timestamp; SSO events after the HR change confirm the SP session was still valid. Absence of session-end events shows nobody revoked anything.

Before 02:00 (containment, in this order):

1. Remove the 6 manual memberships. These will not self-heal and are the clearest audit finding.
2. End Okta sessions for all 120 users (user.session.end), then have the ERP administrator terminate the SP-side sessions or trigger SAML single logout. Ending only the Okta session leaves the ERP cookie intact.
3. Correct the vendor feed so department is not sent as a static value; if the vendor cannot fix it tonight, quarantine the CSV import rather than re-running a known-bad payload.
4. Take a CSV export of Finance-App-Users before any rule edit so you can restore exact membership.

Permanent changes:

• Make Finance-App-Users a rule-only group. Document and enforce 'no manual adds to entitlement groups'; where an exception is genuinely needed, use a separate, time-boxed exception group with an owner and an expiry date rather than a manual membership.
• Change app assignment for high-value apps so it comes from a small number of audited, rule-driven groups, not ad hoc memberships.
• Stream System Log events to the SIEM and alert on group.user_membership.add where the actor is a human and the target group grants a privileged app.
• Add a pre-import validation step: reject or alert on any CSV row where department disagrees with HR for more than one cycle.
• Run a quarterly access certification on Finance-App-Users so a stale membership cannot survive a quarter again.

Validation has to be evidence-based, because a group rule mistake is silent until someone loses access.

Before saving:

• Use the rule preview to see exactly which users would be added and removed. Compare that list against the expected 120 and against the pre-change export. Any name outside those two sets means the condition is too broad.
• Check rule priority. If another rule can also add a user to the same group, document which one wins for the overlapping population.
• Test with a small pilot group first: one converted employee, one rule-added contractor, one manually added user, and one employee whose department is genuinely Finance. Confirm each behaves as predicted.
• Rehearse the rollback: restoring the CSV export of memberships is faster and safer than rewriting rules under pressure.

After the change, monitor for 72 hours:

• Count group.user_membership.remove events and confirm the total matches the expected population; a larger number means the rule condition over-matched.
• Watch help-desk ticket volume and user.authentication.sso failure rates for the ERP app. A spike usually means legitimate employees lost the entitlement.
• Watch for user.account.update_profile events from the CSV import reverting department values, which would re-add users on the next run.
• Confirm the 6 previously manual users no longer appear in the group and that no new manual adds appear.

Schedule the change for a low-traffic window and have the ERP administrator on call, since SP-side session termination cannot be done from the Okta console alone.