Will Outlook on the web and the modern Outlook app still work?

Yes. They use modern authentication. This is about clients and protocols that only speak username and password — not a properly linked current Outlook.

Can we see who still signs in with basic authentication?

Yes. Floor ICT can inventory legacy sign-ins (which mailbox, which client type) and propose what you turn off or migrate. Without your approval we do not casually open or close a production exception outside the agreed policy.

What if the warehouse scanner truly needs SMTP AUTH?

Create a named exception with an owner and an end date, or choose a more modern send path. Permanent basic authentication on a personal mailbox is rarely the best answer.

Does Floor ICT do this by default when managing Microsoft 365?

At intake or when Microsoft 365 is in scope, we turn legacy authentication off by default and report on legacy sign-ins per your policy. Which exceptions remain is yours. Essential/Advanced/Elite say nothing about authentication policy; that is tenant configuration beside the MSP package.

Legacy authentication in Microsoft 365: why an SME should turn off basic auth

Old phones, scanners and scripts that still sign in with username and password. What you turn off — and what Floor ICT checks.

What legacy authentication is — and is not

In Microsoft 365, “legacy authentication” roughly means clients and protocols that do not speak modern authentication (OAuth 2.0 / OpenID Connect). Typical SME examples:

IMAP / POP / SMTP AUTH: an old phone, a Linux mail client, or a “send as” script that still uses a password;
Older Office or ActiveSync clients: apps that cannot do a token flow and fall back to basic authentication;
Devices without a browser login: some multifunction printers, label printers or monitoring tools that only know “user + password”.

That is different from Outlook on the web or the current Outlook app with MFA: those use modern authentication. The risk is the quiet back door — not the daily workstation you already hardened.

Why an SME should turn basic authentication off

Three practical reasons. MFA bypass: you turned on multifactor authentication, but an IMAP login with only the password never asks for the second factor — see turning on MFA in Microsoft 365. Stolen passwords: password sprays and leaked credentials hit hardest where basic authentication is still open. False comfort: Secure Score and “everyone has MFA” mean little if scanners and scripts may still use legacy auth. Email authentication (SPF, DKIM and DMARC) protects your sending domain; it does not stop an inbound IMAP login with a stolen password. Those layers sit side by side.

What you should write down

Keep it short enough to decide this quarter:

default: basic authentication / legacy protocols off (tenant-wide Authentication policies or equivalent);
exceptions: only by name (mailbox, app or device), with owner, reason and end date;
replace first: modern authentication, Microsoft Graph / a connector with an app registration, or refresh the device — not “app password forever”;
ban or tightly limit: app passwords as an MFA bypass for personal mailboxes;
review: every quarter walk legacy sign-ins; on leaver and inactive accounts, check whether legacy clients still hang on;
hygiene: basic authentication off as a fixed item next to MFA, anti-forward and account review.

Put those points on one page. That is your authentication policy; the tenant follows that text.

What breaks — and what you put in its place

What often breaks when you turn basic authentication off: an old iPhone or Android still doing “Exchange” with a password; a scanner sending scan-to-mail via SMTP AUTH; an accounting or CRM script pulling POP/IMAP; a monitoring tool with a stored password. What you put instead: re-link the mail app with modern authentication; scan-to-mail via a connector, a relay with modern auth, or a dedicated send-as under strict policy; move scripts to Microsoft Graph with an app registration and least privilege — not another shared password. See also shared mailboxes: info@ on one password plus IMAP is exactly the pattern to leave behind.

What Floor ICT configures — and what you decide

In the Microsoft 365 tenant we typically set: Authentication policies (or equivalent blocks) so IMAP, POP, SMTP AUTH and other legacy clients are off by default; reporting or alerts on legacy sign-in attempts; an inventory of which mailboxes or apps still use basic authentication; and a short migration path per exception after your approval. We tie this to MFA policy and joiner/leaver so new accounts do not quietly reopen legacy paths.

You still decide: whether the default is truly “everything off”; which scanner or integration gets a temporary exception; how long it lasts; and whether you refresh the device or the script. Technical toggles without ownership do not fix “the warehouse scanner has mailed like this for five years”; policy without execution does not either.

More depth

Checklist for SME directors

1) Decide: basic authentication off by default. 2) Inventory legacy sign-ins (which mailbox, which device). 3) Prepare the replacement before you flip the switch. 4) Exceptions only by name with an end date. 5) Ban app passwords as a structural bypass. 6) Review every quarter.

App passwords: sometimes needed, rarely structural

An app password is a long password for clients that cannot show an MFA prompt. It bypasses the second factor. Use it only as a temporary bridge with an owner and an end date — not as the default for the whole team.

SMTP AUTH for scanners

Many multifunction devices can only do SMTP with username/password. Options: a modern connector or relay, a tightly limited send account with monitoring, or replace the device. Floor ICT helps pick the least-risky path once you have locked the goal (scan-to-mail).

View MSP packages Request intake Microsoft 365