Proximity-based authentication reduces friction because the clinician does not need to stop, unlock a device, and type a code into the EMR. That saves time during prescribing and lowers the chance of user error. The security value comes from combining convenience with a second factor that confirms the user is present and using an enrolled mobile device.
Why proximity changes the clinician experience
Proximity-based authentication reduces the number of steps between a clinician and the task they are trying to complete. Instead of breaking attention to unlock a phone, read a code, and enter it into the EMR, the second factor is satisfied in the background when the enrolled device is nearby. That matters most in time-sensitive workflows where even small interruptions create delays and increase the chance of mistakes.
For clinicians, the friction is not just typing a code. It is the context switch: putting down a chart, finding a phone, waiting for the code, and returning to the record. A proximity flow keeps the interaction closer to normal work patterns, so the authentication step feels like a short confirmation rather than a separate task.
In practice, that is why these systems are usually better accepted at the point of care than one-time codes. They reduce interruption costs while still preserving a second-factor check tied to the user’s present device.
How proximity lowers error and interruption during prescribing
Manually typed token codes create avoidable failure points. Codes can be mistyped, expire before entry, or be entered into the wrong session when a clinician is moving quickly between patients. Proximity-based authentication removes most of that manual handling, so the user is less likely to make a simple input error at the exact moment they are trying to complete a clinical action.
The workflow benefit is especially visible in prescribing and order entry. When authentication is smoother, clinicians are less likely to delay a legitimate task, reattempt sign-in, or work around the control. That lowers the operational drag that often appears when a security step is technically sound but awkward in the middle of care delivery.
At scale, the value is cumulative. A few seconds saved on each authentication event becomes material across repeated logins, session revalidation, and step-up prompts throughout a shift.
Why the security trade-off is still acceptable
Proximity-based authentication is not simply about convenience. It keeps a second factor in place while reducing dependence on user memory and manual code entry. The security posture remains stronger than a password alone because the system still checks that the clinician is present and using an enrolled mobile device, which raises the bar for casual misuse and some forms of remote abuse.
That said, the control is only as strong as the underlying enrolment, device protection, and session handling. A proximity factor should be treated as part of a broader authentication design, not as a standalone guarantee that the right person is always behind the keyboard.
For that reason, the best implementations combine usability with clear device binding, sensible session timeouts, and recovery paths that do not quietly weaken the control when a phone is unavailable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Covers authenticators and phishing-resistant sign-in trade-offs for proximity-based MFA. |
| Recommendation — Use AAL guidance to select a second factor that is strong but low-friction for clinicians. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Clinician sign-in is workforce authentication and access control for user sessions. |
| IA-5 — Authenticator Management | The answer depends on managing typed codes, device-bound authenticators and fallback methods. | |
| Recommendation — Apply IA-2 to require strong user authentication at clinical workstations and EMR sessions. Manage authenticators so proximity can replace manual codes without weakening recovery or rotation. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Proximity authentication is an access-control choice aimed at reducing friction while enforcing entry controls. |
| Recommendation — Define access rules that fit point-of-care workflows and avoid unnecessary login friction. | ||
| OWASP ASVS | V6 — Authentication | The topic is an authentication design choice balancing user experience and second-factor assurance. |
| Recommendation — Require authentication flows that reduce user error without dropping second-factor assurance. | ||
Practitioner Guidance
What to verify: Confirm that the proximity method actually removes the manual code step in the clinical workflow, and that fallback paths do not silently reintroduce weaker sign-in behaviour. If staff still need to type a code frequently, the friction benefit is likely being lost in implementation.
Common mistake: Teams often measure the authentication method only by security strength and ignore workflow latency. In a clinical environment, a control that is secure but slow invites workaround behaviour, repeated prompts, and user frustration that can undermine adoption.
Decision rule: If the goal is to protect frequent logins at the point of care, favour the least interruptive factor that still preserves strong device binding and a clear recovery path. If the workflow depends on shared stations, intermittent connectivity, or unreliable enrolment, the design needs to be tested under real shift conditions before rollout.
Practitioner takeaway: The main advantage is not that proximity is “easier”, it is that it preserves second-factor assurance while removing manual steps that disrupt clinical attention and slow down patient-facing work.
Related resources from NHI Mgmt Group
- Why does proximity-based authentication reduce the friction of traditional OTP flows?
- When does OpenPGP key storage on a hardware token reduce risk compared with software-based key handling?
- Why does webhook-based token enrichment reduce security risk compared with hosted scripts or direct provider-side logic?
- How should security teams reduce the risk of Android banking trojans stealing SMS-based authentication codes?