Imprivata EAM Keeps Appliance Keys Trusted Until Redeployment

A stolen private key from an Imprivata Enterprise Access Management appliance could remain useful for the life of its deployment. In its September 23 vulnerability note, CERT/CC says EAM versions 26.2.6 and below provide no supported way to rotate the RSA key pair that gives the appliance its X.509 identity. For hospitals and other organizations using EAM for sign-on, a new certificate made with the same key leaves the compromised identity in place.

CERT/CC reports no fix or delivery timeline. The CVE Program record and NVD record identify the affected range for CVE-2026-82356. Teams still running those versions need to protect existing key copies and prepare a recovery path if one has escaped.

One key across appliance certificates

EAM’s appliance certificate identifies the authentication system to clinical workstations, Electronic Health Record (EHR) platforms and shared-device sign-on flows. CERT/CC says the product uses the same RSA key pair to generate that certificate after deployment.

The reporter, Frank “5y5tem5” Mileto, brought the issue to CERT/CC. After reviewing documentation and engaging Imprivata support, CERT/CC wrote that “no supported mechanism exists to rotate this RSA key pair after deployment.” Changing a certificate while retaining the same private key leaves its holder able to present the trusted appliance identity.

Key copies extend the risk

CERT/CC names three ways someone could obtain that key: exfiltrating a backup, taking a hypervisor snapshot, or gaining privileged access to the appliance filesystem. With the private key, an attacker could impersonate the appliance to an endpoint that trusts its certificate and intercept authentication traffic for applications it brokers, including EHR credentials, SSO tokens and session assertions. If a connection lacks perfect forward secrecy and its traffic was captured, key compromise could also expose earlier sessions.

CISA’s enrichment in the CVE record marks exploitation “none.” CERT/CC supplies no key-theft indicator or appliance-impersonation signature; look at access to the places where private-key copies can reside when deciding whether a particular deployment needs incident response.

Protect copies and map trust

Identify appliances on 26.2.6 or earlier and the clinical workstations, EHR systems and shared devices that trust their certificates. Then restrict appliance administrator and filesystem access, and limit who can read or export backups and hypervisor snapshots. Review existing access records for those stores and the appliance’s privileged accounts, especially around any unexplained snapshot or backup export.

CERT/CC also recommends enforcing perfect forward secrecy on upstream connections, which limits retrospective decryption if captured traffic and a private key meet later. It does not remove the key from a stolen backup. If key exposure is suspected, preserve the access evidence and plan appliance redeployment with Imprivata and the teams responsible for trusting endpoints. CERT/CC says redeployment is the available way to replace a compromised appliance identity while supported key rotation is absent.

CERT/CC says Imprivata is aware of the issue and reportedly working toward a resolution; its vendor table contains no Imprivata statement. If Imprivata issues fix instructions, check whether they replace the RSA key pair; a certificate renewal with the same key leaves the exposure intact.

Confirm the key-copy owners

Scope the affected EAM appliances and their trusting endpoints, tighten privileged appliance access and backup/snapshot permissions, and confirm that upstream sessions negotiate perfect forward secrecy. Check the actual access-control entries on the appliance and backup stores with their owners. The expected result is a named, authorized set of key-copy holders and a documented redeployment path if a copy is unaccounted for. The certificate can look current while its underlying private key remains unchanged.