Konica Minolta bizhub OAuth Migration Guide

Modern authentication for Scan to Email and related SMTP-based workflows

Last reviewed: 2026-04-02

This guide consolidates the key information from the prior discussion and expands it into a practical implementation document. Menu names and behavior can vary by exact model and firmware. Always validate the exact device against Konica Minolta documentation before rollout.

Executive summary

Konica Minolta has introduced OAuth 2.0 support for many bizhub and related models, but support is model- and firmware-dependent. The practical outcome is simple: supported devices can move away from basic SMTP authentication and use modern authentication with Microsoft 365 or Google Workspace; unsupported devices need an alternative design.

For supported models, the migration is not just an SMTP setting change. It normally requires: a firmware level that includes OAuth support, a designated sender mailbox, outbound HTTPS reachability to the provider login flow, device-side OAuth enablement, and then a token acquisition step on the printer control panel.

For Microsoft 365, OAuth-capable SMTP client submission remains the straightforward path for devices that can sign in. For Google Workspace, Google officially recommends SMTP relay for many printer and scanner scenarios, while supported Konica models can also use the vendor OAuth flow. For unsupported legacy devices, SMTP relay, scan-to-folder, or another mail path is often the only realistic migration route.

What problem this migration solves

Older multifunction printers often send scan emails by logging in to an SMTP service with only a username and password. That model is being phased out because it is weaker against credential theft, brute-force attacks, and mailbox misuse.

Google Workspace no longer supports less secure app sign-ins for Workspace accounts and requires OAuth for apps and devices that access Google accounts directly. Microsoft is also moving SMTP AUTH basic authentication toward disable-by-default and long-term retirement, while continuing to support OAuth-based SMTP scenarios.

Because of those platform changes, printers that continue to rely on basic authentication may suddenly stop sending Scan to Email, Internet Fax notifications, user box email delivery, and similar workflows. The migration to OAuth is therefore both a security upgrade and a business continuity task.

Affected Konica Minolta functions

On supported Konica Minolta devices, OAuth may apply to more than just Scan to Email. Depending on model family and firmware, the affected functions can include Scan to Email, Scan to Me, Scan to URL, Internet Fax transmission, email sending from a User Box, email sending from OpenAPI or IWS applications, administrator email notifications, total counter notifications, forward transmission, and TSI routing.

This matters during planning because a successful test from one scan screen does not automatically prove every email-related function has been validated. A good migration should identify all workflows on each device before changing the authentication method.

Compatibility and firmware reality

OAuth support on Konica Minolta devices is not universal. The vendor publishes a product matrix that shows which models have released firmware, which are scheduled, which are under planning, and which are marked N/A. A device marked N/A, or a device not listed in the support notice, should be treated as not receiving an OAuth firmware path unless Konica Minolta explicitly states otherwise.

In practice, this creates three broad categories. First, supported models: update firmware and configure OAuth. Second, partially supported or in-planning models: verify the exact firmware availability before designing the migration. Third, unsupported legacy models: redesign the workflow instead of spending time trying to force unsupported authentication methods onto the device.

Do not assume two very similar bizhub models behave the same. Even within the same product family, firmware availability and function versions can differ. Always verify the exact model name and currently installed firmware/function version before scheduling migration work.

High-level migration workflow

A reliable project flow is: inventory devices and workflows, classify models by support status, choose a target sending method per model, update firmware where supported, prepare the sender mailbox and tenant settings, configure the device, complete token acquisition at the panel, perform end-to-end testing, document the final settings, and define a re-authentication procedure for when tokens expire or are revoked.

The key implementation mistake is starting on the device before confirming provider-side prerequisites. OAuth on the printer does not compensate for mailbox-level or tenant-level restrictions such as disabled SMTP AUTH, blocked TLS versions, missing proxy access, or sender mailbox permission mismatches.

Prerequisites before touching the printer

Identify the exact model, current firmware, and whether the machine is in the vendor support matrix for OAuth. If the device is unsupported, stop and choose an alternative workflow instead of beginning a device-side configuration exercise that cannot succeed.

Choose a dedicated sender mailbox wherever possible. Shared operational addresses such as scanner@company.com or mfp-floor2@company.com are easier to document, monitor, permission, and rotate than using a personal account. They also reduce audit confusion when multiple users scan from one device.

Confirm outbound network requirements. OAuth usually requires the printer to reach provider authentication endpoints over HTTPS, and it may also require DNS resolution, NTP/time accuracy, and proxy configuration. A printer with incorrect time or blocked outbound web access can fail the sign-in flow even when SMTP settings look correct.

Confirm the organisation has a fallback plan. If OAuth fails during change windows, know in advance whether the fallback is scan-to-folder, SMTP relay, or rollback to an existing internal mail relay while troubleshooting continues.

Konica Minolta device-side configuration sequence

On supported models, Konica Minolta documents a consistent sequence. First, set the machine administrator email address to the Microsoft or Google mailbox that will be used during OAuth. Second, configure proxy settings if your environment needs them. Third, enable OAuth in the email transmission settings. Fourth, move to the OAuth sign-in screen from the device control panel and complete authentication there. Fifth, set the SMTP server for the selected provider.

The commonly referenced path is Utility -> Administrator -> Network -> E-mail Setting -> E-mail TX (SMTP) -> OAuth Settings. In that area, set OAuth 2.0 to ON and choose the provider, usually Microsoft or Google. After that, the machine prompts you to move into the authentication flow.

A practical nuance: Konica Minolta documentation and field guidance indicate that refresh token acquisition is done at the printer panel. On some models or firmware levels, Web Connection alone is not the full place to finish the OAuth process. Administrators should therefore plan to stand physically at the device, not only in a browser session.

Why the administrator email matters

Konica Minolta ties the OAuth flow to the sender identity. Before the authentication step, the administrator registration on the machine needs the same mailbox identity that the device will use as the sender. If this is misconfigured, the machine can complete an apparent sign-in flow but still fail to send mail in production because the authenticated identity and the From address logic do not align.

For Internet Fax scenarios, the vendor documentation also notes that the machine address used for that function should match the administrator email configuration where applicable. This is another reason to inventory all email-dependent features before changing authentication.

From address behavior and user experience

One of the most important operational details is the Change From Address behavior. If the printer is configured to send as the logged-in user address, or to allow users to change the From address, the OAuth prompt can appear when each user sends email. That creates a very different user experience from a shared device that always sends from a fixed service mailbox.

If the organisation wants a simple support model, use a fixed administrator or bulk sender address and pre-authenticate that mailbox in OAuth Settings. If the organisation intentionally wants per-user sending identity, be prepared for user-level authentication prompts, training, and potentially more support calls.

Microsoft 365 requirements and design notes

For Microsoft 365, the usual target method on OAuth-capable devices is authenticated client SMTP submission. Microsoft recommends modern authentication for this scenario. The normal server name is smtp.office365.com, using port 587 with TLS or STARTTLS enabled.

The sending account should be a licensed Microsoft 365 mailbox. Also verify that SMTP AUTH is enabled for the designated mailbox if your tenant policy disables it broadly. Microsoft notes that security defaults in Entra ID disable SMTP AUTH, so that setting must be considered during design. Even if the printer supports OAuth, an overly restrictive tenant policy can still prevent the workflow from working.

If the device signs in with one mailbox but sends with another address, make sure the signed-in account has Send As permission where required. Otherwise Microsoft may reject the message with a permission-related NDR. For this reason, many teams keep the authenticated mailbox and displayed From address the same for shared printers.

Google Workspace requirements and design notes

For Google Workspace, the strategic picture is slightly different. Google requires OAuth for direct account access by devices and apps, but for printer and scanner scenarios Google officially recommends SMTP relay as the preferred option in many environments. This is especially relevant when older devices do not implement OAuth well, or when administrators want IP-based control instead of mailbox-style sign-in on each device.

Supported Konica Minolta models can still use the vendor OAuth flow with Google. However, for unsupported legacy printers, Google makes clear that older scanners and printers may simply not support OAuth and may therefore not support sending email directly. In those cases, SMTP relay, scan-to-folder, or another application path should be treated as the primary migration strategy.

Some Konica Minolta notices mention Gmail app-password-based workarounds in limited cases, but organisations should evaluate that carefully against current Google policy and internal security standards. In most enterprise environments, a relay-based design or an OAuth-capable device is cleaner than relying on exception paths.

Recommended decision matrix

If the model is supported for OAuth and the environment uses Microsoft 365, use Konica OAuth plus Microsoft 365 SMTP submission with a dedicated mailbox. If the model is supported and the environment uses Google Workspace, use Konica OAuth or compare it with Google SMTP relay depending on operational preference and policy.

If the model is unsupported and the environment uses Microsoft 365, prefer an internal SMTP relay or Microsoft 365 relay design only if the device and network fit that architecture; otherwise move the scan workflow away from email. If the model is unsupported and the environment uses Google Workspace, prefer Google SMTP relay or non-email scan destinations. Do not spend project time trying to force unsupported OAuth into the device.

Detailed implementation checklist

1. Confirm the exact model and firmware. 2. Review the Konica Minolta support matrix. 3. Decide the target workflow: direct OAuth or relay-based alternative. 4. Reserve a dedicated sender identity. 5. Validate tenant-side prerequisites. 6. Check DNS, NTP, outbound HTTPS, and proxy behavior. 7. Update printer firmware and function version if needed. 8. Record current settings before changes. 9. Configure the administrator email on the device. 10. Enable OAuth and select the provider. 11. Acquire the token on the printer panel. 12. Set the SMTP endpoint for the provider. 13. Send test mail to internal and external recipients. 14. Validate multifunction features beyond Scan to Email. 15. Document re-authentication and support ownership.

Testing strategy

Testing should cover at least five scenarios: internal recipient, external recipient, a scan job from the common scan screen, any user-authenticated sending path, and at least one administrator-originated email notification function if the organisation uses those features.

The best proof of success is not just that one email arrived. It is that the email arrived from the expected sender, with the expected display name, through the expected mailbox path, without prompting unexpectedly, and that the printer retained its working state after a reboot or short waiting period.

Where possible, verify logs in both places: the printer event or job history and the mail platform trace tools. That makes it much faster to determine whether a failure is caused by device sign-in, SMTP submission, sender permission, or recipient routing.

Common failure modes and what they usually mean

The OAuth page never opens or cannot complete: usually outbound web access, DNS, proxy, certificate trust, or time synchronization issues. Check whether the device can reach the provider over HTTPS and whether proxy settings are correct.

Authentication appears to succeed but messages do not send: often the SMTP server details, mailbox permissions, From address mapping, or provider-side mailbox restrictions are wrong. On Microsoft 365, also verify SMTP AUTH and Send As requirements.

The printer asks every user to authenticate: this is usually expected when the From address policy uses login user address or allows user changes. Change the sender model if a shared fixed mailbox is desired.

Microsoft OAuth is unavailable even though menus exist: Konica notes that when TLS 1.3 is forced as both minimum and maximum, Microsoft OAuth may not be available on certain models. Review the device TLS configuration.

The feature still fails after configuration on an older machine: confirm again that the exact model is actually supported. Many migration projects lose time because a near-match model was assumed to be equivalent to a supported one.

Operational support after go-live

Document who owns the sender mailbox, who can re-authenticate the device, and where the printer physically lives. Token or consent problems are often solved fastest by someone who can stand at the control panel and authenticate immediately.

Keep a short runbook near the service documentation: which mailbox is used, which provider is selected, what the SMTP endpoint is, whether a proxy is required, whether the sender is fixed or per-user, and what the approved fallback method is if email sending fails.

When the service mailbox password, MFA posture, consent policy, tenant policy, or outbound proxy rules change, retest the device. Printers are infrastructure, but they often fail silently until a business user urgently needs a scan delivered.

When not to use direct OAuth on the printer

Do not force direct OAuth on unsupported models. Do not use it where the physical control-panel sign-in burden is unacceptable. Do not use per-user From address behavior on a shared device unless the business explicitly wants that experience. Do not keep personal mailboxes embedded in printer workflows if a shared operational mailbox would meet the requirement.

In many organisations, the cleanest long-term architecture is not direct email from every printer. It is a mix of supported OAuth-capable devices where needed, SMTP relay where policy permits, and scan-to-folder or workflow-platform integrations for the rest.

Practical rollout plan for multiple devices

Start with one pilot device from each model family. Validate firmware, OAuth acquisition, and provider behavior. Then create a standard change template that includes screenshots, settings capture, test recipients, and rollback steps.

Group rollout windows by model family and location. Keep one technician or administrator available who understands both the printer UI and the mail platform. After each batch, update the asset register with the final mailbox, firmware, authentication method, and support notes.

For estates with many unsupported devices, build a separate remediation stream. Those machines need architecture decisions, not only configuration changes.

Appendix A - Quick comparison table

| Preferred secure direction | OAuth-based client SMTP submission for supported devices | OAuth-capable devices or SMTP relay for printer/scanner scenarios |

| Typical SMTP endpoint | smtp.office365.com | Depends on method; verify current Google method for your design |

| Typical SMTP port | 587 with TLS/STARTTLS | Depends on method; relay and direct submission options differ |

| Mailbox requirement | Usually a licensed mailbox for direct SMTP submission | Varies by chosen method |

| Common blocker | SMTP AUTH disabled by security defaults or mailbox policy | Device does not support OAuth well enough for direct account access |

| Best fallback for old devices | Relay or non-email scan workflow | SMTP relay or non-email scan workflow |

Appendix B - Troubleshooting table

| OAuth screen does not load | Proxy, DNS, outbound HTTPS, certificate, or time problem | Check proxy, DNS, NTP, web access, and provider reachability |

| Sign-in works but mail fails | SMTP endpoint, port, sender mapping, permissions, or SMTP AUTH policy issue | Verify SMTP settings, sender identity, and platform-side restrictions |

| Users are prompted to authenticate | From address policy is set per user | Use fixed sender mode if shared-mailbox behavior is desired |

| Works on one model, fails on another | Firmware or support status differs | Check exact support matrix entry and firmware version |

| Microsoft provider option not usable | TLS 1.3 minimum and maximum forced on device | Review device TLS settings and firmware notes |

References

1. Konica Minolta global notice: OAuth 2.0 support notice for SMTP authentication

2. Konica Minolta manual: Using OAuth Authentication (example bizhub i-Series manual)

3. Microsoft Learn: How to set up a multifunction device or application to send email using Microsoft 365 or Office 365

4. Microsoft Learn: Enable or disable SMTP AUTH in Exchange Online

5. Microsoft Exchange Team: Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline

6. Google Workspace Admin Help: Control access to less secure apps

7. Google Workspace Admin Help: Send email from a printer, scanner, or app