There is a printer in almost every German office that nobody thinks about until it stops working. It scans documents, sends them to a shared mailbox, and has been doing so without complaint for seven years. When Microsoft finally switches off Basic Authentication for SMTP, that printer will go silent — and the timing will feel like the worst possible moment.
This is not hypothetical. Microsoft began signalling this change in 2019. The final enforcement for tenants still using SMTP AUTH with Basic credentials is rolling out through 2025 and into early 2026. If you have not acted yet, this guide tells you exactly what to check, what your options are, and what the consequences are of doing nothing.
Why Basic Auth for SMTP Is a Security Problem
Basic Authentication sends your username and password with every email request, encoded in Base64. That is not encryption — Base64 can be decoded in seconds. Anyone intercepting the connection, or anyone who finds that password in a configuration file, can use your mail account without restriction.
The deeper problem is that Basic Auth cannot support Multi-Factor Authentication. A stolen password is enough. Microsoft's own data shows that over 99% of compromised accounts do not use MFA. Legacy authentication protocols are the direct enabler of most credential-based attacks the company investigates.
From a DSGVO perspective, this matters directly. Article 32 of the GDPR requires organisations to implement appropriate technical measures to protect personal data. Using an authentication method that is widely known to be exploitable — when modern alternatives exist — is difficult to defend in a breach investigation. German supervisory authorities (Datenschutzbehörden) have been increasingly specific about what "state of the art" means in security assessments. Basic Auth no longer qualifies.
What Gets Affected — A Practical Checklist
Not everything that sends email through your Microsoft 365 tenant uses SMTP AUTH. The question is whether the sending application authenticates using a username and password combination rather than a certificate or OAuth token. Work through this list:
- →Multifunction printers / copiers with Scan-to-Email: Kyocera, Ricoh, Canon, Konica Minolta — virtually all of them use stored credentials. Check the device's network settings for an SMTP username field.
- →Line-of-business applications: ERP systems like SAP Business One, DATEV, Lexware, and many custom-built applications send order confirmations, reminders, and reports via SMTP. Each one is a potential failure point.
- →Monitoring and alerting tools: Server monitoring software, UPS systems, and NAS devices often send alert emails. These are usually forgotten until something breaks.
- →Older CRM and ticketing systems: On-premise installations of tools like SugarCRM or Redmine often have hardcoded SMTP credentials in configuration files.
- →Website contact forms: PHP-based websites using PHPMailer or similar libraries connected to an Exchange Online mailbox via SMTP AUTH.
To find all SMTP AUTH usage in your tenant, go to Exchange Admin Center → Reports → Mail flow and filter for SMTP AUTH client submissions. The report shows you exactly which accounts have authenticated via legacy SMTP in the past 30 days.
Your Three Migration Paths
There is no single right answer. The right path depends on whether the sending device or application can be updated to support modern authentication.
Option 1: OAuth 2.0 (Recommended for Applications)
Modern line-of-business applications and newer printer firmware versions support OAuth 2.0. The application registers as an app in Entra ID and exchanges a client secret for a short-lived token instead of storing a password. This is the most secure option and eliminates the risk of a stolen static credential. Implementation requires creating an app registration in Azure, granting it SMTP.Send permissions, and updating the application's mail configuration to use the token endpoint.
Option 2: Direct Send via Microsoft 365 (Good for Printers)
If the device only sends to recipients within your own domain, you can configure it to use the Microsoft 365 direct send endpoint (your tenant's MX record) without any authentication at all — provided you whitelist the device's IP address. No credentials are stored on the device. This works well for printers that send scans to internal mailboxes but cannot be used to send to external addresses like customers or suppliers.
Option 3: SMTP Relay via Azure or a Third-Party Service
For devices that need to send externally but cannot support OAuth 2.0, the cleanest solution is to route through an SMTP relay service. Azure Communication Services, SendGrid, or a dedicated on-premise relay server accepts the connection from the device using a static credential scoped to that relay only — not your main Microsoft 365 tenant. This keeps Exchange Online credentials out of legacy devices entirely.
Step-by-Step: Migrate a Printer to Direct Send
This is the most common scenario and the fastest to implement. Here is what to do for a Ricoh, Kyocera, or similar MFP that only sends internally:
- Log into the device's web interface (usually at its local IP address).
- Navigate to Email / SMTP Settings.
- Change the SMTP server address from
smtp.office365.com to your tenant's MX endpoint (visible in Microsoft 365 Admin Center → Domains → your domain → MX record).
- Set the port to 25 and disable authentication entirely.
- In Exchange Admin Center, navigate to Mail flow → Connectors and create an inbound connector that accepts mail from the printer's IP address.
- Send a test scan and verify delivery in the target mailbox.
The whole process takes about 20 minutes per device once you know what you are doing. The risk is forgetting a device — which is why the audit step matters so much.
What Happens If You Do Nothing
Microsoft will disable SMTP AUTH at the tenant level. Devices and applications still using it will start receiving authentication errors. Email flows stop. In a finance department, this means invoice PDFs stop reaching customers. In a logistics operation, dispatch notifications stop sending. The timing is unpredictable because Microsoft rolls out enforcement in waves across tenants.
Beyond operational disruption, there is the compliance angle. If a breach occurs through a legacy SMTP account between now and the time you disable it, you will need to explain to your insurer and potentially to your Datenschutzbehörde why a known deprecated authentication method was still in use. That is not a comfortable position.
How IDE Solutions Can Help
We run a full SMTP AUTH audit across your tenant and every sending device or application we can identify. For each one, we recommend the right migration path and handle the technical implementation — whether that is configuring OAuth 2.0 app registrations in Entra ID, setting up direct send connectors, or deploying an SMTP relay for your legacy hardware.
Most projects are completed within one to two days of work. We document every change, test every flow, and leave you with a configuration record that satisfies both your IT team and any future compliance review.
Reference: Microsoft Exchange Online Auth Documentation