Introduction
Okta’s Identity Threat Protection (ITP) provides continuous, real-time threat detection and automated response capabilities that operate beyond the initial authentication event. While ITP’s power lies in its ability to act on post-authentication signals, that power is only realized consistently if the underlying policies, network contexts, and signal integrations are configured consistently across environments.
That’s where Infrastructure as Code comes in.
This post covers how to manage the full ITP surface — network zones, user risk assignments, entity risk policy rules, session protection rules, and third-party signal ingestion — declaratively using the Okta Terraform Provider.
Why Terraform for ITP?
Terraform’s declarative model offers concrete operational advantages for security configuration:
- Version-controlled policy: Every change to a network zone or risk response rule is committed to source control, giving you a full audit trail and the ability to roll back.
- Repeatable deployments: Apply the same ITP configuration across dev, staging, and production environments without manual re-entry or clipboard-driven inconsistency.
- Drift elimination: Terraform’s plan/apply cycle detects and corrects out-of-band changes, helping to ensure your live configuration matches your declared intent.
- CI/CD integration: Security policy changes go through the same pull request review, automated testing, and deployment pipeline as application code.
With the Okta Terraform Provider specifically, you can:
- Manage ITP configurations alongside the rest of your IAM infrastructure in a single codebase
- Enforce consistent threat response controls across all environments
- Peer-review risk policy changes via pull requests before they reach production
- Rapidly reconfigure automated responses when your threat model changes
- Maintain full lifecycle management of network zones, risk signals, Shared Signals Framework (SSF) receivers, and policy rules
The following sections walk through each of the six primary ITP-related resources in the Okta Terraform Provider.
Network Zones —
okta_network_zone
Network Zones define the geographic regions, IP ranges, or autonomous system numbers that Okta uses to classify the network context of an authentication attempt or active session. In an ITP context, zones serve two roles: they identify trusted network contexts (such as a corporate VPN range) that can exempt users from certain risk checks, and define blocklists (such as Tor anonymizers) that immediately elevate risk regardless of other signals.
Managing zones in Terraform gives you a versioned, auditable inventory of every trusted and blocked network range in your environment. The type argument controls the zone classification — IP for explicit CIDR ranges or IP ranges, DYNAMIC for proxy-type classifications such as Tor, and DYNAMIC_V2 for ASN-based dynamic zones. The usage argument determines whether the zone feeds into policy evaluation (POLICY) or acts as a blocklist (BLOCKLIST).
resource "okta_network_zone" "corporate_vpn" {
name = "Corporate VPN"
type = "IP"
usage = "POLICY"
gateways = ["203.0.113.0/24", "198.51.100.10-198.51.100.20"]
}
resource "okta_network_zone" "tor_blocklist" {
name = "TOR Blocklist"
type = "DYNAMIC"
usage = "BLOCKLIST"
dynamic_proxy_type = "TorAnonymizer"
}
The corporate_vpn zone is referenced later in the session violation rule, demonstrating how network context flows through the ITP policy stack.
User Risk Management —
okta_user_risk
The okta_user_risk resource allows you to programmatically assign a risk classification to a specific Okta user. Supported values for risk_level are HIGH, MEDIUM, and LOW. This resource is most valuable as part of an automated remediation workflow: a SIEM or SOAR platform detects a compromise indicator, triggers a Terraform run (or calls the Okta API directly), sets the affected user’s risk to HIGH, and the Entity Risk Policy rules defined below take over — terminating active sessions or invoking a remediation workflow.
This closes the loop between external detection tooling and Okta’s continuous evaluation engine without requiring manual intervention.
resource "okta_user_risk" "compromised_user" {
user_id = okta_user.example.id
risk_level = "HIGH"
}
In practice, the user_id will typically be sourced from a data lookup or passed in as a variable during an automated pipeline run rather than being hardcoded.
Entity Risk Policy Rules —
okta_entity_risk_policy_rule
Entity Risk Policy Rules define the automated responses Okta executes when ITP assigns a risk score to a user that meets or exceeds a configured threshold. The Entity Risk Policy itself is automatically provisioned when ITP is enabled on your Okta tenant — you do not create the policy via Terraform. Instead, you retrieve its ID using the okta_entity_risk_policy data source and create rules within it.
Rules can target specific risk levels (HIGH, MEDIUM, or LOW) and support two response actions: terminate_all_sessions immediately invalidates all of the user’s active sessions, and workflow_id invokes an Okta Workflow for more complex remediation steps such as sending notifications, disabling accounts, or triggering external integrations.
Note: The default rule (priority 99) is pre-provisioned and cannot be modified or deleted. Terraform-managed rules should use priorities lower than 99.
data "okta_entity_risk_policy" "main" {}
resource "okta_entity_risk_policy_rule" "high_risk_response" {
policy_id = data.okta_entity_risk_policy.main.id
name = "High Risk - Terminate All Sessions"
risk_level = "HIGH"
terminate_all_sessions = true
priority = 1
}
resource "okta_entity_risk_policy_rule" "medium_risk_response" {
policy_id = data.okta_entity_risk_policy.main.id
name = "Medium Risk - Trigger Remediation Workflow"
risk_level = "MEDIUM"
workflow_id = "abc123"
priority = 2
}
Additional arguments such as users_excluded and groups_included allow you to scope rules to specific user populations, which is useful when rolling out ITP enforcement incrementally.
Post Auth Session Policy Rules —
okta_post_auth_session_policy_rule
The Post Auth Session Policy Rule governs what Okta does when a continuous evaluation check on an active session fails after initial authentication — for example, when a user’s device compliance state changes, their network context shifts to a blocked zone, or their risk score rises in response to an inbound SSF signal.
Important: Unlike most Terraform resources, okta_post_auth_session_policy_rule is pre-provisioned by Okta and cannot be created or destroyed via Terraform. You must import the existing rule before managing it:
terraform import okta_post_auth_session_policy_rule.session_protection <policy_id>/<rule_id>
Retrieve the policy and rule IDs from the Okta Admin Console or via the okta_post_auth_session_policy data source and the Okta API.
Despite the import-only constraint, Terraform management still delivers significant value here: the configuration is version-controlled, changes go through peer review, and the termination behavior is codified alongside all other ITP policy in a single repository.
data "okta_post_auth_session_policy" "main" {}
resource "okta_post_auth_session_policy_rule" "session_protection" {
policy_id = data.okta_post_auth_session_policy.main.id
name = "Post-Auth Session Protection"
status = "ACTIVE"
terminate_session = true
}
The groups_included and groups_excluded arguments allow scoped enforcement, and workflow_id supports the same Okta Workflows integration as the entity risk rules.
Session Violation Detection Policy Rules —
okta_session_violation_policy_rule
Session Violation Detection Policy Rules define the conditions under which Okta classifies an active session as a policy violation. Where the Post Auth Session Policy Rule defines the response to a violation, this resource defines the detection logic: what minimum risk level and network context must be present before a session is flagged.
The min_risk_level argument sets the detection threshold (LOW, MEDIUM, or HIGH). The network_connection argument scopes enforcement — setting it to ZONE and providing zone IDs via network_includes or network_excludes gives you fine-grained control.
For example excluding sessions originating from your corporate VPN from violation detection.
Important: Like the Post Auth Session Policy Rule, okta_session_violation_policy_rule is pre-provisioned by Okta and must be imported before Terraform can manage it:
terraform import okta_session_violation_policy_rule.high_risk_sessions <policy_id>/<rule_id>
data "okta_session_violation_policy" "main" {}
resource "okta_session_violation_policy_rule" "high_risk_sessions" {
policy_id = data.okta_session_violation_policy.main.id
name = "High Risk Session Violation"
min_risk_level = "HIGH"
network_connection = "ZONE"
network_excludes = [okta_network_zone.corporate_vpn.id]
policy_evaluation_enabled = true
}
Note that okta_network_zone.corporate_vpn.id references the network zone defined in the first section. The Terraform resource graph helps ensure the zone exists before the session violation rule references it.
SSF Receiver Configuration —
okta_security_events_provider
The okta_security_events_provider resource configures Okta as a Shared Signals Framework (SSF) receiver, enabling it to ingest security event signals from third-party providers such as CrowdStrike, Zscaler, or other Okta tenants. These inbound signals feed directly into ITP’s risk engine.
An endpoint detection event from a third-party security vendor can elevate a user’s risk score in real time, which then triggers the Entity Risk Policy rules defined above.
Managing SSF receivers in Terraform helps ensure that the full signal-to-response chain — from inbound threat intelligence to automated session termination — is consistently configured and auditable across all environments.
The type argument identifies the SSF provider type. For providers that publish an SSF discovery document, set settings.well_known_url to the provider’s /.well-known/ssf-configuration endpoint. For providers without a discovery document, set settings.issuer and settings.jwks_url directly. The is_enabled argument accepts ACTIVE or INACTIVE.
resource "okta_security_events_provider" "crowdstrike" {
name = "CrowdStrike Threat Intelligence"
type = "okta"
is_enabled = "ACTIVE"
settings {
well_known_url = "https://crowdstrike.example.com/.well-known/ssf-configuration"
}
}
Once the receiver is active, signals from the configured provider flow into Okta’s risk engine and are evaluated against the entity risk and session violation rules defined in the preceding sections.
Conclusion
Managing ITP via Terraform transforms your security posture from a manually maintained configuration into a version-controlled, peer-reviewed, continuously deployable system. The six resources covered in this post collectively cover the full ITP management surface:
Resource | Role |
okta_network_zone | Define trusted and blocked network contexts for risk evaluation |
okta_user_risk | Programmatically assign risk levels to users in automated workflows |
okta_entity_risk_policy_rule | Automate threat responses — session termination, workflow invocation — based on ITP risk scores |
okta_post_auth_session_policy_rule | Control Okta’s behaviour when continuous evaluation fails on an active session |
okta_session_violation_policy_rule | Define the conditions — risk level, network context — that flag a session as a policy violation |
okta_security_events_provider | Ingest third-party threat signals via SSF to enrich ITP’s real-time risk engine |
Together, these resources close the loop between detection and response entirely in code. A third-party signal arrives via SSF, elevates a user’s risk score, triggers an entity risk policy rule to terminate sessions, and the session violation rule helps ensure any surviving sessions are caught by continuous evaluation — all of it declared in HCL, reviewed in a pull request, and applied consistently across every environment.
For full argument reference and provider configuration, see the Okta Terraform Provider documentation.
