🇦🇹 --:--:--
±0h
--:--:-- 🌍

M365 Security: The 5 Settings Missing in Almost Every Tenant

From Monitoring Practice: five settings that are missing in almost every Microsoft 365 environment and would prevent most incidents.

E
Edin Kovacevic
3 min read
Erstellt mit KI-Unterstützung, redaktionell geprüft von shinpo IT
M365 Security: The 5 Settings Missing in Almost Every Tenant

We manage and monitor Microsoft 365 environments of all sizes. What we notice: it's almost always the same five settings that are missing. None of them cost significant additional licensing fees, and none require a major project. Together, they prevent the vast majority of incidents we encounter in practice. Here they are, in order of importance.

1. Conditional Access: Login Rules Instead of Hope

Conditional Access is the ruleset that checks at every login: Who is logging in, from where, with which device, and is a second confirmation needed? Without these rules, the password alone decides access, and passwords are stolen daily and automatically.

The minimum that should be set up in every tenant (this is what your own Microsoft 365 environment is called): Multi-factor authentication mandatory for all users, stricter rules for administrators, and block logins from countries you have no business dealings with. Important: Microsoft's default settings ("Security Defaults") are better than nothing, but they are not a substitute for well-thought-out rules, because they cannot be tailored to your own way of working.

2. Disable Legacy Authentication

Old login methods such as IMAP, POP3, or SMTP Basic Auth date from a time before multi-factor authentication. They only know username and password, and that's exactly why attackers love them: these protocols allow any multi-factor rule to be bypassed. They simply try stolen passwords, without any second factor.

Microsoft has since disabled much of this itself, but not everything and not everywhere. In login logs you can quickly see whether old clients are still accessing. Typical candidates are an old copier that sends scans by email, or a business application from 2015. For these cases there are clean solutions, such as dedicated transmission channels with modern procedures. After that, legacy auth should be completely blocked by policy, not just "unused".

3. Clean Up App Registrations

The most underestimated point on this list. Every app that has ever been connected to the tenant, every tool that was tried out, every "Sign in with Microsoft" leaves behind a permission. Over the years, dozens of entries accumulate, many with far-reaching rights: read mailboxes, write files, act as a user. Attackers exploit exactly this: instead of cracking an account, they hijack a forgotten app with substantial permissions, because no one notices.

The solution is unglamorous: review the list of app registrations and enterprise applications once per quarter. What's no longer needed gets deleted. What remains gets pruned to the minimum necessary permissions. And user consent for new apps should be restricted, so that not every employee accidentally grants an external app mailbox access.

4. Check Mail Forwarding Rules

A classic from incident response: an account gets compromised, and the first thing the attacker does is set up an inconspicuous forwarding rule. Every incoming email now quietly goes to an external address. This way the attacker reads along for weeks, learns payment processes, and strikes at the right moment, for example with a fake invoice whose account number has been "updated".

Two measures against this: First, centrally block automatic forwarding to external addresses—this can be done in Exchange Online with just a few clicks. Second, completely review existing mailbox rules, because yesterday's rule survives today's password change. If you've never checked this before, you'll typically find at least one surprise.

5. Set Up a Break-Glass Account

The stricter the login rules, the more important the emergency exit. A break-glass account is an emergency administrator account for when all regular admin access no longer works: because a Conditional Access rule is faulty, the only admin lost their phone, or a multi-factor authentication service is down.

The key points: a separate account with a very long, random password, stored in a secure location outside your IT systems, for example in a safe. It is exempt from login rules, but has monitoring: every login with this account triggers an alarm. This way the emergency exit remains usable without becoming a back door. Without this account, every tightening of login rules is playing with fire.

Conclusion

None of these five points is exotic. Yet in almost every tenant we take over, at least half of them are missing. The effort for all five together is one to two working days, as a one-time task, plus a brief review routine per quarter. Measured against what a single successful attack on your email system costs—in money, time, and trust—this is one of the best investments a company can make in its IT.

Questions? [email protected]

E
Edin Kovacevic

Fragen zu diesem Thema?

Wir helfen gerne weiter, 30 Minuten, kostenlos.

Termin buchen