Over the past year, incident response teams have had a front-row seat to a wave of SaaS-driven intrusions where attackers exploited identity trust and operational gaps instead of software vulnerabilities. In my prior role, I had a deep visibility into our customers’ incident response efforts and saw firsthand how even well-prepared organizations still struggled when facing threat actors like ShinyHunters and Scattered Spider.
Public reporting and IR investigations have shown these groups repeatedly target Salesforce environments through telephone-based social engineering, or vishing attacks. Once access is obtained, attackers move quickly, harvesting credentials and tokens to pivot laterally across identity providers and cloud platforms, most notably Okta and Microsoft 365. In many of these incidents, Okta became the critical control plane that determined whether an incident stayed contained or expanded across the enterprise.
What stood out most during these incidents was that Okta was rarely the initial point of compromise, but it was frequently the deciding factor in blast radius, meaning organizations that didn’t use Okta had a higher risk of a widespread attack. Weak authentication policies, permissive MFA configurations, insufficient alerting, and limited identity visibility allowed a single SaaS breach to cascade across multiple platforms and environments.
In this post, we’ll walk through how these attacks unfold from an identity perspective, where Okta defenses most often break down, and how an Okta-focused security playbook can help reduce the likelihood and impact of modern SaaS-driven incidents.
Note about Okta Engines
There are two versions of Okta: the legacy Okta Classic and the Okta Identity Engine, the upgraded version. Okta Identity Engine offers more advanced and customizable settings, so the first priority when using Okta should be to update to the Identity Engine. This post will focus on the security settings available in Okta Identity Engine.
Methodology of an Okta Audit
Okta has a lot of settings, and many of them are interdependent with one another, so it is important to follow a risk-based methodology to quickly check the most critical areas first.
Each Okta organization has a different threat profile, so it is important to understand the broader security context of your organization first. This will help set the guidance for which settings should be enabled and how bypasses may occur to further target your search.
After your threat model is understood, you can begin reviewing each Okta policy in layers. This should be done from the outside in, going from Global Session Policies, Authenticator Enrollment policies, Account Management policies, Application Sign-In Policies, User Profile Policies, and finally to Notification settings. After reviewing all of these policies, you will have a strong picture of your organization’s security policy and be able to tweak any necessary settings or policies to keep attackers out and your applications secure.
Steps for Auditing an Okta Organization
Step 1: Survey the Broader Context
The foundational configuration of an Okta organization includes which authenticators are enabled, which external identity providers (IdPs) are in use, and how network zones are defined.
Authenticators determine what types of Multi-factor Authentication (MFA) are possible. Weak MFA, or no MFA at all, can lead to account takeover if passwords are compromised. Identifying users without MFA helps determine whether MFA enforcement is actually present on all accounts.
External IdPs are a critical threat boundary that determines membership to your Okta org. They shift assurance outside of Okta, and so only trusted IdPs should be enabled on an Okta organization. It is very important to audit these IdPs for unknown, inactive, or misgrouped users.
Network zones are also often used as implicit trust boundaries. Even though network zones should never be the only control for Okta logins, they are a strong defense-in-depth measure. Reviewing the number, scope, and ownership of defined network ranges is especially important, as broad or public IP ranges can significantly weaken authentication decisions.
Okta Behavior Detection should also be reviewed to confirm that meaningful security signals, such as new devices, IPs, locations, and velocity, are defined and reasonably tuned.
Step 2: Global Session Policies
Global session policies (Admin Console → Security → Global Session Policies) define how Okta sessions are created. These policies determine whether MFA is required for logins, how long sessions remain valid, and whether re-authentication is required.
Because application access is evaluated only after a session exists, weak global session policies cannot be fully mitigated later. A review should therefore start by assessing whether global session policies consistently enforce strong MFA and whether contextual signals such as networks or behaviors are used appropriately.
The main settings to review here are whether sessions can be created without MFA, whether untrusted IdPs are used in rules, if sessions are overly long, whether network zones are used as part of your session policies, and if so, whether they are overly broad.
Step 3: Authenticator Enrollment
Authenticator enrollment policies (Security → Authenticators → Enrollment) determine which MFA devices users are allowed to enroll. These policies do not control when MFA is prompted (this is handled by the Global Session Policy), but whether MFA actually exists on user accounts.
It is important to confirm that MFA enrollment is mandatory for all interactive users, and to understand how users without enrolled MFA are handled. Enrollment policies are closely tied to password configuration and recovery behavior, making them a key area for identifying MFA enrollment abuse and account takeover persistence.
Within this step, it is also important to review your organization’s password policies, as this is the first factor that is used for a user to authenticate. A strong password policy should enforce password complexity, restrict commonly used passwords, and enforce password history checks.
The key settings to review here are whether strong MFA devices are enabled (such as WebAuthn and Okta Verify), whether overly long grace periods are enabled for authenticator enrollment, and whether any authenticator enrollments are Optional or Disabled.
Step 4: Account Management
The Okta Account Management Policy (Security → Authentication Policies → Okta account management) governs authentication for sensitive actions such as password changes, MFA setup, and account recovery. Weak protections in this area can allow attackers to bypass otherwise strong login controls.
Reviewing the Okta management policy should assess whether single-factor authentication is ever permitted for account management actions, and whether users without a second factor can modify or recover accounts in a way that undermines MFA enforcement.
Step 5: Application Sign-in Policies
Application sign-in policies (Security → Authentication Policies → App Sign-In Policies) are the final layer that define how access to individual applications is protected after an Okta session exists. These policies should be reviewed within the context of global session behavior. Particular attention should be paid to:
- The default policy
- The policy assigned to Microsoft 365 (as it may potentially support legacy insecure authentication protocols)
- Policies assigned to sensitive applications such as VPNs or cloud platforms
- Whether policies make use of Behavior to reject suspicious sessions
Common issues include catch-all rules that allow password-only access, legacy authentication protocols that bypass MFA, and conditional logic that unintentionally weakens enforcement based on platform or network conditions. Policies should be highly specific and use modern authentication protocols.
Step 6: User Profile Policies
User profile policies do not directly control authentication, but they influence account recovery, attribute-driven access, and persistence after compromise.
A review should confirm that users cannot modify profile attributes that affect access, group membership, or recovery workflows, and that authoritative sources such as directories or HR systems are clearly defined. Any profile attributes that affect access should be limited to admin users and highly restricted.
Step 7: Notifications and Monitoring
Critical actions should be alerted and monitored for reactive incident response. Alerts and monitors are not proactive security controls, but do help identify malicious activity within your Okta organization, so they should be your last step in an Okta organization review.
Your review should confirm that security notification emails should be sent for all critical account actions, such as: Sign on from an Unknown Browser, Password Change, New Authenticator Enrollment, and Authenticator Reset. Furthermore, Suspicious Activity Reporting should be enabled to allow end users to report any notifications or actions they were not expecting. This will help expedite your security response process for finding new incidents.
It is also important to ensure that ThreatInsight is enabled and that policy denials are monitored routinely. Your system log should be retained for an appropriate amount of time, and routinely exported to an external SIEM for further analysis.
Your Checklist for Auditing Okta Security
- Upgrade Authentication Engine to Identity Engine
- Any remaining Classic Engine policies have been migrated or retired
- Survey your Okta landscape
- Identify which Okta orgs are in scope
- Understand which authenticators are defined
- Understand what external Identity Providers (IdPs) are in use
- Review what network zones are enabled, both the number and the ranges
- Ensure that behavior detection settings are enabled
- Review Global Session Policies
- Ensure that MFA is required before a session can be created
- Ensure that strict session lifetimes are set
- Review Authenticator Enrollment
- Ensure that weak authenticators like SMS and security questions are disabled
- Verify that overly long grace periods are not enabled
- Review password policies for complexity, history, exclusions and reset rules
- Review Account Management
- Ensure that MFA is required for all account management actions
- Ensure that users without an MFA device cannot recover an account
- Review Application Sign-In Policies
- Ensure that no application sign-in policies support password-only access
- Ensure that applications do not use any legacy authentication protocols
- Audit policies to ensure there is no conditional logic that bypasses existing security controls
- Review User Profile Policies
- Ensure that users cannot modify any profile attributes that elevate their access
- Review Notifications and Monitoring
- Security Notification Emails are sent for critical account actions
- Suspicious Activity Reporting should be enabled
- Okta ThreatInsight is enabled
- Confirm Okta System Log retention and exports to an SIEM
You can also check out your Okta HealthInsight dashboard (Admin Console → Security → HealthInsight) for a quick programmatic audit. For a more detailed checklist see our Okta Security Assessment Checklist.
Conclusion
Okta is one of the most sensitive parts of an organization’s security posture, but it is often overlooked in security audits. Ensuring that secure settings are enabled across your org is the best way to build a strong defense around your internal resources.
In Okta Identity Engine, security controls operate in parallel across multiple layers. Global session policies, enrollment policies, application sign-in rules, password and recovery settings, and organization-wide detection features all contribute to the final authentication outcome. Effective Okta reviews require understanding how these layers interact in real authentication flows rather than evaluating individual settings in isolation.
If you need assistance reviewing your Okta configuration, having an independent perspective can help identify gaps that are easy to miss when focusing on individual policies. Reach out to Cloud Security Partners today for help reviewing your Okta organization, or other parts of your security posture, and setting you up for a more secure future.
Stay in the loop.
Subscribe for the latest in AI, Security, Cloud, and more—straight to your inbox.
