diff --git a/rules/integrations/okta/credential_access_multiple_user_agent_os_authentication.toml b/rules/integrations/okta/credential_access_multiple_user_agent_os_authentication.toml
new file mode 100644
index 00000000000..fcd136e42f2
--- /dev/null
+++ b/rules/integrations/okta/credential_access_multiple_user_agent_os_authentication.toml
@@ -0,0 +1,107 @@
+[metadata]
+creation_date = "2025/10/22"
+maturity = "production"
+updated_date = "2025/10/22"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is
+highly anomalous because a device token token is tied to a specific device and its operating system. This alert strongly
+indicates that an attacker has stolen a device token token and is using it to impersonate a legitimate user from a
+different machine.
+"""
+false_positives = [
+    """
+    Applications will tag the operating system as null when the device is not recognized as a managed device. In
+    environments where users frequently switch between managed and unmanaged devices, this may lead to false positives.
+    """,
+]
+from = "now-60m"
+index = ["logs-okta.system-*"]
+language = "kuery"
+name = "Okta Multiple OS Names Detected for a Single DT Hash"
+note = """## Triage and analysis
+
+### Investigating Okta Multiple OS Names Detected for a Single DT Hash
+
+This rule detects when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is highly anomalous because a device token token is tied to a specific device and its operating system. This alert strongly indicates that an attacker has stolen a device token token and is using it to impersonate a legitimate user from a different machine.
+
+### Possible investigation steps
+- Review the `okta.debug_context.debug_data.dt_hash` field to identify the specific device
+trust hash associated with multiple operating systems.
+- Examine the `user.email` field to determine which user account is associated with the suspicious activity
+- Analyze the `source.ip` field to identify the IP addresses from which the different operating systems were reported. Look for any unusual or unexpected locations.
+- Review the `user_agent.os.name` field to see the different operating systems reported for the
+same dt_hash. This will help identify the nature of the anomaly.
+- Check the `event.action` field to understand the context of the authentication events (e.g., MFA verification, standard authentication).
+- Investigate the timeline of events to see when the different operating systems were reported for the same dt_hash. Look for patterns or sequences that may indicate malicious activity.
+- Correlate this activity with other security events in your environment, such as failed login attempts, unusual access patterns, or alerts from endpoint security solutions.
+
+### False positive analysis
+- Applications will tag the operating system as null when the device is not recognized as a managed device
+- In environments where users frequently switch between managed and unmanaged devices, this may lead to false positives.
+
+### Response and remediation
+- Immediately investigate the user account associated with the suspicious activity to determine if it has been compromised.
+- If compromise is confirmed, reset the user's credentials and enforce multi-factor authentication (MFA)
+- Revoke any active sessions associated with the compromised account to prevent further unauthorized access.
+- Review and monitor the affected dt_hash for any further suspicious activity.
+- Educate users about the importance of device security and the risks associated with device token tokens.
+- Implement additional monitoring for device token tokens and consider using conditional access policies to restrict access based on device compliance status.
+"""
+risk_score = 73
+rule_id = "fb3ca230-af4e-11f0-900d-f661ea17fbcc"
+severity = "high"
+tags = [
+    "Domain: Identity",
+    "Data Source: Okta",
+    "Data Source: Okta System Logs",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+data_stream.dataset: "okta.system"
+    and not okta.debug_context.debug_data.dt_hash: "-"
+    and user_agent.os.name: *
+    and event.action: (
+        "user.authentication.verify" or
+        "user.authentication.auth_via_mfa"
+    )
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1539"
+name = "Steal Web Session Cookie"
+reference = "https://attack.mitre.org/techniques/T1539/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "okta.debug_context.debug_data.dt_hash",
+    "user.email",
+    "source.ip",
+    "user_agent.os.name",
+    "event.action",
+]
+
+[rule.threshold]
+field = ["okta.debug_context.debug_data.dt_hash"]
+value = 1
+[[rule.threshold.cardinality]]
+field = "user_agent.os.name"
+value = 2
+
+