diff --git a/rules/integrations/okta/persistence_mfa_deactivation_with_no_reactivation.toml b/rules/integrations/okta/persistence_mfa_deactivation_with_no_reactivation.toml
index ca42fcb56..c20d0f5bd 100644
--- a/rules/integrations/okta/persistence_mfa_deactivation_with_no_reactivation.toml
+++ b/rules/integrations/okta/persistence_mfa_deactivation_with_no_reactivation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/20"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/07/02"
+updated_date = "2025/08/15"
 
 [rule]
 author = ["Elastic"]
@@ -33,11 +33,12 @@ This rule fires when an Okta user account has MFA deactivated and no subsequent
 
 #### Possible investigation steps:
 
-- Identify the actor related to the alert by reviewing `okta.actor.alternate_id` field in the alert. This should give the username of the account being targeted.
-- Review `okta.target` or `user.target.full_name` fields to determine if deactivation was performed by a se parate user.
-- Using the `okta.actor.alternate_id` field, search  for MFA re-activation events where `okta.event_type` is `user.mfa.factor.activate`.
-- Review events where `okta.event_type` is `user.authenticate*` to determine if the user account had suspicious login activity.
+- Identify the entity related to the alert by reviewing `okta.target.alternate_id`, `okta.target.id` or `user.target.full_name` fields. This should give the username of the account being targeted. Verify if MFA is deactivated for the target entity.
+- Using the `okta.target.alternate_id` field, search for MFA re-activation events where `okta.event_type` is `user.mfa.factor.activate`. Note if MFA re-activation attempts were made against the target.
+- Identify the actor performing the deactivation by reviewing `okta.actor.alternate_id`, `okta.actor.id` or `user.full_name` fields. This should give the username of the account performing the action. Determine if deactivation was performed by a separate user. 
+- Review events where `okta.event_type` is `user.authenticate*` to determine if the actor or target accounts had suspicious login activity.
     - Geolocation details found in `client.geo*` related fields may be useful in determining if the login activity was suspicious for this user.
+- Examine related administrative activity by the actor for privilege misuse or suspicious changes.
 
 #### False positive steps:
 
@@ -75,7 +76,7 @@ tags = [
 type = "eql"
 
 query = '''
-sequence by okta.actor.id with maxspan=12h
+sequence by okta.target.id with maxspan=12h
     [any where event.dataset == "okta.system" and okta.event_type in ("user.mfa.factor.deactivate", "user.mfa.factor.reset_all")
         and okta.outcome.reason != "User reset SECURITY_QUESTION factor" and okta.outcome.result == "SUCCESS"]
     ![any where event.dataset == "okta.system" and okta.event_type == "user.mfa.factor.activate"]