Printer and MFD Service Accounts: LDAP and SMTP

Every multifunction device (MFD) that looks up the address book or scans to email holds a directory or mail credential that anyone with its admin console can redirect to a host they control. These LDAP bind accounts, SMTP submission credentials and scan to folder accounts are non-human identities: typed into a web console once, shared across a fleet, rarely owned and almost never rotated. This guide covers only those service credentials: how pass-back attacks extract them, how to design the LDAP bind and SMTP relay so a stolen credential is worth little, how to detect misuse, and how to rotate across a fleet without breaking scanning. It is for identity, infrastructure and print teams. Device hardening, the Windows Print Spooler and print server configuration are covered in the Printer and Print Server Security Guide and are not repeated here.

Source note: protocol, event and mail options below are summarised from the Microsoft, Rapid7 and Common Criteria documents listed in the references, as checked in November 2026. Design patterns are NHI Mgmt Group recommendations. Confirm against the official text before relying on it.

Key takeaways

The admin console is the credential store. Whoever can change the LDAP or SMB server address on a device can usually make it send its stored credential to them, without ever seeing the password field.
Design for theft, not secrecy. Assume the bind and scan credentials will leak: a read-only LDAP account scoped to the address book attributes and a scan account that can only write to one share make the leak boring.
Prefer certificates over passwords for mail. A certificate-authenticated SMTP relay connector removes the mailbox password from the device; Basic authentication for Exchange Online SMTP AUTH is disabled by default for existing tenants from the end of December 2026.
Directory logs already show you the devices. Domain controller events 2887, 2889, 3039 and 3040 list clients doing simple binds over cleartext LDAP or LDAPS binds without channel binding, which is where most MFDs appear first.
Rotation is a fleet change, not a password reset. One credential per site or device group, held in a vault with an owner, lets you rotate in rings and prove the old password is dead.

The three credentials an MFD holds

A typical office MFD integrates with the directory and mail estate through three service credentials, plus its own local administrator account. Each is a non-human identity with a different blast radius if stolen.

Credential	What the device does with it	Protocol and port	What an attacker gets if it leaks
LDAP bind account	Searches the directory for the address book and, on many models, authenticates users at the panel	LDAP TCP 389, LDAPS TCP 636 (Global Catalog 3268 or 3269 on Active Directory)	A valid domain account (ATT&CK T1078.002 Domain Accounts) able to read the directory, and anything else that account was granted
SMTP submission credential	Sends scan to email messages	SMTP submission TCP 587 with TLS, or relay on TCP 25	A mailbox password usable to send internal-looking phishing and, if the account has a mailbox, to read mail (T1114.002 Remote Email Collection)
Scan to folder account	Writes scanned files to an SMB share (sometimes FTP)	SMB TCP 445; FTP TCP 21	A domain account with write access to shares, or an NTLM handshake that can be cracked or relayed (T1557.001)
Device administrator	Manages all of the above in the web console and panel	HTTPS to the embedded web server	The ability to read or redirect every credential on the device

The common failure is one privileged domain account doing all three jobs with the same password on every device. See the Service Account Security Guide for the general service account model this page applies to devices.

How pass-back attacks extract stored credentials

A pass-back attack does not need the stored password to be visible. The attacker changes where the device sends it. Rapid7's published research on Xerox VersaLink MFPs (CVE-2024-12510 and CVE-2024-12511, fixed in firmware) describes the pattern:

Reach the configuration: the attacker gets into the device's admin account (a default or weak password, or a console left open), or in some cases a user-level remote panel that exposes address book entries.
Redirect the target: they change the LDAP server address, or an SMB or FTP destination in the address book, to a host they control.
Trigger a connection: a "check connection" button, an address book lookup or a test scan makes the device authenticate to the new host.
Capture: on cleartext LDAP the listener receives the bind password in clear text; for SMB it receives a NetNTLMv2 handshake that can be cracked offline or relayed to another server; FTP gives up a cleartext password.

Rapid7 states the impact as capture of Active Directory credentials and lateral movement, and its mitigations are firmware updates, a strong admin password, and not using privileged Windows accounts for LDAP or scan to SMB. Defensively, three controls break the chain at different points:

Protect the console: a unique, vaulted administrator password per device and management access limited to an admin network stops step 1. The Default Credential Breaches Lessons Guide shows how often the first step is this easy.
Bind to a verified server: LDAPS with certificate validation against a trusted CA, where the device firmware supports it, means a rogue host without a valid certificate for the directory name does not receive the bind. Test this: a device that accepts any certificate gives no protection.
Make the credential worthless: a read-only, non-privileged bind account and a write-only scan account limit what a captured password can do even when steps 1 to 3 succeed.

For the SMB side, the relay half of the attack is addressed in the NTLM Relay Guide and the SMB Signing Guide. Microsoft notes that SMB signing confirms the sender's and receiver's identities and prevents relay attacks.

Designing the LDAP bind account

The bind account exists to read a handful of attributes. Build it for exactly that.

Scope: a dedicated standard user, not a member of any administrative group, with read access to the address book attributes the device actually queries (display name, mail, telephone number, and for panel login the user principal name). On Active Directory, authenticated users can read most of these by default, so the account usually needs no extra grants at all.
Logon restrictions: deny the account interactive and Remote Desktop logon through User Rights Assignment (Deny log on locally, Deny log on through Remote Desktop Services), and where your directory supports it restrict the account's logon workstations.
Transport: configure LDAPS on TCP 636 with certificate validation. On Active Directory, the policy Domain controller: LDAP server signing requirements set to Require signing makes domain controllers reject simple binds on cleartext connections, which is the end state; Microsoft's KB4520412 adds Domain controller: LDAP server channel binding token requirements (Never, When Supported, Always) for LDAPS.
Segmentation: one bind account per site or device group, so a leak from one floor does not force a fleet-wide change.

Before you require signing, find the devices that would break. Domain controllers log event 2887 as a 24 hour summary of unsigned SASL and cleartext simple binds; setting the diagnostic value 16 LDAP Interface Events to 2 (Basic) produces event 2889 per client with the client IP, the identity used and the bind type (1 is a simple bind without signing). For LDAPS, event 3040 counts binds without channel binding while the policy is Never, and 3039 records clients that fail validation once it is When Supported or Always. MFDs and scanners are usually the bulk of these lists. See the LDAP Security Deep Dive Guide for the wider directory hardening.

Designing the SMTP relay for scan to email

The mail credential is the one most often attached to a real, licensed mailbox, which makes it the most valuable to steal. For Microsoft 365, Microsoft documents four ways a device or application can send mail, including High Volume Email for internal recipients only; the three below are the ones that matter for most devices, and the choice determines whether there is a password on the device at all.

Method	How the device authenticates	Recipients	Credential risk on the device	Choose when
Client SMTP submission (smtp.office365.com, port 587, TLS 1.2 or 1.3)	Licensed mailbox username and password, or OAuth	Internal and external	A mailbox password, usable from anywhere unless Conditional Access or SMTP AUTH settings restrict it	The device supports OAuth, or as a short bridge while you move to a relay
SMTP relay through an inbound connector (your MX endpoint, port 25)	TLS certificate whose subject or SAN contains an accepted domain (recommended), or a dedicated static public IP	Internal and external	None for IP; a certificate for the certificate option, which should sit on a relay host rather than each device	Most fleets: no mailbox, no password, sender can be any address in an accepted domain
Direct Send (your MX endpoint, port 25)	Anonymous	Microsoft 365 recipients only	None, but anyone who can reach port 25 from your IP can send as your domain	Microsoft states most customers do not need it; only for devices that support nothing else

Timeline that drives the decision: the Exchange team's updated deprecation post (January 2026, checked 12 November 2026) says Basic authentication for SMTP AUTH will be disabled by default for existing tenants at the end of December 2026, administrators can re-enable it, and a final removal date will be announced in the second half of 2027. OAuth SMTP AUTH is the supported method. See the Exchange Online SMTP AUTH Basic Auth Retirement guide.

For most estates the practical pattern is an internal relay that accepts connections only from the print VLAN and forwards to Microsoft 365 through a certificate-authenticated connector, so devices hold no cloud credential. Whatever the platform:

No shared human mailboxes: if a mailbox credential must exist, it is a dedicated, unlicensed or minimally licensed send-only identity, with Send As granted only for the addresses scans should come from. Microsoft notes a sign-in account sending as another address needs Send As, otherwise sends fail with 5.7.60.
Restrict sender and recipients: fix the From address on the device or the relay, and consider restricting scan to email to internal recipients where the business allows.
Keep SPF, DKIM and DMARC aligned: relay and Direct Send traffic from your IP still needs SPF, and Microsoft calls out DKIM and DMARC misconfiguration as a security gap.

Scan to folder accounts

The scan to folder account is a domain account whose NTLM response a pass-back attack can capture or relay. Give each site or device group its own account with write (not modify, not read) permission to a dedicated scan share, no other group memberships, interactive and Remote Desktop logon denied, and a long random password from the vault. Where devices support Kerberos for SMB, enable it; the NTLM Deprecation and Elimination Guide explains why NTLM-only devices become a blocker. Scan to folder via FTP sends the password in clear text and should be retired. For print management servers, see the Group Managed Service Accounts (gMSA) Guide.

Choosing the design: small and large estates

Situation	LDAP	Mail	Scan to folder
Small office, a few devices, cloud mail only	One read-only bind account over LDAPS, or a static address book if the directory is small	Certificate or static IP connector; OAuth submission if the device supports it	One write-only account to one share, or scan to cloud storage via the print vendor's service
Multi-site enterprise	One bind account per site or device group, LDAPS with certificate validation, signing required on domain controllers	Internal relay restricted to print VLANs, certificate connector to cloud mail	Per-site accounts and shares; Kerberos where supported
Print management or secure release platform	The platform's server account does directory lookups; devices hold no bind credential	The platform or relay sends mail; devices hold no mail credential	The platform writes to storage under a gMSA or managed identity
Legacy devices that support only cleartext LDAP, SMTP AUTH Basic or SMB1	Isolate on a dedicated VLAN, give them throwaway credentials with no privileges, record an exception with an owner and a replacement date, and plan hardware replacement

Rotation across a device fleet

Rotation fails on MFDs because nobody knows which devices use which account. Treat it as a fleet change.

Inventory first: from DC events 2889 and 3040, relay logs, file server access logs and the devices' configuration exports, build a list of every device, the account it uses for each function, its site and its owner. Record each account in the vault with that owner. The NHI Inventory Reconciliation guide covers reconciling sources.
Split shared accounts: create the per-site accounts before the first rotation so that each later rotation touches a bounded set of devices.
Use a pilot ring: change one site. Where possible push the new credential through the vendor's fleet management tool or configuration templates rather than by hand at each web console, then test an address book lookup, a scan to email and a scan to folder on each device.
Overlap, then cut over: for scan to folder and LDAP, create a new account (blue/green) rather than resetting the old one, move devices across, and only then disable the old account. This gives an instant rollback: re-enable the old account.
Prove the old credential is dead: after disabling, watch for failed logons and LDAP bind failures using the old account name for a week; each one is a device you missed or an attacker who has it.
Set the cadence: rotate on a schedule, and immediately on device disposal, on a service contract change where the engineer knew the passwords, and after any suspected pass-back. The Rotating a Windows or Linux Service Account Password runbook and Credential Rotation at Scale cover the mechanics.

Detection and measurement

Watch the accounts, not only the devices:

Logons from the wrong place: any authentication by an MFD bind, scan or mail account from an IP outside the print VLAN or device range (Windows event 4624 and 4625 on servers, 4768 and 4776 on domain controllers, sign-in logs for cloud mailboxes).
Interactive or unusual logon types: logon type 2 or 10 for a device account is never legitimate.
Configuration change on the device: forward device audit logs to the SIEM where the model supports it (the Common Criteria Hardcopy Device protection profile includes audit generation and external audit storage over a trusted channel) and alert on LDAP server, SMB destination or SMTP server changes.
Mail anomalies: scan sender addresses sending to external recipients at unusual volume, or from outside the relay.

Metrics that show the programme is working:

Percentage of MFD credentials that are unique per site or device group, vaulted and owned.
Number of cleartext simple binds per day from device subnets (target: zero, then enforced).
Percentage of devices sending mail without a stored mailbox password (relay or connector).
Days since last rotation per MFD credential, against your standard.
Number of MFD service accounts in any privileged group (target: zero).

Framework mapping

Framework	Reference	How it applies to MFD credentials
NIST SP 800-53 Rev. 5	IA-5 Authenticator Management; IA-5(1) Password-based Authentication	Unique, vaulted, rotated bind, mail and scan credentials; factory defaults changed
NIST SP 800-53 Rev. 5	AC-6 Least Privilege; AC-6(5) Privileged Accounts	Read-only bind and write-only scan accounts, never privileged group members
NIST SP 800-53 Rev. 5	IA-9 Service Identification and Authentication; SC-8 Transmission Confidentiality and Integrity	LDAPS with certificate validation, TLS for SMTP, signed SMB
NIST CSF 2.0	PR.AA-01, PR.AA-05, PR.DS-02, DE.CM-01	Credentials for services and hardware managed; least privilege; data in transit protected; network services monitored
CIS Controls v8.1	Control 5 Account Management	Service accounts inventoried, owned and managed with the rest of the account estate
MITRE ATT&CK v20	T1078.002, T1187, T1557.001, T1040, T1114.002	Domain account reuse, forced authentication by the device, SMB relay, cleartext capture, mailbox access

Common failure patterns

A privileged account behind the scanner: a domain admin or broad file server account used for scan to folder because permissions were "too hard". Rapid7 explicitly warns against privileged Windows accounts for LDAP and scan to SMB.
Default administrator passwords left on devices: the console is the first step of every pass-back, and fleet-wide defaults turn one device into all of them.
Requiring LDAP signing without an inventory: enforcement breaks address books across sites and gets rolled back, leaving cleartext binds permanently in place. Use events 2887 and 2889 first.
Rotating by resetting the shared password: every missed device breaks at once and the old password is restored "temporarily". Use per-site accounts and overlap.
Devices disposed of with credentials inside: leased MFDs returned without a factory reset carry the bind and scan passwords out of the building.

Practitioner checklist

Inventory every MFD credential (LDAP bind, SMTP, scan to folder, device admin) with device, site and owner, in the vault.
Remove every MFD account from privileged groups; make the bind account read-only and the scan account write-only to one share.
Deny interactive and Remote Desktop logon to all device service accounts.
Set unique, vaulted administrator passwords per device and restrict console access to an admin network.
Move LDAP to LDAPS with certificate validation; enable event 2889 logging and drive cleartext binds to zero before requiring signing.
Replace mailbox passwords with a certificate-authenticated relay or OAuth before Basic SMTP AUTH is disabled by default at the end of December 2026.
Split shared credentials per site and rotate in rings with new accounts and an overlap period.
Alert on device account logons from outside the print network and on device configuration changes.
Factory reset devices at disposal and rotate any credential the reset cannot be verified for.

Printer and MFD Service Accounts: SMTP Relays and LDAP Bind Credentials