A risk assessment of the systems that stop sending email when Basic authentication for SMTP AUTH is disabled — by default at the end of December 2026, per Microsoft’s updated deprecation timeline.
For the timeline itself and the full list of migration options, see EXCHANGE-ONLINE-SMTP-AUTH.md. This page is about inventory: finding the things in your environment that will quietly stop working.
The systems most at risk share a nasty property: they only send email when something is already wrong. A backup failure alert, a UPS on battery, a disk in a NAS degrading, a monitoring alarm. Nobody notices they’ve stopped working until the day one of them needed to reach you and didn’t.
Scan-to-email breaks loudly — a user complains the same morning. Alerting breaks silently, and you find out during the incident it should have warned you about.
Before auditing devices one by one, ask Exchange Online who is actually still using SMTP AUTH. The report covers the last 90 days:
Connect-ExchangeOnline
# Which mailboxes still have SMTP AUTH enabled?
Get-CASMailbox -ResultSize Unlimited |
Where-Object { $_.SmtpClientAuthenticationDisabled -eq $false } |
Select-Object DisplayName, PrimarySmtpAddress
# Tenant-wide setting ($false here means SMTP AUTH is allowed)
Get-TransportConfig | Select-Object SmtpClientAuthenticationDisabled
Microsoft also exposes a SMTP AUTH client submission report in the Exchange admin center (Reports → Mail flow) showing which clients and IPs have authenticated recently — that’s usually the fastest way to find the forgotten device nobody remembers configuring.
These aren’t predictions; the vendor or a support channel has documented the breakage publicly.
| System | Evidence |
|---|---|
| Ricoh multifunction printers | Official advisory listing affected products and firmware status |
| Microsoft Dynamics NAV / Business Central | Vendor guidance for affected installs |
| Laserfiche workflows | Community thread — workflow emails failing |
| ManageEngine OpManager | Vendor fix guide for the SMTPClientAuth error |
| Cerberus FTP Server | Support article on the exact 535 5.7.139 error |
| Fax servers (e.g. Faxination) | Vendor timeline notice |
| Cisco Unity Connection | Named in Microsoft’s own deprecation docs |
| Microsoft Teams Rooms | Named in Microsoft’s docs as needing modern auth enabled |
| QNAP NAS | Community confirmation that QNAP does not support OAuth for notifications |
| Veeam (older versions) | Veeam docs — some versions support only SMTP basic auth; newer ones added OAuth |
Whether a specific unit breaks depends on two things: can its firmware do OAuth 2.0, and has your admin re-enabled Basic auth as a stopgap. Older and cheaper hardware overwhelmingly cannot do OAuth and never will.
Scan-to-email on Ricoh, Canon, Konica Minolta, Xerox, Sharp, Kyocera, Brother, HP, Epson, Lexmark. Devices more than a few years old rarely get firmware adding OAuth. See PRINTERS.md for per-brand settings.
NAS units (QNAP, Synology, TrueNAS), UPS monitoring (APC PowerChute and similar), RAID controller alerts, IPMI/iDRAC/iLO out-of-band notifications, switch and firewall alerting. This is the silent-failure category — these only email you when hardware is already failing.
Veeam, Acronis, Macrium, Bacula, Nakivo, and custom backup scripts. A backup job that fails silently for months is materially worse than one that fails loudly on day one.
Nagios, Zabbix, PRTG, Icinga, LibreNMS, ManageEngine, Checkmk. Same silent failure mode, and often the very system meant to catch the others.
ERP and accounting (Dynamics NAV/BC, Sage, older SAP integrations), document management (Laserfiche and similar), ticketing and helpdesk, HR and payroll systems, hospital/lab/school information systems. Frequently vendor-locked, out of support, or maintained by someone who left years ago.
WordPress with an SMTP plugin, WooCommerce order mail, Nextcloud, GitLab, Jenkins, Grafana alerts, Zabbix, Home Assistant, phpBB, and any in-house app whose mail config is a hardcoded username and password.
PowerShell using Send-MailMessage (itself deprecated), Python smtplib,
cron jobs, scheduled tasks, database jobs (SQL Server Database Mail), CI/CD
pipelines. Usually the easiest to fix — someone can edit the code — but also
the easiest to forget, because they’re not in any asset inventory.
Alarm panels, camera/NVR motion alerts, access control, environmental sensors in server rooms. Old, rarely touched, and often the last thing anyone thinks to audit.
ZeroSMTP accepts ordinary SMTP AUTH (username + password over TLS), so for a device with no OAuth path it’s a three-field change: server, port, credentials. Nothing else about the device changes.
It fits the silent-alert category well: NAS and UPS notifications, backup job results, monitoring alarms, scan-to-email inside an organization, homelabs, schools and small offices with no budget for a paid relay. For those, what matters is that the message arrives at all — the sender address is irrelevant.
It does not fit anything customer-facing, anything that must come from your company domain, anything above roughly 200 messages a day, or regulated environments where sender identity is auditable. For those, use OAuth/Graph, a Direct Send connector, your own relay, or a paid service — all covered in the migration guide, which recommends them over this project where they’re the better answer.
Test the network path first with check-connection.sh
— corporate firewalls often block outbound 587/465 to a new host, which looks
identical to an authentication problem.