What's New in Imprivata Enterprise Access Management 26.1

Beginning with 26.1, the Classic Windows login has reached end of life and is no longer supported. The Classic Windows login provides desktop access on Windows endpoints.

After upgrading the Imprivata appliance to 26.1, the Windows desktop authentication experience automatically transitions from the Classic Windows login to the Imprivata login. Consider the following:

• This behavior occurs the first time the Imprivata agent syncs with an upgraded appliance.

• This behavior occurs regardless of the version of the Imprivata agent. For example, the first time a 25.4 agent syncs with a 26.1 appliance, users will see the Imprivata login when authenticating to Windows desktops.

• You cannot revert to the Classic Windows login. Choosing which login experience to use is no longer configurable using computer policy customization (Computer policy > Customization tab).

The Imprivata Application Profile Generator (Imprivata APG) and Single Sign-On (SSO) feature lets your enterprise identify authentication-related screens within third-party applications. EAM logs into those applications based on the user's EAM desktop session. The application logins are based on credentials of that desktop session's user.

The APG now extends EAM Clinical Workflows to Windows application authentication within the APG workflow.

The screens can be an initial application login screen, or re-authentication screens within the application (for additional authentication before sensitive actions).

For complete details, see APG - Login Behavior.

This integration allows Microsoft Entra ID to invoke Imprivata as an external second-factor provider during multi-factor authentication (MFA). When configured, Entra ID delegates the MFA challenge to ImprivataEAM, which validates the user’s second authentication factor and returns the result back to Entra ID. See Web SSO - Second Factor Only.

Imprivata Virtual Desktop Access now supports access to Windows 365 Cloud PCs on Windows devices. Supporting Windows 365 Cloud PCs lets you move workloads to the cloud, reducing reliance on managing complex on-premises infrastructure, while still delivering secure end user access.

The Application Profile Generator (APG) and Single Sign-On (SSO) feature lets your enterprise identify authentication-related screens within third-party applications. EAM logs into those applications based on the user's EAM desktop session. The application logins are based on credentials of that desktop session's user.

The APG now extends EAM Clinical Workflows to Windows application authentication within the APG workflow. See Login Behavior.

In response to Microsoft announcing the deprecation of basic authentication in Exchange Online (SMTP AUTH), you can now configure an SMTP server connection over OAuth to send email notifications to administrators and end users.

For more information, see Setting the Mail Server and Standard Messages.

Imprivata Virtual Desktop Access lets you customize the behavior of Microsoft RDS sessions using a registry value (ExtraRemotePCParams). This value helps to improve the usability and flexibility of your Microsoft RDS workflows.

• Support of this value has been extended to workflows that include Windows Server session host (RDSH) deployments.

• Support for workflows that include Remote PCs was introduced in Enterprise Access Management 25.2.

For more information, see Configuring Support for Microsoft Remote Desktop Services.

The License page in the Imprivata Admin Console has been updated to include a toggle allowing the display of either the legacy EAM license page or the EAM new modules in the Access Intelligence dashboard.

Risk-Based Access (RBA) for Desktop Access allows authentication requirements to change dynamically based on the risk level of an authentication. Risk evaluation is performed by EAM's integration with Imprivata Identity Threat Detection and Response (ITDR). The Advanced Passwordless Access license is required. See Risk-Based Access.

Risk-Based Access for Web SSO integrations with Open ID Connect and WS Federation are available for Learning Mode only for this release. In Learning Mode, all authentications for Web SSO are sent to Imprivata ITDR for evaluation, but not enforced. ITDR Learning Mode provides the opportunity to assess the outcomes of rule sets, and revise them, before enabling them in a future release. See Risk-Based Access.

With Grace Period enabled, the authenticator used during initial authentication must also be used throughout the entire grace period workflow. This requirement prevents users from switching to lower-assurance authenticators during the process.

In this release, eIDAS Substantial enforcement is extended to remote-access workflows, ensuring that only users who have been securely enrolled and authenticated at the required assurance level can access Patient Health Information (PHI) remotely.

For more information on new 26.1 qualifications and certifications, see Imprivata Enterprise Access Management with SSO Supported Components.

The Imprivata EAM Self-Service Password Reset application has been updated with a design that aligns with the interface users are familiar with from Web SSO authentications. The authentication methods required before resetting a user password can include face biometric, SMS, email, Imprivata ID, and Imprivata PIN. This updated feature is not available for the Imprivata agent on thin clients. The legacy application that enables self-service password reset with security questions is still available when the new feature is not enabled. See Self-Service Password Reset.

This is a reminder that Internet Explorer is not supported. Any functionality related to Internet Explorer or IE mode will be deprecated as of December 2026.

While Microsoft has not announced a release date for their planned update to LDAP channel binding and LDAP signing requirements, it is recommended that Imprivata administrators verify that their Imprivata directory (domain) connections are configured for SSL. When the update is applied, any directory connection that is not configured for SSL may fail.

To verify the connection settings, go to the Directories page (Users menu > Directories) and open the required domain. Verify that Use TLS for secure communication is selected.

As part of Imprivata's continuing effort to increase our security posture, beginning with the 7.4 release, Imprivata disables the use of older TLS versions 1.0 and 1.1 for all appliance communications.

For more information on TLS usage, see the "About TLS Communication" topic in the Imprivata Online Help.

As part of Imprivata's continuing effort to increase our security posture, this release includes two modes of API access through the Confirm ID and ProveID API:

• Full

  Full access enables the ability to use the Confirm ID COM interface. Full access is required in the following areas because of the reliance on the COM interfaces:

  • Clinical Workflows

  • EPCS

  • Imprivata Connector for Epic Hyperdrive

  • When Imprivata Confirm ID needs a password.

• Restricted

  In restricted mode, access to Password and UserAppCreds resources are disabled. A ResourceRequest that includes an attribute id of Password or UserAppCreds returns a response with a message stating that access is restricted and status code 403.

By default, Confirm ID access is disabled and ProveID API access is set to restricted. The settings to manage API access are on the API access page in the Imprivata Admin Console.

The Imprivata agent continues to install the Chrome extension for SSO, but no longer enables it.

If you plan on installing Imprivata agents on new endpoints or upgrading existing Imprivata agents, you must enable/allow the extension using a Microsoft Active Directory GPO. Per the Chrome Safe Browsing Policy, a GPO is the only supported way to enable extensions silently.

Microsoft has announced the deprecation of VBScript, but has not announced a release date on which VBScript will be retired.

Per Microsoft, VBScript will be available as a feature on demand before being retired in a future Windows release. While Imprivata procedure code extension objects continue to support VBScript, it is recommenced that Imprivata administrators create new event triggers using another supported scripting language, such as PowerShell, while planning for the retirement of VBScript.

Enterprises who have clinicians' faces enrolled for authentication in Mobile EPCS must migrate those enrollments to the new Imprivata Cloud Platform (ICP) Face Recognition support. This is accomplished with a custom migration tool. For more information, see the Imprivata Upgrade portal.

Does not apply to customers whose end-users have faces enrolled only for Desktop Authentication.

Face authentication is a new modality and is supported on Windows.

• If your enterprise uses mixed endpoints (thin clients, medical devices, etc.), test to verify that they continue to work after enabling Face recognition.

• If you encounter issues on non-Windows platforms, disable multiple second factors using computer policy overrides and reach out to your vendor and Imprivata representative.

Imprivata has identified limited cases where Imprivata agents running on non-Windows platforms are unable to authenticate depending on user policy configuration. Limiting the second factor options in your environment is recommended to resolve this.

Beginning with 25.2, you can no longer directly run the Imprivata agent installer. This includes:

• Double-clicking the MSI.

• Right-clicking the MSI and running as an administrator.

Launching the installer directly requires you to execute the MSI from an elevated command prompt. Directly running the MSI results in an error message stating that you do not have the required permissions. This behavior occurs even if you are logged into the Windows endpoint with administrator credentials.

Imprivata's Secure Walk Away added support for a Nordic Bluetooth Low Energy (BLE) receiver in Imprivata OneSign and Imprivata Confirm ID 7.11. The Bluetooth receiver sensitivity may vary for different mobile devices. If your users report that their workstations lock because Secure Walk Away does not detect their mobile devices, adjust the Secure Walk Away – Imprivata ID Sensitivity slider control in the computer policy assigned to those workstations.

For more information, see Configuring Imprivata Secure Walk Away