Quick answer
Test authentication as a lifecycle: enrollment, sign-in, authenticator replacement, recovery and session termination. SSO reduces repeated sign-ins but does not automatically make every application session or fallback route secure. Specify the required authentication properties and prove them on each supported access path.
Evaluate the journey behind the sign-in button
A nurse signs into a shared workstation, opens the EHR through SSO, walks to another wing and later uses a tablet. A remote prescriber uses a different device. The same “SSO supported” statement can cover very different session and recovery behavior across those paths.
NIST SP 800-63B-4 distinguishes authentication, authenticator lifecycle and session management. It also explains why manually entered one-time codes are not phishing-resistant. The publication's federal assurance requirements are not automatically a universal SNF mandate; buyers can use its distinctions to specify the security properties their risk assessment requires.
Authentication proves control of credentials. Authorization determines what the authenticated person may do. Keep the staff-role design connected but separate so successful sign-in does not imply correct facility or resident access.
Map the supported paths
List browser, native mobile, remote access, administrative console and any local credentials that bypass the primary identity provider. For each, identify who performs authentication, which factors are accepted, how the application learns the result and which party controls session expiry. Document dependencies on internet access, devices and support staffing.
This original acceptance pack tests more than a successful login:
| Scenario | Observe | Decision supported |
|---|---|---|
| New staff member enrolls | Identity verification, factor binding and first access | Whether onboarding can be operated reliably |
| Shared workstation changes user | Prior session, cached screens and new identity | Whether attribution survives a shift handoff |
| Authenticator is lost | Verification before replacement and old-factor invalidation | Whether recovery creates a weaker entry route |
| Account is disabled centrally | Existing sessions and subsequent sign-ins | Actual containment scope and timing |
| Primary identity service is unavailable | Reviewed emergency process and recorded use | Whether care continuity depends on an untested bypass |
| Privileged action is attempted | Required reauthentication or stronger factor if specified | Whether sensitive actions receive the intended protection |
Use synthetic accounts and an approved test environment. Test behavior, not merely configuration screenshots.
Include recovery in the security claim
A phishing-resistant factor does not make a help-desk reset resistant to impersonation. Establish who can authorize replacement, how the requester is verified, what notifications are sent and when old factors are invalidated. Staff should have an accessible recovery path without sharing credentials or borrowing another person's token.
Consider the real working conditions: gloves, shared stations, unavailable personal phones, agency staff and after-hours arrivals. Assess supported hardware and accessible authentication options. Do not assume that requiring a personal smartphone is operationally or contractually acceptable for every worker.
Measure interruption and revocation explicitly
A fictional test disables an account at 10:00. New sign-ins fail immediately, but a mobile session continues until 10:20. Record both observations and investigate the application's revocation and session design. “Directory disabled” and “all sessions ended” are different states.
Similarly, measure the actual steps needed to change users on a shared workstation. A design that is secure only when staff perform six rarely followed steps may need workflow redesign. Set acceptance criteria through the organization's security and clinical operations review; do not invent a universal session timeout for all SNFs.
Decide what must change before deployment
The final comparison should identify supported factors, local-login exceptions, session behavior, recovery requirements, support coverage and implementation dependencies. Include costs for identity licenses, compatible authenticators, enrollment labor and spare devices where applicable.
A successful purchase decision names which paths are ready, which require local configuration and which remain restricted until tested. It also schedules retesting after identity-provider, application or mobile-client changes. That is a stronger basis for deployment than treating the presence of an SSO logo as proof of a complete authentication design.
Questions & answers
Is every MFA method phishing-resistant?
No. NIST distinguishes phishing resistance from the presence of multiple factors; manually entered one-time codes are not phishing-resistant under its guidance.
Does disabling a directory account instantly close all sessions?
Do not assume so. Test existing EHR sessions, mobile sessions, refresh mechanisms and any local-login routes to establish actual behavior.
Primary sources
Use the cited source and its applicable version when making a facility-specific decision. These guides explain operational evaluation methods; they are not individualized clinical, coding, or legal advice.