Imprivata EAM EUVD-2026-85537

The weakness is inherent to any deployment of Imprivata Enterprise Access Management at version 26.2.6 or earlier that generates X.509 certificates - the product provides no post-deployment RSA key-pair rotation mechanism, so the condition is simply running an affected version over time. Realized harm is strongly limited: there is no described direct attack that leaks data, and impact only materializes if the static private key is separately compromised via theft, insider access, or cryptanalysis over its indefinite lifetime. There is no PoC and no observed exploitation; this is a cryptographic lifecycle deficiency, not a turnkey remote exploit.

This is a low-priority, best-practice cryptographic hygiene finding rather than a directly exploitable vulnerability. All exploitation signals are cold: EPSS is 0.07% (0th percentile), there is no CISA KEV listing, and no public exploit code has been identified. The CISA SSVC decision framework reinforces this - Exploitation is scored 'none' (no observed or PoC exploitation), and although Automatable is 'yes', Technical Impact is only 'partial'. The published CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/C:H = 7.5) appears inflated relative to the described weakness: the CWE-326 issue is that Imprivata EAM cannot rotate its RSA key pair after deployment, meaning a single key is used indefinitely for X.509 certificate generation. This is a latent design deficiency that increases long-term exposure to key compromise or cryptanalysis - it is NOT a standalone remote path that yields confidentiality loss on its own. There is no attacker action described that directly reads data; C:H would only be realized if the fixed key were separately compromised (by cryptanalytic effort or exfiltration over its indefinite lifetime). The AV:N/AC:L/PR:N framing overstates ease relative to that prerequisite. Net: high nominal CVSS but low real-world urgency - remediate as crypto lifecycle hygiene, not as an emergency.

Because Imprivata EAM reuses one RSA key pair indefinitely for certificate generation, an attacker who obtains that private key (through theft, insider access, or long-horizon cryptanalysis) can impersonate the service or decrypt/forge certificates indefinitely, since the deployment provides no mechanism to rotate and invalidate the compromised key. No direct network exploit is described and no public proof-of-concept exists; realized impact depends entirely on a separate key-compromise event that the missing rotation capability makes permanent.