Reactivation restores stale privileges after a rehire
A 2,400-person services company uses Okta as its identity provider. HR sends joiner/mover/leaver events to Okta through SCIM. Six months ago, Priya N. left the company; her Okta account was deactivated but not deleted. Her old profile had been manually added to the IT Admins group during a six-week project, and that group is assigned a delegated admin role. She also had 14 direct app assignments, including a finance planning tool. Last week Priya was rehired into a different role in Finance. A helpdesk agent searched her name, clicked Reactivate, and reset her password. Within an hour, Priya could open the finance planning tool and the admin console. The access review is in two weeks. The company has a group rule that assigns Finance users to the finance tool, but Priya's access came from a direct assignment made during the project. There are 38 other dormant accounts older than 90 days.
1. What should the helpdesk agent have checked before reactivating Priya's existing account, and what risks did the reactivation create?
Read the worked answer
The reactivation was risky because reactivation restores the identity's prior state, not the state required by the new Finance role. Before clicking Reactivate, the agent should have reviewed the account's group memberships, direct app assignments, delegated admin role assignments, and last-login history. The IT Admins membership is especially dangerous: it was a manual assignment from a temporary project, and the group carries an admin role. Reactivation also restored 14 direct app assignments, including the finance planning tool, without manager approval. The correct judgement is that a rehire is not the same as a returning user with unchanged duties. The old account should have been cleaned first - remove privileged and project groups, remove direct app assignments, remove admin roles - or a new account should have been created and linked to the new HR record. If audit history requires keeping the old account, reactivate it only after access reset and document the approval.
2. Design a repeatable rehire process that prevents stale access while preserving audit history.
Read the worked answer
Treat a rehire as a new access decision, not as a button click. At the leaver event, the process should remove all group memberships that are not needed for audit history, remove direct app assignments, remove delegated admin roles, and revoke sessions and tokens. If the account must be retained, rename or annotate it and move it to a disabled container. On rehire, the HR event should create a new access request tied to the new manager and job code. Baseline access should come from group rules or access request workflows, not from restored manual assignments. Privileged access should require separate approval and a time-bound assignment. The identity team should also run a monthly dormant-account report and require justification before any reactivation. This preserves the old audit trail while ensuring the new role starts from least privilege.
3. Which three checks would you run before the upcoming access review to find similar cases?
Read the worked answer
First, list active users with no sign-in for more than 90 days and compare that list to HR status; dormant active accounts are the pool where stale reactivations hide. Second, compare group membership sources: identify users in privileged or app-assignment groups whose membership is manual rather than rule-based or request-based. Third, review all delegated admin role assignments and direct app assignments, especially those attached to users who have changed departments or been rehired. I would also pull the System Log for user.lifecycle.reactivate events in the last year and inspect each one for group and app changes immediately after reactivation. These checks focus the review on restored privilege rather than only on users who look inactive today.