CPU consumption with Imprivata OneSign + SafeSign Identity Client (UZI card) installed

Though I’m not deeply technical active any more, last week I got involved in a VDI performance investigation. We discovered something that I solved in 2011, back in my days as an engineer, but came back because of the move to a 64-bit architecture. Because this issue is still relevant these days, I thought (after +4 years) let’s write a blog to inform others on how to solve this. Let’s dive in…

Most healthcare organizations are using Imprivata OneSign to provide convenient and safe access to their (Virtual) Desktop environment using proximity cards. Beside that every health care organization in The Netherlands uses the UZI-pass smart card for insurance declaration and other government regulated identifications. This card requires the SafeSign Identity Client to be installed as middleware.

When both products are installed on a Windows bases machine small CPU spikes (±3-4%) are visible in the Windows Task manager every few seconds. This may sound as something to neglect, however imagine this in a Virtual Desktop environment where +60 VM’s have this behavior on a single host. This makes a huge difference in the scalability of the host, but eventually also the user experience.

So what is happening? The Windows Task Manager reveals that the spikes are generated by the SSOManHost.exe process, this belongs to the Imprivata OneSign agent.

When using Process Monitor we discovered that the process is cycling through the following register keys, and all sub keys, every few seconds:


This key contains all installed smart card drivers. With a few smart card drivers installed (A clean Windows installation only contains three entries) this is no issue at all; however this list contains hundreds of entries causing the CPU usage.

So why is this list so huge? Well, the SafeSign Identity Client is used as middle ware software for a lot of Smart Card implementations. Because of this, a gigantic list of drivers is installed. This explains why the issue is only visible when both products are installed.

We’ve contacted Imprivata to ask for explanation:

The SSOManHost process cyclically reads data from registry and extracts information about the available smart cards using this method to observe if any changes have occurred. Since there are nearly hundred entries it takes some time and uses quite a bit of the CPU to obtain this information for each entry then then to process this information.

However, every Imprivata implementation I know of doesn’t use Imprivata for Smart Card authentication and only uses Proximity Card based authentication. So, this feature is not used at all. Imprivata provided us with a solution to disable the Smart Card functionality with the following steps:

  • In a registry go to HKEY_LOCAL_MACHINE\SOFTWARE\SSOProvider\DeviceManager\Devices\PKIS
  • Rename three entries under this registry path: CLSID, ProxyCLSID and StupCLSID
  • Reboot the machine
  • After this the SSOManHost process stop to read smart cards data from the registry.

However, on a x64 system the keys are a little different:

  • HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\SSOProvider\DeviceManager\Devices\PKISC
  • Rename six entries under the registry path: CLSID64, ProxyCLSID64, StupCLSID64, CLSID, ProxyCLSID and StupCLSID

Because nearly all health care organizations in The Netherlands use this software combination they are facing this behavior for sure without knowing. This ‘fix’ will give a positive boost on resource usage, especially in VDI environments, giving back the resources for more relevant things 🙂