Okta Penetration Testing and Tenant Review

Okta’s own platform is hardened and heavily scrutinised. The risk in almost every tenant we look at sits in the configuration: a sign-on policy with a rule that matches before the strict one does, a network zone trusting an office IP range nobody has used since 2021, or a group rule granting an application to more people than intended.

Why Okta findings are configuration, not code

The failure modes are specific and repeatable. Apps still assigned to the shared default sign-in policy with its catch-all rule. A sign-in redirect URI with Allow wildcard ticked. An SSWS API token created under a super admin account. A nightly script calling that token, so it never lapses. A help desk role that can reset factors for admins.

An Okta API token inherits the privilege level of the admin who created it, and when that admin’s role changes the token’s level changes with it. Tokens are valid for 30 days from last use, and every API call refreshes that, so a script that calls the token at least monthly keeps a super admin token valid. Read Okta’s API token guide for the exact behaviour.

We attack it as a standard user, then as a help desk admin, then with one stolen API token. We try each sign-in rule, redirect URI and token to see which apps and users we can reach, and what we can reset, change or export. So we pen test the tenant the way an attacker holding one valid credential would, then again as a low-privilege admin. Okta is one of several identity platforms we publish pages for, and we pen test others besides. ISO 27001, SOC 2, PCI DSS and Cyber Essentials Plus audits accept manual penetration test evidence. Scan-only evidence is generally insufficient.