Departed administrators leave active API tokens
A 900-person logistics company centralizes Okta administration in a 25-person IT team. Over 18 months, the team had high turnover. A new identity lead discovers 11 active API tokens in Okta. Three tokens are owned by administrators who left more than six months ago; one is used by a CI job that creates users from Workday, but its owner is unknown. Two tokens have the Super Administrator role, and five have Read-only Administrator. The helpdesk also has 14 agents with the Help Desk Administrator role; three of those agents were contractors whose contracts ended last month but whose Okta accounts are still active. The company has no token inventory, no expiry standard, and no admin MFA policy separate from the general user policy. System Log shows one token used from a new country last week.
1. Prioritize the remediation steps for the API tokens. What would you do first and why?
Read the worked answer
First, build an inventory: token owner, role or scopes, last-used time, source IP, and the job it supports. Then prioritize by blast radius. The two Super Administrator tokens come first, especially any owned by departed admins. I would not revoke the unknown CI token blindly because that could stop Workday user creation. Instead, identify the CI job, create a dedicated service identity with least privilege, rotate the token, and then revoke the old one. Revoke tokens owned by departed admins after confirming no active integration depends on them. For the Read-only Administrator tokens, validate whether they are still needed and rotate or remove them. The new-country event should be investigated in parallel, because it may indicate token misuse. Remediation order should protect availability while reducing the highest privileges first.
2. How would you redesign admin access to reduce this risk, including roles and authentication?
Read the worked answer
Move admin access to group-based, least-privilege role assignments and review them quarterly. Use custom admin roles where the built-in roles are too broad, and separate helpdesk duties from super admin duties. Require a dedicated admin MFA policy with phishing-resistant factors such as FIDO2 or FastPass, not just the general user policy. For integrations, replace long-lived API tokens with OAuth 2.0 service apps scoped to the minimum required operations, and assign each integration a named owner. Rotate credentials on a schedule and at owner departure. Contractor accounts should be tied to contract end dates and deactivated automatically. The goal is to make privileged access attributable, time-bound, and reviewable rather than relying on anonymous tokens and shared admin roles.
3. What evidence would you collect to determine whether the token used from the new country was compromised?
Read the worked answer
I would pull System Log events for the token's actor, the source IP, user agent, target resources, and the actions performed. I would compare the new-country activity with the token's normal baseline and check whether it made user, group, policy, or app changes. I would also review MFA events and admin role changes around the same time, because a token can be used to create persistence. If the token belongs to a departed admin or an unknown CI job, that raises the risk. Containment would include revoking the token, rotating any dependent integration credential, and checking for unauthorized changes. The judgement is to treat the event as a potential compromise until the token owner and the action pattern are explained, rather than dismissing it as a geographic anomaly.