Secure Authentication

MyQ supports a range of authentication methods across its different interfaces and client applications. The right combination for your organization depends on your infrastructure, your user population, and your security requirements.

Supported Authentication Methods

Choosing Your Authentication Strategy

No single authentication method suits every environment. The right choice depends on your infrastructure, your user population, and how much friction users can tolerate at the device. The following scenarios cover the most common deployment patterns.

Managed Domain, Windows-Joined Devices

If all users are on domain-joined Windows workstations and the MyQ server is also domain-joined, Integrated Windows Authentication is the lowest-friction option for Web Interface and Desktop Client access – users authenticate silently using their Windows identity without entering credentials. At embedded terminals, combine this with ID card authentication to avoid a separate manual login step: users are already identified by domain at their workstation, and tap their card at the device to release jobs.

Cloud-First and Entra ID Environments

Where your organization uses Entra ID as the primary identity provider and devices are Entra ID-joined, Entra ID SSO is usually the preferred silent-authentication option for client workstations. Users are authenticated silently at Desktop Client startup using their OS identity and a token from Entra ID. Sign in with Microsoft covers Web Interface and Mobile Client access for the same user population.

At embedded terminals, the MyQ X Mobile Client with QR code login continues the same pattern. Users sign in to the mobile app with their Microsoft account – including any Entra ID MFA step already in place – and authenticate at devices by scanning a QR code on the terminal panel.

Hybrid Environments

Many organizations run a mix of on-premises AD and Entra ID, with a combination of domain-joined and Entra ID-joined devices. One useful pattern is to layer the two silent authentication methods in the Desktop Client: Entra ID SSO and IWA. MyQ attempts Entra ID SSO first; IWA can be used as a fallback for domain-joined devices where Entra ID SSO is not available. Users who cannot use either silent method can fall back to a configured manual login method.

For the Web Interface, both IWA and Sign in with Microsoft can be enabled simultaneously, covering domain-joined and cloud-managed users respectively.

Mixed Device Fleet Including BYOD

Where some users are on managed devices and others are not – personal laptops, macOS, mobile devices – silent authentication cannot cover the whole population. IWA and Entra ID SSO both require specific device join conditions that BYOD devices will not meet. Ensure a manual fallback is always available: username + PIN or username + password for users who cannot authenticate silently. For users with Microsoft accounts, Sign in with Microsoft can provide a manual login option that does not depend on Windows domain membership. Note that this is different from Desktop Client Entra ID SSO, which has device and operating system prerequisites.

At embedded terminals, ID card + PIN 2-step authentication provides consistent security regardless of how the user authenticated at their workstation.

Guest and Contractor Access

Users without a permanent directory presence need a lightweight onboarding path. One practical pattern is self-registration via Jobs via Email combined with temporary PINs. When configured correctly, users can be created automatically after sending their first email print job and receive a time-limited PIN by email. The PIN expires automatically, reducing follow-up cleanup, but the account and group assignment still need to be planned.

High-Security Environments

Where print and scan content is sensitive two-factor authentication at embedded terminals is strongly recommended. A common implementation is ID Card + PIN: the card identifies the user account, and the PIN adds a second check before access is granted. PINs should be long enough relative to your user population to prevent guessable combinations.

For a stronger terminal-authentication model, consider the Mobile Client QR code model with biometric lock enabled. Users unlock the Mobile Client with Face ID or fingerprint recognition, then scan the terminal QR code to authenticate at the device.

Security Best Practices

The following recommendations apply across the user management and authentication configuration described in this section. Review them as a set before finalizing your deployment design.

Use Two-Factor Authentication for Sensitive Environments

Where print or scan content is sensitive, avoid relying on PIN-only terminal authentication as the only control. Consider ID Card + PIN or ID Card + Password as a stronger baseline. The Mobile Client QR code model with biometric lock can also be considered where users have suitable mobile devices and app access.

Protect Administrative Accounts

Create separate accounts for administrative and everyday use. Apply stricter authentication requirements to admin accounts – longer passwords, MFA where available – without impacting the daily experience of regular users. Disable the built-in *admin account once initial setup is complete.

Enforce LDAPS for Directory Communication

Configure directory authentication and synchronization to use encrypted LDAP wherever supported, such as LDAPS/TLS. For Active Directory authentication servers, configure TLS and use port 636. For LDAPS to work, the MyQ server must trust the certificate presented by the directory server. Install the issuing root CA certificate in the Windows certificate store on the MyQ server. If your organization distributes CA certificates via Group Policy, this may already be handled automatically.

Protect Sensitive Directory Attributes

If ID card numbers, PIN codes, or other sensitive user identifiers are stored in Active Directory and synced to MyQ, be aware that standard AD attributes are readable by any authenticated domain user by default. Before enabling sync of these values, review whether they need to be protected using confidential attributes – a mechanism that restricts read access to specified trustee accounts, such as the service account used by MyQ for synchronization.

For stronger protection, store these values in custom schema extension attributes rather than standard AD attributes. Custom attributes are less predictable to enumerate and can be flagged as confidential. If schema changes or confidential attribute configuration are required, test the approach in a lab environment before applying it to production.

Apply Least Privilege to the Sync Service Account

The service account used by MyQ for LDAP synchronization should have read-only access scoped to the organizational units being synced – nothing more. A sync account with broad directory read permissions is an unnecessary risk. If confidential attributes are used for card or PIN data, the service account must be explicitly granted trustee access to those attributes.

Control Access to Job Content

Manage Settings and Manage Queues rights give administrators access to system configuration without exposing job content. Withhold Read Jobs and Manage Jobs from anyone who does not have a documented need to view print or scan content. In environments subject to GDPR or similar privacy requirements, this separation is a technical control that should be documented and auditable.

Size PINs Appropriately for Your User Population

PIN codes are the most common authentication method at embedded terminals and carry the full authentication burden – no username is required. The security of PIN authentication is directly determined by the ratio of possible PIN combinations to the number of users. If every possible 4-digit combination is in use across 10,000 users, any 4-digit number will authenticate as someone.

Ensure the minimum PIN length is set so that possible combinations significantly exceed the number of users. MyQ will warn you when the user count approaches the point where uniqueness can no longer be guaranteed – act on that warning promptly by increasing the minimum length and regenerating PINs.

Define Account Lockout Policy

MyQ supports configuring the maximum number of failed login attempts before an account is locked, and the lockout duration. Define these values before go-live – the defaults may not meet your organization's security policy. For sensitive environments, a low attempt threshold with a meaningful lockout duration can help reduce brute-force attempts against PIN and password authentication.