A company buys Microsoft 365, migrates email, employees start working, and everyone assumes security is taken care of. After all, it is Microsoft. That is partly true: the platform has many layers of protection. But a good share of them are switched off or only partly on in a new tenant, because Microsoft cannot know how your company works and leaves the decision to the administrator.
In our experience, when we take over Microsoft 365 administration, the most common finding is not a breach but a tenant running on default settings: MFA enabled only for administrators, legacy email protocols open, the audit log not turned on, and a few employees who have set up rules that forward email to a personal mailbox. None of this is visible in daily work until an incident happens.
Below are the eight settings we check first. Most of them have no extra cost and can be turned on in hours, not weeks.
MFA for everyone, not just administrators
Multifactor authentication (MFA) is the single most important measure against account takeover. Passwords get leaked, guessed and phished, and a second factor breaks that chain. Microsoft turns on security defaults for new tenants, which require MFA, but in older tenants they are often switched off, and in companies that use Conditional Access the responsibility moves to policies.
What to check: whether MFA registration is required for all users, including shared mailboxes that are signed in to directly, and service accounts. Whether the Microsoft Authenticator app is used rather than SMS, which is the weakest form. Whether protection against MFA fatigue is on, where a user taps “approve” just because the prompts will not stop.
Conditional Access instead of “everyone gets everything”
Conditional Access is an Entra ID P1 feature that Business Premium and Enterprise plans include. It lets you set rules: which countries sign-ins may come from, whether the device has to be managed, when to ask for MFA again, which apps to block.
The most common situation is a company that has Premium but not a single Conditional Access policy. That means paying for a feature that does not run. The minimum set we recommend:
- Block sign-ins from countries where the company does not operate.
- Require MFA for all cloud apps.
- Require a compliant device for administrator accounts.
- Block legacy authentication protocols (more on that below).
- Limit session lifetime on unmanaged devices.
We turn policies on in report-only mode first, to see what would be blocked, and only then activate them. That avoids the situation where half the company cannot sign in on Monday morning.
Legacy protocols that bypass MFA
POP3, IMAP, SMTP AUTH and older Outlook versions use what is called legacy authentication, which does not support MFA. If these protocols are open, an attacker needs only the password, and nobody will ask for a second factor. Most password-guessing attacks go through exactly these protocols.
Microsoft has disabled some of them at the platform level, but SMTP AUTH can still be enabled for individual mailboxes, and it often is for multifunction printers, scanners or old applications that send email. The fix is to check the sign-in logs to see who really uses legacy protocols, move the devices to modern authentication or to a separate sending connector, and then block the protocols with a Conditional Access policy.
Control of mail forwarding rules
This is one of the quietest and most dangerous things. When an attacker takes over an account, the first move is often not reading email but creating a rule: forward every message containing words such as “invoice,” “payment” or “bank” to an external address and delete it from the inbox. The user notices nothing, while the attacker follows the correspondence with customers for months and waits for the right moment to change the bank details on an invoice.
What to set: in the Exchange Online outbound spam policy, block automatic forwarding to external domains. Turn on the alert for newly created forwarding rules. Once a month, review the forwarding settings of all mailboxes. If forwarding is genuinely needed, allow it for a specific mailbox, not for everyone.
Data loss prevention (DLP)
DLP policies let you detect and stop the sending of sensitive data: national ID numbers, bank accounts, card numbers, confidential documents. Microsoft Purview has ready-made templates, including one for the EU General Data Protection Regulation, but none of them is on by default.
It is worth starting in monitoring mode: the policy records who sends sensitive data and where, but does not block anything. After a month you see the real picture. It usually turns out that personal data travels in Teams chats and to personal email much more often than anyone imagined. Then you tighten the policies: a warning to the user, blocking with the option to give a business justification, blocking with no exceptions.
The audit log and how long it is kept
The unified audit log records who signed in, when and from where, which files they opened, which rules they created and what they deleted. Without it, an incident investigation is guesswork. In new tenants it is usually on, but older tenants need checking, and the retention period depends on the plan: in Business plans and E3, records are kept for 180 days.
If NIS2 or DORA applies to your company, 180 days may not be enough. Then you need either the add-on for longer retention or an export of the logs to an external system. This is one of the things we check when we perform an IT security audit.
Sharing settings in SharePoint and OneDrive
By default, SharePoint and OneDrive allow sharing files with anyone, including an anonymous “anyone with the link” link. It is convenient, but it means an employee can accidentally make a whole folder public, and the link stays valid indefinitely.
We recommend: allow external sharing only with specific guests who sign in after verifying their identity. Give anonymous links an expiration date and read-only permissions. Change the default link option from “anyone” to “people in your organisation.” Turn on guest access reviews so that guests you no longer work with are removed automatically.
Administrator accounts: separate and without email
A common situation: the person responsible for IT uses their everyday account with Global Administrator rights. They read email, open attachments and browse, and all of it with permissions that allow deleting the entire tenant. One successful phishing email and the attacker has everything.
The right way: a separate account for administration, with no licence and no mailbox, with mandatory MFA and, if possible, a hardware key. No more than two or three Global Administrators, with everyone else getting narrower roles by function (Exchange, SharePoint, User Administrator). One emergency (break-glass) account with a long password kept in a safe, excluded from Conditional Access policies. If an external provider administers the tenant, they should sign in through their own separate accounts, not through a shared “admin” user.
Where to start
None of these settings requires a project. It only takes consistency.
- Open the Microsoft Secure Score report in the admin centre. It shows which of the items above are not enabled in your tenant and how many users have no MFA.
- Week one: MFA for everyone, blocking legacy protocols, a ban on external forwarding. These three things stop most account takeover cases.
- Week two: Conditional Access policies in report-only mode, separation of administrator accounts, tighter sharing settings.
- Within a month: DLP in monitoring mode, a check of the audit log retention period.
- Every quarter: a Secure Score review and a check of forwarding rules.
If you want us to set this up and maintain it, our Microsoft 365 security service covers all eight points as an initial cleanup and ongoing monitoring. Together with Microsoft 365 administration, it means the settings will not drift back when someone turns a policy off “temporarily” and forgets to turn it on again.
