Imprivata Security: Configure Badge Tap SSO, EPCS Workflows and Admin Roles

In a hospital that uses Imprivata, a badge tap at a shared workstation can open a clinician's Windows session, the clinical applications behind it and, with a second factor, the signing step for a controlled substance prescription, so the customer-side settings behind that tap carry real clinical and regulatory weight. Imprivata now documents the product formerly called Imprivata OneSign as Imprivata Enterprise Access Management, with the former Imprivata Confirm ID as Enterprise Access Management for MFA. This guide covers how to configure it securely: delegated administrator roles, the Appliance Console, user and computer policies, proximity card enrolment, workflow policies for EPCS and clinical signing, API access, logging and a hardening baseline. It is for identity engineers, clinical application teams and security staff running Imprivata in healthcare. The sector-wide picture is in the Healthcare Identity Security Guide.

This is an independent guide from NHI Mgmt Group, based on Imprivata's public documentation as of November 2026. It is not sponsored or reviewed by Imprivata. Product features change, so confirm settings against Imprivata's current documentation.

Key takeaways

• Scope every administrator. Keep the built-in Super Administrator role for at least two named people per site or region, and give everyone else a subordinate role limited by operation and by domain, OU or site.
• Require secure cards at the endpoint. Turn on "Require use of secure proximity cards" in computer policies so readers accept only encrypted MIFARE DESFire cards (Smart Prox).
• Keep two factors genuinely two. In the workflow policy, never allow a single-factor method that duplicates one factor of a two-factor method, or two-factor authentication is not enforced.
• Close the Appliance Console when it is not in use. It is enabled by default; disable it per appliance and keep its separate credentials in a privileged access vault.
• Disable leavers in both places. Disable the Active Directory account and the Imprivata account; Super Administrator accounts are not disabled by synchronisation and must be removed by hand.

How identity and access work in Imprivata

Imprivata Enterprise Access Management runs on a set of Imprivata appliances that form an enterprise, with an agent on each Windows endpoint, thin client or virtual desktop. Users are synchronised from your directories (domains); there are no user accounts in a fresh install. Two policy types then decide how people authenticate.

Badge tap and proximity cards

Imprivata documents secure proximity cards as MIFARE DESFire EV1, EV2 and EV3, which use encrypted card communication; authentication with them is called Smart Prox. To use them:

1. Enable Proximity Card in the relevant user policy.
2. If your cards use non-default DESFire master keys, add them under the gear icon > Settings > Proximity cards (16, 32 or 48 hexadecimal digits, one per line). Use the default key only if your cards actually use it.
3. In each computer policy, under Card Readers, turn on Require use of secure proximity cards.
4. Plan for the documented behaviour: offline authentication is not available with secure cards, and grace periods apply only when the first authentication used Smart Prox, so plain proximity users are asked for a second factor on computers that require Smart Prox.

Badges carrying both FIDO2 and DESFire run as FIDO2 by default. For FIDO2 background see the FIDO2 and WebAuthn Internals Guide.

Card enrolment controls

• Self-enrolment: under Devices > Proximity cards, select Enforce self-enroll setting. Users can then self-enrol only cards that are listed, Available and marked Allow Self-enrollment; only the Super Administrator can allow self-enrolment.
• Card number rules: under Proximity card rules, add Allow list or Deny list ranges so only your organisation's card ranges can be enrolled. Rules apply at enrolment only, not to cards already enrolled.
• Pre-enrolment: assign cards with Change Assignment or a CSV import. After a CSV import, review card counts per user against the limit set in user policy.
• Lost or returned cards: unassign the card or delete the user's proximity card enrolment data, and keep Enforce self-enroll setting on so deleted cards cannot be re-enrolled by someone else.

Admin roles and privileged access

Imprivata has two consoles with separate credentials. The Admin Console manages users, policies, SSO and reports; the Appliance Console manages individual appliances (system, network and security settings, upgrades, logs and joining or removing appliances).

Delegated administration in the Admin Console

The only built-in role is Super Administrator, which cannot be edited or deleted and can do everything enterprise-wide. Subordinate roles combine operations (what an administrator can do, grouped as System, Policies, Users, Reports, Tokens, SSO and MFA) with scope (users limited by domain and OU, computers limited by Imprivata site). Roles can inherit from a base role, so later changes to the base flow down.

Imprivata's security considerations treat these as the most sensitive operations: assigning Super Administrator, granting Admin Console access, directory synchronisation, and deleting a domain (which removes all its user records and stored application credentials). Restrict them to the smallest group, and record who holds them.

1. Assign Super Administrator to at least two people per site or region, as Imprivata recommends, and to no one else.
2. Require Imprivata ID for Windows Access for administrators and turn off password-only access, following Imprivata's guidance.
3. Base new roles on a site-scoped role when scope may change, or on an operation-based role when duties may change.
4. Store Appliance Console credentials in a privileged access management vault with strong passwords, change key administrator passwords the day an IT administrator leaves, and log out of both consoles after use. See the Privileged Access Management Guide.
5. Disable Appliance Console access on each appliance when it is not needed (from the VM console menu, Enable/disable Appliance UI); re-enable it for restaging or upgrades. The setting is per appliance, not global.

Integrations, API tokens and service accounts

Several non-human identities sit behind an Imprivata deployment and need owners, least privilege and credential rotation. See the Service Account Security Guide.

• Directory synchronisation accounts: the accounts Imprivata uses to read your domains. Give them read access to the user OUs in scope, connect over SSL, and track them in your service account inventory.
• ProveID Web API and ProveID Embedded: third-party products such as thin clients and clinical devices integrate through the gear icon > API Access page. Enable access per product rather than with the global option, and review the enabled list when products are retired.
• ID token servers and RADIUS: external OTP token servers and RADIUS integrations require shared configuration on both sides. Keep shared secrets in a vault and restrict which appliances the token server trusts.
• SSO application profiles and credential stores: the SSO operations include shared credential stores and provisioning adaptors. Limit the Application Profile Creator role, and restrict who may maintain multiple accounts for an application, as Imprivata advises.
• Temporary workers and vendors: place non-domain users in an Imprivata Directory Domain with their own user policy; use temporary codes with a maximum expiry of 14 days, block them from enrolling authentication methods, and set vendor accounts to expire automatically.

EPCS and clinical workflows

Workflow policies define which methods satisfy each workflow. Imprivata lists EPCS desktop and mobile authentication, EPCS access control, e-prescribing of non-controlled substances, different user authentication, regulated and non-regulated user verification, medical device log in and remote access log in. For EPCS desktop signing, Imprivata documents two-factor combinations such as fingerprint plus network password, fingerprint plus Imprivata ID, fingerprint plus OTP token, network password plus Imprivata ID, and OTP token plus network password.

• Identity proofing: required before DEA-regulated workflows. Organisations with an institutional DEA number can proof internally with Enrollment Supervisors; others use a certificate authority.
• Supervised enrolment: enrolment supervisors witness and attest to enrolment of fingerprints, facial biometrics, OTP tokens and Imprivata IDs.
• State rules: select your state under State-specific regulations so the page flags methods your state does not allow; remove flagged methods before saving.
• Grace periods: optional grace periods of up to 24 hours 59 minutes let users skip the second factor after card or fingerprint authentication. They do not apply to EPCS workflows; keep them short elsewhere.
• Separate policies: keep signing policies in their own user policies and associate only the clinicians who need each workflow.

The regulatory background is in the DEA EPCS Rules.

Logging and detection

Three log sources matter. The Appliance Console holds Imprivata server logs (HTTP access and error, user directory, RADIUS, fingerprint) and appliance logs (Appliance Console HTTP access, syslog, backup, replication); the console shows only the most recent 10,000 entries, so forward them. Set the syslog server under the Appliance Console System > Logs tab (it defaults to localhost) and use Test to confirm delivery. In the Admin Console, enable Post Heartbeat Info and System Status to Syslog, use reports and Audit Records for administrative and authentication history, and choose the Export to syslog action on event notifications you want in the SIEM. Schedule audit log backups on the Settings page.

Metrics that show the configuration is holding: share of endpoints whose computer policy requires secure cards; number of Super Administrators per site (target two); share of administrators using Imprivata ID rather than password-only; time from HR leaver event to Imprivata account disablement; share of syslog sources reaching the SIEM; and count of vendor accounts without an expiry date (target zero). See the SIEM Log Source Onboarding Checklist.

Hardening baseline

Introduce changes in pilot units before hospital-wide rollout, because a mistaken computer or workflow policy can stop clinicians signing in.

1. Platform resilience: add a second appliance immediately after the first, as Imprivata instructs, schedule audit log backups, and apply Imprivata upgrades promptly through the Appliance Console.
2. Administration: build the delegated role model, enforce Imprivata ID for administrators, vault console credentials and disable Appliance Console access by default.
3. Endpoints: remove local administrator and root rights from end users, protect the registry and Imprivata folders, and set inactivity detection under 15 minutes in shared areas, with Secure Walk Away where it fits. See the Kiosk and Shared Device Security Guide.
4. Cards: move to DESFire cards, add master keys, enforce self-enrolment controls and card range rules, then turn on the secure card requirement unit by unit. Roll back by switching the computer policy setting off for that unit.
5. Workflows: configure EPCS and clinical workflows with state rules selected and no duplicated single factors; test signing in each clinical application in a test environment first.
6. Self-service and remote access: if self-service password reset is reachable externally, allow HTTPS only to the documented URLs and ports; require two-factor for Remote Access and a VPN for offsite staff.
7. Lifecycle: disable leavers in Active Directory and in Imprivata the same day; where sync runs hourly or less often, disable manually; have users report lost devices within 24 hours and delete their Imprivata ID enrolment.

Common misconfigurations

• Duplicated factor in a workflow: allowing Imprivata ID alone alongside Password plus Imprivata ID means users can complete the workflow with one factor.
• Secure cards issued but not required: DESFire cards are rolled out, but computer policies still accept plain proximity cards, so older badges keep working.
• Open self-enrolment: without Enforce self-enroll setting and card range rules, any compatible card can be enrolled to an account.
• Super Administrator accounts at departure: remove or disable Super Administrator accounts by hand as part of leaver processing, as directory synchronisation leaves them in place.
• Appliance Console always on: console access left enabled on every appliance with a shared password kept outside a vault.
• Long-lived vendor access: temporary codes or vendor accounts with no expiry, sitting in the same user policy as staff.

Practitioner checklist

• Limit Super Administrator to two named people per site or region and scope every other role by operation and by OU or site.
• Enforce Imprivata ID for Windows Access for administrators with password-only access off.
• Vault Appliance Console credentials and disable console access when not in use.
• Require secure proximity cards in computer policies and configure DESFire master keys.
• Turn on Enforce self-enroll setting and card range allow lists.
• Review every workflow for duplicated single factors and select state-specific regulations.
• Keep EPCS signing in dedicated user policies with supervised enrolment and identity proofing.
• Enable API access only for named products and review the list quarterly.
• Forward appliance syslog and event notifications to the SIEM and back up audit logs.
• Disable leavers in Active Directory and Imprivata the same day, and expire vendor accounts automatically.

Standards and references

• Imprivata: Enterprise Access Management Security Considerations
• Imprivata: Administrator Roles (Delegated Administration)
• Imprivata: The Imprivata Appliance Console
• Imprivata: Secure Proximity Cards
• Imprivata: Managing Proximity Cards
• Imprivata: Configuring the Workflow Policy
• Imprivata: E-Prescription of Controlled Substances
• Imprivata: OneSign Syslog Reference Guide

Related NHI Mgmt Group resources: Healthcare Identity Security Guide · DEA EPCS Rules · Kiosk and Shared Device Security Guide · Privileged Access Management Guide · Service Account Security Guide