Single sign-on

SSO centralizes authentication

In a federated design, an identity provider authenticates a person and sends an assertion to a relying application. The application evaluates that assertion and creates a session. The user experiences one sign-in across connected services.

The final NIST federation guideline focuses on identity federation and assertions. It explains roles and technical requirements for federal digital identity. Private practices can use the concepts while selecting protocols and assurance appropriate to their own risks.

SSO does not decide application access

Authentication asks whether the claimant is the identity asserted. Authorization asks what that identity may do. A scheduler, BCBA, biller, contractor, and administrator need different permissions even when all use the same identity provider.

Map each identity attribute and group to application roles. Avoid broad default groups, unreviewed role inheritance, and permanent elevated access. The application remains responsible for enforcing its permissions and protecting each client, report, export, and administrative action.

Build an application inventory

For every application, record:

• owner, vendor, users, data, business impact, and environment
• federation protocol, identity provider, relying-party identifier, and certificates
• MFA and assurance requirements, claims, groups, and role mapping
• joiner, mover, and leaver provisioning plus expected timing
• session duration, reauthentication, timeout, logout, and token revocation
• local, vendor-support, service, and emergency accounts
• logs, alerts, failure route, recovery, and outage fallback

An “SSO supported” feature can mean login federation only. It may leave account creation, role changes, and deletion as manual work.

Connect SSO to the workforce lifecycle

Create access from an approved role and start date. Change it when duties, sites, clients, or employment status change. Remove it promptly when access ends. Reconcile the identity provider, human-resources source, application accounts, privileged roles, and vendor users.

Test deprovisioning. A disabled central account may leave an active local password, API token, remembered session, mobile device, or recovery channel. Record ownership and removal evidence for each path.

Pair SSO with strong MFA

SSO concentrates access and can make consistent MFA easier. It also increases the effect of a compromised central identity. Apply phishing-resistant MFA where supported, especially for administrators, remote access, clinical records, billing, email, and vendor consoles.

The broader NIST Digital Identity Guidelines address identity proofing, authentication, and federation for government systems. Use the assurance concepts as a reference. Choose authenticators, recovery, and exceptions from the practice's actual risk and governing sources.

Control sessions as well as sign-in

An assertion may be valid when the application creates a session, then conditions can change. Define session lifetime, inactivity timeout, reauthentication for sensitive actions, device trust, token storage, logout, and revocation. Test whether central logout ends application sessions and whether a disabled user can continue through an existing token.

Map attribute freshness. A role change at the identity provider may not reach an application until the next login or scheduled synchronization. Decide which changes require immediate revocation. Keep clock synchronization, certificate rotation, signing-key updates, audience checks, and assertion replay protection in the technical test plan. Record failures in language that helps support staff act without exposing sensitive configuration.

A fictional portfolio review

Zainab's practice locks 25 applications for review. Twenty-one have current SSO, MFA, role mapping, provisioning, deprovisioning, session, logging, and emergency-access evidence: 21 of 25, or 84%.

One application keeps local passwords. Two have stale role mappings. One lacks a tested outage path. The four remain visible with owners and age. The percentage measures control completeness, not protection from account compromise.

Plan for failure and emergency access

An identity-provider outage can block every connected application. Define critical applications, minimum safe access, support contacts, recovery authority, and tested local or emergency paths. Limit emergency credentials, store them securely, monitor use, and review every activation.

Avoid creating a universal bypass. Clinical readiness, client safety, documentation, payroll, and payer deadlines may need different downtime decisions. Restore central access and then reconcile activity performed through alternate routes.

Current 45 CFR 164.312 separately addresses access control, audit controls, integrity, authentication, and transmission security for ePHI. SSO can support several controls but does not complete them.

Measure coverage and exceptions

Useful measures include applications with complete lifecycle control divided by applications due, accounts reconciled by date divided by accounts due, access removals completed within target divided by removals due, and exceptions closed by date divided by exceptions due. Report local and privileged accounts separately.

Review after an application, vendor, role, identity provider, protocol, certificate, or workforce process changes. The NIST Cybersecurity Framework offers voluntary outcomes for organizing this work.