At most companies, Microsoft 365 holds both the email and the documents, and Entra ID is the sign-in point for many other cloud applications. Someone who takes over a user account therefore gets access to far more than a mailbox.
In many tenants the settings have not been touched since the tenant was set up. The defaults are built for quick collaboration, and tightening them is left to whoever runs the tenant. Below we go through five areas and their typical mistakes, and at the end we describe the order in which to tackle them.
Authentication
An attack on a tenant usually starts with an account takeover, using a stolen or guessed password. Multi-factor authentication makes this harder, but how much harder depends on the method and the exceptions. We covered the strength of the different methods in our article on MFA types; here we focus on the mistakes typical of a tenant.
Administrator accounts
A Global Administrator has access to everything in the tenant. A common mistake is giving this role to too many accounts, including ones the owner uses every day for email and browsing. Admin work needs a separate account used for nothing else, with the narrowest role that will do the job: resetting passwords only needs the Helpdesk Administrator role, and managing mailboxes the Exchange Administrator role. These accounts should use phishing-resistant authentication, such as a FIDO2 key or a passkey.
The emergency access account
If a faulty Conditional Access policy or an outage of the MFA service locks out every administrator, the only way back in is an emergency access account prepared in advance. This account is deliberately excluded from the policies, so it has to be protected with a strong credential kept offline, and every sign-in to it should trigger an alert. Many tenants have no such account, or have one that nobody has tested in years.
Legacy authentication
Some older mail protocols and clients cannot do multi-factor authentication, so for them a password alone is enough to sign in. Microsoft has largely retired basic authentication in Exchange Online, but it is still worth checking that a Conditional Access policy blocks it in your tenant as well, and whether such sign-ins still show up in the log. If a printer or an old application sends mail with a password, it needs its own narrowly scoped solution.
Application consent
MFA does not help when the user grants access themselves. In consent phishing, the attacker asks the user to approve a harmless-looking application, which then gets permission to read the mailbox or the files. That permission survives a password change. Limit which permissions users can grant on their own, require admin approval for the rest, and review from time to time which applications already have access in the tenant.
Conditional Access
Conditional Access is the policy engine of Entra ID. At every sign-in it looks at who is signing in, from where, from what device, and into which application, and based on that it allows access, asks for multi-factor authentication, or blocks it. This is how you can require, for example, that on an unknown device documents open only in the browser and cannot be downloaded.
If the tenant has no Conditional Access policies at all, at least turn on security defaults. The two cannot run at the same time, so if you move to policies, they have to cover everything the security defaults gave you until then.
Typical mistakes
- The exclusion list grows. A service account, an executive who does not want to use a phone: each exclusion seems justified on its own, but together they form a group that no policy applies to.
- The policy stays in report-only mode. Trying out a new policy first in a mode that only logs is the right approach, but in many tenants it stays there for years and blocks nothing.
- It does not cover every application. If the policy lists specific applications, a newly introduced one falls outside it. The baseline policy that requires MFA should apply to all cloud apps.
- Guest accounts are left out. Sign-ins by external partners need a policy too.
- The office network is excluded as a trusted location. Then an attacker sitting at an office computer, or a compromised VPN connection, does not need a second factor either.
Before you switch a policy on, the What If tool and the sign-in log show which policy would apply to whom, and who would fall outside all of them.
External sharing
The sharing level for SharePoint and OneDrive is set at the tenant level, and individual sites can only be stricter than that. The riskiest option is the link anyone can use: whoever receives it opens the document without signing in and can forward it as well. If the business needs such links, they should expire and grant read-only access. The default link type should be the one for specific people or for people in your organization, so users have to choose wider sharing deliberately.
Guest access in Teams and chat with users from other organizations are two separate settings. For both, decide whether any external domain is allowed or only your partners' domains.
Guest accounts do not disappear on their own. When a project ends, the partner's account stays in the tenant with all its access, so the guest list needs regular review.
Internal sharing matters too. Copilot sees only what the user can see, so the contents of a folder shared too widely can show up in its answers as well. We cover this in more detail on our secure Copilot rollout page.
Externally, the question is whether someone else can send email in the company's name. SPF, DKIM, and DMARC take care of that, and we have a separate article on them. Inside the tenant, the following settings matter most.
Automatic forwarding to external addresses
In a compromised mailbox, one of the first things an attacker often does is set up a rule that quietly copies incoming mail to an external address. Block automatic forwarding to external addresses at the tenant level, and allow it only for named mailboxes where there is a good reason.
Mailbox rules
Just as telling is a new rule that deletes mail from certain senders or with certain keywords, or moves it to a rarely checked folder. That way the user does not notice the attacker's messages, or partners writing back because something looks suspicious. The alert set up in the logging section below watches for such rules.
Anti-phishing policies
In the mail filtering policies you can set up impersonation protection for the names of executives and key partners, and external sender tagging, which places a warning above messages that come from outside the organization.
Logging
When investigating an account takeover, the first question is when and from where someone signed in, and what they did with the account. The unified audit log and the Entra ID sign-in log answer this, provided they are turned on and the entries still exist.
The audit log is on by default in newer tenants; in older ones it is worth checking. The bigger problem is retention: logs are kept in the tenant only for a limited time, and intrusions are often discovered weeks later. That is why it pays to copy them to separate storage or to a SIEM, where even an attacker who has gained rights in the tenant cannot delete them.
At a minimum, you need alerts for a new administrator role assignment, a change to an MFA method, external forwarding or a suspicious mailbox rule, and a sign-in from an unusual location. We described what to collect from which source for an incident in our article on logging.
What to fix first
If you cannot do everything at once, this order gives the most protection for the least work:
- Administrator accounts: few Global Administrators, separate admin accounts with phishing-resistant MFA, and a tested emergency access account.
- Multi-factor authentication for every user, with narrow and documented exclusions, and legacy authentication blocked.
- Blocking automatic forwarding to external addresses and restricting application consent.
- Checking the audit log, copying the logs out, and setting up the first alerts.
- Tightening the external sharing defaults and reviewing guest accounts.
- Refining Conditional Access with device-based and risk-based conditions.
The first two steps barely change anything for users if the policies were tried out in report-only mode beforehand.
If you want to know where your own tenant stands, our Microsoft 365 security hardening starts with an assessment of the tenant's security posture. After that we set up multi-factor authentication and Conditional Access policies, tighten the external sharing and email settings, and document the changes we made.
