Imprivata and Microsoft 365: what works, what doesn't

Imprivata OneSign is the identity and rapid-context-switching layer running on most shared clinical workstations. Any Microsoft 365 file storage layer sitting alongside Imprivata has to match its session model: mount at tap-in, unmount at tap-out, no cross-user residue on the endpoint, fast enough that clinicians do not walk away waiting. The OneDrive sync client does not meet these requirements. This piece walks through what Imprivata expects from a file-storage layer, why the sync client struggles, and how Cloud Drive Mapper aligns with Imprivata's session model.

What does Imprivata OneSign need from a file-storage layer?

The Imprivata pattern is unusual compared to a one-user-one-machine office setup. On a ward PC, a workstation on wheels, or a reception station, a clinician taps a proximity badge and reaches a live desktop in seconds. Another clinician taps in later and gets the same hardware presented as their own workspace. The whole arrangement only holds together if every layer on the endpoint respects the same session model.

In practice, that means a file-storage layer sitting alongside Imprivata has to meet five specific requirements:

Mount at tap-in, fast

A clinician taps in and expects a live desktop within a couple of seconds. Their file storage has to be ready in that window. Anything that needs minutes to bootstrap or reconcile at session start is not a fit.

Unmount at tap-out, cleanly

When the clinician taps out, everything associated with their session has to disappear from the endpoint. No cached files waiting on disk, no lingering credentials, no background processes still trying to reach the tenant on behalf of a user who left.

Per-user isolation

The next clinician who taps in must see none of the previous user's content, none of their history, and none of their search results. This is a hard requirement in HIPAA environments; it is a strong preference elsewhere.

No PHI on the endpoint

Anything cached locally is patient information at rest on a shared device. Most information-governance regimes will not accept it. The safest posture is a storage layer that does not cache at all.

Compatible with the VDI backing

Imprivata frequently front-ends a Citrix, Azure Virtual Desktop, or Omnissa Horizon session that gets delivered on tap-in. Whatever the file-storage layer is, it has to work inside the VDI session it is delivered into.

Why the OneDrive sync client doesn't meet these requirements

The OneDrive sync client was designed for a persistent, single-user Windows machine. Every design decision follows from that assumption. Against Imprivata's requirements, six specific problems show up:

Session-start sync bootstrapping is too slow for tap-in

OneDrive can take minutes to reach a usable state when it starts against a fresh Windows session, especially on a non-persistent VDI host that reset since the user's last login. Clinicians tap in, wait, walk away, tap in somewhere else. The workstation gets a bad reputation and quietly goes out of use.

Local cache persists across tap-out

OneDrive mirrors files locally by design. On a shared workstation, the previous user's cached files are still on disk when the next user taps in. Wipe scripts help but never fully close the window; PHI is at rest on the endpoint for as long as the cache exists.

Search index leaks across users

Windows Search indexes local OneDrive content by default. That index can carry across sessions on a shared endpoint. Nurse A's OneDrive contained patient names; Nurse B searches for something unrelated and hits results from A's files.

Sync-client user model doesn't match rapid context switching

The sync client expects one user per Windows profile. In the shared-workstation environments Imprivata is designed for, the same physical endpoint sees dozens of different user identities across a shift. The sync client's model does not accommodate that gracefully.

Multi-server VDI amplifies every sync problem

When Imprivata front-ends a Citrix, AVD or Horizon estate, the OneDrive sync client running inside those sessions inherits every problem documented in OneDrive for Business in Citrix: container growth, sync loops, cross-host conflicts, uncontrolled auto-updates.

Files On-Demand hydration misses the urgency window

A clinician tapping in to write up an encounter cannot wait for a smart-sync stub to hydrate. If the shift-handover template is not already local, the workflow stalls. The whole point of Imprivata is to remove friction at the workstation; smart-sync latency puts it back.

What are the fix options?

Three approaches. The first two try to make the sync client fit; the third replaces the storage-access layer with something built for this pattern.

Deny the sync client, force browser-only file access

Push clinicians to the SharePoint browser or Teams client for all Microsoft 365 file access. Solves the PHI-at-rest problem; produces poor UX. Adoption suffers, clinicians work around it, files end up in the wrong places.

Configure OneDrive extremely carefully with per-workstation controls and FSLogix

Combine per-workstation OneDrive policy, aggressive cache-wipe scripts on tap-out, FSLogix containers for the sync client state, and profile-management controls to keep search indexes clean. Complex, fragile, and does not fully solve the PHI-at-rest problem because the sync client still caches files locally between the wipe cycles.

Use a drive-mapping approach (Cloud Drive Mapper)

Replace the sync client with a drive-mapping layer that streams file content on demand. No local cache, so no PHI at rest and no cross-user residue. Per-user mount on tap-in, unmounted cleanly on tap-out. Works in the VDI session Imprivata delivers into. This is the approach the rest of this page is about.

How Cloud Drive Mapper works with Imprivata

CDM does not integrate with Imprivata directly. It does not touch OneSign's authentication flow, its badge readers, its policy engine or its reporting. What CDM does is behave the way Imprivata needs a file-storage layer to behave. Five specific alignments matter.

Per-user session mount, triggered at tap-in

When Imprivata authenticates a clinician into their Windows session (whether on a physical endpoint or via a VDI delivery), CDM mounts SharePoint and OneDrive as drive letters as part of that session. The clinician sees their desktop and their drives at the same time.

Mount is fast because there is no cache to bootstrap

CDM does not maintain a persistent local cache. There is nothing to reconcile at session start; CDM authenticates and mounts. This is the specific architectural reason CDM fits tap-in workflows where the OneDrive sync client does not.

Clean unmount at tap-out

When the clinician taps out, the mount goes with the session. No cached content remains on the endpoint, no partially-hydrated stubs, no lingering search-index artefacts.

Per-user isolation is native, not layered on

Each user's mount runs in their own session against their own delegated credentials. Twenty clinicians over a shift means twenty discrete sessions, each with its own view of Microsoft 365 content. There is no shared cache for one user's content to leak through to another.

Works in every VDI backing Imprivata sits in front of

Whether the delivered desktop is Citrix Virtual Apps and Desktops, Azure Virtual Desktop, Windows 365 Cloud PC, Omnissa Horizon, or a direct Windows session, CDM behaves the same way. Because there is no persistent cache, the non-persistent session hosts common in VDI estates hold no special complication.

Imprivata-specific configuration notes

CDM does not require changes to the Imprivata deployment, OneSign policy, or the badge/proximity workflow. A few things to line up on the CDM side:

• Deploy CDM per Windows session, not per machine, so each authenticated user gets their own mount.
• Configure CDM to mount at Windows session start; this fires when Imprivata authenticates the user into the session.
• Map SharePoint document libraries to consistent drive letters (typically M:, N:, P:) so clinicians recognise them across workstations.
• Verify unmount behaviour with a tap-out test on a representative workstation before broader rollout.
• For information governance sign-off, walk stakeholders through the zero-access architecture underpinning CDM: no local cache, delegated permissions to the customer tenant, no IAM Cloud staff access to customer content by design.

CDM supports Imprivata-fronted workflows in the following deployment models:

• Windows desktops (direct)
• Citrix Virtual Apps and Desktops
• Citrix DaaS
• Azure Virtual Desktop (AVD)
• Windows 365 Cloud PC
• Omnissa Horizon (formerly VMware Horizon)

Cloud Drive Mapper is used across healthcare providers to match Imprivata's session model for Microsoft 365 file access on shared clinical workstations.

Frequently asked questions

Does Cloud Drive Mapper work with Imprivata OneSign?

Yes. CDM's per-user mount model aligns with Imprivata's rapid-context-switching workflows. When a clinician taps in with their proximity badge, CDM mounts their SharePoint and OneDrive drives as part of the session; when they tap out, the mount goes with the session. No cross-user residue, no local cache to reconcile.

How fast does Cloud Drive Mapper mount at tap-in?

Fast enough for tap-in workflows. Because CDM does not maintain a persistent local cache, it does not need to reconcile any state at session start; it authenticates and mounts. Clinicians see their drives appear with their desktop, not minutes later. This is the specific reason CDM works in tap-in environments where the OneDrive sync client does not.

Does anything from the previous user's session persist after tap-out?

No. CDM does not cache file content locally. When one clinician taps out, there is no OneDrive-style cache folder waiting on the local disk, no search-index residue, no partially-hydrated stubs. The next user who taps in gets a fresh mount against their own credentials with no visibility into the previous user's content.

Does CDM work on Citrix, Azure Virtual Desktop, and Omnissa Horizon when they sit behind Imprivata?

Yes. Imprivata often front-ends a VDI estate: users tap in at a physical endpoint, Imprivata initiates the VDI session, and the clinical desktop is delivered by Citrix, AVD or Horizon. CDM runs inside the VDI session and behaves the same way it does on a direct Windows desktop. Because there is no persistent cache, CDM is unaffected by non-persistent session hosts.

Does CDM require any changes to the Imprivata deployment?

No. CDM does not integrate with Imprivata directly, does not touch OneSign's authentication flow, and does not require any changes to Imprivata policy or configuration. CDM installs into the Windows session that Imprivata authenticates the user into; the two operate independently.

Is CDM used outside healthcare in Imprivata deployments?

Imprivata is most common in healthcare, but the same shared-workstation and rapid-context-switching patterns exist in some financial-services branch environments, public-safety, and government contexts. The CDM plus Imprivata combination is agnostic to the vertical; the requirements a file-storage layer has to meet are the same wherever tap-in on shared workstations is in play.

Related solutions

• EPIC and Microsoft 365: what works, what doesn't
• MEDITECH and Microsoft 365: what works, what doesn't
• OneDrive for Business in Citrix (the VDI backing most Imprivata deployments sit on)
• Zero-access architecture in Cloud Drive Mapper
• Desktop applications and real file paths
• Cloud Drive Mapper for healthcare
• Case study: Respiratory Health Association

← Back to all solutions