A Microsoft 365 security review needs to examine more than whether the tenant is working. Forwarding, authentication, privileged access, sharing, and audit retention each deserve a deliberate configuration decision.
These five areas are a starting point for that review. Check licensing before making changes: Conditional Access requires Microsoft Entra ID P1 or P2, and risk-based policies require P2. Extended audit retention has separate licensing requirements, covered below. See Microsoft Entra licensing.
1. Mailbox auto-forwarding to external recipients
After a mailbox is compromised, one of the first persistence moves attackers make is a forwarding rule that silently copies inbound mail to an attacker-controlled address. The user keeps using their mailbox normally. The attacker watches the conversation — useful for wire fraud, vendor impersonation, and long-term reconnaissance.
Where to look. Review outbound spam policies in Exchange Online Protection, the built-in protection for cloud mailboxes, along with Exchange Online remote domains, mail flow rules, and mailbox forwarding settings. Set automatic external forwarding explicitly to Off where it is not required. That policy blocks both inbox-rule and administrator-configured forwarding to external recipients; inspect existing rules and mailbox settings as well. See Microsoft's external forwarding controls.
What to alert on. Review the built-in policies "Suspicious email forwarding activity" and "Creation of forwarding/redirect rule" in the Microsoft Defender portal. The first detects forwarding to suspicious external accounts; the second tracks forwarding or redirect rules created through Outlook on the web or Exchange Online PowerShell. Neither is a complete monitor for every mailbox-rule change or deletion. Check policy availability, enabled status, and notification recipients against Microsoft's alert-policy documentation, and route notifications to a monitored mailbox.
2. Legacy authentication protocols
Legacy authentication clients cannot complete modern MFA challenges. Conditional Access can block those clients; it is not bypassed simply because an authentication request uses a legacy protocol. Review the protocols still enabled in your tenant and whether your policies block their use. Microsoft documents the policy in Block legacy authentication with Conditional Access.
Where to look. In the Microsoft Entra admin center, open Entra ID → Monitoring & health → Sign-in logs. Filter Client App for the legacy authentication protocols, and repeat the check on the User sign-ins (non-interactive) tab. Review successful and failed attempts and their authentication details. Identify dependencies such as scanners or business applications before disabling a protocol, and plan their migration to supported authentication.
What to change. Create a Conditional Access policy to block legacy authentication, following Microsoft's targeting and emergency-access exclusions. Evaluate the impact in report-only mode before enforcement. Tenants without Conditional Access licensing can evaluate security defaults as a baseline alternative. Treat protocol exceptions as documented dependencies to resolve, rather than leaving broad access enabled.
What to watch. Investigate unexpected legacy sign-ins even when Conditional Access blocks access. Microsoft documents that Conditional Access is enforced after primary authentication. For a password-based legacy attempt, that can mean a valid password was presented. Check the authentication details, failure reason, user, application, and source before determining what happened. Treat suspicious activity with successful primary authentication as possible credential compromise and follow your incident-response process. Successful access also needs investigation for exclusions, policy coverage, or remaining dependencies.
3. Conditional Access for privileged roles
Privileged accounts need deliberate protection. A label saying MFA is enabled does not replace a review of the authentication methods, policy coverage, and exceptions that apply to each account. Separate everyday administration from emergency access.
Where to look. In the Microsoft Entra admin center, open Entra ID → Roles & admins. Review privileged role assignments and the effective policies for everyday administrator accounts. Microsoft documents how to list role assignments. Identify emergency-access accounts separately so a blanket policy change does not remove your recovery path.
What to change. Require strong MFA for everyday administration and review policy exclusions. For emergency access, Microsoft recommends two or more dedicated accounts with phishing-resistant authentication, excluded from Conditional Access policies that could block or restrict sign-in. Protect their credentials, test access, and alert on use. Follow Microsoft's emergency-access guidance rather than treating a routine administrator account as an informal break-glass account.
What to watch. Monitor privileged role changes and emergency-account activity. Where licensed, evaluate sign-in and user risk through Entra ID Protection; risk-based policies require P2. Test enforcement and maintain the emergency-access exclusions described above.
4. SharePoint and OneDrive anonymous link settings
An attacker with permission to create sharing links can use anonymous links to expose SharePoint or OneDrive content. Existing Anyone links also allow access without authentication. Review the links and expiration controls actually configured in your organization rather than assuming they expire automatically.
Where to look. Review organization-wide settings under SharePoint admin center → Policies → Sharing, then inspect sensitive sites and their file or folder permissions. Site and tenant configuration commands do not enumerate individual sharing links. The standard site sharing report also excludes Anyone links, so do not treat it as a complete anonymous-link inventory.
What to change. Use "Specific people" as the default link type. Where Anyone links are necessary, configure a maximum lifetime under Advanced settings for Anyone links. Where they are unnecessary, change the site's external-sharing level to an authenticated guest option or turn external sharing off. "Existing guests" requires authentication and limits sharing to guests already in the directory; it is not a form of anonymous sharing. See Microsoft's site sharing settings.
What to watch. New anonymous link creation, especially on sites containing finance, HR, or customer data. Surface this in Purview activity reports or build a Microsoft Sentinel detection on AnonymousLinkCreated events.
5. Audit log retention and unified audit search
Audit Standard retains records generated on or after October 17, 2023 for 180 days. Investigations can require older evidence, so choose retention based on the history your organization needs to reconstruct, and verify that collection and storage cover that period.
Where to look. Check user licensing and retention in Purview → Audit. Audit Premium provides a default one-year policy for Exchange Online, SharePoint, OneDrive, and Microsoft Entra records generated by appropriately licensed users. Other activities generally retain the 180-day default unless a custom policy applies. The built-in policy is not listed on the retention-policy dashboard.
What to change. Match retention to investigation needs and licensing. E3 alone does not provide extended Audit Premium retention. Keeping user audit records beyond 180 days within Purview requires qualifying E5 or Audit Premium add-on licensing for the users generating those records. Check custom policies as well, because they take precedence over the default. Confirm auditing is enabled and validate the records you can retrieve. See Microsoft's audit-retention documentation.
For retention outside Purview, Microsoft also supports collecting records through the Office 365 Management Activity API into a SIEM or other storage. Configure collection before records expire and manage the destination's retention, access controls, and costs. This does not extend retention inside Purview or restore expired records. See Microsoft's Audit Standard capabilities.
What to watch. This one is preparation, not detection. The audit log is the artifact you need on the day you start an incident, not the day you ship the post-mortem.
Closing
These five checks are a starting point, not a complete hardening framework. Review licensing, dependencies, and recovery access before enforcement, and confirm the resulting behavior in your own tenant.