When the office scanner stops sending email

It is just before nine on a Monday morning. A signed purchase order needs to go to accounts. The office scanner says the job is complete, but nothing arrives in the inbox. While someone tries the scan again, another part of the business may be relying on the same kind of connection. The ERP system sends invoices. The backup system emails someone when a job fails.

These messages are easy to overlook. They rarely have a project of their own, and some never make it into the IT documentation. That matters at the end of 2026, when Microsoft plans to turn off username-and-password authentication by default for authenticated SMTP sending in Exchange Online. Which processes are affected depends on how each device and application actually sends mail.

For a small business with a lean IT team, I would start with the three messages you would least want to miss. Follow each one from the event that triggers it to the person who receives it. Half an hour with finance, operations or your IT provider can tell you more than a long equipment list that says “email configured” beside every printer.

SMTP is the protocol systems use to hand off email. With SMTP AUTH, the device or application signs in to the mail service to send it. The older method, Basic Authentication, uses a username and password. OAuth uses an access token. Your software or device needs to support the appropriate sign-in flow and be able to obtain a fresh token when required. Turning on TLS encrypts the connection. The sign-in method is a separate setting.

Microsoft’s Exchange team says behaviour stays as it is until the December 2026 change. At the end of December, Basic Authentication for SMTP AUTH is due to be disabled by default in existing Microsoft 365 tenants. Administrators will still be able to enable it if necessary, according to the announcement. For tenants created after December 2026, OAuth will be the supported authentication method. Microsoft plans to announce the final removal date in the second half of 2027. This reflects the guidance available on 6 November 2026. Exchange team timeline

For a newer device, I would first ask whether its current firmware explicitly supports the OAuth sign-in flow for Microsoft 365. For an older scanner that is already due for replacement, it may make more sense to send through a centrally managed mail server. The longer the workaround is likely to last and the more important the message, the less I would want to rely on a one-off setup on the device itself.

Test against the people who actually receive the messages. The receptionist may usually scan to an internal mailbox but send a delivery note directly to a supplier every Friday. A test that only sends a PDF to your own inbox misses that part of the job. Microsoft sets out the requirements and limitations in its guide to email from devices and applications.

The SMTP AUTH clients report in the Exchange admin center is a good starting point. It shows authenticated SMTP senders and helps you identify how they sign in. Start with accounts using Basic Authentication and find out which devices or applications are behind them. An account called “scanner” might also be in use by the old warehouse system. Microsoft’s report documentation

Then look for messages that rarely go out. A backup system may only send mail when something fails. Payroll might send on a particular day of the month. A website form may go unnoticed if someone usually reads enquiries in the application itself. A short reporting period tells you little about those cases. Ask the teams who own them and check delivery logs for vendor-hosted applications as well.

Write one sentence for each workflow that someone outside IT would understand. For example, “The ERP emails invoices to customers at month-end. Finance handles bounces. The ERP provider supports the sending setup.” Add the technical route, the sender address and the person who will accept the change. Keep credentials in the approved password manager.

I would start with a manageable workflow in November and plan to switch it before the holidays. Use a real test case with a controlled recipient and a harmless document. Check that the message arrives and that the logs show it going out. For invoices, make sure replies and bounces reach the right team. For a backup alert, deliberately trigger a test alert and check that it reaches the person who would act on it.

For a device using OAuth, run a second test after a restart and test again later in normal use. A successful sign-in during setup gives you limited evidence about what will happen next week. With a relay, test its boundaries too. A device outside the intended network or an unauthorised sender should be unable to send through it. Decide who checks the logs when a message fails to arrive.

If a critical workflow still depends on the old sign-in when the change takes effect, Microsoft’s announced option to re-enable it for existing tenants may buy time where your policies permit. I would name the owner and set an expiry date in advance. Give critical workflows a fallback as well, such as an independent alerting channel or an agreed manual process. After sign-off, review and remove the sending accounts, stored passwords and exceptions you no longer need.

That is the question I would put at the centre of this change. IT can run the mail service well and still miss the fact that month-end invoices have stopped going out. Knowing what triggers each message, who receives it and who owns the process gives you something concrete to test. Start with the message you would least want to miss.