v0.4.1-draft AI Drafted

Home / Guides / Okta

Okta Hardening Guide

Identity Last updated: 2026-08-08

Identity Provider hardening for SSO, MFA policies, and API token security

Product Docs API Docs Hardening Guide

Code Packs: Terraform API Scripts Config Sigma Rules

View:

Overview

Okta is an identity and access management (IAM) platform that controls authentication for 18,000+ organizations with 7,000+ integrations in its network. As the central authentication provider for enterprise applications, Okta represents the highest-leverage hardening target in most organizations. The 2022 LAPSUS$ breach and October 2023 support system breach (affecting all 18,400 customers via HAR file exfiltration) demonstrated how stolen session tokens grant attackers SSO access to thousands of downstream applications.

Intended Audience

• Security engineers managing identity infrastructure
• IT administrators configuring Okta tenants
• GRC professionals assessing IAM compliance
• Third-party risk managers evaluating SSO integrations

How to Use This Guide

• L1 (Crawl): Essential controls for all organizations
• L2 (Walk): Enhanced controls for security-sensitive environments
• L3 (Run): Strictest controls for regulated industries

Scope

This guide covers Okta-specific security configurations including authentication policies, OAuth/SCIM governance, session management, and integration security. Infrastructure hardening for Okta agents is out of scope.

---

Table of Contents

1. Authentication & Access Controls
2. Network Access Controls
3. OAuth & Integration Security
4. Session Management
5. Monitoring & Detection
6. Third-Party Integration Security
7. Operational Security
8. Compliance Quick Reference

---

1. Authentication & Access Controls

1.1 Enforce Phishing-Resistant MFA (FIDO2/WebAuthn)

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls	6.3, 6.5
NIST 800-53	IA-2(1), IA-2(6)
DISA STIG	V-273190, V-273191, V-273193 (HIGH), V-273194 (HIGH)

Description

Require phishing-resistant authenticators (FIDO2 security keys or platform authenticators) for all users, especially administrators. This eliminates vulnerabilities to real-time phishing proxies that bypass TOTP and push-based MFA.

Rationale

Why This Matters:

• TOTP and push notifications can be intercepted via real-time phishing (Evilginx, Modlishka)
• The October 2023 Okta breach was enabled by session cookie theft from HAR files
• FIDO2 binds authentication to specific origins, preventing token theft

Attack Prevented: Real-time phishing, session hijacking, MFA bypass

Real-World Incidents:

• October 2023 Okta Support Breach: HAR files containing session cookies were exfiltrated, affecting all 18,400 customers
• January 2022 LAPSUS$ Breach: Third-party support engineer compromised via social engineering

Prerequisites

• Okta tenant with MFA capabilities
• FIDO2-compatible security keys (YubiKey 5 series, Google Titan)
• Super Admin access for policy configuration
• User inventory for phased rollout

ClickOps Implementation

Step 1: Enable FIDO2 (WebAuthn) as Authenticator

1. Navigate to: Security → Authenticators
2. Click Add Authenticator → Select FIDO2 (WebAuthn)
3. Configure:
   • User verification: Required
   • Authenticator attachment: Cross-platform (for security keys) or Platform (for biometrics)
4. Click Add

Step 2: Create Phishing-Resistant Authentication Policy

1. Navigate to: Security → Authentication Policies
2. Click Add Policy → Name: “Phishing-Resistant MFA”
3. Add Rule:
   • IF: User is member of “Administrators” group
   • THEN: Authentication requires FIDO2 (WebAuthn)
   • Re-authentication frequency: Every session
4. Save and set priority above default policies

Step 3: Enforce for All Admin Access

1. Navigate to: Security → Global Session Policy
2. Create rule for Admin Console access requiring FIDO2
3. Apply to Admin groups

Step 4: Configure Authentication Policy Requirements Configure both Okta Dashboard and Admin Console policies:

1. Navigate to: Security → Authentication Policies
2. Click the Okta Dashboard policy
3. Click Actions next to the top rule → Edit
4. In “User must authenticate with”, select Password/IdP + Another factor or Any 2 factor types
5. In “Possession factor constraints are” section, check Phishing resistant
6. Repeat for the Okta Admin Console policy

Specification	Requirement
DISA STIG V-273190, V-273191	Phishing resistant box must be checked for Dashboard and Admin Console
DISA STIG V-273193, V-273194 (HIGH)	MFA required: “Password/IdP + Another factor” or “Any 2 factor types”

Time to Complete: ~30 minutes (policy) + user enrollment time

Code Implementation

Code Pack: Terraform

hth-okta-1.01-enforce-phishing-resistant-mfa.tf View source on GitHub ↗

# Enable FIDO2 (WebAuthn) as an authenticator
resource "okta_authenticator" "fido2" {
  name   = "FIDO2 WebAuthn"
  key    = "webauthn"
  status = "ACTIVE"
  settings = jsonencode({
    userVerification = "REQUIRED"
    attachment       = "ANY"
  })
}

# Signon policy requiring phishing-resistant MFA for admins
resource "okta_policy_signon" "phishing_resistant" {
  name        = "Phishing-Resistant MFA Policy"
  status      = "ACTIVE"
  description = "Requires FIDO2 for all admin access"
  priority    = 1

  groups_included = [var.admin_group_id]
}

# Rule enforcing FIDO2 on the phishing-resistant policy
resource "okta_policy_rule_signon" "require_fido2" {
  policy_id          = okta_policy_signon.phishing_resistant.id
  name               = "Require FIDO2"
  status             = "ACTIVE"
  priority           = 1
  access             = "ALLOW"
  mfa_required       = true
  mfa_prompt         = "ALWAYS"
  primary_factor     = "PASSWORD_IDP_ANY_FACTOR"
  session_lifetime   = 120
  session_persistent = false
}

Code Pack: API Script

hth-okta-1.01-enforce-phishing-resistant-mfa.sh View source on GitHub ↗

# Create FIDO2 authenticator policy
info "1.1 Creating phishing-resistant MFA policy..."
POLICY_RESPONSE=$(okta_post "/api/v1/policies" '{
  "type": "ACCESS_POLICY",
  "name": "Phishing-Resistant MFA Policy",
  "description": "Requires FIDO2 for sensitive applications",
  "priority": 1,
  "conditions": {
    "people": {
      "groups": {
        "include": ["EVERYONE"]
      }
    }
  }
}') || {
  fail "1.1 Failed to create MFA policy"
  increment_failed
  summary
  exit 0
}

POLICY_ID=$(echo "${POLICY_RESPONSE}" | jq -r '.id // empty' 2>/dev/null || true)

# Create policy rule requiring WebAuthn
info "1.1 Creating policy rule requiring FIDO2..."
okta_post "/api/v1/policies/${POLICY_ID}/rules" '{
  "name": "Require FIDO2",
  "priority": 1,
  "conditions": {
    "network": {
      "connection": "ANYWHERE"
    }
  },
  "actions": {
    "signon": {
      "access": "ALLOW",
      "requireFactor": true,
      "factorPromptMode": "ALWAYS",
      "primaryFactor": "PASSWORD_IDP_ANY_FACTOR",
      "factorLifetime": 0
    }
  }
}' > /dev/null 2>&1 || warn "1.1 Policy rule creation returned non-zero (may already exist)"

Code Pack: Sigma Detection Rule

hth-okta-1.01-enforce-phishing-resistant-mfa.yml View source on GitHub ↗

detection:
    selection:
        eventType: 'user.authentication.auth_via_mfa'
        debugContext.debugData.factor: 'FIDO2_WEBAUTHN'
    condition: selection
fields:
    - actor.displayName
    - actor.alternateId
    - client.ipAddress
    - debugContext.debugData.factor
    - outcome.result
    - published

Validation & Testing

1. Attempt admin login with only password - should be blocked
2. Attempt admin login with TOTP - should be blocked (if FIDO2 required)
3. Complete admin login with FIDO2 key - should succeed
4. Review System Log for successful WebAuthn authentications

Expected result: Only FIDO2-authenticated sessions can access admin console

Monitoring & Maintenance

Ongoing monitoring:

• Alert on authentication attempts that fail FIDO2 requirement
• Monitor for users bypassing policy via legacy sessions

Log query: See Code Pack section 1.1 (cli) above for the System Log filter expression.

Maintenance schedule:

• Monthly: Review FIDO2 enrollment completion rates
• Quarterly: Audit policy exceptions and temporary bypasses
• Annually: Review authenticator hardware lifecycle (key expiration)

Operational Impact

Aspect	Impact Level	Details
User Experience	Medium	Users must carry/use security keys
System Performance	None	No performance impact
Maintenance Burden	Medium	Key distribution and replacement
Rollback Difficulty	Easy	Can disable policy rule

Potential Issues:

• Lost security keys require backup authentication method
• Platform authenticators may not work on shared devices

Rollback Procedure:

1. Navigate to Authentication Policy
2. Disable or lower priority of FIDO2 requirement rule
3. Enable fallback MFA methods temporarily

---

1.2 Implement Admin Role Separation

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls	5.4, 6.8
NIST 800-53	AC-5, AC-6(1)

Description

Separate administrative privileges using Okta’s custom admin roles instead of granting Super Admin access. Create role-specific permissions for Help Desk, Application Admins, and Read-Only Auditors.

Rationale

Why This Matters:

• Super Admin compromise provides complete tenant control
• LAPSUS$ attack leveraged over-privileged support access
• Least privilege limits blast radius of compromised accounts

Attack Prevented: Privilege escalation, lateral movement via admin accounts

ClickOps Implementation

Step 1: Create Custom Admin Roles

1. Navigate to: Security → Administrators → Roles
2. Click Create new role
3. Create the following roles:

Help Desk Admin:

• Reset passwords
• Unlock accounts
• View user profiles
• NO: Edit policies, manage apps, access API tokens

Application Admin:

• Manage specific applications
• Configure SAML/OIDC settings
• NO: Manage users, access system settings

Security Auditor (Read-Only):

• View all configurations
• Access System Log
• NO: Make any changes

Step 2: Assign Roles to Specific Groups

1. Navigate to: Security → Administrators
2. Click Add Administrator
3. Select user/group and assign custom role
4. Limit scope to specific apps/groups if applicable

Code Implementation

Code Pack: API Script

hth-okta-1.02-admin-role-separation.sh View source on GitHub ↗

# Create custom Help Desk Admin role
info "1.2 Creating Help Desk Admin custom role..."
okta_post "/api/v1/iam/roles" '{
  "label": "Help Desk Admin",
  "description": "Limited admin for password resets and account unlocks",
  "permissions": [
    "okta.users.read",
    "okta.users.credentials.resetPassword",
    "okta.users.lifecycle.unlock"
  ]
}' > /dev/null 2>&1 && {
  pass "1.2 Help Desk Admin role created"
  increment_applied
} || {
  fail "1.2 Failed to create Help Desk Admin role"
  increment_failed
}

---

1.3 Enable Hardware-Bound Session Tokens

Profile Level: L2 (Walk)

Framework	Control
NIST 800-53	SC-23, IA-11

Description

Configure Okta to bind session tokens to specific devices using device trust and Okta FastPass, preventing session token theft and replay attacks.

Rationale

Why This Matters:

• The October 2023 breach exploited stolen session cookies from HAR files
• Device-bound tokens cannot be replayed from different devices
• Okta FastPass provides passwordless + phishing-resistant authentication

Attack Prevented: Session token theft and replay from attacker-controlled devices (HAR-file session hijacking)

Real-World Incidents:

• October 2023: Attackers exfiltrated HAR files containing session tokens from Okta support portal

ClickOps Implementation

Step 1: Enable Okta Verify with FastPass

1. Navigate to: Security → Authenticators
2. Click Okta Verify → Edit
3. Enable:
   • Okta FastPass: On
   • User verification with Okta FastPass: Required
4. Save

Step 2: Configure Device Trust

1. Navigate to: Security → Device Integrations
2. Configure device trust for managed devices:
   • Jamf Pro for macOS
   • Microsoft Intune for Windows
   • VMware Workspace ONE
3. Create policy requiring managed devices

Step 3: Create Device-Bound Session Policy

1. Navigate to: Security → Authentication Policies
2. Create rule:
   • Condition: Device trust = Not trusted
   • Action: Deny access OR require additional verification

---

1.4 Configure Password Policy

Profile Level: L1 (Crawl)

Framework	Control
NIST 800-53	IA-5(1)
DISA STIG	V-273195, V-273196, V-273197, V-273198, V-273199, V-273200, V-273201, V-273208, V-273209

Description

Configure comprehensive password policies with appropriate complexity, age, and history requirements. These controls protect against weak passwords, password reuse, and rapid password cycling.

Rationale

Why This Matters:

• Short, weak, or common passwords are cracked quickly by offline brute-force and dictionary attacks, handing attackers a foothold into the identity provider that fronts every connected application
• Without password history and a minimum-age rule, users immediately cycle back to a favorite password after a forced reset, defeating rotation entirely
• The common-password check rejects credentials already exposed in public breach corpuses, which are the seed lists for credential-stuffing campaigns
• Because Okta is the SSO gateway, a single guessed password can cascade into access across thousands of downstream apps

Attack Prevented: Password brute-forcing, dictionary attacks, credential stuffing, password reuse

Prerequisites

• Super Admin access
• Okta-mastered users (not applicable if using external directory services)

Specification Requirements

Requirement	L1 (Crawl)	L2/L3 (DISA STIG)
Minimum length	12 characters	15 characters
Uppercase required	Yes	Yes
Lowercase required	Yes	Yes
Number required	Yes	Yes
Special character required	Yes	Yes
Minimum password age	—	24 hours
Maximum password age	90 days	60 days
Common password check	Recommended	Required
Password history	4 generations	5 generations

ClickOps Implementation

Step 1: Access Password Authenticator Settings

1. Navigate to: Security → Authenticators
2. Click the Actions button next to Password
3. Select Edit

Step 2: Configure Each Password Policy For each listed Password Policy, click Edit and configure:

Complexity Requirements:

• Minimum Length: Set to at least 15 characters (L2/L3) or 12 (L1)
• Upper case letter: ☑ Checked
• Lower case letter: ☑ Checked
• Number (0-9): ☑ Checked
• Symbol (e.g., !@#$%^&*): ☑ Checked

Password Age Settings:

• Minimum password age is XX hours: Set to at least 24 (prevents rapid cycling)
• Password expires after XX days: Set to 60 (L2/L3) or 90 (L1)

Password History:

• Enforce password history for last XX passwords: Set to 5

Step 3: Enable Common Password Check

1. Under Password Settings section
2. Check Common Password Check
3. Click Save

Code Implementation

Code Pack: API Script

hth-okta-1.04-configure-password-policy.sh View source on GitHub ↗

okta_put "/api/v1/policies/${POLICY_ID}" "{
  \"settings\": {
    \"password\": {
      \"complexity\": {
        \"minLength\": ${MIN_LENGTH},
        \"minLowerCase\": 1,
        \"minUpperCase\": 1,
        \"minNumber\": 1,
        \"minSymbol\": 1
      },
      \"age\": {
        \"maxAgeDays\": ${MAX_AGE_DAYS},
        \"minAgeMinutes\": ${MIN_AGE_MINUTES},
        \"historyCount\": ${HISTORY_COUNT}
      }
    }
  }
}" > /dev/null 2>&1 && {
  updated=$((updated + 1))
} || warn "1.4 Failed to update policy '${POLICY_NAME}'"

Validation

1. Navigate to: Security → Authenticators → Password → Edit
2. For each policy, verify all settings match the requirements table above

Note: If Okta relies on external directory services for user sourcing, password policy is managed by the connected directory service.

---

1.5 Configure Account Lockout

Profile Level: L1 (Crawl)

Framework	Control
NIST 800-53	AC-7
DISA STIG	V-273189

Description

Enforce account lockout after consecutive invalid login attempts to protect against brute-force password attacks. This control significantly reduces the risk of unauthorized access via password guessing.

Rationale

Why This Matters:

• Without a lockout threshold, an attacker can submit unlimited password guesses against an account until one succeeds
• Automated brute-force and password-spray tools depend on being able to try many attempts per account undeterred
• Locking accounts after a small number of failures forces attackers into slow, noisy attempts that are easy to detect
• As the front door to SSO, an unlimited-guess Okta login exposes every federated application behind it

Attack Prevented: Brute-force password guessing, password spraying, credential stuffing

Specification Requirements

Requirement	L1 (Crawl)	L2/L3 (DISA STIG)
Lockout threshold	5 attempts	3 attempts
Lockout duration	30 minutes	Until admin unlock

ClickOps Implementation

Step 1: Configure Password Authenticator Lockout

1. Navigate to: Security → Authenticators
2. Click the Actions button next to Password
3. Select Edit

Step 2: Configure Each Password Policy For each listed Password Policy:

1. Click Edit on the policy
2. Locate the Lock Out section
3. Check Lock out after X unsuccessful attempts
4. Set the value to 3 (L2/L3) or 5 (L1)
5. Click Save

Code Pack: API Script

hth-okta-1.05-configure-account-lockout.sh View source on GitHub ↗

okta_put "/api/v1/policies/${POLICY_ID}" "{
  \"settings\": {
    \"password\": {
      \"lockout\": {
        \"maxAttempts\": ${LOCKOUT_THRESHOLD},
        \"autoUnlockMinutes\": 30,
        \"showLockoutFailures\": true
      }
    }
  }
}" > /dev/null 2>&1 && {
  updated=$((updated + 1))
} || warn "1.5 Failed to update lockout for policy '${POLICY_NAME}'"

Validation

1. Navigate to: Security → Authenticators → Password → Edit
2. For each policy, verify lockout settings are configured

Note: If Okta relies on external directory services for user sourcing, account lockout is managed by the connected directory service.

---

1.6 Configure Account Lifecycle Management

Profile Level: L1 (Crawl)

Framework	Control
NIST 800-53	AC-2(3)
DISA STIG	V-273188

Description

Automatically disable user accounts after a period of inactivity to reduce the risk of dormant account compromise. Attackers targeting inactive accounts may maintain undetected access since account owners won’t notice unauthorized activity.

Rationale

Why This Matters:

• Dormant accounts retain valid credentials and application entitlements while no one is watching them, making them ideal takeover targets
• A legitimate owner who has stopped using an account will not notice unauthorized sign-ons, password resets, or new factor enrollments
• Inactive accounts often belong to departed staff, contractors, or abandoned service identities that should no longer have access at all
• Auto-suspending stale accounts shrinks the standing attack surface without waiting on manual deprovisioning

Attack Prevented: Dormant account takeover, orphaned-account abuse, undetected persistence

Specification Requirements

Requirement	L1 (Crawl)	L2/L3 (DISA STIG)
Inactivity threshold	90 days	35 days
Action	Suspend	Suspend

Prerequisites

• Okta Workflows license (required for Automations)
• Super Admin or Org Admin access

ClickOps Implementation

Step 1: Create Inactivity Automation

1. Navigate to: Workflow → Automations
2. Click Add Automation
3. Enter a name (e.g., “User Inactivity - Auto Suspension”)

Step 2: Configure Trigger Condition

1. Click Add Condition
2. Select User Inactivity in Okta
3. Set duration to 35 days (L2/L3) or 90 days (L1)
4. Click Save

Step 3: Configure Schedule

1. Click the edit button next to Select Schedule
2. Set Schedule field to Run Daily
3. Set Time field to an appropriate time (e.g., 2:00 AM local time)
4. Click Save

Step 4: Configure Scope

1. Click the edit button next to Select group membership
2. In the Applies to field, select Everyone
3. Click Save

Step 5: Configure Action

1. Click Add Action
2. Select Change User lifecycle state in Okta
3. In Change user state to, select Suspended
4. Click Save

Step 6: Activate Automation

1. Click the Inactive button near the top of the screen
2. Select Activate

Validation

1. Navigate to: Workflow → Automations
2. Verify the automation is listed and shows Active status
3. Review the automation history after the first scheduled run

Note: If Okta relies on external directory services (e.g., Active Directory) for user sourcing, this automation may not be applicable. The connected directory service must perform this function instead.

---

1.7 Configure PIV/CAC Smart Card Authentication

Profile Level: L3 (Run)

Framework	Control
NIST 800-53	IA-2(12)
DISA STIG	V-273204, V-273207

Description

Configure Okta to accept Personal Identity Verification (PIV) credentials and Common Access Cards (CAC) for authentication. This enables hardware-based multifactor authentication using approved certificate authorities.

Rationale

Why This Matters:

• PIV/CAC smart cards bind authentication to a hardware-held private key validated against an approved certificate authority, so the credential cannot be phished or replayed
• Certificate-based authentication satisfies the AAL3 hardware-bound assurance required for high-sensitivity and U.S. Government systems
• Unlike passwords or shared secrets, the smart card credential never traverses the network in a reusable form
• Matching the certificate identifier (e.g., EDIPI) to the Okta profile ties every login to a vetted, government-issued identity

Attack Prevented: Credential phishing, password theft, replay attacks, unauthorized non-PIV access

Prerequisites

• Super Admin access
• Approved certificate chain (root and intermediate CA certificates)
• Smart Card IdP capability in your Okta edition

ClickOps Implementation

Step 1: Add Smart Card Authenticator

1. Navigate to: Security → Authenticators
2. In the Setup tab, click Add authenticator
3. Select the configured Smart Card Identity Provider
4. Complete the configuration and click Add

Step 2: Configure Smart Card Identity Provider

1. Navigate to: Security → Identity Providers
2. Click Add identity provider
3. Select Smart Card IdP and click Next
4. Enter a name for the identity provider (e.g., “CAC Authentication”)

Step 3: Build Certificate Chain

1. Click Browse to select your root CA certificate file
2. Click Add Another to add intermediate CA certificates
3. Continue until the complete certificate chain is uploaded
4. Click Build certificate chain
5. Verify the chain builds successfully with all certificates shown
6. If errors occur, verify certificate order and format

Step 4: Configure User Matching

1. In IdP username, select idpuser.subjectAltNameUpn
   • This attribute stores identifiers like the Electronic Data Interchange Personnel Identifier (EDIPI)
2. In Match Against, select the Okta Profile Attribute where the identifier is stored
3. Click Save

Step 5: Activate the Identity Provider

1. Verify the IdP status shows Active
2. If inactive, click Activate

Validation

1. Navigate to: Security → Identity Providers
2. Verify Smart Card IdP is listed with Type as “Smart Card”
3. Verify Status is “Active”
4. Click Actions → Configure and verify certificate chain is from approved CA

---

1.8 Configure FIPS-Compliant Authenticators

Profile Level: L3 (Run)

Framework	Control
NIST 800-53	SC-13
DISA STIG	V-273205

Description

Configure Okta Verify to only connect with FIPS-compliant devices. This ensures that authentication uses FIPS 140-2 validated cryptographic modules.

Rationale

Why This Matters:

• Non-validated cryptographic implementations may contain weaknesses that allow key extraction or signature forgery against the authenticator
• FIPS 140-2 validation provides assurance that the cryptographic module has been independently tested against a government standard
• Regulated and federal environments mandate FIPS-validated cryptography for any authentication touching protected systems
• Restricting Okta Verify to FIPS-compliant devices prevents enrollment of authenticators that fail to meet the required cryptographic baseline

Attack Prevented: Cryptographic weakness exploitation, non-compliant authenticator enrollment, key compromise

Prerequisites

• Super Admin access
• Okta Verify authenticator enabled
• Users with FIPS-compliant devices (devices that support FIPS 140-2 mode)

ClickOps Implementation

Step 1: Edit Okta Verify Settings

1. Navigate to: Security → Authenticators
2. In the Setup tab, click Edit next to Okta Verify

Step 2: Enable FIPS Compliance

1. Locate the FIPS Compliance field
2. Select FIPS-compliant devices only
3. Click Save

Validation

1. Navigate to: Security → Authenticators
2. From the Setup tab, select Edit Okta Verify
3. Verify FIPS Compliance is set to “FIPS-compliant devices only”

Note: Enabling FIPS-compliant devices only will prevent users with non-FIPS compliant devices from enrolling in Okta Verify. Ensure users have compatible devices before enabling this setting.

---

1.9 Audit Default Authentication Policy

Profile Level: L1 (Crawl)

Framework	Control
NIST 800-53	AC-3, IA-2

Description

Audit and mitigate the risk posed by Okta’s immutable Default Authentication Policy, which permits password-only login with no MFA requirement. This built-in policy acts as a catch-all backstop and cannot be modified or deleted. Any application or login flow that falls through to the default policy bypasses all MFA enforcement.

Rationale

Why This Matters:

• Okta ships with a “Default Policy” that allows single-factor (password-only) authentication
• This policy is immutable – it cannot be edited, deleted, or reordered
• It serves as the final catch-all: any login not matched by a higher-priority policy silently falls through to the default
• New applications added to the tenant are assigned to the default policy unless explicitly moved
• Organizations often believe MFA is enforced globally, unaware that the default backstop allows password-only access

Attack Prevented: MFA bypass via policy gap exploitation. An attacker who discovers an application assigned to the default policy can authenticate with stolen credentials alone, completely circumventing phishing-resistant MFA controls configured in other policies.

Real-World Context:

• Obsidian Security Research: Identified that a significant percentage of Okta tenants have applications inadvertently assigned to the default policy, creating silent MFA gaps in otherwise hardened environments

ClickOps Implementation

Step 1: Identify the Default Authentication Policy

1. Navigate to: Security → Authentication Policies
2. Locate the policy named “Default Policy” – it will be at the bottom of the policy list
3. Click the policy to inspect its rules
4. Note: The default rule permits access with “Password” only and cannot be changed

Step 2: Audit Application Policy Assignments

1. Navigate to: Security → Authentication Policies
2. For each authentication policy, click the Applications tab
3. Document which applications are assigned to each policy
4. Critical: Check the Default Policy → Applications tab
5. If ANY applications appear under the Default Policy, they are vulnerable to password-only login

Step 3: Reassign Applications to Explicit Policies

1. For each application assigned to the Default Policy:
   • Navigate to: Applications → Applications → [App Name]
   • Click the Sign On tab
   • Under Authentication policy, click Edit
   • Select an appropriate custom authentication policy that enforces MFA
   • Click Save
2. Repeat until the Default Policy has zero applications assigned

Step 4: Create a Catch-All Deny Rule in Custom Policies

1. Navigate to: Security → Authentication Policies
2. For each custom authentication policy:
   • Click Add Rule
   • Name: “Catch-All Deny”
   • IF: Any user, any device, any network
   • THEN: Access is Denied
   • Position this rule as the second-to-last rule (above only the default rule)
3. This ensures that any request not explicitly permitted by a higher-priority rule is denied rather than falling through

Step 5: Establish Ongoing Governance

1. Create a recurring calendar reminder (monthly) to re-audit policy assignments
2. Document the policy assignment standard in your security runbook
3. Include policy assignment verification in your application onboarding checklist

Time to Complete: ~45 minutes (initial audit) + 5 minutes per application reassignment

Code Implementation

Code Pack: Terraform

hth-okta-1.09-audit-default-auth-policy.tf View source on GitHub ↗

# Reference the immutable Default Authentication Policy
data "okta_policy" "default_access" {
  name = "Default Policy"
  type = "ACCESS_POLICY"
}

# Custom catch-all policy to replace reliance on the default policy
resource "okta_app_signon_policy" "mfa_required" {
  name        = "MFA Required - All Applications"
  description = "Enforces MFA for all applications - prevents fallthrough to default policy"
}

# Catch-all deny rule (lowest priority in custom policy)
resource "okta_app_signon_policy_rule" "catch_all_deny" {
  policy_id          = okta_app_signon_policy.mfa_required.id
  name               = "Catch-All Deny"
  priority           = 99
  access             = "DENY"
  factor_mode        = "2FA"
  constraints        = []
  groups_excluded    = []
  groups_included    = ["EVERYONE"]
  network_connection = "ANYWHERE"
}

# MFA enforcement rule (higher priority than catch-all)
resource "okta_app_signon_policy_rule" "require_mfa" {
  policy_id                   = okta_app_signon_policy.mfa_required.id
  name                        = "Require MFA"
  priority                    = 1
  access                      = "ALLOW"
  factor_mode                 = "2FA"
  groups_included             = ["EVERYONE"]
  network_connection          = "ANYWHERE"
  re_authentication_frequency = "PT2H"
}

Code Pack: API Script

hth-okta-1.09-audit-default-auth-policy.sh View source on GitHub ↗

# Find the default policy (system=true)
DEFAULT_POLICY_ID=$(okta_get "/api/v1/policies?type=ACCESS_POLICY" \
  | jq -r '.[] | select(.system == true and .name == "Default Policy") | .id' 2>/dev/null || true)

# List apps assigned to the default policy
DEFAULT_APPS=$(okta_get "/api/v1/policies/${DEFAULT_POLICY_ID}/app" 2>/dev/null || echo "[]")
APP_COUNT=$(echo "${DEFAULT_APPS}" | jq 'length' 2>/dev/null || echo "0")

Code Pack: Sigma Detection Rule

hth-okta-1.09-audit-default-auth-policy.yml View source on GitHub ↗

detection:
    selection:
        eventType: 'policy.evaluate_sign_on'
        debugContext.debugData.policyType: 'ACCESS_POLICY'
    filter_default_policy:
        target.displayName|contains: 'Default Policy'
    condition: selection and filter_default_policy
fields:
    - actor.displayName
    - client.ipAddress
    - outcome.result
    - published

Validation & Testing

1. Run API query to list all apps assigned to the Default Policy – result should be zero applications
2. Attempt login to a test application with password only – should be denied by catch-all rule
3. Attempt login to a test application with password + MFA – should succeed
4. Add a new test application and verify it is not automatically assigned to the Default Policy
5. Review System Log for policy.evaluate_sign_on events referencing the Default Policy – should show no recent hits
6. Verify each custom policy has a catch-all deny rule as the second-to-last rule

Expected result: Zero applications assigned to the Default Policy; all authentication flows require MFA through explicit custom policies.

Monitoring & Maintenance

Log query and SIEM alert rule: See Code Pack section 1.9 (cli and db) above for log filter expressions and SIEM detection queries.

Maintenance schedule:

• Weekly: Automated script to check for apps on Default Policy (integrate into CI/CD)
• Monthly: Manual review of authentication policy assignments
• On application onboarding: Mandatory policy assignment as part of app deployment checklist
• Quarterly: Full audit of all policy rules and catch-all deny rule placement

---

1.10 Harden Self-Service Recovery

Profile Level: L1 (Crawl)

Framework	Control
NIST 800-53	IA-5(1), IA-11

Description

Restrict self-service account recovery to trusted methods and network locations. Remove weak recovery options (SMS, voice call, security questions) that are susceptible to interception, SIM swapping, and social engineering. Limit recovery flows to corporate network zones to prevent account hijacking from untrusted locations.

Rationale

Why This Matters:

• Self-service password recovery is a primary account takeover vector – attackers bypass MFA by resetting credentials
• SMS-based recovery is vulnerable to SIM swapping, SS7 interception, and carrier social engineering
• Voice call recovery is susceptible to call forwarding attacks and voicemail compromise
• Security questions can be researched or socially engineered (mother’s maiden name, first pet, etc.)
• Recovery flows initiated from untrusted networks allow attackers to reset passwords remotely without triggering network-based controls
• Once an attacker resets a password, they can enroll their own MFA factors and establish persistent access

Attack Prevented: Account takeover via password recovery abuse. An attacker with access to a target’s phone number (via SIM swap) or personal information (via OSINT) initiates self-service recovery, resets the password, enrolls a new authenticator, and gains persistent access to all SSO-connected applications.

Real-World Context:

• Obsidian Security Research: Identified that recovery flows from untrusted networks are a top account hijack technique, especially when SMS or security questions are enabled as recovery options

Prerequisites

• Super Admin access
• Network zones configured (see Section 2.1)
• Corporate network zone defined with VPN egress IPs
• Okta Verify or email-based authenticator deployed to users

ClickOps Implementation

Step 1: Remove Weak Recovery Authenticators

1. Navigate to: Security → Authenticators
2. Review the list of active authenticators
3. For Phone (SMS/Voice):
   • Click Actions → Edit
   • Under Used for, uncheck Recovery (leave Authentication if still needed for non-admin users)
   • If SMS/Voice is not needed at all, click Actions → Deactivate
4. For Security Question:
   • Click Actions → Deactivate
   • Confirm deactivation
   • Note: Existing enrolled security questions will be removed from user accounts

Step 2: Configure Password Recovery Settings

1. Navigate to: Security → Authenticators
2. Click Actions next to Password → Select Edit
3. For each Password Policy listed, click Edit:
   • Locate the Account Recovery section
   • Recovery authenticators: Ensure only Email and Okta Verify are selected
   • Phone (SMS/Voice call): Uncheck / remove
   • Security question: Uncheck / remove
4. Click Save for each policy

Step 3: Restrict Recovery to Corporate Network Zones

1. Navigate to: Security → Authentication Policies
2. Select your primary authentication policy (or create a new one for recovery)
3. Click Add Rule:
   • Name: “Block Recovery from Untrusted Networks”
   • IF: Network zone is NOT “Corporate Network” (or your defined trusted zone)
   • AND: User is attempting self-service recovery
   • THEN: Access is Denied
4. Position this rule above your general allow rules
5. Click Save

Step 4: Configure Authenticator Enrollment Policy

1. Navigate to: Security → Authenticators → Enrollment tab
2. Edit the enrollment policy:
   • Okta Verify: Set to Required
   • Email: Set to Required
   • Phone: Set to Disabled or Optional (not for recovery)
   • Security Question: Set to Disabled
3. Click Save

Step 5: Test Recovery Flow

1. From a corporate network IP, initiate a test password recovery
2. Verify only email and authenticator-based options are presented
3. From an external/untrusted IP, attempt recovery – verify it is blocked or requires step-up

Time to Complete: ~30 minutes

Code Implementation

Code Pack: Terraform

hth-okta-1.10-harden-self-service-recovery.tf View source on GitHub ↗

# Deactivate security question authenticator
resource "okta_authenticator" "security_question" {
  name   = "Security Question"
  key    = "security_question"
  status = "INACTIVE"
}

# Configure phone authenticator -- remove recovery usage, keep for auth only
resource "okta_authenticator" "phone" {
  name   = "Phone"
  key    = "phone_number"
  status = "ACTIVE"
  settings = jsonencode({
    allowedFor = "authentication"
  })
}

# Password policy with hardened recovery settings
resource "okta_policy_password" "hardened_recovery" {
  name                     = "Hardened Password Policy"
  status                   = "ACTIVE"
  description              = "Password policy with restricted recovery methods"
  priority                 = 1
  password_min_length      = var.password_min_length
  password_min_lowercase   = 1
  password_min_uppercase   = 1
  password_min_number      = 1
  password_min_symbol      = 1
  password_max_age_days    = var.password_max_age_days
  password_min_age_minutes = 1440
  password_history_count   = var.password_history_count
  recovery_email_token     = 1
  email_recovery           = "ACTIVE"
  sms_recovery             = "INACTIVE"
  call_recovery            = "INACTIVE"
  question_recovery        = "INACTIVE"

  groups_included = [var.everyone_group_id]
}

Code Pack: API Script

hth-okta-1.10-harden-self-service-recovery.sh View source on GitHub ↗

okta_put "/api/v1/policies/${POLICY_ID}" '{
  "settings": {
    "recovery": {
      "factors": {
        "okta_email": {
          "status": "ACTIVE",
          "properties": {
            "recoveryToken": {
              "tokenLifetimeMinutes": 10
            }
          }
        },
        "okta_sms": {
          "status": "INACTIVE"
        },
        "okta_call": {
          "status": "INACTIVE"
        },
        "recovery_question": {
          "status": "INACTIVE"
        }
      }
    }
  }
}' > /dev/null 2>&1 && {
  updated=$((updated + 1))
} || warn "1.10 Failed to update recovery for policy '${POLICY_NAME}'"

# Step 2: Deactivate Security Question authenticator
info "1.10 Deactivating Security Question authenticator..."
SECURITY_QUESTION_ID=$(okta_get "/api/v1/authenticators" \
  | jq -r '.[] | select(.key == "security_question") | .id' 2>/dev/null || true)

if [ -n "${SECURITY_QUESTION_ID}" ]; then
  okta_post "/api/v1/authenticators/${SECURITY_QUESTION_ID}/lifecycle/deactivate" '{}' > /dev/null 2>&1 \
    && info "1.10 Security Question authenticator deactivated" \
    || warn "1.10 Security Question may already be inactive"
fi

# Step 3: Update Phone authenticator to remove recovery usage
info "1.10 Removing Phone authenticator from recovery..."
PHONE_ID=$(okta_get "/api/v1/authenticators" \
  | jq -r '.[] | select(.key == "phone_number") | .id' 2>/dev/null || true)

if [ -n "${PHONE_ID}" ]; then
  okta_put "/api/v1/authenticators/${PHONE_ID}" '{
    "name": "Phone",
    "settings": {
      "allowedFor": "authentication"
    }
  }' > /dev/null 2>&1 \
    && info "1.10 Phone authenticator restricted to authentication only" \
    || warn "1.10 Failed to update phone authenticator"
fi

Code Pack: Sigma Detection Rules (2)

hth-okta-1.10-harden-self-service-recovery.yml View source on GitHub ↗

detection:
    selection:
        eventType:
            - 'user.account.reset_password'
            - 'user.credential.forgot_password'
        securityContext.isProxy: true
    condition: selection
fields:
    - actor.displayName
    - client.ipAddress
    - client.geographicalContext.city
    - client.geographicalContext.country
    - outcome.result
    - published

---

hth-okta-1.10-harden-self-service-recovery-b.yml View source on GitHub ↗

detection:
    selection:
        eventType: 'user.account.reset_password'
        debugContext.debugData.factor:
            - 'SMS'
            - 'CALL'
            - 'QUESTION'
    condition: selection
fields:
    - actor.displayName
    - client.ipAddress
    - outcome.result
    - published

Validation & Testing

1. Navigate to Security → Authenticators and verify Security Question shows Inactive
2. Navigate to Security → Authenticators → Password → Edit and verify SMS, Voice, and Security Question are disabled for recovery
3. Initiate a password reset from a corporate network IP – verify only Email and Okta Verify options appear
4. Initiate a password reset from an external/untrusted IP – verify the request is blocked or requires additional verification
5. Attempt to enroll a security question as a user – should not be available
6. Review System Log for user.account.reset_password events and verify they originate only from trusted network zones
7. Verify recovery token lifetime is set to 10 minutes or less

Expected result: Self-service recovery limited to email and authenticator-based methods; no SMS, voice, or security question options; recovery blocked from untrusted networks.

Monitoring & Maintenance

Log query and SIEM alert rules: See Code Pack section 1.10 (cli and db) above for log filter expressions and SIEM detection queries.

Maintenance schedule:

• Monthly: Verify authenticator enrollment policy still disables weak recovery options
• Quarterly: Audit recovery events in System Log for anomalies
• On policy changes: Re-verify that recovery restrictions remain in place after any authenticator or policy modifications
• Annually: Review recovery methods against current threat landscape (new attack techniques against remaining methods)

---

1.11 Enable End-User Security Notifications

Profile Level: L1 (Crawl)

Framework	Control
NIST 800-53	SI-4, IR-6

Description

Enable all five end-user security notification types in Okta so that users receive immediate alerts when security-relevant changes occur on their accounts. Additionally enable Suspicious Activity Reporting to allow users to flag unauthorized actions directly from notification emails, creating actionable system log events for security teams.

Rationale

Why This Matters:

• End users are often the first to notice unauthorized access to their accounts – a notification about an unrecognized sign-on or authenticator change prompts immediate reporting
• Without notifications, an attacker who compromises an account can operate undetected for days or weeks while enrolling new factors, changing passwords, and accessing applications
• Authenticator enrolled/reset notifications detect a critical persistence technique: attackers who gain temporary access immediately register their own MFA factors to maintain access after the initial vector is closed
• Suspicious Activity Reporting turns every user into a sensor – when a user clicks “Report Suspicious Activity” in a notification email, Okta generates a user.account.report_suspicious_activity_by_enduser system log event that SIEM can automatically escalate
• These notifications cost nothing to enable and provide significant detection value with no user friction

Attack Prevented: Undetected account takeover and persistence. An attacker who compromises credentials and enrolls a new authenticator will trigger an “authenticator enrolled” notification to the legitimate user, who can immediately report the unauthorized change before the attacker establishes persistent access.

Real-World Context:

• Okta HealthInsight: Flags missing end-user notifications as a security gap in tenant health assessments
• Obsidian Security Research: Recommends all five notification types as a low-effort, high-value detection control

ClickOps Implementation

Step 1: Enable End-User Notification Types

1. Navigate to: Settings → Account
2. Scroll to the End-User Notifications section
3. Enable all five notification types:

Notification	Description	Enable
New sign-on notification	Alerts users when a sign-on occurs from an unrecognized device or browser	Yes
Authenticator enrolled notification	Alerts users when a new authenticator (MFA factor) is registered to their account	Yes
Authenticator reset notification	Alerts users when an authenticator is removed or reset on their account	Yes
Password changed notification	Alerts users when their password is changed	Yes
MFA factor reset notification	Alerts users when an MFA factor is reset by an administrator	Yes

1. Click Save

Step 2: Enable Suspicious Activity Reporting

1. Navigate to: Security → General
2. Scroll to the Suspicious Activity Reporting section
3. Set to Enabled
4. Click Save
5. When enabled, notification emails include a “Report Suspicious Activity” button
6. User clicks generate a system log event: user.account.report_suspicious_activity_by_enduser

Step 3: Verify Notification Delivery

1. Using a test user account, perform a sign-on from a new browser or device
2. Verify the test user receives a “New sign-on” notification email
3. Verify the email contains the “Report Suspicious Activity” button (if Suspicious Activity Reporting is enabled)
4. Click “Report Suspicious Activity” and verify the system log event is created

Step 4: Configure SIEM Alerting for Suspicious Activity Reports

1. In your SIEM, create a high-priority alert for the event type user.account.report_suspicious_activity_by_enduser
2. This event should trigger an immediate incident response workflow
3. Correlate with recent authentication and factor enrollment events for the reporting user

Time to Complete: ~15 minutes

Code Implementation

Code Pack: Terraform

hth-okta-1.11-enable-security-notifications.tf View source on GitHub ↗

# Org-level configuration for end-user support
resource "okta_org_configuration" "notifications" {
  end_user_support_help_url = var.support_url

  # End-user notification settings are managed via the org settings API.
  # Use the provisioners below for full control.
}

# Enable Suspicious Activity Reporting via API call
# (Not all org-level settings are natively supported in Terraform)
resource "null_resource" "enable_suspicious_activity_reporting" {
  provisioner "local-exec" {
    command = <<-EOT
      curl -s -X POST "https://${var.okta_domain}/api/v1/org/privacy/suspicious-activity-reporting" \
        -H "Authorization: SSWS ${var.okta_api_token}" \
        -H "Content-Type: application/json" \
        -d '{"enabled": true}'
    EOT
  }

  triggers = {
    always_run = timestamp()
  }
}

# Enable all end-user notification types via API call
resource "null_resource" "enable_end_user_notifications" {
  provisioner "local-exec" {
    command = <<-EOT
      curl -s -X PUT "https://${var.okta_domain}/api/v1/org/settings" \
        -H "Authorization: SSWS ${var.okta_api_token}" \
        -H "Content-Type: application/json" \
        -d '{
          "endUserNotifications": {
            "newSignOnNotification": {"enabled": true},
            "authenticatorEnrolledNotification": {"enabled": true},
            "authenticatorResetNotification": {"enabled": true},
            "passwordChangedNotification": {"enabled": true},
            "factorResetNotification": {"enabled": true}
          }
        }'
    EOT
  }

  triggers = {
    always_run = timestamp()
  }
}

Code Pack: API Script

hth-okta-1.11-enable-security-notifications.sh View source on GitHub ↗

# Enable all five end-user notification types
info "1.11 Enabling all five notification types..."
okta_put "/api/v1/org/settings" '{
  "endUserNotifications": {
    "newSignOnNotification": {
      "enabled": true
    },
    "authenticatorEnrolledNotification": {
      "enabled": true
    },
    "authenticatorResetNotification": {
      "enabled": true
    },
    "passwordChangedNotification": {
      "enabled": true
    },
    "factorResetNotification": {
      "enabled": true
    }
  }
}' > /dev/null 2>&1 && {
  pass "1.11 All five end-user notification types enabled"
} || {
  fail "1.11 Failed to enable end-user notifications"
  increment_failed
  summary
  exit 0
}

# Enable Suspicious Activity Reporting
info "1.11 Enabling Suspicious Activity Reporting..."
okta_post "/api/v1/org/privacy/suspicious-activity-reporting" '{
  "enabled": true
}' > /dev/null 2>&1 && {
  pass "1.11 Suspicious Activity Reporting enabled"
} || {
  warn "1.11 Suspicious Activity Reporting may already be enabled"
}

Code Pack: Sigma Detection Rules (2)

hth-okta-1.11-enable-security-notifications.yml View source on GitHub ↗

detection:
    selection:
        eventType: 'user.account.report_suspicious_activity_by_enduser'
    condition: selection
fields:
    - actor.displayName
    - actor.alternateId
    - client.ipAddress
    - client.geographicalContext.city
    - client.geographicalContext.country
    - outcome.result
    - published

---

hth-okta-1.11-enable-security-notifications-b.yml View source on GitHub ↗

detection:
    selection:
        eventType:
            - 'user.mfa.factor.activate'
            - 'user.mfa.factor.enroll'
            - 'system.mfa.factor.activate'
            - 'user.account.update_password'
    condition: selection
fields:
    - actor.displayName
    - target.displayName
    - client.ipAddress
    - client.userAgent.rawUserAgent
    - published

Validation & Testing

1. Navigate to Settings → Account → End-User Notifications and verify all five notification types are Enabled
2. Navigate to Security → General → Suspicious Activity Reporting and verify it is Enabled
3. Sign in with a test user from a new device/browser – verify “New sign-on” email is received
4. Enroll a new authenticator for a test user – verify “Authenticator enrolled” email is received
5. Reset an authenticator for a test user – verify “Authenticator reset” email is received
6. Change a test user’s password – verify “Password changed” email is received
7. In a notification email, click “Report Suspicious Activity” – verify the system log event user.account.report_suspicious_activity_by_enduser is created
8. Verify SIEM alert fires for the suspicious activity report event

Expected result: All five notification types active; users receive timely emails for security-relevant account changes; suspicious activity reports generate system log events that trigger SIEM alerts.

Monitoring & Maintenance

Log queries and SIEM alert rules: See Code Pack section 1.11 (cli and db) above for log filter expressions and SIEM detection queries.

Incident response workflow for suspicious activity reports:

1. SIEM receives user.account.report_suspicious_activity_by_enduser event
2. Automatically create incident ticket with HIGH priority
3. Pull last 24 hours of authentication and factor events for the reporting user
4. Check for: new factor enrollments, password changes, sign-ons from unusual locations
5. If compromise indicators found: suspend user session, force re-authentication, reset factors

Maintenance schedule:

• Monthly: Review suspicious activity report volume and response times
• Quarterly: Verify all five notification types are still enabled (configuration drift check)
• Quarterly: Test notification delivery by performing a controlled sign-on from a new device
• Annually: Review notification types against Okta feature updates (new notification types may be added)

---

1.12 Enforce Device Assurance Policies

Profile Level: L2 (Walk)

Framework	Control
CIS Controls	4.1, 7.3
NIST 800-53	CM-6, IA-3, SI-2

Description

Device Assurance policies define the minimum security posture a device must meet before its user is permitted to authenticate, and they are bound to access decisions through device conditions in application sign-in policy rules. Each policy is scoped to a single platform (Android, ChromeOS, iOS, macOS, or Windows) and evaluates signals such as minimum OS version and patch level, disk encryption, screen lock, jailbreak or root status, and secure hardware presence, collected by Okta Verify or by Chrome Device Trust on managed Chrome browsers. See Okta’s Device assurance policies guide for the full attribute model and the underlying Device Assurance Policies API.

Rationale

Why This Matters:

• Phishing-resistant MFA proves who is signing in but says nothing about what they are signing in from — a correctly authenticated user on a compromised endpoint hands a valid session to whatever else is running on that device
• Minimum OS version and patch-level requirements deny authentication from devices carrying known-exploited vulnerabilities instead of waiting for endpoint management to catch up
• Jailbreak and root detection prevents attackers from defeating the platform keystore protections that Okta Verify and FastPass rely on for device-bound credentials
• Device Assurance is the enforcement point for blocking the outdated Okta Verify and Okta Browser Plugin versions identified through the advisory monitoring process in Section 7.2
• Okta Verify Advanced Posture Checks (early access, announced February 2026) extends the model with administrator-written osquery rules that evaluate device hygiene at sign-in — installed applications, persistent services, running processes, binaries and configuration files in common install paths, Homebrew and npm packages, listening ports, and Docker artifacts — so unwanted software on a corporate device denies access at the authentication decision rather than surfacing hours later in an EDR console. See Okta Threat Intelligence, Detecting OpenClaw

Attack Prevented: Authentication from compromised, unpatched, jailbroken, or unmanaged endpoints; session theft from devices running credential-stealing or unsanctioned remote-access software; policy bypass via outdated client versions

Prerequisites

• Okta Identity Engine tenant with Device Assurance available in your edition
• Okta Verify deployed to managed endpoints, or Chrome Device Trust configured for managed browsers
• Device registration or endpoint management integration already in place (see Section 1.3)
• Super Admin access

ClickOps Implementation

Step 1: Confirm the Device Signal Source

1. Navigate to: Security → Authenticators and confirm Okta Verify is active with Okta FastPass enabled (see Section 1.3)
2. For managed Chrome browsers, navigate to: Security → Device Integrations and add the Chrome Device Trust connector
3. Navigate to: Directory → Devices and confirm managed endpoints are reporting with a registered/managed status

Step 2: Create a Device Assurance Policy per Platform

1. Navigate to: Security → Device Assurance Policies
2. Click Add a policy
3. Enter a descriptive name that includes the platform (e.g., “Windows — Corporate Baseline”)
4. Select the Platform: Android, ChromeOS, iOS, macOS, or Windows — one policy per platform
5. Configure the attributes available for that platform:

Attribute	Recommended Setting
Minimum OS version	Current vendor-supported release at the latest security patch level
Disk encryption	Required
Screen lock	Required
Jailbroken or rooted device	Blocked (iOS and Android)
Secure hardware	Required (TPM or Secure Enclave-backed keys)

1. Click Save
2. Repeat for every platform present in your fleet — a platform with no policy is a platform with no assurance

Step 3: Bind the Policy to Application Sign-In Rules

1. Navigate to: Security → Authentication Policies
2. Select the policy protecting your most sensitive applications — start with the Okta Admin Console policy
3. Click Actions next to the rule you want to harden and select Edit
4. Under the device conditions, set device state to Registered and select the device assurance policies created in Step 2
5. Set the rule action to Allowed only when the assurance policy is satisfied, then add a lower-priority rule that denies access when it is not
6. Click Save
7. Repeat for each authentication policy protecting sensitive applications

Step 4: Configure Grace Periods and Remediation Messaging

1. Re-open each device assurance policy
2. Set a grace period on the OS version requirement so users are warned before enforcement begins — 7 days for L2, 0 days for L3
3. Enable remediation guidance so end users see the specific failed check and how to fix it rather than a generic denial
4. Click Save

Step 5: Add Advanced Posture Checks (Early Access, Optional)

1. Confirm the Advanced Posture Checks early-access feature is enabled for your tenant under Settings → Features
2. Author custom osquery rules that assert the absence of prohibited software or the presence of required agents on corporate devices
3. Attach the custom check to the relevant device assurance policy
4. Roll the check out in a monitoring posture first, review the sign-in outcomes for false positives, then move to enforcement

Time to Complete: ~2 hours for initial policy creation across platforms, plus fleet remediation time

Validation & Testing

1. Navigate to Security → Device Assurance Policies and verify one active policy exists for every platform in your fleet
2. Sign in from a compliant managed device — access should succeed
3. Roll a test device back to an OS version below the minimum and attempt sign-in — access should be denied with remediation guidance displayed
4. Attempt sign-in from an unregistered or unmanaged device — should be denied by the sign-in policy rule
5. Attempt sign-in from a jailbroken or rooted test device (iOS or Android) — should be denied
6. Review the System Log for policy.evaluate_sign_on events and confirm the device assurance condition appears in the evaluation result

Expected result: Only devices meeting the documented posture baseline can authenticate to protected applications; non-compliant devices are denied with actionable remediation guidance.

Monitoring & Maintenance

Maintenance schedule:

• Monthly: Review denial volume by failed attribute to catch fleet-wide patch lag before it becomes a helpdesk surge
• Quarterly: Raise the minimum OS version to track vendor support and patch cadence
• On advisory publication: Update the minimum Okta Verify and Browser Plugin versions per Section 7.2
• Annually: Review the attribute set against new platform signals added by Okta

Compliance Mappings

Framework	Control	Requirement
CIS Controls v8	4.1	Establish and maintain a secure configuration process for enterprise assets
CIS Controls v8	7.3	Perform automated operating system patch management
NIST 800-53	CM-6	Configuration settings enforced on endpoints before access is granted
NIST 800-53	IA-3	Device identification and authentication
NIST 800-53	SI-2	Flaw remediation enforced through minimum OS and patch-level requirements
SOC 2	CC6.6	Logical access restricted to devices meeting defined security requirements

---

1.13 Require Visual Identity Verification for Help Desk Account Actions

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls	5.4, 14.2
NIST 800-53	IA-12, IA-5(1), AT-2

Description

Require help desk agents to visually verify a caller’s identity — a live video call with a government-issued or corporate photo ID, or an equivalent out-of-band proofing step — before performing any account recovery action, including password resets, MFA factor resets, and enrollment of a new authenticator. Okta’s own cross-tenant impersonation guidance names this control directly: “Strengthen help desk identity verification processes using visual verification.” (Okta Security — Cross-Tenant Impersonation: Prevention and Detection)

Rationale

Why This Matters:

• In the August 2023 cross-tenant impersonation campaign, threat actors social-engineered IT service desk personnel into resetting all MFA factors on highly privileged Super Administrator accounts — the technical controls held, the human process did not
• Every phishing-resistant authenticator configured in Section 1.1 is nullified the moment a help desk agent enrolls an attacker-controlled factor on a legitimate account
• Voice-only verification depends on knowledge (employee ID, manager name, last four digits of an identifier) that is trivially harvested from OSINT, prior breach corpuses, or an earlier phishing round, and is now cheaply defeated by real-time voice cloning
• Visual verification against a photo ID on a live video call forces an attacker to defeat a liveness check rather than recite facts, raising the cost of the attack far above the effort of a phone call
• Factor reset is the highest-privilege operation a help desk agent can perform and it leaves the same log trail as a legitimate reset, so prevention at the process layer is the only reliable control — detection arrives after the attacker already holds the account

Attack Prevented: Help desk social engineering leading to MFA factor reset and account takeover, privileged account impersonation, attacker-controlled authenticator enrollment on Super Admin accounts

ClickOps Implementation

Step 1: Define and Publish the Verification Standard Document a written standard requiring, for every password reset, MFA factor reset, and new authenticator enrollment performed by an agent:

1. A live video call on a corporate-approved platform — never audio-only, never chat
2. Presentation of a government-issued or corporate photo ID matched against the identity on file
3. An agent-initiated callback to the number of record plus a second approver when video is genuinely unavailable
4. Mandatory manager or security-team approval for any action on an account holding an admin role
5. A ticket record capturing the verification method, the verifier, the timestamp, and an evidence reference

Step 2: Constrain What the Help Desk Role Can Do

1. Navigate to: Security → Administrators → Roles
2. Open the Help Desk custom role created in Section 1.2
3. Confirm permissions are limited to password reset and account unlock, and exclude okta.users.manage, okta.apps.manage, and all IdP permissions
4. Open the role’s Resource sets and scope it to a group that explicitly excludes all administrators — help desk agents should not be technically capable of acting on privileged accounts
5. Click Save

Step 3: Require Step-Up Authentication for Factor Resets

1. Navigate to: Security → General
2. Scroll to Protected Actions and click Edit
3. Confirm Reset user MFA factors is selected
4. Set the authenticator requirement to phishing-resistant (FIDO2/WebAuthn)
5. Click Save

Step 4: Notify the Account Owner on Every Reset

1. Navigate to: Settings → Account and confirm the Authenticator reset notification and MFA factor reset notification types are enabled (see Section 1.11)
2. Navigate to: Security → General → Suspicious Activity Reporting and confirm it is Enabled so an account owner can report a reset they did not request

Step 5: Train and Test the Help Desk

1. Deliver targeted training on the impersonation techniques used against service desks, using the Okta cross-tenant impersonation writeup as the case study
2. Give agents explicit authority to refuse or escalate any request that skips verification, with no performance penalty for the resulting delay
3. Run a social engineering exercise at least twice a year, including at least one attempt impersonating an executive or administrator under manufactured time pressure
4. Track the refusal rate as a control metric alongside ticket resolution time

Time to Complete: ~2 hours for policy drafting, plus training rollout

Validation & Testing

1. A written verification standard exists, is published to the help desk, and names visual verification as mandatory for password resets, factor resets, and new factor enrollment
2. Review a sample of the last 20 password and factor reset tickets — each must record the verification method and the verifier
3. Navigate to Security → Administrators → Roles and confirm the help desk resource set excludes all admin accounts
4. Navigate to Security → General → Protected Actions and confirm MFA factor reset requires step-up authentication
5. Conduct an unannounced social engineering test against the help desk — the agent should refuse and escalate
6. Review System Log user.mfa.factor.reset and user.account.reset_password events and confirm each maps to a ticket documenting visual verification

Expected result: No account recovery action is performed without recorded visual verification, and help desk agents cannot act on privileged accounts at all.

Monitoring & Maintenance

Maintenance schedule:

• Monthly: Sample recent reset tickets for verification evidence
• Quarterly: Reconcile System Log reset events against ticket records and investigate any reset without a matching ticket
• Semi-annually: Run a help desk social engineering exercise and retrain on findings
• Annually: Review the verification standard against current impersonation techniques, including synthetic voice and video

Compliance Mappings

Framework	Control	Requirement
CIS Controls v8	5.4	Restrict administrator privileges to dedicated administrator accounts
CIS Controls v8	14.2	Train workforce members to recognize social engineering attacks
NIST 800-53	IA-12	Identity proofing prior to issuing or resetting authenticators
NIST 800-53	IA-5(1)	Authenticator management controls for reset and re-issuance
NIST 800-53	AT-2	Role-based security awareness training including social engineering
SOC 2	CC6.1	Logical access credentials issued and reset only to verified individuals

---

2. Network Access Controls

2.1 Configure IP Zones and Network Policies

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls	13.3
NIST 800-53	AC-3, SC-7

Description

Define network zones (corporate, VPN, known bad) and enforce authentication policies based on network location. Block or require step-up authentication from untrusted networks.

Rationale

Why This Matters:

• Attackers often operate from non-corporate infrastructure
• IP-based policies add defense layer even if credentials stolen
• Enables geographic restrictions for compliance

Attack Prevented: Credential stuffing from botnets, unauthorized access from foreign locations

ClickOps Implementation

Step 1: Define Network Zones

1. Navigate to: Security → Networks
2. Create zones:

Corporate Network:

• Type: IP Zone
• IPs: Your office CIDR ranges
• Gateway IPs: VPN egress IPs

Blocked Locations:

• Type: Dynamic Zone
• Block: TOR exit nodes, known-bad IP ranges
• Use threat intelligence feeds

Step 2: Create Zone-Based Authentication Policy

1. Navigate to: Security → Authentication Policies
2. Add rule:
   • IF: Network zone = “Not Corporate”
   • THEN: Require MFA + limit session duration
3. Add rule:
   • IF: Network zone = “Blocked Locations”
   • THEN: Deny access

Code Implementation

Code Pack: Terraform

hth-okta-2.01-configure-network-zones.tf View source on GitHub ↗

# Corporate network zone with configurable CIDRs
resource "okta_network_zone" "corporate" {
  count = length(var.corporate_gateway_cidrs) > 0 ? 1 : 0

  name     = "Corporate Network"
  type     = "IP"
  status   = "ACTIVE"
  gateways = var.corporate_gateway_cidrs
}

# IP blocklist zone
resource "okta_network_zone" "blocklist" {
  count = length(var.blocked_ip_cidrs) > 0 ? 1 : 0

  name     = "Blocked IPs"
  type     = "IP"
  status   = "ACTIVE"
  usage    = "BLOCKLIST"
  gateways = var.blocked_ip_cidrs
}

Code Pack: API Script

hth-okta-2.01-configure-network-zones.sh View source on GitHub ↗

# Create Corporate Network zone
# NOTE: Replace gateway CIDRs with your actual corporate IP ranges
info "2.1 Creating Corporate Network zone..."
ZONE_RESPONSE=$(okta_post "/api/v1/zones" '{
  "type": "IP",
  "name": "Corporate Network",
  "status": "ACTIVE",
  "gateways": [
    {"type": "CIDR", "value": "203.0.113.0/24"},
    {"type": "CIDR", "value": "198.51.100.0/24"}
  ]
}' 2>/dev/null) && {
  ZONE_ID=$(echo "${ZONE_RESPONSE}" | jq -r '.id' 2>/dev/null || true)
  pass "2.1 Corporate Network zone created (ID: ${ZONE_ID})"
  warn "2.1 IMPORTANT: Update the zone with your actual corporate IP ranges"
} || {
  fail "2.1 Failed to create Corporate Network zone"
}

info "2.1 Creating TOR/Anonymizer block zone..."
okta_post "/api/v1/zones" '{
  "type": "DYNAMIC_V2",
  "name": "Blocked - TOR and Anonymizers",
  "status": "ACTIVE",
  "proxyType": "TorAnonymizer",
  "usage": "BLOCKLIST"
}' > /dev/null 2>&1 && {
  pass "2.1 TOR/Anonymizer block zone created"
} || {
  warn "2.1 Failed to create TOR block zone (may require Adaptive MFA license)"
}

---

2.2 Restrict Admin Console Access by IP

Profile Level: L1 (Crawl)

Framework	Control
NIST 800-53	AC-3(7)

Description

Limit access to the Okta Admin Console to specific IP ranges (corporate network, VPN, security team IPs).

Rationale

Why This Matters:

• The Admin Console grants full control over authentication policies, users, and integrations, making it the single highest-value target in the tenant
• Restricting console access to known corporate and VPN egress IPs means stolen admin credentials or session tokens cannot be used from arbitrary attacker infrastructure
• IP allowlisting adds a network-layer control that holds even when credentials or MFA are compromised
• The October 2023 breach showed that stolen admin sessions are replayed from external networks — an IP allowlist blocks that replay path

Attack Prevented: Stolen admin credential reuse, session token replay from external networks, unauthorized console access

ClickOps Implementation

1. Navigate to: Security → General
2. Under Okta Admin Console, configure:
   • Allowed IPs: Add corporate network ranges
   • Block all other IPs: Enable
3. Test access from allowed IP before enforcement

Warning: Ensure break-glass procedure for lockout scenarios.

---

2.3 Configure Dynamic Network Zones and Anonymizer Blocking

Profile Level: L2 (Walk)

Framework	Control
NIST 800-53	SC-7, AC-3

Description

Activate Okta’s Enhanced Dynamic Zone to automatically block traffic from anonymizing proxies, Tor exit nodes, and residential proxies. The DefaultEnhancedDynamicZone ships inactive by default and must be explicitly activated.

Rationale

Why This Matters:

• Attackers use anonymizing proxies, Tor, and VPNs to hide their origin during credential stuffing and session replay attacks
• Okta’s Enhanced Dynamic Zones leverage IP intelligence to categorize traffic sources automatically
• The default zone exists but is INACTIVE — many organizations don’t know it’s available
• Blocking anonymizers reduces attack surface without impacting legitimate users

Attack Prevented: Credential stuffing via anonymized infrastructure, session replay from Tor/proxy networks

ClickOps Implementation

Step 1: Activate Enhanced Dynamic Zone

1. Navigate to: Security → Networks
2. Locate DefaultEnhancedDynamicZone in the zone list
3. Click Edit
4. Change Zone Status to Active
5. Set Usage to Blocklist
6. Click Save

Step 2: Configure Blocked IP Categories

1. In the Enhanced Dynamic Zone settings, select categories to block:
   • Anonymizing Proxies: ☑ Checked
   • Tor Exit Nodes: ☑ Checked
   • Residential Proxies: ☑ Checked (optional, may impact remote workers using ISP proxies)
2. Click Save

Step 3: Apply to Authentication Policies

1. Navigate to: Security → Authentication Policies
2. For each policy, add a rule:
   • IF: Network zone = “DefaultEnhancedDynamicZone”
   • THEN: Deny access
3. Position this rule with higher priority than allow rules

Step 4: Configure Geographic Restrictions (Optional)

1. Navigate to: Security → Networks
2. Click Add Zone → Dynamic Zone
3. Configure:
   • Name: “Blocked Countries”
   • Locations: Select countries where your organization has no users
   • Usage: Blocklist
4. Add deny rule in authentication policies for this zone

Code Implementation

Code Pack: Terraform

hth-okta-2.03-block-anonymizers.tf View source on GitHub ↗

# Block anonymizing proxies and Tor exit nodes
resource "okta_network_zone" "block_anonymizers" {
  count = var.profile_level >= 2 ? 1 : 0

  name               = "Block Anonymizers"
  type               = "DYNAMIC_V2"
  status             = "ACTIVE"
  usage              = "BLOCKLIST"
  dynamic_proxy_type = "TorAnonymizer"
}

# Block traffic from high-risk countries
resource "okta_network_zone" "block_countries" {
  count = var.profile_level >= 2 ? 1 : 0

  name              = "Blocked Countries"
  type              = "DYNAMIC"
  status            = "ACTIVE"
  usage             = "BLOCKLIST"
  dynamic_locations = var.blocked_countries
}

Code Pack: API Script

hth-okta-2.03-block-anonymizers.sh View source on GitHub ↗

# Activate the zone as a blocklist
info "2.3 Activating DefaultEnhancedDynamicZone as blocklist..."
okta_put "/api/v1/zones/${ZONE_ID}" '{
  "type": "DYNAMIC_V2",
  "name": "DefaultEnhancedDynamicZone",
  "status": "ACTIVE",
  "usage": "BLOCKLIST",
  "proxyType": "TorAnonymizer"
}' > /dev/null 2>&1 && {
  pass "2.3 Enhanced Dynamic Zone activated with anonymizer blocking"
  increment_applied
} || {
  fail "2.3 Failed to activate Enhanced Dynamic Zone"
  increment_failed
}

Code Pack: Sigma Detection Rule

hth-okta-2.03-block-anonymizers.yml View source on GitHub ↗

detection:
    selection:
        eventType: 'security.threat.detected'
        debugContext.debugData.threatSuspected: 'ANONYMIZER'
    condition: selection
fields:
    - actor.displayName
    - actor.alternateId
    - client.ipAddress
    - debugContext.debugData.threatSuspected
    - outcome.result
    - published

Validation & Testing

1. Navigate to Security → Networks and verify DefaultEnhancedDynamicZone shows Active status
2. Verify zone usage is set to Blocklist
3. Test access from a Tor exit node or known anonymizing proxy — should be denied
4. Verify legitimate users on corporate VPN are not affected

Monitoring & Maintenance

Log query: See Code Pack section 2.3 (cli) above for the System Log filter expression.

Maintenance schedule:

• Monthly: Review blocked traffic patterns for false positives
• Quarterly: Update geographic restrictions based on business expansion

---

3. OAuth & Integration Security

3.1 Implement OAuth App Consent Policies

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls	6.2
NIST 800-53	AC-6, CM-7

Description

Control which OAuth applications users can authorize and require admin approval for new app integrations. Prevent shadow IT through unconsented OAuth grants.

Rationale

Why This Matters:

• Okta’s 7,000+ integrations create massive attack surface
• Malicious apps can request broad OAuth scopes
• Unconsented apps bypass security review

Attack Prevented: OAuth phishing, malicious app consent, shadow IT

ClickOps Implementation

Step 1: Configure App Integration Policies

1. Navigate to: Applications → App Integration Policies
2. Create policy:
   • Name: “Require Admin Approval for New Apps”
   • Scope: All users except Admins
   • Action: Require admin approval for user-initiated apps

Step 2: Review Existing App Grants

1. Navigate to: Reports → Application Access Audit
2. Export list of all OAuth grants
3. Review for over-permissioned or suspicious apps
4. Revoke unnecessary grants

Step 3: Restrict API Token Creation

1. Navigate to: Security → API → Tokens
2. Review existing tokens
3. Configure:
   • Require admin approval for new tokens
   • Set expiration policies (max 90 days)

Code Implementation

Code Pack: API Script

hth-okta-3.01-oauth-consent-policies.sh View source on GitHub ↗

# List all active applications with OAuth/OIDC sign-on
info "3.1 Listing active applications..."
ACTIVE_APPS=$(okta_get "/api/v1/apps?filter=status%20eq%20%22ACTIVE%22&limit=200") || {
  fail "3.1 Failed to list active applications"
  increment_failed
  summary
  exit 0
}

TOTAL_COUNT=$(echo "${ACTIVE_APPS}" | jq 'length' 2>/dev/null || echo "0")
OAUTH_APPS=$(echo "${ACTIVE_APPS}" | jq '[.[] | select(.signOnMode == "OPENID_CONNECT" or .signOnMode == "OAUTH_2_0")]' 2>/dev/null || echo "[]")
OAUTH_COUNT=$(echo "${OAUTH_APPS}" | jq 'length' 2>/dev/null || echo "0")

info "3.1 Total active apps: ${TOTAL_COUNT}, OAuth/OIDC apps: ${OAUTH_COUNT}"
echo "${OAUTH_APPS}" | jq -r '.[] | "  - \(.label // .name) (mode: \(.signOnMode), created: \(.created))"' 2>/dev/null || true

# Audit OAuth token clients on default authorization server
info "3.1 Auditing OAuth clients on default authorization server..."
AUTH_CLIENTS=$(okta_get "/api/v1/authorizationServers/default/clients" 2>/dev/null || echo "[]")
CLIENT_COUNT=$(echo "${AUTH_CLIENTS}" | jq 'length' 2>/dev/null || echo "0")

if [ "${CLIENT_COUNT}" -gt 0 ]; then
  info "3.1 Found ${CLIENT_COUNT} OAuth client(s) on default auth server"
  echo "${AUTH_CLIENTS}" | jq -r '.[] | "  - \(.client_name // "unnamed") (ID: \(.client_id))"' 2>/dev/null || true
else
  info "3.1 No OAuth clients on default authorization server"
fi

---

3.2 Harden SCIM Provisioning Connectors

Profile Level: L2 (Walk)

Framework	Control
NIST 800-53	AC-2, IA-4

Description

Secure SCIM (System for Cross-domain Identity Management) connectors that provision/deprovision users to downstream applications. SCIM tokens enable identity manipulation across connected apps.

Rationale

Why This Matters:

• SCIM connectors create/delete users in downstream apps
• Compromised SCIM tokens enable backdoor account creation
• Unlimited token validity creates persistent risk

Attack Prevented: Backdoor account creation in downstream apps via stolen SCIM tokens

Attack Scenario: Attacker steals SCIM token, creates backdoor accounts in connected SaaS apps

ClickOps Implementation

Step 1: Audit SCIM-Enabled Apps

1. Navigate to: Applications → Applications
2. Filter by: Provisioning = Enabled
3. Document all SCIM integrations

Step 2: Rotate SCIM Tokens

1. For each SCIM-enabled app:
   • Navigate to app → Provisioning tab
   • Regenerate API token
   • Update receiving application
2. Document token rotation schedule (quarterly minimum)

Step 3: Limit SCIM Scope

1. Configure provisioning to sync only required attributes
2. Disable “Sync Password” unless required
3. Enable “Group Push” only for necessary groups

Monitoring

Code Pack: Sigma Detection Rule

hth-okta-3.02-harden-scim-provisioning-connectors.yml View source on GitHub ↗

detection:
    selection:
        eventType:
            - 'system.scim.user.create'
            - 'system.scim.user.update'
    condition: selection
fields:
    - actor.displayName
    - target.displayName
    - target.type
    - eventType
    - client.ipAddress
    - published

---

3.3 Implement OAuth Application Allowlisting

Profile Level: L2 (Walk)

Framework	Control
NIST 800-53	CM-7, AC-6

Description

Restrict which third-party applications can receive OAuth grants from users. OAuth consent phishing is a growing attack vector where malicious applications request broad scopes to access organizational data through user consent flows.

Rationale

Why This Matters:

• Over-privileged OAuth tokens from third-party integrations enable supply chain attacks
• Users can unknowingly grant broad access to malicious applications via consent phishing
• SaaS-to-SaaS connections create hidden trust relationships that bypass traditional security controls
• Unsanctioned apps with broad OAuth scopes create persistent backdoors

Attack Prevented: OAuth consent phishing, supply chain compromise via over-privileged integrations, shadow IT

ClickOps Implementation

Step 1: Review Existing OAuth Grants

1. Navigate to: Applications → Applications
2. Filter by: Sign-on method = OpenID Connect or OAuth 2.0
3. For each application, click Okta API Scopes tab
4. Document all granted scopes — flag any with okta.users.manage, okta.apps.manage, or okta.authorizationServers.manage

Step 2: Configure App Integration Policies

1. Navigate to: Settings → Account → App Integration Settings
2. Under User app requests:
   • Select Require admin approval for user-initiated app integrations
3. Under Third-party app consent:
   • Select Only allow pre-approved applications
4. Click Save

Step 3: Audit API Scopes for Each Application

1. Navigate to: Security → API → Authorization Servers
2. Select the default authorization server
3. Click Scopes tab — review all custom scopes
4. Click Access Policies tab — verify policies restrict token issuance to approved clients

Step 4: Create Regular Grant Review Process

1. Export OAuth grant report monthly
2. Revoke grants for applications no longer in use
3. Alert on new OAuth consent events

Code Implementation

Code Pack: API Script

hth-okta-3.03-oauth-app-allowlisting.sh View source on GitHub ↗

# List all active OIDC/OAuth apps
ACTIVE_APPS=$(okta_get "/api/v1/apps?filter=status%20eq%20%22ACTIVE%22&limit=200" 2>/dev/null || echo "[]")
APP_IDS=$(echo "${ACTIVE_APPS}" | jq -r '.[] | select(.signOnMode == "OPENID_CONNECT" or .signOnMode == "OAUTH_2_0") | .id' 2>/dev/null || true)

GRANTS=$(okta_get "/api/v1/apps/${APP_ID}/grants" 2>/dev/null || echo "[]")
BROAD_SCOPES=$(echo "${GRANTS}" | jq -r '.[] | select(.scopeId | test("manage|write"; "i")) | .scopeId' 2>/dev/null || true)

# List OAuth clients on default authorization server
info "3.3 Auditing default authorization server clients..."
okta_get "/api/v1/authorizationServers/default/clients" 2>/dev/null \
  | jq -r '.[] | "  - \(.client_name // "unnamed") (ID: \(.client_id))"' 2>/dev/null || true

Code Pack: Sigma Detection Rule

hth-okta-3.03-oauth-app-allowlisting.yml View source on GitHub ↗

detection:
    selection:
        eventType:
            - 'app.oauth2.consent.grant'
            - 'app.oauth2.as.consent.grant'
    condition: selection
fields:
    - actor.displayName
    - actor.alternateId
    - target.displayName
    - debugContext.debugData.requestedScopes
    - client.ipAddress
    - published

Validation & Testing

1. Verify admin approval is required for new app integrations
2. Attempt to add an unauthorized OAuth application as a standard user — should require admin approval
3. Confirm no applications have overly broad scopes (*.manage, *.write) unless justified

Monitoring & Maintenance

Log query: See Code Pack section 3.3 (cli) above for the System Log filter expression.

Maintenance schedule:

• Monthly: Review OAuth consent grants across all users
• Quarterly: Audit application scopes and remove excessive permissions
• On new integration: Require security review before OAuth grant approval

---

3.4 Govern Non-Human Identities (NHI)

Profile Level: L1 (Crawl)

Framework	Control
NIST 800-53	IA-4, IA-5, AC-2
DISA STIG	v1.1 NHI Controls (Feb 2026)

Description

Implement governance for non-human identities: service accounts, API tokens, automation accounts, and machine-to-machine (M2M) integrations. Migrate from static SSWS API tokens to OAuth 2.0 for API access. NHI compromise is a leading cause of identity-based breaches and is now covered by DISA STIG v1.1.

Rationale

Why This Matters:

• The October 2023 Okta breach was caused by a compromised service account whose credentials were saved to a personal Google profile
• Static SSWS API tokens never expire unless manually revoked, creating persistent access risk
• Service accounts tied to individual admin users become orphaned when that admin leaves
• OAuth 2.0 provides shorter token lifespans, granular scopes, and automatic key rotation vs static SSWS
• DISA STIG v1.1 (Feb 2026) adds five new checks specifically for NHI security

Attack Prevented: Service account compromise, API token theft and replay, persistent unauthorized access via stale tokens

Real-World Incidents:

• October 2023: Compromised service account credentials stored in personal Google profile enabled breach of Okta support system

ClickOps Implementation

Step 1: Audit All API Tokens

1. Navigate to: Security → API → Tokens
2. Document all active tokens:
   • Token name and purpose
   • Created by (which admin)
   • Created date
   • Last used date
   • Network restrictions (if any)
3. Flag tokens with no activity in 90+ days for deactivation
4. Flag tokens created by users who are no longer active

Step 2: Add IP Restrictions to Existing SSWS Tokens

1. For each active SSWS token:
   • Navigate to: Security → API → Tokens
   • Click the token name
   • Under Network, select a specific network zone (e.g., “Corporate Network” or “Automation Servers”)
   • Click Save
2. This limits where stolen tokens can be replayed from

Step 3: Create OAuth 2.0 Service Apps (Migration)

1. Navigate to: Applications → Applications
2. Click Create App Integration
3. Select API Services → Next
4. Configure:
   • App integration name: “[Service Name] API Access”
   • Grant type: Client Credentials
   • Client authentication: Public key / Private key (recommended) or Client secret
5. Under Okta API Scopes, grant ONLY the minimum required scopes
6. Click Save
7. Configure token lifetime: Security → API → Authorization Servers → default → Access Policies

Step 4: Create Dedicated Service Accounts

1. Navigate to: Directory → People
2. Click Add Person
3. Create a dedicated service account:
   • First name: “SVC”
   • Last name: “[Service Name]”
   • Username: “svc-[service]@yourdomain.com”
   • User type: Set to a custom “Service Account” type if available
4. Assign minimum-required admin role (custom role preferred over built-in)
5. Never use personal admin accounts for service/automation purposes

Step 5: Establish Token Rotation Policy

1. Document token rotation schedule:
   • SSWS tokens (legacy): Rotate every 90 days maximum
   • OAuth 2.0 client secrets: Rotate every 180 days
   • OAuth 2.0 private keys: Rotate annually
2. Set calendar reminders for rotation dates
3. Include token rotation in operational runbooks

Code Implementation

Code Pack: Terraform

hth-okta-3.04-govern-non-human-identities.tf View source on GitHub ↗

# OAuth 2.0 service app using client_credentials with private_key_jwt
resource "okta_app_oauth" "service_automation" {
  label                      = "SVC - Automation API Access"
  type                       = "service"
  grant_types                = ["client_credentials"]
  response_types             = ["token"]
  token_endpoint_auth_method = "private_key_jwt"
  pkce_required              = false

  jwks {
    kty = "RSA"
    e   = var.service_app_public_key_e
    n   = var.service_app_public_key_n
  }
}

# Grant minimum-required API scopes to the service app
resource "okta_app_oauth_api_scope" "users_read" {
  app_id = okta_app_oauth.service_automation.id
  issuer = "https://${var.okta_domain}"
  scopes = ["okta.users.read"]
}

Code Pack: API Script

hth-okta-3.04-govern-non-human-identities.sh View source on GitHub ↗

# List all active API tokens
info "3.4 Listing all active API tokens..."
API_TOKENS=$(okta_get "/api/v1/api-tokens" 2>/dev/null || echo "[]")
TOKEN_COUNT=$(echo "${API_TOKENS}" | jq 'length' 2>/dev/null || echo "0")

# List service applications (OAuth client_credentials)
info "3.4 Listing OAuth service applications..."
SERVICE_APPS=$(okta_get "/api/v1/apps?filter=status%20eq%20%22ACTIVE%22&limit=200" 2>/dev/null \
  | jq '[.[] | select(.settings.oauthClient.grant_types? // [] | index("client_credentials"))]' 2>/dev/null || echo "[]")
SVC_COUNT=$(echo "${SERVICE_APPS}" | jq 'length' 2>/dev/null || echo "0")

Code Pack: Sigma Detection Rule

hth-okta-3.04-govern-non-human-identities.yml View source on GitHub ↗

detection:
    selection:
        eventType:
            - 'system.api_token.create'
            - 'system.api_token.revoke'
            - 'app.oauth2.token.grant'
    condition: selection
fields:
    - actor.displayName
    - actor.alternateId
    - eventType
    - target.displayName
    - client.ipAddress
    - published

SSWS to OAuth 2.0 Migration Checklist

• Inventory all active SSWS tokens and their consumers
• Create OAuth 2.0 service app for each integration
• Generate and distribute private keys to consuming services
• Update consuming services to use OAuth 2.0 client credentials flow
• Test each integration with OAuth 2.0 tokens
• Add IP restrictions to SSWS tokens during transition (as fallback)
• Revoke SSWS tokens after successful migration verification
• Document new OAuth 2.0 credentials and rotation schedule

Validation & Testing

1. Verify all API tokens have network restrictions applied
2. Confirm no tokens are older than 90 days without documented exception
3. Test OAuth 2.0 service app authentication using client credentials flow
4. Verify no SSWS tokens are assigned to personal admin accounts used by humans

Monitoring & Maintenance

Log query: See Code Pack section 3.4 (cli) above for the System Log filter expression.

Maintenance schedule:

• Monthly: Review API token usage (flag tokens with no recent activity)
• Quarterly: Rotate SSWS tokens and OAuth 2.0 client secrets
• On employee departure: Audit and reassign any tokens created by departing admin
• Annually: Rotate OAuth 2.0 private keys

---

3.5 Authorize AI Agents and MCP Servers with Cross App Access (XAA)

Profile Level: L2 (Walk)

Framework	Control
CIS Controls	5.4, 6.8
NIST 800-53	AC-3, AC-6, IA-4, IA-5, AU-2

Description

Cross App Access (XAA) is Okta’s extension to OAuth 2.0 that lets an enterprise broker, scope, and audit the connections AI agents and Model Context Protocol (MCP) servers make to business applications, replacing the standing API keys those integrations otherwise require. It combines RFC 8693 token exchange with RFC 7523 JWT bearer authorization so an agent receives a scoped, short-lived, centrally revocable token bound to an enterprise identity instead of a long-lived secret pasted into a configuration file. The Model Context Protocol specification has adopted the pattern as “Enterprise-Managed Authorization,” and Okta has stated Okta Integration Network availability for Workforce Identity customers beginning August 2026. (Okta announces Cross App Access partners)

Rationale

Why This Matters:

• AI agents and MCP servers are being onboarded the way early SaaS integrations were — a human generates a long-lived API key, pastes it into a config, and nobody revisits it — which is exactly the standing-credential pattern Section 3.4 exists to eliminate
• An agent holding a static key inherits its creator’s access indefinitely; when that person changes roles or leaves, the agent keeps working and no part of the joiner-mover-leaver process catches it
• Keys embedded in agent configuration are routinely readable by the model’s own context, committed to repositories, or synced to unmanaged endpoints — the same failure mode as the October 2023 service account credential saved to a personal Google profile
• XAA issues per-connection tokens scoped to specific resources with enterprise-set lifetimes, so revoking a user or an agent in Okta severs every downstream connection immediately instead of requiring a hunt for issued keys
• Because the exchange runs through Okta, every agent-to-application call produces a System Log record attributable to an enterprise identity, turning agent activity into auditable access rather than anonymous API traffic in the destination app

Attack Prevented: Standing API key theft and replay, orphaned agent access after offboarding, unbounded agent privilege, unauditable AI-to-SaaS data movement, supply chain compromise through third-party MCP servers

Prerequisites

• Okta Workforce Identity Cloud tenant
• XAA entitlement confirmed with your Okta account team (OIN availability begins August 2026)
• Completed non-human identity inventory from Section 3.4
• Super Admin access

ClickOps Implementation

Step 1: Inventory AI Agents and MCP Servers Already in Use

1. Navigate to: Reports → Application Access Audit and export the current OAuth grants
2. Navigate to: Security → API → Tokens and flag every SSWS token whose consumer is an AI assistant, agent framework, or MCP server
3. Interview engineering and operations teams about MCP servers running on developer workstations against corporate SaaS — these almost never appear in the application inventory
4. Record for each agent: the applications it reaches, the credential type it holds, the human who created it, and the scopes granted

Step 2: Confirm XAA Availability for Your Tenant and Applications

1. Confirm your edition and XAA entitlement with your Okta account team
2. Navigate to: Applications → Browse App Catalog and check whether each target application publishes an XAA-enabled integration
3. For applications without XAA support, keep them on the OAuth 2.0 service app pattern from Section 3.4 and record the gap in your risk register

Step 3: Register the Agent as an Identity-Bound Client

1. Navigate to: Applications → Applications
2. Click Create App Integration, select API Services, and click Next
3. Name the integration for the agent rather than the person who configured it (e.g., “MCP — Ticket Triage Agent”)
4. Set Client authentication to Public key / Private key — never a shared client secret
5. Under Okta API Scopes and the resource application’s scopes, grant only the scopes the agent’s task actually requires, read-only wherever the workflow permits
6. Click Save

Step 4: Enable the Cross App Access Connection

1. Open the resource application’s configuration and enable the Cross App Access connection for the registered agent client
2. Assign the connection to a named group of authorized users rather than to Everyone — the agent’s effective access is bounded by the user identity it acts on behalf of
3. Confirm the agent obtains access through token exchange and holds no application-native API key of its own
4. Remove the superseded static key from both Okta and the downstream application

Step 5: Set Token Lifetimes and a Revocation Path

1. Navigate to: Security → API → Authorization Servers → default → Access Policies
2. Set the access token lifetime for agent clients to the shortest value the workflow tolerates — start at 1 hour
3. Document the revocation path: deactivating the app integration or removing the user from the assigned group terminates the agent’s access immediately
4. Add agent connections to the quarterly access review in Section 7.3

Time to Complete: ~1 hour per agent integration, plus inventory time

Validation & Testing

1. Every AI agent and MCP server in the inventory maps to either an XAA connection or a documented OAuth 2.0 service app — zero remain on static SSWS tokens
2. Confirm no agent integration authenticates with a shared client secret; all use private key authentication
3. Confirm agent scopes are read-only unless a write path is explicitly justified and documented
4. Revoke a test agent’s group assignment and confirm its next call to the downstream application fails
5. Review the System Log for app.oauth2.as.token.grant and token exchange events and confirm each agent call is attributable to a named enterprise identity
6. Deactivate a test user and confirm the agent connections acting on that user’s behalf stop working

Expected result: No AI agent or MCP server holds a standing credential; every agent-to-application connection is scoped, time-limited, attributable to an enterprise identity, and revocable from Okta.

Monitoring & Maintenance

Maintenance schedule:

• Monthly: Review new agent registrations and confirm each went through security review before receiving scopes
• Quarterly: Re-certify agent connections as part of the access review in Section 7.3
• On offboarding: Confirm the departing user’s agent connections are terminated, not just their interactive access
• On MCP server addition: Treat a third-party MCP server as a third-party integration and run it through Section 6.1 risk assessment first

Compliance Mappings

Framework	Control	Requirement
CIS Controls v8	5.4	Restrict privileges to dedicated accounts, including non-human identities
CIS Controls v8	6.8	Define and maintain role-based access control for service integrations
NIST 800-53	AC-3	Access enforcement through brokered, scoped authorization
NIST 800-53	AC-6	Least privilege applied to machine and agent identities
NIST 800-53	IA-4	Identifier management for non-human identities
NIST 800-53	IA-5	Authenticator management with short-lived, revocable tokens
NIST 800-53	AU-2	Auditable event records for every agent-to-application call
SOC 2	CC6.1	Logical access to systems restricted to authorized identities

---

4. Session Management

4.1 Configure Session Timeouts

Profile Level: L1 (Crawl)

Framework	Control
NIST 800-53	AC-12, SC-10
DISA STIG	V-273186, V-273187, V-273203

Description

Set session timeouts appropriate to risk level. Reduce maximum session lifetime and enforce re-authentication for sensitive applications.

Rationale

Why This Matters:

• Long sessions increase window for session hijacking
• October 2023 breach exploited long-lived session cookies
• Idle timeouts reduce exposure from abandoned sessions

Attack Prevented: Session hijacking via long-lived or abandoned sessions, stolen session cookie replay

Specification Requirements

Setting	L1 (Crawl)	L2 (Walk)	L3/DISA STIG
Max session lifetime	12 hours	8 hours	18 hours
Max idle time	1 hour	30 minutes	15 minutes
Admin Console idle time	30 minutes	15 minutes	15 minutes
Persistent sessions	Optional	Disabled	Disabled

ClickOps Implementation

Step 1: Configure Global Session Policy

1. Navigate to: Security → Global Session Policy
2. Select the Default Policy
3. Click Add rule (create a custom rule at Priority 1, not the “Default Rule”)
4. Configure settings per the specification requirements table above

Step 2: Configure Admin Console Session Timeout

1. Navigate to: Applications → Applications → Okta Admin Console
2. Click the Sign On tab
3. Under “Okta Admin Console session”, set:
   • Maximum app session idle time: 15 minutes (L2/L3)

Step 3: Create App-Specific Session Policies For sensitive apps (PAM, admin consoles, financial systems):

1. Navigate to app → Sign On tab
2. Configure:
   • Session lifetime: 2 hours max
   • Re-authentication: Required on every access

Code Pack: Terraform

hth-okta-4.01-configure-session-timeouts.tf View source on GitHub ↗

# Global session policy with hardened timeout values
resource "okta_policy_signon" "session_timeouts" {
  name        = "Hardened Session Timeouts"
  status      = "ACTIVE"
  description = "Session timeout configuration per HTH hardening guide"
  priority    = 3
}

resource "okta_policy_rule_signon" "session_timeout_rule" {
  policy_id          = okta_policy_signon.session_timeouts.id
  name               = "Enforce Session Timeouts"
  status             = "ACTIVE"
  priority           = 1
  access             = "ALLOW"
  mfa_required       = true
  mfa_prompt         = "SESSION"
  session_lifetime   = var.session_max_lifetime_minutes
  session_idle       = var.session_max_idle_minutes
  session_persistent = false
}

Code Pack: API Script

hth-okta-4.01-configure-session-timeouts.sh View source on GitHub ↗

# Get global session policies and report current settings
POLICIES=$(okta_get "/api/v1/policies?type=OKTA_SIGN_ON") || {
  fail "4.1 Failed to retrieve global session policies"
  increment_failed
  summary
  exit 0
}

POLICY_COUNT=$(echo "${POLICIES}" | jq 'length' 2>/dev/null || echo "0")

if [ "${POLICY_COUNT}" -eq 0 ]; then
  warn "4.1 No global session policies found"
  increment_skipped
  summary
  exit 0
fi

for POLICY_ID in $(echo "${POLICIES}" | jq -r '.[].id' 2>/dev/null); do
  POLICY_NAME=$(echo "${POLICIES}" | jq -r ".[] | select(.id == \"${POLICY_ID}\") | .name" 2>/dev/null || echo "unknown")
  info "4.1 Reviewing session policy '${POLICY_NAME}' (${POLICY_ID})..."

  RULES=$(okta_get "/api/v1/policies/${POLICY_ID}/rules" 2>/dev/null || echo "[]")
  RULE_COUNT=$(echo "${RULES}" | jq 'length' 2>/dev/null || echo "0")

  if [ "${RULE_COUNT}" -gt 0 ]; then
    echo "${RULES}" | jq -r '.[] | "  - Rule: \(.name), MaxLifetime: \(.actions.signon.session.maxSessionLifetimeMinutes // "default")min, MaxIdle: \(.actions.signon.session.maxSessionIdleMinutes // "default")min, Persistent: \(.actions.signon.session.usePersistentCookie // "default")"' 2>/dev/null || true
  fi
done

---

4.2 Disable Session Persistence

Profile Level: L2 (Walk)

Framework	Control
NIST 800-53	SC-23
DISA STIG	V-273206

Description

Disable “Remember Me” and persistent session features that increase session hijacking risk. Persistent global session cookies allow sessions to survive browser restarts, which extends the window for session hijacking.

Rationale

Why This Matters:

• Persistent session cookies survive browser restarts and stay valid for extended periods, lengthening the window in which a stolen cookie can be replayed
• “Remember me” and persistent MFA-device features let an attacker who steals a session token bypass re-authentication entirely
• The October 2023 breach demonstrated that long-lived session cookies extracted from HAR files grant direct access without credentials or MFA
• Ending sessions with the browser limits exposure on shared, lost, or compromised devices

Attack Prevented: Session cookie theft and replay, session hijacking, persistent access from compromised devices

ClickOps Implementation

1. Navigate to: Security → Global Session Policy
2. Select the Default Policy
3. Click Add rule (create a custom rule at Priority 1)
4. Disable:
   • Remember my device for MFA
   • Okta global session cookies persist across browser sessions: Disabled
   • Stay signed in for: Set to minimum
5. Navigate to: Customizations → Other
6. Disable: Allow users to remain signed in

Code Pack: Terraform

hth-okta-4.02-disable-session-persistence.tf View source on GitHub ↗

# Global signon policy that disables persistent sessions
# Prevents session cookies from surviving browser restarts
resource "okta_policy_signon" "disable_session_persistence" {
  count = var.profile_level >= 2 ? 1 : 0

  name        = "Disable Session Persistence"
  status      = "ACTIVE"
  description = "Disables Remember Me and persistent session cookies to reduce session hijacking risk"
  priority    = 2
}

# Rule enforcing non-persistent sessions with strict timeouts
resource "okta_policy_rule_signon" "no_persistent_sessions" {
  count = var.profile_level >= 2 ? 1 : 0

  policy_id          = okta_policy_signon.disable_session_persistence[0].id
  name               = "No Persistent Sessions"
  status             = "ACTIVE"
  priority           = 1
  access             = "ALLOW"
  mfa_required       = true
  mfa_prompt         = "SESSION"
  session_lifetime   = 480
  session_idle       = 30
  session_persistent = false
}

Code Pack: API Script

hth-okta-4.02-disable-session-persistence.sh View source on GitHub ↗

POLICIES=$(okta_get "/api/v1/policies?type=OKTA_SIGN_ON") || {
  fail "4.2 Failed to retrieve global session policies"
  increment_failed
  summary
  exit 0
}

persistent_found=false

for POLICY_ID in $(echo "${POLICIES}" | jq -r '.[].id' 2>/dev/null); do
  RULES=$(okta_get "/api/v1/policies/${POLICY_ID}/rules" 2>/dev/null || echo "[]")
  PERSISTENT=$(echo "${RULES}" | jq '[.[] | select(.actions.signon.session.usePersistentCookie == true)] | length' 2>/dev/null || echo "0")

  if [ "${PERSISTENT}" -gt 0 ]; then
    persistent_found=true
    POLICY_NAME=$(echo "${POLICIES}" | jq -r ".[] | select(.id == \"${POLICY_ID}\") | .name" 2>/dev/null || echo "unknown")
    warn "4.2 Found ${PERSISTENT} rule(s) with persistent sessions in policy '${POLICY_NAME}' (${POLICY_ID})"
  fi
done

---

4.3 Configure Admin Session Security

Profile Level: L1 (Crawl)

Framework	Control
NIST 800-53	SC-23, AC-12

Description

Harden admin sessions with ASN binding, IP binding, and Protected Actions. These controls prevent session hijacking by invalidating admin sessions when network characteristics change, and require step-up authentication before critical operations.

Rationale

Why This Matters:

• The October 2023 breach demonstrated that stolen admin session tokens can be replayed from any network
• Admin Session ASN Binding invalidates sessions when the Autonomous System Number changes (e.g., attacker replays from a different ISP)
• Admin Session IP Binding is more restrictive — invalidates on any IP change
• Protected Actions require step-up authentication before high-impact operations like creating IdPs or resetting MFA factors
• These are post-breach product enhancements specifically designed to prevent session hijacking

Attack Prevented: Admin session hijacking, stolen session token replay, unauthorized critical operations

Real-World Incidents:

• October 2023: Stolen HAR file session tokens replayed from attacker infrastructure to access admin consoles

ClickOps Implementation

Step 1: Verify Admin Session ASN Binding (Enabled by Default)

1. Navigate to: Security → General
2. Scroll to Admin Session Settings
3. Verify Bind admin sessions to ASN is ON
4. If not enabled, toggle it ON and click Save

Step 2: Enable Admin Session IP Binding (Recommended for L2+)

1. Navigate to: Security → General
2. Under Admin Session Settings:
   • Enable Bind admin sessions to IP address
3. Click Save

Note: IP binding may cause disruptions for admins on dynamic IP addresses or mobile networks. Test with a pilot group before enforcing broadly.

Step 3: Enable Protected Actions

1. Navigate to: Security → General
2. Scroll to Protected Actions
3. Click Edit
4. Enable Protected Actions and select the operations that require step-up authentication:
   • ☑ Activate/deactivate identity providers
   • ☑ Create/modify identity providers
   • ☑ Reset user MFA factors
   • ☑ Modify authentication policies
   • ☑ Create/modify admin role assignments
   • ☑ Modify network zones
5. Set Authenticator requirement: Phishing-resistant (FIDO2/WebAuthn)
6. Click Save

Step 4: Disable MFA Device Remembrance for Admin Sessions

1. Navigate to: Security → Authentication Policies
2. Select the Okta Admin Console policy
3. Edit the active rule:
   • Set MFA remember device: Disabled (require MFA every session)
   • Set Re-authentication frequency: Every sign-in attempt
4. Click Save

Code Implementation

Code Pack: API Script

hth-okta-4.03-admin-session-security.sh View source on GitHub ↗

info "4.3 Updating admin session binding settings..."
okta_put "/api/v1/org/settings" "{
  \"adminSessionASNBinding\": \"${asn_target}\",
  \"adminSessionIPBinding\": \"${ip_target}\"
}" > /dev/null 2>&1 && {
  pass "4.3 Admin session security updated (ASN: ${asn_target}, IP: ${ip_target})"
  increment_applied
} || {
  fail "4.3 Failed to update admin session settings"
  increment_failed
}

Code Pack: Sigma Detection Rules (2)

hth-okta-4.03-admin-session-security.yml View source on GitHub ↗

detection:
    selection:
        eventType: 'user.session.invalidate'
    filter_binding:
        debugContext.debugData.reason: 'ADMIN_SESSION_BINDING'
    condition: selection and filter_binding
fields:
    - actor.displayName
    - actor.alternateId
    - client.ipAddress
    - debugContext.debugData.reason
    - outcome.result
    - published

---

hth-okta-4.03-admin-session-security-b.yml View source on GitHub ↗

detection:
    selection:
        eventType:
            - 'system.protected_action.challenge'
            - 'system.protected_action.success'
    condition: selection
fields:
    - actor.displayName
    - actor.alternateId
    - eventType
    - target.displayName
    - client.ipAddress
    - published

Validation & Testing

1. Verify ASN binding is active: Navigate to Security → General → Admin Session Settings
2. Verify IP binding is active (if applicable)
3. Test Protected Actions: Attempt to modify an IdP — should prompt for step-up authentication
4. Test session invalidation: Log in as admin, change network (e.g., switch from WiFi to VPN) — session should be invalidated if IP binding is enabled

Monitoring & Maintenance

Log queries: See Code Pack section 4.3 (cli) above for session binding and Protected Actions log filter expressions.

Maintenance schedule:

• Monthly: Review Protected Actions audit log for any failures or unusual patterns
• Quarterly: Review IP binding exceptions for admins on dynamic networks

---

5. Monitoring & Detection

5.1 Enable Comprehensive System Logging

Profile Level: L1 (Crawl)

Framework	Control
NIST 800-53	AU-2, AU-3, AU-6
DISA STIG	V-273202 (HIGH)

Description

Configure Okta System Log forwarding to SIEM with comprehensive event capture for security monitoring and incident response.

Rationale

Why This Matters:

• Without centralized log forwarding, security teams cannot detect authentication anomalies, policy tampering, or account takeover in time to respond
• Okta retains System Log data for a limited window — streaming to a SIEM preserves the evidence needed for forensic investigation and compliance retention
• Correlating Okta events with other telemetry surfaces multi-stage attacks (impossible travel, factor enrollment, privilege change) that are invisible in isolation
• DISA STIG V-273202 (HIGH) and most audit frameworks require centralized, tamper-evident audit logging of identity events

Attack Prevented: Undetected account takeover, log tampering, delayed incident response, evidence loss

ClickOps Implementation

Step 1: Configure Log Streaming

1. Navigate to: Reports → Log Streaming
2. Click Add Log Stream
3. Select integration type:
   • AWS EventBridge - For AWS-based SIEM solutions
   • Splunk Cloud - For Splunk deployments
4. Complete the required configuration fields
5. Click Save and verify the connection is Active

Step 2: Alternative - Okta Log API Integration If your SIEM is not directly supported:

1. Navigate to: Security → API → Tokens
2. Create an API token with read-only System Log permissions
3. Configure your SIEM to pull logs via the System Log API endpoint

Step 3: Create Alert Rules (via SIEM)

Code Pack: API Script

hth-okta-5.01-comprehensive-logging.sh View source on GitHub ↗

# Verify System Log API is accessible and returning events
info "5.1 Testing System Log API access..."
LOG_RESPONSE=$(okta_get "/api/v1/logs?limit=1" 2>/dev/null || echo "[]")
LOG_COUNT=$(echo "${LOG_RESPONSE}" | jq 'length' 2>/dev/null || echo "0")

# Check for log streaming integrations
info "5.1 Checking log streaming configuration..."
LOG_STREAMS=$(okta_get "/api/v1/logStreams" 2>/dev/null || echo "[]")
STREAM_COUNT=$(echo "${LOG_STREAMS}" | jq 'length' 2>/dev/null || echo "0")

Code Pack: Sigma Detection Rules (3)

hth-okta-5.01-comprehensive-logging.yml View source on GitHub ↗

detection:
    selection:
        eventType|startswith: 'system.role'
    condition: selection
fields:
    - actor.displayName
    - actor.alternateId
    - target.displayName
    - eventType
    - client.ipAddress
    - published

---

hth-okta-5.01-comprehensive-logging-b.yml View source on GitHub ↗

detection:
    selection:
        eventType: 'user.session.start'
        outcome.result: 'FAILURE'
    condition: selection
fields:
    - actor.displayName
    - actor.alternateId
    - client.ipAddress
    - outcome.result
    - outcome.reason
    - published

---

hth-okta-5.01-comprehensive-logging-c.yml View source on GitHub ↗

detection:
    selection:
        eventType: 'user.authentication.sso'
    condition: selection
fields:
    - actor.displayName
    - actor.alternateId
    - client.ipAddress
    - client.geographicalContext.country
    - client.geographicalContext.city
    - published

---

5.2 Configure ThreatInsight

Profile Level: L1 (Crawl)

Description

Enable Okta ThreatInsight to automatically block authentication from known-malicious IPs based on Okta’s threat intelligence.

Rationale

Why This Matters:

• ThreatInsight draws on signals aggregated across Okta’s customer base to identify IPs actively conducting credential-based attacks
• Setting the action to Block stops authentication attempts from known-malicious sources before they ever reach a password or MFA check
• Network-level blocking of attacker infrastructure reduces the volume of credential-stuffing and password-spray traffic the tenant must absorb
• It is a low-effort control requiring no additional credentials that adds a proactive defensive layer in front of every login

Attack Prevented: Credential stuffing, password spraying, brute-force attempts from known-malicious IPs

ClickOps Implementation

1. Navigate to: Security → General
2. Under Okta ThreatInsight:
   • Action: Block
   • Exempt IPs: Add known testing IPs if needed
3. Save

Code Pack: Terraform

hth-okta-5.02-configure-threatinsight.tf View source on GitHub ↗

# Enable ThreatInsight in block mode
resource "okta_threat_policy" "threatinsight" {
  action = "block"
}

Code Pack: API Script

hth-okta-5.02-configure-threatinsight.sh View source on GitHub ↗

# Enable ThreatInsight with block action
info "5.2 Setting ThreatInsight to block mode..."
okta_post "/api/v1/threats/configuration" '{
  "action": "block"
}' > /dev/null 2>&1 && {
  pass "5.2 ThreatInsight set to block mode"
  increment_applied
  summary
  exit 0
} || true

# Try PUT instead (API may vary by Okta version)
okta_put "/api/v1/threats/configuration" '{
  "action": "block"
}' > /dev/null 2>&1 && {
  pass "5.2 ThreatInsight set to block mode"
  increment_applied
} || {
  warn "5.2 Failed to configure ThreatInsight -- may require Adaptive MFA license"
  warn "5.2 Configure manually: Security > General > ThreatInsight > Block"
  increment_skipped
}

---

5.3 Enable Identity Threat Protection (ITP)

Profile Level: L2 (Walk)

Framework	Control
NIST 800-53	SI-4, RA-5

Description

Enable Identity Threat Protection with Okta AI for continuous post-authentication risk evaluation. Unlike traditional MFA (authentication-time only), ITP evaluates risk signals during active sessions and can automatically terminate sessions, require step-up MFA, or trigger Workflows responses in real-time.

Rationale

Why This Matters:

• Traditional authentication is a point-in-time check — once past MFA, an attacker has free access until the session expires
• ITP continuously evaluates risk signals: session anomalies, impossible travel, credential compromise intelligence
• Aligns with NIST 800-63-4’s Digital Identity Risk Management (DIRM) framework for continuous risk evaluation
• Can automatically respond to detected threats without human intervention

Attack Prevented: Session hijacking detected post-authentication, compromised credential use, anomalous session behavior

Prerequisites

• Okta Identity Threat Protection license (add-on to Okta Identity Engine)
• Super Admin access
• SIEM integration configured (to receive ITP events)

ClickOps Implementation

Step 1: Enable Identity Threat Protection

1. Navigate to: Security → Identity Threat Protection
2. Click Enable ITP
3. Review the default risk policies

Step 2: Configure Risk Policies

1. Navigate to: Security → Identity Threat Protection → Policies
2. Configure response actions for each risk level:

Risk Level	Recommended Action
Low	Log only
Medium	Require step-up MFA
High	Terminate session immediately
Critical	Terminate session + lock account

1. Click Save

Step 3: Configure Session Risk Evaluation

1. Navigate to: Security → Authentication Policies
2. Edit rules to include: Evaluate risk with ITP = Enabled
3. Set re-authentication triggers based on risk score changes

Step 4: Integrate with Okta Workflows (Optional)

1. Navigate to: Workflow → Flows
2. Create a flow triggered by ITP Risk Event
3. Configure automated response actions:
   • Send Slack/Teams alert to security team
   • Create ticket in ITSM
   • Revoke active sessions for affected user
   • Add source IP to dynamic blocklist

Monitoring & Maintenance

Code Pack: Sigma Detection Rule

hth-okta-5.03-enable-identity-threat-protection.yml View source on GitHub ↗

detection:
    selection_event:
        eventType:
            - 'security.threat.detected'
            - 'security.session.risk_change'
    selection_risk:
        debugContext.debugData.riskLevel:
            - 'HIGH'
            - 'CRITICAL'
    condition: selection_event and selection_risk
fields:
    - actor.displayName
    - client.ipAddress
    - outcome.result
    - debugContext.debugData.riskLevel
    - debugContext.debugData.riskReasons
    - published

---

5.4 Configure Behavior Detection Rules

Profile Level: L2 (Walk)

Framework	Control
NIST 800-53	SI-4, AC-7

Description

Configure Okta’s Behavior Detection to identify anomalous user behavior patterns and trigger adaptive authentication responses. Detection types include new device, new location, new IP, velocity anomalies (impossible travel), and IP reputation.

Rationale

Why This Matters:

• Behavioral analytics detect account compromise that static policies miss
• New device/location from an existing user may indicate credential theft
• Impossible travel (logging in from two distant locations within minutes) is a strong indicator of token replay
• Risk-based authentication adapts security requirements to threat level

Attack Prevented: Account takeover via stolen credentials, session replay from anomalous locations, impossible travel attacks

ClickOps Implementation

Step 1: Configure Behavior Detection Rules

1. Navigate to: Security → Behavior Detection
2. Review the default behavior types:

Behavior Type	Recommended Action
New Device	Challenge with additional factor
New IP	Challenge with additional factor
New City	Challenge with additional factor
New State	Log only
New Country	Deny
Velocity (impossible travel)	Deny

1. Click Edit for each behavior type
2. Set the Action per the table above
3. Click Save

Step 2: Enable Risk Scoring in Authentication Policies

1. Navigate to: Security → Authentication Policies
2. Edit the primary user-facing policy
3. In the rule conditions, enable:
   • Risk score: Evaluate risk for each authentication request
4. Configure responses:
   • Low risk: Allow with current factors
   • Medium risk: Challenge with additional factor
   • High risk: Deny access
5. Click Save

Code Implementation

Code Pack: Terraform

hth-okta-5.04-behavior-detection.tf View source on GitHub ↗

# Behavior detection rule for new location sign-on
resource "okta_behaviour" "new_location" {
  count = var.profile_level >= 2 ? 1 : 0

  name                      = "New Location Sign-On"
  type                      = "ANOMALOUS_LOCATION"
  status                    = "ACTIVE"
  number_of_authentications  = 3
  location_granularity_type  = "CITY"
}

# Behavior detection rule for new device
resource "okta_behaviour" "new_device" {
  count = var.profile_level >= 2 ? 1 : 0

  name                      = "New Device Sign-On"
  type                      = "ANOMALOUS_DEVICE"
  status                    = "ACTIVE"
  number_of_authentications  = 3
}

Code Pack: API Script

hth-okta-5.04-behavior-detection.sh View source on GitHub ↗

# List all configured behavior detection rules
info "5.4 Listing current behavior detection rules..."
BEHAVIORS=$(okta_get "/api/v1/behaviors" 2>/dev/null || echo "[]")
BEHAVIOR_COUNT=$(echo "${BEHAVIORS}" | jq 'length' 2>/dev/null || echo "0")

info "5.4 Creating new country detection rule..."
okta_post "/api/v1/behaviors" '{
  "name": "New Country Detection",
  "type": "ANOMALOUS_LOCATION",
  "status": "ACTIVE",
  "settings": {
    "maxEventsUsedForEvaluation": 50
  }
}' > /dev/null 2>&1 && {
  pass "5.4 New Country Detection behavior rule created"
} || {
  warn "5.4 Failed to create behavior rule (may already exist with different name)"
}

Code Pack: Sigma Detection Rule

hth-okta-5.04-behavior-detection.yml View source on GitHub ↗

detection:
    selection:
        eventType: 'security.behavior_detection.triggered'
    condition: selection
fields:
    - actor.displayName
    - actor.alternateId
    - client.ipAddress
    - client.geographicalContext.city
    - client.geographicalContext.country
    - debugContext.debugData.behaviors
    - outcome.result
    - published

Validation & Testing

1. Verify all behavior detection rules are active: Security → Behavior Detection
2. Test new device detection: Log in from an unrecognized browser — should trigger MFA challenge
3. Review risk score evaluation: Check system log for security.behavior_detection.triggered events

Monitoring & Maintenance

Log query: See Code Pack section 5.4 (cli) above for the System Log filter expression.

---

5.5 Monitor for Cross-Tenant Impersonation

Profile Level: L1 (Crawl)

Framework	Control
NIST 800-53	SI-4, AU-6

Description

Monitor for cross-tenant impersonation attacks where an adversary with admin access configures a malicious Identity Provider (IdP) to impersonate any user without credentials or MFA. This is a high-impact, low-volume attack that should trigger immediate investigation.

Rationale

Why This Matters:

• An attacker with admin access can create a malicious external IdP
• They then configure routing rules to direct authentication through the malicious IdP
• This allows impersonation of ANY user without knowing their credentials or MFA
• The attack leaves traces in system logs but is difficult to detect without specific monitoring
• IdP lifecycle events are high-impact but low-volume — ideal for alerting

Attack Prevented: Cross-tenant impersonation via malicious IdP configuration, unauthorized federation trust establishment

Real-World Context:

• Obsidian Security Research: Documented this technique as a post-compromise persistence mechanism used against Okta customers

ClickOps Implementation

Step 1: Restrict IdP Configuration Permissions

1. Navigate to: Security → Administrators
2. Review all users with admin roles that include IdP management permissions
3. Limit IdP configuration capability to the absolute minimum number of administrators
4. Create a custom admin role WITHOUT IdP management if possible:
   • Navigate to: Security → Administrators → Roles → Create new role
   • Exclude permissions: okta.idps.manage, okta.policies.manage (for IDP_DISCOVERY type)
5. Reassign administrators to the restricted role

Step 2: Audit Existing Identity Providers

1. Navigate to: Security → Identity Providers
2. Document all configured IdPs:
   • Name, type, status, created date, created by
3. Flag any IdPs that are unfamiliar or recently created
4. Verify each IdP has a legitimate business purpose

Step 3: Audit Routing Rules

1. Navigate to: Security → Identity Providers → Routing Rules
2. Review all routing rules:
   • Verify each rule routes to a legitimate IdP
   • Check for overly broad conditions (e.g., “all users” routing to an external IdP)
   • Flag any recently created or modified rules

Step 4: Create SIEM Alerts for IdP Lifecycle Events Configure alerts in your SIEM for these system log events:

• system.idp.lifecycle.create — New IdP created
• system.idp.lifecycle.update — IdP configuration modified
• system.idp.lifecycle.activate — IdP activated
• system.idp.lifecycle.deactivate — IdP deactivated
• policy.lifecycle.create / policy.lifecycle.update (where policy type = IDP_DISCOVERY) — Routing rule changes

Code Implementation

Code Pack: API Script

hth-okta-5.05-cross-tenant-impersonation.sh View source on GitHub ↗

# Audit all configured identity providers
info "5.5 Listing all configured identity providers..."
IDPS=$(okta_get "/api/v1/idps" 2>/dev/null || echo "[]")
IDP_COUNT=$(echo "${IDPS}" | jq 'length' 2>/dev/null || echo "0")

# Audit IDP discovery (routing) policies
info "5.5 Auditing IDP discovery (routing) policies..."
IDP_POLICIES=$(okta_get "/api/v1/policies?type=IDP_DISCOVERY" 2>/dev/null || echo "[]")
IDP_POLICY_COUNT=$(echo "${IDP_POLICIES}" | jq 'length' 2>/dev/null || echo "0")

if [ "${IDP_POLICY_COUNT}" -gt 0 ]; then
  info "5.5 Found ${IDP_POLICY_COUNT} IDP discovery policy/policies:"
  echo "${IDP_POLICIES}" | jq -r '.[] | "  - \(.name) (status: \(.status), lastUpdated: \(.lastUpdated))"' 2>/dev/null || true

  # Get rules for each IDP discovery policy
  for POLICY_ID in $(echo "${IDP_POLICIES}" | jq -r '.[].id' 2>/dev/null); do
    info "5.5 Routing rules for policy ${POLICY_ID}:"
    okta_get "/api/v1/policies/${POLICY_ID}/rules" 2>/dev/null \
      | jq -r '.[] | "    - Rule: \(.name)"' 2>/dev/null || true
  done
fi

# Search system log for recent IdP lifecycle events (last 7 days)
info "5.5 Checking for recent IdP lifecycle events (last 7 days)..."
SINCE=$(date -d '7 days ago' -u +%Y-%m-%dT%H:%M:%S.000Z 2>/dev/null \
  || date -v-7d -u +%Y-%m-%dT%H:%M:%S.000Z 2>/dev/null || echo "")

if [ -n "${SINCE}" ]; then
  IDP_EVENTS=$(okta_get "/api/v1/logs?filter=eventType+sw+%22system.idp.lifecycle%22&since=${SINCE}" 2>/dev/null || echo "[]")
  EVENT_COUNT=$(echo "${IDP_EVENTS}" | jq 'length' 2>/dev/null || echo "0")

  if [ "${EVENT_COUNT}" -gt 0 ]; then
    warn "5.5 Found ${EVENT_COUNT} IdP lifecycle event(s) in the last 7 days -- INVESTIGATE IMMEDIATELY"
    echo "${IDP_EVENTS}" | jq -r '.[] | "  - \(.eventType): \(.actor.displayName) -> \(.target[0].displayName // "unknown") at \(.published)"' 2>/dev/null || true
  else
    pass "5.5 No IdP lifecycle events in the last 7 days"
  fi
else
  warn "5.5 Unable to compute date range -- skipping log check"
fi

Code Pack: Sigma Detection Rules (2)

hth-okta-5.05-cross-tenant-impersonation.yml View source on GitHub ↗

detection:
    selection:
        eventType:
            - 'system.idp.lifecycle.create'
            - 'system.idp.lifecycle.activate'
    condition: selection
fields:
    - actor.displayName
    - actor.alternateId
    - target.displayName
    - target.type
    - client.ipAddress
    - published

---

hth-okta-5.05-cross-tenant-impersonation-b.yml View source on GitHub ↗

detection:
    selection:
        eventType:
            - 'policy.lifecycle.create'
            - 'policy.lifecycle.update'
    filter_policy_type:
        debugContext.debugData.policyType: 'IDP_DISCOVERY'
    condition: selection and filter_policy_type
fields:
    - actor.displayName
    - target.displayName
    - client.ipAddress
    - published

Validation & Testing

1. Verify IdP management is restricted to minimum necessary administrators
2. Confirm all existing IdPs have documented business justification
3. Verify SIEM alerts are configured for system.idp.lifecycle.* events
4. Test alert: Create a test IdP in a sandbox tenant and verify alert fires

Monitoring & Maintenance

SIEM alert rules (CRITICAL – investigate immediately): See Code Pack section 5.5 (db) above for IdP creation and routing rule modification detection queries.

Maintenance schedule:

• Weekly: Review IdP configuration and routing rules for unauthorized changes
• Monthly: Verify SIEM alerts for IdP events are functioning (test with log injection)
• On any alert fire: Immediately investigate — this is a high-severity indicator

---

5.6 Run HealthInsight Security Reviews

Profile Level: L1 (Crawl)

Framework	Control
NIST 800-53	CA-7, RA-5

Description

Run Okta HealthInsight regularly to assess your tenant’s security posture against Okta’s 16 built-in security recommendations. HealthInsight provides a posture score and actionable remediation guidance for common misconfigurations.

Rationale

Why This Matters:

• HealthInsight is free and built into every Okta admin console — no additional license needed
• Provides automated detection of common security misconfigurations
• Serves as a baseline security checklist aligned with Okta’s own best practices
• Posture score tracking over time demonstrates continuous improvement for auditors

Attack Prevented: Exploitation of common tenant misconfigurations left undetected between reviews

ClickOps Implementation

Step 1: Access HealthInsight

1. Navigate to: Security → HealthInsight
2. Review the dashboard showing overall posture score

Step 2: Review All 16 Recommendations

#	HealthInsight Check	Category
1	Admin MFA enrollment	Authentication
2	User MFA enrollment	Authentication
3	Phishing-resistant authenticator enabled	Authentication
4	Password policy complexity	Password
5	Password policy age settings	Password
6	Common password check enabled	Password
7	Account lockout configured	Account Security
8	Session timeout configured	Session
9	Persistent sessions disabled	Session
10	ThreatInsight enabled and set to block	Threat Protection
11	Network zones configured	Network
12	Suspicious Activity Reporting enabled	Monitoring
13	New sign-on notification enabled	Notifications
14	Authenticator enrollment notification enabled	Notifications
15	Password change notification enabled	Notifications
16	System log forwarding configured	Logging

Step 3: Remediate Failed Checks

1. For each check with Failed or Warning status:
   • Click the recommendation for detailed remediation steps
   • Follow Okta’s guided remediation
   • Mark as resolved after implementation
2. Target: All 16 checks should show Passed

Step 4: Schedule Regular Reviews

1. Set a monthly calendar reminder to review HealthInsight
2. Document posture score in your security metrics dashboard
3. Include HealthInsight review in your quarterly security review process

Validation & Testing

1. Navigate to Security → HealthInsight and verify it loads
2. Document current posture score as baseline
3. Verify all 16 checks have been reviewed
4. Remediate any Failed checks and confirm they move to Passed

Monitoring & Maintenance

Maintenance schedule:

• Monthly: Run HealthInsight review, remediate new findings
• Quarterly: Report posture score to security leadership
• After configuration changes: Re-run HealthInsight to verify no regression

---

5.7 Deploy Identity Security Posture Management (ISPM)

Profile Level: L2 (Walk)

Framework	Control
CIS Controls	5.3, 6.2
NIST 800-53	CA-7, RA-5, AC-2(3), AC-6(7)

Description

Identity Security Posture Management is Okta’s native posture module that continuously scans the identity graph and reports exploitable weaknesses rather than checking a fixed list of tenant settings. It surfaces shadow admin accounts and permissions, dormant identities unused for 90 days or more, access points without MFA including local accounts, permission creep where users hold more access than their current role requires, and offboarded users who still retain active access. Coverage extends past Okta itself into Microsoft Entra ID and Microsoft 365, AWS, and Salesforce. (Okta Identity Security Posture Management)

Rationale

Why This Matters:

• HealthInsight (Section 5.6) checks sixteen fixed tenant settings and answers “is Okta configured correctly” — it cannot see that a user accumulated three overlapping admin grants, or that a contractor’s account still holds Salesforce access two months after offboarding
• Shadow admins hold administrative capability through group nesting, delegated permissions, or app-level roles without ever appearing on the Security → Administrators list, so the admin-count review in Section 7.3 misses them entirely
• Dormant accounts are the preferred takeover target precisely because no legitimate owner will notice the sign-on; Section 1.6 automates suspension inside Okta, but ISPM finds the same problem in connected clouds where no such automation exists
• MFA coverage gaps rarely present as an obvious policy misconfiguration — they present as a specific local account, a legacy protocol path, or an application still assigned to the Default Policy, and finding those requires graph analysis rather than a settings check
• Posture findings are continuous and scored, which converts identity hygiene into a trackable metric for leadership and gives auditors evidence of ongoing monitoring instead of a point-in-time review

Attack Prevented: Privilege escalation via shadow admin paths, dormant account takeover, MFA bypass through uncovered access points, lateral movement using stale offboarded access, privilege creep exploitation

Prerequisites

• ISPM entitlement confirmed with your Okta account team
• Super Admin access
• Read-only service credentials for any connected platform (Entra ID, AWS, Salesforce)

ClickOps Implementation

Step 1: Enable ISPM and Run the First Scan

1. Confirm ISPM entitlement for your Okta edition with your account team
2. In the Admin Console, open Identity Security Posture Management from the security navigation
3. Complete the initial tenant scan and wait for the first posture report to populate

Step 2: Connect Additional Identity Sources

1. Open the ISPM integrations configuration
2. Connect the platforms that hold privileged access outside Okta: Microsoft Entra ID / Microsoft 365, AWS, and Salesforce
3. Grant each connector read-only permissions — posture assessment never requires write access
4. Re-run the scan and confirm each connected source is reporting identities and permissions

Step 3: Triage the First Posture Report Work the findings in this order:

Priority	Finding Type	Action
1	Shadow admin accounts and permissions	Remove the implicit path or convert it to an explicit, scoped custom admin role (Section 1.2)
2	Offboarded users with active access	Deprovision immediately, then fix the offboarding gap that allowed it
3	Access points without MFA	Bring under an explicit authentication policy (Sections 1.1 and 1.9)
4	Dormant identities (90+ days)	Suspend per Section 1.6 and extend the same rule to connected platforms
5	Over-privileged access and permission creep	Reduce to current-role need at the next access review (Section 7.3)

Step 4: Assign Ownership and Route Findings

1. Assign a named owner for each finding category
2. Route new critical findings into your ticketing system so they are tracked to closure rather than admired in a dashboard
3. Forward ISPM events to your SIEM alongside System Log data (Section 5.1)

Step 5: Baseline and Track

1. Record the initial posture score and per-category finding counts as your baseline
2. Set a target reduction for each category and review progress monthly
3. Report the trend to security leadership quarterly alongside the HealthInsight score

Time to Complete: ~2 hours for enablement and connector setup, plus remediation time proportional to findings

Validation & Testing

1. ISPM is enabled and has completed a full scan of the Okta tenant
2. All connected identity platforms report identities and permissions successfully
3. Baseline posture score and per-category finding counts are documented
4. Every shadow admin finding is either remediated or carries a documented, time-bounded exception
5. Create a test user, grant it an indirect admin path via nested group membership, and confirm ISPM reports it as a shadow admin
6. Confirm the “offboarded users with active access” category shows zero findings after remediation

Expected result: Continuous, scored visibility into identity posture across Okta and connected platforms, with shadow admin and stale-access findings driven to zero and tracked over time.

Monitoring & Maintenance

Maintenance schedule:

• Weekly: Review new critical and high findings
• Monthly: Full triage pass and posture score trend update
• Quarterly: Report the posture trend to leadership alongside HealthInsight, and reconcile ISPM findings against the access review in Section 7.3
• On new platform onboarding: Connect the platform to ISPM as part of the deployment checklist

Note: ISPM complements rather than replaces HealthInsight (Section 5.6). HealthInsight validates tenant configuration against Okta’s sixteen built-in checks; ISPM analyzes the identity graph for exploitable access paths across Okta and connected platforms. Run both.

Compliance Mappings

Framework	Control	Requirement
CIS Controls v8	5.3	Disable dormant accounts
CIS Controls v8	6.2	Establish an access revoking process
NIST 800-53	CA-7	Continuous monitoring of security posture
NIST 800-53	RA-5	Vulnerability monitoring across identity infrastructure
NIST 800-53	AC-2(3)	Disable accounts that are dormant or no longer required
NIST 800-53	AC-6(7)	Review of user privileges to validate least privilege
SOC 2	CC6.1	Logical access reviewed and restricted to authorized users
SOC 2	CC7.1	Detection of configuration and access deviations

---

6. Third-Party Integration Security

6.1 Integration Risk Assessment Matrix

Risk Factor	Low	Medium	High
OAuth Scopes	Profile read-only	Read user data	Write users, groups, apps
SCIM Access	No SCIM	Read-only sync	Create/delete users
Admin API	No API access	Limited endpoints	Full API access
Data Access	User profile only	Group membership	Authentication data

Code Pack: API Script

hth-okta-6.01-integration-risk-assessment.sh View source on GitHub ↗

info "6.1 Fetching active applications..."
ACTIVE_APPS=$(okta_get "/api/v1/apps?filter=status%20eq%20%22ACTIVE%22&limit=200" 2>/dev/null || echo "[]")
TOTAL_APPS=$(echo "${ACTIVE_APPS}" | jq 'length' 2>/dev/null || echo "0")

6.2 Common Integrations and Recommended Controls

Salesforce

Risk Level: High (SSO + Provisioning) Controls:

• ✅ SCIM token rotation quarterly
• ✅ Limit provisioned attributes
• ✅ Enable Salesforce IP restrictions

Microsoft 365

Risk Level: High (Federation) Controls:

• ✅ Configure federation trust validation
• ✅ Disable legacy authentication
• ✅ Sync conditional access policies

GitHub Enterprise

Risk Level: High (Code access) Controls:

• ✅ SAML SSO with MFA
• ✅ Disable username/password fallback
• ✅ Sync team membership carefully

Code Pack: API Script

hth-okta-6.02-common-integrations-controls.sh View source on GitHub ↗

info "6.2 Fetching active OAuth/OIDC applications..."
ACTIVE_APPS=$(okta_get "/api/v1/apps?filter=status%20eq%20%22ACTIVE%22&limit=200" 2>/dev/null || echo "[]")
OAUTH_APPS=$(echo "${ACTIVE_APPS}" | jq '[.[] | select(.signOnMode == "OPENID_CONNECT" or .signOnMode == "OAUTH_2_0")]' 2>/dev/null || echo "[]")
OAUTH_COUNT=$(echo "${OAUTH_APPS}" | jq 'length' 2>/dev/null || echo "0")

# Fetch grants for this application
GRANTS=$(okta_get "/api/v1/apps/${APP_ID}/grants" 2>/dev/null || echo "[]")
GRANT_COUNT=$(echo "${GRANTS}" | jq 'length' 2>/dev/null || echo "0")

if [ "${GRANT_COUNT}" -eq 0 ]; then
  info "6.2   ${APP_LABEL}: no explicit scope grants"
  continue
fi

# Extract all granted scope IDs
SCOPE_LIST=$(echo "${GRANTS}" | jq -r '.[].scopeId // empty' 2>/dev/null || true)

# Check default authorization server
AUTH_CLIENTS=$(okta_get "/api/v1/authorizationServers/default/clients" 2>/dev/null || echo "[]")
DEFAULT_CLIENT_COUNT=$(echo "${AUTH_CLIENTS}" | jq 'length' 2>/dev/null || echo "0")

if [ "${DEFAULT_CLIENT_COUNT}" -gt 0 ]; then
  info "6.2 Default auth server has ${DEFAULT_CLIENT_COUNT} registered client(s):"
  echo "${AUTH_CLIENTS}" | jq -r \
    '.[] | "  - \(.client_name // "unnamed") (ID: \(.client_id))"' \
    2>/dev/null || true
else
  info "6.2 No clients registered on default authorization server"
fi

# List all custom authorization servers
AUTH_SERVERS=$(okta_get "/api/v1/authorizationServers" 2>/dev/null || echo "[]")
CUSTOM_SERVERS=$(echo "${AUTH_SERVERS}" | jq '[.[] | select(.name != "default")]' 2>/dev/null || echo "[]")
CUSTOM_COUNT=$(echo "${CUSTOM_SERVERS}" | jq 'length' 2>/dev/null || echo "0")

if [ "${CUSTOM_COUNT}" -gt 0 ]; then
  info "6.2 Found ${CUSTOM_COUNT} custom authorization server(s):"
  echo "${CUSTOM_SERVERS}" | jq -r \
    '.[] | "  - \(.name) (ID: \(.id), audiences: \(.audiences // [] | join(", ")))"' \
    2>/dev/null || true
fi

---

7. Operational Security

These controls address operational procedures and organizational practices that complement technical hardening. Many are driven by breach post-mortems and SOC 2 audit findings.

7.1 Sanitize HAR Files Before Sharing

Profile Level: L1 (Crawl)

Framework	Control
NIST 800-53	SC-28, SI-12

Description

Establish a mandatory procedure to sanitize HTTP Archive (HAR) files before sharing with Okta support or any third party. HAR files capture all HTTP traffic including session cookies, authorization tokens, and CSRF tokens. The October 2023 Okta breach was caused by unsanitized HAR files uploaded to Okta’s support system.

Rationale

Why This Matters:

• HAR files contain active session tokens that can be replayed to hijack user sessions
• The October 2023 breach affected 134 customers whose HAR files contained valid session cookies
• Okta support regularly requests HAR files for troubleshooting — this is a recurring operational risk
• Automated sanitization reduces human error in the manual stripping process

Attack Prevented: Session hijacking via HAR file token exfiltration

Real-World Incidents:

• October 2023: Threat actor accessed Okta support system and extracted session tokens from HAR files uploaded by 134 customers

Implementation

Step 1: Create Organizational Policy Document a formal policy requiring:

• All HAR files MUST be sanitized before sharing with any external party
• Engineers must use the automated sanitization script (below) or approved tooling
• Random audits of support ticket attachments to verify compliance

Step 2: Manual Sanitization Procedure

1. Open the HAR file in a text editor
2. Search for and remove all values in these fields:
   • Cookie request headers
   • Authorization request headers
   • Set-Cookie response headers
   • x-csrf-token or similar CSRF headers
   • Any Bearer token values
3. Save the sanitized file
4. Verify no sensitive tokens remain by searching for common patterns: sid=, sessionToken, Bearer, SSWS

Step 3: Automated Sanitization Script

Code Pack: Config

hth-okta-7.01-sanitize-har-files.sh View source on GitHub ↗

# har-sanitize.sh - Strip sensitive headers from HAR files
# Usage: ./har-sanitize.sh input.har > sanitized.har

INPUT_FILE="$1"
if [ -z "$INPUT_FILE" ]; then
  echo "Usage: $0 <input.har>"
  exit 1
fi

jq '
  .log.entries[].request.headers |= map(
    if (.name | test("^(Cookie|Authorization|X-CSRF-Token|X-Okta-Session)$"; "i"))
    then .value = "[REDACTED]"
    else .
    end
  ) |
  .log.entries[].response.headers |= map(
    if (.name | test("^(Set-Cookie)$"; "i"))
    then .value = "[REDACTED]"
    else .
    end
  ) |
  .log.entries[].request.cookies |= map(.value = "[REDACTED]") |
  .log.entries[].response.cookies |= map(.value = "[REDACTED]")
' "$INPUT_FILE"

Step 4: Alternative Tools

• Google HAR Sanitizer Chrome Extension — browser-based sanitization
• BurpSuite — export filtered HAR with token stripping
• mitmproxy — can export sanitized HAR during capture

Validation & Testing

1. Sanitization script is available and tested
2. Policy documented and communicated to all IT/engineering staff
3. Test: Generate a HAR file, sanitize it, verify no tokens remain by searching for sid=, Bearer, SSWS

---

7.2 Monitor Okta Security Advisories

Profile Level: L1 (Crawl)

Framework	Control
NIST 800-53	SI-5, RA-5

Description

Establish a process to monitor Okta security advisories and ensure all Okta client software (Verify, Browser Plugin) is kept up to date. Recent vulnerabilities include DLL hijacking in Okta Verify, XSS in the Browser Plugin, and iOS push notification bypasses.

Rationale

Why This Matters:

• Okta Verify for Windows was vulnerable to privilege escalation via DLL hijacking (fixed in 5.0.2)
• Okta Browser Plugin versions 6.5.0-6.31.0 were vulnerable to cross-site scripting
• Okta Verify for iOS had a push bypass allowing responses regardless of user selection
• Downstream dependencies (React/Next.js CVEs) affect Okta-integrated applications
• Okta maintains an active bug bounty program (153 valid issues, $405K paid)

Attack Prevented: Exploitation of known vulnerabilities in outdated Okta client software (DLL hijacking privilege escalation, XSS, push bypass)

Implementation

Step 1: Subscribe to Security Advisories

1. Bookmark: trust.okta.com/security-advisories
2. Subscribe to Okta’s security advisory RSS feed or email notifications
3. Add to your security team’s weekly monitoring checklist

Step 2: Establish Client Update Policy

1. Define maximum patch delay: Critical = 48 hours, High = 7 days, Medium = 30 days
2. Use MDM to enforce Okta client updates:
   • Jamf Pro (macOS): Auto-update Okta Verify via patch management
   • Microsoft Intune (Windows): Deploy Okta Verify updates via Win32 app
   • Chrome Enterprise: Force-update Okta Browser Plugin via policy
3. Block outdated client versions from authenticating (via Device Assurance policies)

Step 3: Monitor Downstream Dependencies

1. Track CVEs in frameworks used with Okta authentication:
   • React Server Components (CVE-2025-55182)
   • Next.js middleware (CVE-2025-29927)
   • Auth0 SDK versions
2. Include Okta dependency monitoring in your vulnerability management program

Validation & Testing

1. Security advisory monitoring is assigned to a specific team member
2. Client update policy is documented and enforced via MDM
3. Verify all Okta Verify installations are on the latest version

---

7.3 Conduct Regular Access Reviews

Profile Level: L1 (Crawl)

Framework	Control
NIST 800-53	AC-2(3)
SOC 2	CC6.1, CC6.2

Description

Perform periodic access reviews (recertification campaigns) to verify user access is appropriate and remove orphaned accounts, stale privileges, and excessive permissions. SOC 2 auditors specifically look for documented evidence of regular access reviews.

Rationale

Why This Matters:

• Access accumulates over time as users change roles, so without recertification, entitlements drift far beyond what each person actually needs
• Orphaned accounts from departed employees and contractors retain valid SSO access to every connected application until someone removes them
• Excess Super Admin and privileged-group membership multiplies the blast radius of any single account compromise
• The review itself is the control that catches deprovisioning gaps, and SOC 2 requires documented evidence that it happens regularly

Attack Prevented: Privilege creep, orphaned-account abuse, insider misuse, excessive standing access

ClickOps Implementation

Step 1: Review Admin Accounts

1. Navigate to: Security → Administrators
2. Review all admin accounts:
   • Verify each admin is a current employee with legitimate need
   • Count Super Admin accounts — should be fewer than 5
   • Remove admin access for anyone who has changed roles
3. Document review with date and reviewer name

Step 2: Review User Accounts

1. Navigate to: Directory → People
2. Filter by Status: Active
3. Cross-reference with HR system for terminated employees
4. Suspend any accounts for users no longer with the organization

Step 3: Review Application Assignments

1. Navigate to: Applications → Applications
2. For each sensitive application, review assigned users/groups
3. Remove users who no longer need access

Step 4: Review Group Memberships

1. Navigate to: Directory → Groups
2. Review privileged groups (admin groups, security groups)
3. Remove members who no longer need membership

Code Implementation

Code Pack: API Script

hth-okta-7.03-access-reviews.sh View source on GitHub ↗

info "7.3 Finding inactive users (no login in 90+ days)..."
ACTIVE_USERS=$(okta_get "/api/v1/users?filter=status+eq+%22ACTIVE%22&limit=200" 2>/dev/null || echo "[]")
TOTAL_ACTIVE=$(echo "${ACTIVE_USERS}" | jq 'length' 2>/dev/null || echo "0")

# Try the IAM assignees endpoint first
SUPER_ADMIN_COUNT=$(okta_get "/api/v1/iam/assignees/users?roleType=SUPER_ADMIN" 2>/dev/null \
  | jq 'length' 2>/dev/null || echo "unknown")

if [ "${SUPER_ADMIN_COUNT}" != "unknown" ] && [ "${SUPER_ADMIN_COUNT}" -ge 0 ] 2>/dev/null; then
  if [ "${SUPER_ADMIN_COUNT}" -gt 5 ]; then
    warn "7.3 Super Admin count: ${SUPER_ADMIN_COUNT} (should be fewer than 5)"
  else
    pass "7.3 Super Admin count: ${SUPER_ADMIN_COUNT} (within recommended limit of < 5)"
  fi
else
  warn "7.3 Unable to count Super Admin assignments via IAM API"

  # Fallback: enumerate users and check roles individually
  info "7.3 Attempting fallback Super Admin enumeration (checking first 50 users)..."
  super_count=0
  for USER_ID in $(echo "${ACTIVE_USERS}" | jq -r '.[].id' 2>/dev/null | head -50); do
    ROLES=$(okta_get "/api/v1/users/${USER_ID}/roles" 2>/dev/null || echo "[]")
    IS_SUPER=$(echo "${ROLES}" | jq '[.[] | select(.type == "SUPER_ADMIN")] | length' 2>/dev/null || echo "0")
    if [ "${IS_SUPER}" -gt 0 ]; then
      USER_LOGIN=$(echo "${ACTIVE_USERS}" | jq -r ".[] | select(.id == \"${USER_ID}\") | .profile.login" 2>/dev/null || echo "unknown")
      warn "7.3   Super Admin: ${USER_LOGIN}"
      super_count=$((super_count + 1))
    fi
  done

  SUPER_ADMIN_COUNT="${super_count}"
  if [ "${super_count}" -gt 5 ]; then
    warn "7.3 Found ${super_count} Super Admin(s) in first 50 users (should be < 5)"
  else
    pass "7.3 Found ${super_count} Super Admin(s) in first 50 users"
  fi
fi

info "7.3 Listing admin role assignments..."
ADMIN_ROLES=$(okta_get "/api/v1/iam/assignees/users" 2>/dev/null || echo "[]")
ADMIN_COUNT=$(echo "${ADMIN_ROLES}" | jq 'length' 2>/dev/null || echo "0")

if [ "${ADMIN_COUNT}" -gt 0 ]; then
  info "7.3 Found ${ADMIN_COUNT} admin role assignment(s)"
  echo "${ADMIN_ROLES}" | jq -r \
    '.[] | "  - User: \(.userId), Role: \(.role // .type // "unknown")"' \
    2>/dev/null || true
fi

Quarterly Access Review Checklist

• All admin accounts verified against current employee list
• Super Admin count is < 5
• No orphaned accounts (users who left but weren’t deprovisioned)
• No accounts with last login > 90 days (unless exempted)
• Privileged group memberships reviewed and justified
• Sensitive application assignments reviewed
• Review documented with date, reviewer, and findings

Monitoring & Maintenance

Maintenance schedule:

• Monthly: Review admin accounts for changes
• Quarterly: Full access review (all users, groups, applications)
• On employee termination: Immediate account deprovisioning (verify within 24 hours)
• Annually: Document access review program for SOC 2 auditors

---

7.4 Implement Change Management for Okta Configuration

Profile Level: L2 (Walk)

Framework	Control
NIST 800-53	CM-3
SOC 2	CC8.1

Description

Establish a change management process for Okta configuration changes. All modifications to authentication policies, admin roles, network zones, and integrations should be tracked, approved, and auditable.

Rationale

Why This Matters:

• Unreviewed changes to authentication policies, admin roles, or IdP configuration can silently weaken or disable security controls across the entire tenant
• An attacker with admin access can quietly relax MFA, add a malicious IdP, or widen network zones — change tracking makes these modifications visible and reversible
• Managing configuration as code with peer-reviewed pull requests enforces a second set of eyes before high-impact changes take effect
• Separation of duties prevents any single admin from both proposing and approving a critical change, satisfying SOC 2 CC8.1 change-control requirements

Attack Prevented: Unauthorized policy weakening, malicious configuration changes, insider sabotage, undetected control drift

Implementation

Step 1: Define Change Categories

Change Type	Approval Required	Examples
Critical	Security team + management	Authentication policy changes, admin role modifications, IdP configuration
Standard	Security team	Application integration, group membership changes, network zone updates
Low Risk	Self-approved (with logging)	User profile updates, non-privileged group changes

Step 2: Track Configuration as Code

1. Export Okta configuration using Terraform (see Code Pack section 7.4 cli for commands)
2. Store Terraform state in version control
3. Require pull request review for all Okta Terraform changes
4. Use terraform plan diff as the change documentation

Step 3: Monitor Configuration Changes via System Log Key events to track:

Event Type	Description
policy.lifecycle.create	New policy created
policy.lifecycle.update	Policy modified
policy.lifecycle.delete	Policy deleted
policy.rule.create	Policy rule created
policy.rule.update	Policy rule modified
application.lifecycle.create	New application added
application.lifecycle.update	Application modified
group.user_membership.add	User added to group
group.user_membership.remove	User removed from group
zone.lifecycle.create	Network zone created
zone.lifecycle.update	Network zone modified
system.role.create	Admin role created

Step 4: Implement Separation of Duties

• No single admin can both propose and approve critical changes
• Require two-person integrity for authentication policy modifications
• Use Okta Workflows to enforce approval gates for critical changes

Code Pack: Sigma Detection Rules (5)

hth-okta-7.04-implement-change-management.yml View source on GitHub ↗

detection:
    selection:
        eventType: 'system.role.create'
    condition: selection
fields:
    - actor.displayName
    - actor.alternateId
    - eventType
    - target.displayName
    - client.ipAddress
    - published

---

hth-okta-7.04-implement-change-management-b.yml View source on GitHub ↗

detection:
    selection:
        eventType:
            - 'application.lifecycle.create'
            - 'application.lifecycle.update'
    condition: selection
fields:
    - actor.displayName
    - actor.alternateId
    - eventType
    - target.displayName
    - client.ipAddress
    - published

---

hth-okta-7.04-implement-change-management-c.yml View source on GitHub ↗

detection:
    selection:
        eventType:
            - 'group.user_membership.add'
            - 'group.user_membership.remove'
    condition: selection
fields:
    - actor.displayName
    - eventType
    - target.displayName
    - client.ipAddress
    - published

---

hth-okta-7.04-implement-change-management-d.yml View source on GitHub ↗

detection:
    selection:
        eventType:
            - 'zone.lifecycle.create'
            - 'zone.lifecycle.update'
    condition: selection
fields:
    - actor.displayName
    - actor.alternateId
    - eventType
    - target.displayName
    - client.ipAddress
    - published

---

hth-okta-7.04-implement-change-management-e.yml View source on GitHub ↗

detection:
    selection:
        eventType:
            - 'policy.lifecycle.create'
            - 'policy.lifecycle.update'
            - 'policy.lifecycle.delete'
            - 'policy.rule.create'
            - 'policy.rule.update'
    condition: selection
fields:
    - actor.displayName
    - actor.alternateId
    - eventType
    - target.displayName
    - client.ipAddress
    - published

Validation & Testing

1. Change management process documented
2. Configuration tracked in version control (Terraform or equivalent)
3. SIEM alerts configured for unauthorized configuration changes
4. Separation of duties enforced for critical changes

---

7.5 Establish Identity Incident Response Procedures

Profile Level: L2 (Walk)

Framework	Control
NIST 800-53	IR-4, IR-6
SOC 2	CC7.3

Description

Document specific response procedures for identity-based security incidents. These runbooks complement your organization’s broader incident response plan with Okta-specific actions and API calls.

Rationale

Why This Matters:

• Identity incidents move fast — a compromised admin or stolen session can be used to enroll factors, create IdPs, and pivot before responders understand what happened
• Pre-written, Okta-specific runbooks let responders suspend accounts, revoke sessions, and deactivate malicious IdPs in minutes instead of improvising under pressure
• API commands tested in a sandbox ensure containment actions actually work during a real incident rather than failing on unfamiliar syntax
• Documented procedures satisfy NIST IR-4/IR-6 and SOC 2 CC7.3 and shorten the dwell time of an active attacker

Attack Prevented: Prolonged attacker dwell time, incomplete containment, persistence via factors and IdPs, repeat compromise

Incident Response Runbooks

Runbook 1: Compromised Admin Account

1. Contain: Immediately suspend the admin account (see api-ir-suspend-admin in Code Pack)
2. Revoke: Clear all active sessions (see api-ir-revoke-sessions in Code Pack)
3. Investigate: Audit all changes made by the compromised account (see api-ir-audit-changes in Code Pack)
4. Remediate: Reset credentials, re-enroll MFA, review all configuration changes
5. Restore: Reactivate account only after re-verification of identity

Runbook 2: Stolen Session Tokens

1. Revoke all active sessions for affected users
2. Identify the source of token theft (HAR files, malware, XSS)
3. Block the source IPs in network zones
4. Force re-authentication for all affected users

Runbook 3: Malicious IdP Creation

1. Deactivate the malicious IdP immediately (see api-ir-deactivate-idp in Code Pack)
2. Audit all authentications that used the malicious IdP
3. Revoke sessions for all users who authenticated via the malicious IdP
4. Investigate which admin created it and whether their account is compromised

Runbook 4: Unauthorized MFA Enrollment

1. Remove the unauthorized factor (see api-ir-delete-factor in Code Pack)
2. Investigate how the enrollment occurred (account takeover, social engineering of helpdesk)
3. Force password reset and MFA re-enrollment under verified identity
4. Review all account activity since the unauthorized enrollment

Runbook 5: Mass Password Spray Attack

1. Activate IP blocking for source IPs via ThreatInsight and network zones
2. Review lockout logs to identify targeted accounts
3. Communicate to affected users about potential credential exposure
4. Force password reset for accounts that were targeted
5. Verify MFA is enforced – password spray is only effective without MFA

Code Pack: API Script

hth-okta-7.05-identity-incident-response.sh View source on GitHub ↗

curl -X POST "https://${OKTA_DOMAIN}/api/v1/users/${USER_ID}/lifecycle/suspend" \
  -H "Authorization: SSWS ${OKTA_API_TOKEN}"

curl -X DELETE "https://${OKTA_DOMAIN}/api/v1/users/${USER_ID}/sessions" \
  -H "Authorization: SSWS ${OKTA_API_TOKEN}"

curl -s -X GET "https://${OKTA_DOMAIN}/api/v1/logs?filter=actor.id+eq+%22${USER_ID}%22&since=${INCIDENT_START}" \
  -H "Authorization: SSWS ${OKTA_API_TOKEN}" | jq '.[] | {eventType, target, published}'

curl -X POST "https://${OKTA_DOMAIN}/api/v1/idps/${IDP_ID}/lifecycle/deactivate" \
  -H "Authorization: SSWS ${OKTA_API_TOKEN}"

curl -X DELETE "https://${OKTA_DOMAIN}/api/v1/users/${USER_ID}/factors/${FACTOR_ID}" \
  -H "Authorization: SSWS ${OKTA_API_TOKEN}"

Validation & Testing

1. All 5 runbooks documented and accessible to security team
2. API commands tested in sandbox environment
3. Security team trained on runbook execution
4. Runbooks integrated into broader incident response plan

Monitoring & Maintenance

Maintenance schedule:

• Quarterly: Review and update runbooks based on new attack techniques
• After each incident: Conduct post-incident review and update relevant runbook
• Annually: Conduct tabletop exercise using runbooks

---

8. Compliance Quick Reference

8.1 SOC 2 Trust Services Criteria

Control ID	Okta Control	Guide Section
CC6.1	Phishing-resistant MFA	1.1
CC6.1	Access reviews & recertification	7.3
CC6.1	Help desk visual identity verification	1.13
CC6.1	Cross App Access for AI agents	3.5
CC6.2	Admin role separation	1.2
CC6.6	Network zone policies	2.1
CC6.6	Device assurance policies	1.12
CC7.1	Identity Security Posture Management	5.7
CC7.2	System log monitoring	5.1
CC7.3	Identity incident response	7.5
CC8.1	Change management	7.4

8.2 NIST 800-53 Rev 5

Control	Okta Control	Guide Section
AC-2	NHI governance	3.4
AC-2(3)	Account lifecycle	1.6
AC-2(3)	Access reviews	7.3
AC-3	Default authentication policy audit	1.9
AC-3	Dynamic network zones	2.3
AC-3	Cross App Access for AI agents	3.5
AC-5	Admin role separation	1.2
AC-6	Cross App Access for AI agents	3.5
AC-6(1)	Custom admin roles	1.2
AC-6(7)	Identity Security Posture Management	5.7
AC-7	Account lockout	1.5
AC-12	Session timeouts	4.1
AT-2	Help desk social engineering training	1.13
AU-2	System log	5.1
AU-2	Cross App Access audit records	3.5
AU-6	Cross-tenant impersonation monitoring	5.5
CA-7	HealthInsight reviews	5.6
CA-7	Identity Security Posture Management	5.7
CM-3	Change management	7.4
CM-6	Device assurance policies	1.12
CM-7	OAuth app allowlisting	3.3
IA-2(1)	MFA enforcement	1.1
IA-2(6)	FIDO2 for admins	1.1
IA-2(12)	PIV/CAC authentication	1.7
IA-3	Device assurance policies	1.12
IA-4	NHI governance	3.4
IA-4	Cross App Access for AI agents	3.5
IA-5	Cross App Access for AI agents	3.5
IA-5(1)	Password policy	1.4
IA-5(1)	Self-service recovery hardening	1.10
IA-5(1)	Help desk visual identity verification	1.13
IA-11	Self-service recovery hardening	1.10
IA-12	Help desk visual identity verification	1.13
IR-4	Identity incident response	7.5
IR-6	End-user security notifications	1.11
RA-5	Security advisory monitoring	7.2
RA-5	Identity Threat Protection	5.3
RA-5	Identity Security Posture Management	5.7
SC-7	Dynamic network zones	2.3
SC-13	FIPS compliance	1.8
SC-23	Session persistence	4.2
SC-23	Admin session security	4.3
SC-28	HAR file sanitization	7.1
SI-2	Device assurance policies	1.12
SI-4	End-user security notifications	1.11
SI-4	Identity Threat Protection	5.3
SI-4	Behavior detection	5.4
SI-4	Cross-tenant impersonation monitoring	5.5
SI-5	Security advisory monitoring	7.2
SI-12	HAR file sanitization	7.1

8.3 NIST 800-63-4 AAL Mapping

NIST SP 800-63-4 (final July 2025) defines Authentication Assurance Levels. Map Okta configurations to AAL levels:

AAL Level	Okta Configuration	Acceptable Authenticators	Guide Reference
AAL1	Password only	Password (NOT recommended)	1.4
AAL2	Password + any MFA	TOTP, Push, FIDO2, Syncable Passkeys	1.1
AAL2 (phishing-resistant)	Password + FIDO2	WebAuthn, FastPass, Passkeys	1.1, 1.3
AAL3	Hardware-bound authenticator	PIV/CAC, FIDO2 hardware key (non-syncable only)	1.7

Key NIST 800-63-4 Changes:

• AAL2 MUST offer a phishing-resistant MFA option (Section 1.1)
• Syncable passkeys are now explicitly accepted at AAL2
• AAL3 requires hardware-bound authenticators (syncable passkeys NOT acceptable)
• Introduces Digital Identity Risk Management (DIRM) framework for continuous risk evaluation (Section 5.3)

8.4 DISA STIG Okta IDaaS V1R1

STIG ID	Severity	Control	Guide Section
V-273186	Medium	Global session idle timeout (15 min)	4.1
V-273187	Medium	Admin Console idle timeout (15 min)	4.1
V-273188	Medium	Account inactivity auto-disable (35 days)	1.6
V-273189	Medium	Account lockout (3 attempts)	1.5
V-273190	Medium	Dashboard phishing-resistant auth	1.1
V-273191	Medium	Admin Console phishing-resistant auth	1.1
V-273192	Medium	DOD warning banner	8.5
V-273193	HIGH	Admin Console MFA required	1.1
V-273194	HIGH	Dashboard MFA required	1.1
V-273195	Medium	Password min length (15 chars)	1.4
V-273196	Medium	Uppercase required	1.4
V-273197	Medium	Lowercase required	1.4
V-273198	Medium	Number required	1.4
V-273199	Medium	Special character required	1.4
V-273200	Medium	Min password age (24 hours)	1.4
V-273201	Medium	Max password age (60 days)	1.4
V-273202	HIGH	Centralized audit logging	5.1
V-273203	Medium	Global session lifetime (18 hours)	4.1
V-273204	Medium	PIV/CAC credential acceptance	1.7
V-273205	Medium	FIPS-compliant Okta Verify	1.8
V-273206	Medium	Disable persistent session cookies	4.2
V-273207	Medium	Approved CA certificates	1.7
V-273208	Medium	Common password check	1.4
V-273209	Medium	Password history (5 generations)	1.4

DISA STIG v1.1 (Feb 2026) adds five new checks for Non-Human Identity (NHI) security: service account governance, API token lifecycle management, and CC SRG alignment. See Section 3.4 for NHI governance controls.

---

8.5 Environment-Specific Requirements

DOD Warning Banner (DISA STIG V-273192)

For U.S. Government systems, display the Standard Mandatory DOD Notice and Consent Banner before granting access. Implementation requires customizing the Okta Sign-In Widget—refer to the “Okta DOD Warning Banner Configuration Guide” in the STIG package.

DOD Banner Text (1300 characters)

---

8.6 Compliance Checklist

Use this checklist to verify controls are implemented for your compliance requirements.

HIGH Priority Controls (DISA STIG)

• MFA required for Admin Console (V-273193) — Section 1.1
• MFA required for Dashboard (V-273194) — Section 1.1
• Audit logs forwarded to SIEM (V-273202) — Section 5.1

Authentication Controls

• Phishing-resistant authentication enabled (1.1)
• Admin role separation implemented (1.2)
• Password policy configured per requirements (1.4)
• Account lockout configured (1.5)
• Account inactivity automation active (1.6)
• Default authentication policy audited — zero apps assigned (1.9)
• Self-service recovery hardened — SMS/voice/questions disabled (1.10)
• End-user security notifications enabled — all five types (1.11)
• Suspicious activity reporting enabled (1.11)
• Device assurance policy active for every platform in the fleet (1.12)
• Help desk visual identity verification required for all resets (1.13)
• PIV/CAC Smart Card configured (if applicable) (1.7)
• FIPS compliance enabled (if applicable) (1.8)

Network & Integration Controls

• Network zones configured (2.1)
• Admin console access restricted by IP (2.2)
• Anonymizer/Tor blocking active (2.3)
• OAuth app allowlisting enforced (3.3)
• Non-human identity governance implemented (3.4)
• SSWS to OAuth 2.0 migration planned/completed (3.4)
• AI agents and MCP servers brokered via Cross App Access or scoped OAuth service apps (3.5)

Session Management

• Global session idle timeout configured (4.1)
• Admin Console session timeout configured (4.1)
• Global session lifetime limited (4.1)
• Persistent session cookies disabled (4.2)
• Admin session ASN binding verified active (4.3)
• Protected Actions enabled for critical operations (4.3)

Monitoring & Detection

• Log streaming or API integration active (5.1)
• ThreatInsight enabled (5.2)
• Identity Threat Protection configured (5.3) — if licensed
• Behavior detection rules active (5.4)
• Cross-tenant impersonation monitoring alerts configured (5.5)
• HealthInsight reviewed — all 16 checks passed (5.6)
• Identity Security Posture Management deployed and findings triaged (5.7)

Operational Security

• HAR file sanitization procedure documented (7.1)
• Security advisory monitoring assigned (7.2)
• Quarterly access reviews scheduled (7.3)
• Change management process for Okta config (7.4)
• Identity incident response procedures documented (7.5)

---

Appendix A: Edition Compatibility

Control	Okta Starter	Okta SSO	Okta Adaptive	Okta Identity
MFA	✅	✅	✅	✅
FIDO2/WebAuthn	✅	✅	✅	✅
ThreatInsight	❌	❌	✅	✅
Device Trust	❌	❌	✅	✅
FastPass	❌	❌	✅	✅
Custom Admin Roles	✅	✅	✅	✅
Log Streaming	Add-on	Add-on	✅	✅
Workflows/Automations	Add-on	Add-on	✅	✅
Identity Threat Protection	❌	❌	❌	Add-on
Behavior Detection	❌	❌	✅	✅
HealthInsight	✅	✅	✅	✅
Protected Actions	✅	✅	✅	✅
Enhanced Dynamic Zones	❌	❌	✅	✅
Identity Governance (OIG)	❌	❌	❌	Add-on

---

Appendix B: References

Official Okta Documentation:

• Trust Center
• Security Trust Center (SafeBase)
• Help Center
• Security Advisories
• 9 Admin Best Practices
• Securing Admin Accounts
• Secure Identity Commitment Whitepaper (Aug 2025)
• Admin Role Permissions
• HealthInsight Recommendations
• Suspicious Activity Reporting
• Protected Actions
• Protecting Admin Sessions
• Blocking Anonymizers
• Global Session Policies
• Identity Threat Protection
• Non-Human Identities
• OAuth Migration from SSWS
• Identity Security Checklist
• Secure Identity Assessment

API Documentation:

• Okta API Reference
• System Log API
• Policies API
• Identity Providers API
• Network Zones API

Compliance Frameworks:

• SOC 2 Type II, ISO 27001, ISO 27017, ISO 27018, FedRAMP High, FedRAMP Moderate, FIPS 140-2, HIPAA, PCI DSS v4.0, CSA STAR, NIST 800-53 Rev 5 — via Okta Compliance
• DISA STIG Library — Okta IDaaS STIG V1R1 (March 2025), v1.1 NHI update (Feb 2026)
• DISA STIG Detail View
• CIS Controls v8
• NIST 800-53 Rev 5
• NIST SP 800-63-4 Final (July 2025)

Third-Party Security Research:

• Nudge Security — 6 Critical Okta Configurations
• Obsidian Security — Fortify Okta Against Session Token Compromise
• Obsidian Security — Cross-Tenant Impersonation in Okta
• AppOmni — Better SaaS Security with Okta Identity Engine

CISA & Government:

• Okta Secure by Design Pledge
• Okta Secure by Design — One Year On

Security Incidents:

• October 2023: Unauthorized access to Okta support system via compromised service account; HAR files containing session cookies exfiltrated, affecting 134 customers (all 18,400 notified) — Root Cause

  Investigation Closure

• January 2022: LAPSUS$ group compromised a Sitel (sub-processor) support engineer for 25 minutes, impacting 2 customers — Okta Investigation

---

Changelog

Date	Version	Maturity	Changes	Author
2026-08-08	0.4.1	draft	Cheat-sheet cell repair: added missing Attack Prevented line(s) to §1.3, §3.2, §4.1, §5.6, §7.2 (no content-facts changed)	Claude Code (Fable 5)
2026-08-03	0.4.0	draft	Guidance-currency refresh. Added 4 new controls: Device Assurance Policies including Okta Verify Advanced Posture Checks (1.12), Help Desk Visual Identity Verification (1.13), Cross App Access for AI agents and MCP servers (3.5), Identity Security Posture Management (5.7). Expanded SOC 2 and NIST 800-53 mappings and the compliance checklist to cover the new controls.	Claude Code (Sonnet 5)
2026-06-29	0.3.1	draft	Add cheat-sheet Description and Rationale for all controls	Claude Code (Opus 4.8)
2026-02-10	0.3.0	draft	Comprehensive audit against Okta SIC, DISA STIG v1.1, NIST 800-63-4, Obsidian/Nudge/AppOmni research. Added 15 new controls: Default Auth Policy Backstop (1.9), Self-Service Recovery (1.10), End-User Notifications (1.11), Dynamic Zones (2.3), OAuth Allowlisting (3.3), NHI Governance (3.4), Admin Session Security (4.3), ITP (5.3), Behavior Detection (5.4), Cross-Tenant Impersonation (5.5), HealthInsight (5.6), HAR Sanitization (7.1), Security Advisory Monitoring (7.2), Access Reviews (7.3), Change Management (7.4), Incident Response (7.5). Expanded compliance mappings with NIST 800-63-4 AAL mapping.	Claude Code (Opus 4.6)
2025-12-26	0.2.0	draft	Integrated DISA STIG Okta IDaaS V1R1 controls into functional sections	Claude Code (Opus 4.5)
2025-12-14	0.1.0	draft	Initial Okta hardening guide	Claude Code (Opus 4.5)

---

Questions or Improvements?

• Open an issue: GitHub Issues
• Contribute: Contributing Guide

Contributing

Found an issue or want to improve this guide?

• Report outdated information: Open an issue with tag content-outdated
• Propose new controls: Open an issue with tag new-control
• Submit improvements: See Contributing Guide