Merge pull request #4526 from MicrosoftDocs/main

[AutoPublish] main to live - 07/17 10:32 PDT | 07/17 23:02 IST

Author: m365-skilling-repo-management[bot]

ATPDocs/assign-multi-factor-authentication-okta-privileged-user-accounts.md

@@ -0,0 +1,28 @@
+---
+title: 'Security assessment: Assign multifactor authentication to Okta privileged user accounts'
+description: Microsoft Defender for Identity security posture assessment on Okta. In this assessment, we recommend customers assign multifactor authentication (MFA) to Okta privileged user accounts.
+ms.service: microsoft-defender-for-identity
+ms.topic: article
+# ms.prod:   microsoft-defender-for-identity
+ms.date: 07/14/2025 
+ms.reviewer: Himanch
+---
+
+# Security assessment: Assign multifactor authentication to Okta privileged user accounts
+
+This report lists any Okta privileged accounts that don't have any multifactor authentication (MFA) methods assigned. 
+
+## Why is a privileged account without MFA a security risk?
+
+All privileged accounts should have multifactor authentication (MFA) enabled to strengthen security. By ensuring that privileged accounts such as Super Admin or Org Admin roles are secured with MFA, organizations can significantly reduce the risk of unauthorized access from compromised credentials. This strategy helps prevent attackers from gaining elevated access, safeguarding sensitive resources and protecting critical administrative functions from abuse.
+
+
+## Remediation steps
+
+1. Review the recommended action at [https://security.microsoft.com/securescore?viewid=actions](https://security.microsoft.com/securescore?viewid=actions) for the "Assign multifactor authentication for Okta privileged user accounts" security assessment.
+1. Review the list of exposed entities to discover which of your Okta privileged user accounts don't have any MFA method assigned.
+1. Assign and enforce a multifactor authentication (MFA) method to the privileged accounts.
+
+## Next steps
+
+- [Learn more about Microsoft Secure Score](/microsoft-365/security/defender/microsoft-secure-score)

ATPDocs/change-okta-password-privileged-user-accounts.md

@@ -0,0 +1,26 @@
+---
+title: 'Security assessment: Change password for Okta privileged User accounts'
+description: Microsoft Defender for Identity security posture assessment on Okta. In this assessment, we recommend customers change the password of Okta privileged user accounts with password last set over 180 days ago.
+ms.service: microsoft-defender-for-identity
+ms.topic: article
+ms.date:     07/14/2025 
+ms.reviewer: Himanch
+---
+
+# Security assessment: Change password for Okta privileged User accounts
+
+This recommendation lists any Okta privileged accounts that use outdated passwords that were last set over 180 days ago.  
+
+## Why is a privileged account with an old password a security risk?
+
+Privileged accounts with old passwords create a significant security risk, as older credentials are more likely to be exposed through data breaches or other attack vectors. Enforcing regular password updates for privileged accounts reduces the likelihood of unauthorized access and strengthens overall security. Applying stringent password policies to accounts with elevated privileges protects sensitive resources and lowers the risk of exploitation.
+
+## Remediation steps
+
+1. Review the recommended action at [https://security.microsoft.com/securescore?viewid=actions](https://security.microsoft.com/securescore?viewid=actions) for the "Change password for Okta privileged User accounts" security assessment.
+1. Review the list of exposed entities to discover which of your Okta privileged user accounts have an old password.
+1. Take appropriate action on those accounts by resetting their password.  
+
+## Next steps
+
+- [Learn more about Microsoft Secure Score](/microsoft-365/security/defender/microsoft-secure-score)

ATPDocs/high-number-of-okta-accounts-with-privileged-role-assigned.md

@@ -0,0 +1,29 @@
+---
+title: 'Security assessment: High number of Okta accounts with privileged role assigned'
+description: Microsoft Defender for Identity security posture assessment on Okta. In this assessment, we recommend customers limit the number of Okta accounts with privileged roles assigned to the minimum required for their organization.
+ms.service: microsoft-defender-for-identity
+ms.topic: article
+ms.date: 07/14/2025 
+ms.reviewer: Himanch
+---
+
+# Security assessment: High number of Okta accounts with privileged role assigned
+
+This article describes the security risks associated with having a high number of Okta accounts with privileged roles assigned and provides recommendations for mitigating these risks.
+
+> [!NOTE]
+> This report lists Okta accounts with administrator roles - excluding Super Administrator, where the number of accounts assigned to these roles is greater than 25.  
+
+## Why is a high number of Okta accounts with privileged roles considered a security risk?
+
+A high number of users with privileged roles increases the risk of misuse or unauthorized access to critical systems. By reducing the number of users assigned to roles such as Super Admin or Org Admin, organizations can better limit access to sensitive resources and reduce the attack surface. Maintaining a smaller, set of privileged accounts ensures more effective governance and minimizes potential security vulnerabilities.
+
+## Remediation steps
+
+1. Review the recommended action at [https://security.microsoft.com/securescore?viewid=actions](https://security.microsoft.com/securescore?viewid=actions) for the "High number of Okta accounts with privileged role assigned" security assessment.
+1. Review the list of exposed entities to discover which of your Okta accounts have privileged roles assigned.
+1. Reduce the number of users assigned to administrator roles (other than Super-Admin) to the minimum necessary to ensure better control and align with least privilege best practices.
+
+## Next steps
+
+- [Learn more about Microsoft Secure Score](/microsoft-365/security/defender/microsoft-secure-score)

ATPDocs/highly-privileged-okta-api-token.md

@@ -0,0 +1,26 @@
+---
+title: 'Security assessment: Highly privileged Okta API token'
+description: Microsoft Defender for Identity security posture assessment on Okta. In this assessment, we recommend customers limit the use of highly privileged API tokens.
+ms.service: microsoft-defender-for-identity
+ms.topic: article
+ms.date: 07/14/2025 
+ms.reviewer: Himanch
+---
+
+# Security assessment: Highly privileged Okta API token
+
+This article describes the security risks associated with highly privileged Okta API tokens and provides recommendations for mitigating these risks.
+
+## Why is a highly privileged Okta API token a security risk?
+
+Okta’s API tokens inherit the permissions of the user who creates them. If a user with sensitive permissions generates an API token, it carries those permissions. Any API token created by a Super Admin has the same level of access as the Super Admin account. This can expose sensitive data and functionality to unauthorized users. If the token is stolen, it can grant the attacker access equivalent to the original user.
+
+## Remediation steps
+
+1. Review the recommended action at [https://security.microsoft.com/securescore?viewid=actions](https://security.microsoft.com/securescore?viewid=actions) for the "Highly privileged Okta API token" security assessment.
+1. Review the list of exposed entities to discover which of your Okta API tokens are highly privileged.
+1. If the API token is no longer required, delete it to eliminate unnecessary exposure.
+
+## Next steps
+
+- [Learn more about Microsoft Secure Score](/microsoft-365/security/defender/microsoft-secure-score)

ATPDocs/limit-number-okta-super-admin-accounts.md

@@ -0,0 +1,26 @@
+---
+title: 'Security assessment: Limit the number of Okta Super Admin accounts'
+description: Microsoft Defender for Identity security posture assessment on Okta. In this assessment, we recommend customers limit the number of Super Admin accounts to the minimum required for their organization.
+ms.service: microsoft-defender-for-identity
+ms.topic: article
+ms.date: 07/14/2025 
+ms.reviewer: Himanch
+---
+
+# Security assessment: Limit the number of Okta Super Admin accounts
+
+This report lists Okta accounts with Super Administrator role, where the number of users assigned to this role is greater than 5.
+
+## Why is having too many Super Admin accounts a security risk?
+
+A high number of users with privileged roles increases the risk of misuse or unauthorized access to critical systems. By reducing the number of users assigned to roles such as Super Admin or Org Admin, organizations can better limit access to sensitive resources and reduce the attack surface. Maintaining a smaller, set of privileged accounts ensures more effective governance and minimizes potential security vulnerabilities.
+
+## Remediation steps
+
+1. Review the recommended action at [https://security.microsoft.com/securescore?viewid=actions](https://security.microsoft.com/securescore?viewid=actions) for the "Limit the number of Okta Super Admin accounts" security assessment.
+1. Review the list of exposed entities to discover which of your Okta accounts have Super Admin role assigned.
+1. Limit Super Administrator access to the minimum number of users necessary to maintain control over highest level of privileged access.
+
+## Next steps
+
+- [Learn more about Microsoft Secure Score](/microsoft-365/security/defender/microsoft-secure-score)

ATPDocs/remove-dormant-okta-privileged-accounts.md

@@ -0,0 +1,26 @@
+---
+title: 'Security assessment: Remove dormant Okta privileged accounts'
+description: Microsoft Defender for Identity security posture assessment on Okta. In this assessment, we recommend customers remove dormant Okta privileged user accounts not accessed for over 60 days.
+ms.service: microsoft-defender-for-identity
+ms.topic: article
+ms.date: 07/14/2025 
+ms.reviewer: Himanch
+---
+
+# Security assessment: Remove dormant Okta privileged accounts
+
+This article describes the security risks associated with dormant Okta privileged accounts and provides recommendations for mitigating these risks.
+
+## Why is a dormant privileged account a security risk?
+
+Dormant privileged accounts represent a significant security risk, as they can become targets for unauthorized access or misuse without detection. Deactivating or removing unused privileged accounts ensures that only active, monitored users have access to critical administrative capabilities.
+
+## Remediation steps
+
+1. Review the recommended action at [https://security.microsoft.com/securescore?viewid=actions](https://security.microsoft.com/securescore?viewid=actions) for the "Remove dormant Okta privileged accounts" security assessment.
+1. Review the list of exposed entities to identify Okta privileged user accounts not used in the last 90 days. This inactivity indicates that the account might be a dormant account or no longer needed.
+1. If the account is no longer required, deactivate or remove it to eliminate unnecessary exposure.
+
+## Next steps
+
+- [Learn more about Microsoft Secure Score](/microsoft-365/security/defender/microsoft-secure-score)

ATPDocs/toc.yml

@@ -266,7 +266,21 @@ items:
          - name: Unsecure account attributes
            href: security-assessment-unsecure-account-attributes.md
          - name: Weak cipher usage assessment
-           href: security-assessment-weak-cipher.md
+           href: security-assessment-weak-cipher.md    
+     - name: Cloud identities
+       items:
+       - name: Assign multi-factor authentication to Okta privileged user accounts
+         href: assign-multi-factor-authentication-okta-privileged-user-accounts.md
+       - name: Change password for Okta privileged user accounts
+         href: change-okta-password-privileged-user-accounts.md 
+       - name: High number of Okta accounts with privileged role assigned
+         href: high-number-of-okta-accounts-with-privileged-role-assigned.md
+       - name: Highly privileged Okta API token
+         href: highly-privileged-okta-api-token.md
+       - name: Limit the number of Okta Super Admin accounts
+         href: limit-number-okta-super-admin-accounts.md
+       - name: Remove dormant Okta privileged accounts
+         href: remove-dormant-okta-privileged-accounts.md
      - name: Identity security initiative (Preview)
        href: identity-security-initiative.md
 - name: Reference

defender-office-365/advanced-delivery-policy-configure.md

@@ -145,8 +145,6 @@ If your MX record doesn't point to Microsoft 365, the IP address in the `Authent
 > - If you're using the [Built-in protection preset security policy](preset-security-policies.md#profiles-in-preset-security-policies) or your custom Safe Links policies have the setting **Do not rewrite URLs, do checks via SafeLinks API only** enabled, time of click protection doesn't treat phishing simulation links in email as threats in Outlook on the web, Outlook for iOS and Android, Outlook for Windows v16.0.15317.10000 or later, and Outlook for Mac v16.74 (23061100) or later. If you're using older versions of Outlook, consider disabling the **Do not rewrite URLs, do checks via SafeLinks API only** setting in custom Safe Links policies.
 >
 > - Adding phishing simulation URLs to the **Do not rewrite the following URLs in email** section in Safe Links policies might result in unwanted alerts for URL clicks. Phishing simulation URLs in email messages are automatically allowed both during mail flow and at time of click.
->
-> - Currently, the advanced delivery policy for SecOps mailboxes doesn't support intra-organizational messages (`DIR:INT`). These messages are quarantined. As a workaround, you can use a separate anti-spam policy for SecOps mailboxes that doesn't quarantine intra-organizational messages. We don't recommend disabling intra-org protection for all mailboxes.
 
 1. In the Microsoft Defender portal at <https://security.microsoft.com>, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Advanced delivery** in the **Rules** section. Or, to go directly to the **Advanced delivery** page, use <https://security.microsoft.com/advanceddelivery>.
 

defender-office-365/reports-mdo-email-collaboration-dashboard.md

@@ -254,7 +254,7 @@ The graph on the **Microsoft 365 Secure Email Gateway performance** card compare
 Organizations with Defender for Office 365 Plan 2 can use the following query in [advanced hunting](/defender-xdr/advanced-hunting-overview) to generate the same data on the [**Phish / Malware Efficacy** card](#phish--malware-efficacy-card).
 
 > [!NOTE]
-> The numbers might differ slightly due to the different refresh rates for advanced hunting vs. reporting data.
+> The numbers might differ slightly due to the different refresh and expiry rates for advanced hunting vs. reporting data.
 
 ```kusto
 let _startTime = ago(30d); 
@@ -263,8 +263,8 @@ let PreDelivery = toscalar(
     EmailEvents 
     | where Timestamp between (_startTime .. _endTime) 
         and EmailDirection == "Inbound" 
-        and DeliveryLocation in ("Junk folder", "Quarantine")
         and (ThreatTypes contains "Phish" or ThreatTypes contains "Malware")
+    | where not(DeliveryAction == "Blocked" and DeliveryLocation in ("Dropped","Failed"))
     | extend MDO_detection = parse_json(DetectionMethods) 
     | extend FirstDetection = iif(isempty(MDO_detection), "Clean", tostring(bag_keys(MDO_detection)[0])) 
     | extend FirstSubcategory = iif(FirstDetection != "Clean" and array_length(MDO_detection[FirstDetection]) > 0, strcat(FirstDetection, ": ", tostring(MDO_detection[FirstDetection][0])), "No Detection (clean)")