What unique user identification requires and why shared logins fail
Your auditor wants proof that every person who can open ePHI has a unique name or number of their own, so that any read, change or deletion can be traced to one individual. The required specification in 45 CFR 164.312(a)(2)(i) asks for exactly that: a unique identifier assigned to each user, which the rule defines as a person or entity with authorized access (45 CFR 164.304). Shared logins, generic accounts such as a front-desk or billing login used by several staff, and accounts reused after a departure all break this link. When an incident occurs, the log shows a credential rather than a person, and the organization cannot show who had access or limit the investigation to specific people. The specification is required, not addressable, so the question is not whether to implement it but how completely you can demonstrate it.
The hard part is usually not the policy but the exceptions. Legacy clinical or billing applications may have only a local admin login that many staff share. Service accounts used by interfaces, backup jobs or integration engines run under one identity with no human owner. Contractors and locum staff may be given copies of an existing login instead of their own account. Before you plan any fix, inventory every system that stores or displays ePHI and list each account on it, marking which are personal, which are shared and which are non-human. For each shared or service account, record the business owner, the people who know the credential and the reason it cannot be replaced. That inventory is the first document an assessor will ask for, and it shows where to start.
Where a system cannot support individual logins, the practical options are to put it behind an identity provider or access proxy that authenticates each person before the shared application is reached, to move the application onto directory-managed accounts, or to retire it. Open-source identity services such as authentik, FreeIPA and Keycloak can federate sign-in to applications and draw users from an existing directory, and midPoint can provision and remove accounts on connected systems as roles change. Confirm with each vendor whether a given application can accept delegated sign-in or directory-managed accounts before you commit to a design, and ask your compliance lead to record any residual shared account as a documented risk decision in the risk analysis.
Which systems, accounts and people unique user identification covers
Unique user identification applies wherever a person or entity holds authorized access to ePHI, which reaches further than the main clinical application. The cards below set out the scoping decisions that change the work most, so the organization can draw its boundary before it assigns a single identifier.
ePHI applications and databases
Start with every application, reporting tool and database that stores, displays or processes ePHI, including vendor-hosted ones. Each one needs its own record of who holds an account, and shared database logins used by an application server count as a scoping decision you must document. Check whether reporting exports and analytics copies also expose ePHI, because those access paths often sit outside the main system inventory.
Operating systems and jump hosts
Servers, workstations and jump hosts that reach ePHI systems are part of the same question, because an administrator who logs in to a database host is still a user of that environment. Confirm that local accounts on Linux and Windows machines map to named individuals rather than generic names such as admin or ops. Privileged access paths deserve the closest review, since one shared root login can hide who made a change.
Workforce and contractor users
Employees, locum staff, temporary workers and contractors all qualify as users when they hold authorized access. The identifier should follow the person through the account lifecycle, so a contractor who returns for a second engagement keeps a traceable identity rather than receiving a fresh generic login. Confirm with HR and procurement how contractor identities are created, reviewed and removed.
Third parties and business associates
Vendors, business associates and their subcontractors that sign in to your systems to support ePHI are users under your risk analysis, even when their staff are not on your payroll. Ask each third party whether it issues named accounts to its own staff, or whether it shares one login across a support team. Your business associate agreement and access records should show which entity holds each identity.
Service accounts and automated processes
This is the decision that changes the work most. Integrations, batch jobs and API clients act on ePHI, and whether they count as users depends on how your organization reads the definition of user in 45 CFR 164.304, which covers a person or entity with authorized access. Many organizations give each automated process its own named identifier with a documented owner, but you should confirm the reading with counsel and your risk analysis against your own environment.
How unique user identification differs from authentication and access control
Unique user identification answers one question: which individual did this? Under 45 CFR 164.312(a)(2)(i), each person or entity with authorized access to systems holding ePHI must be assigned a unique name or number so that their activity can be tied back to them. The specification is about identity assignment and traceability. It does not decide who should get access, and it does not prove that the person typing is who the identifier says they are. Those jobs belong to other requirements. Access control under 164.312(a)(1) decides what each identity may reach, emergency access under 164.312(a)(2)(ii) governs how ePHI is obtained in a crisis, and person or entity authentication under 164.312(d) verifies that a claimed identity is genuine. All three depend on unique identifiers. Without one, an access rule cannot be applied to a specific person and an authentication check has nothing to bind to.
A reader who confuses these requirements often assumes a strong password fixes the problem. It does not. Suppose a clinic's billing workstations all sign in to one shared account with a long, rotated password (illustrative). Authentication may be strong, because the password is hard to guess, yet the specification still fails. Every login looks identical in the audit trail, so when a record is altered, the organization cannot say which employee did it. Shared accounts also make access reviews and termination of a single person's rights nearly impossible. The reverse failure is just as common. A unique ID with no authentication, such as a directory entry whose password is blank or never enforced, meets the naming requirement on paper but leaves the account open to anyone who knows the name. Assessors look for both properties together, so confirm in your environment that every ePHI system maps each login to one person, that the identifier is not reused, and that authentication actually gates it.
The practical check is to trace one ePHI action back to a named individual. Pick a record access or change in each ePHI system and ask whether the log shows one identifier that maps to one person in your identity source. Confirm how the identifier is created, who approves it and how it is retired when someone leaves. Identity platforms can help here. For example, authentik can act as an identity provider that applications delegate sign-in to, Keycloak can federate accounts from an existing LDAP or Active Directory server, and midPoint can create, update and remove accounts on connected systems from role assignments. Those tools manage identifiers and their lifecycle, but the organization still owns the policy, the approval steps and the evidence. For the rule text and the NIST mapping of this specification, the 45 CFR 164.312 section on eCFR(2)(i)) is the next read.
How an assessor tests unique user identification
This table lists the steps an assessor typically takes to test unique user identification, what each step samples, the evidence requested and the findings that come up most often. Read it as a checklist of the entity's own records, since a single account outside the inventory can be enough to produce a finding.
| Test step | What the assessor samples or inspects | Evidence requested | Common findings |
|---|---|---|---|
| Build the ePHI system inventory | Every application, database, server, and device that creates, receives, stores or transmits ePHI, compared with the entity's risk analysis | Current system inventory with owners and the ePHI each system holds | Systems missing from the inventory, so their accounts are never reviewed |
| Reconcile accounts against the workforce roster | Active accounts on each ePHI system matched to current employees, contractors and business associate personnel with authorized access | Account exports from each system and the HR or contractor roster for the same date | Accounts with no matching person, or people with access who are absent from the roster |
| Test for shared or generic accounts | Logins such as admin, front desk, clinic or vendor names, and any credential used by more than one person | Account listings, password vault entries for shared credentials, and login logs showing which individual used each account | Shared logins on clinical or billing applications, and shared administrator credentials on servers |
| Review service account ownership | Non-human accounts used by applications, scripts, interfaces and integrations, and the named person or team responsible for each | Service account register with owner, purpose, systems touched and last review date | Service accounts with no owner, or used interactively by staff who sign in with them |
| Check termination and reuse of identifiers | Accounts of former workforce members and whether their identifiers were disabled, removed or reassigned to someone else | Termination tickets, disable timestamps and a sample of recent leavers traced to their accounts | Disabled accounts still active, or a retired username reissued without clear history |
| Trace identifiers through directory and provisioning | Whether accounts come from a central directory or are created by hand on each system, and whether changes flow through consistently | Provisioning workflow records, directory configuration and any reconciliation reports | Local accounts created outside the directory with no matching record elsewhere |
| Examine documented exceptions | Any approved exception to individual accounts, such as a legacy system that cannot support unique logins, and the compensating controls recorded for it | Written exception with risk acceptance, compensating controls, owner and review date | Exceptions that were never approved, have expired, or lack a stated compensating measure |
| Confirm the entity's own records are the basis | Whether the entity's inventory, roster and account records agree, and whether the assessor can reproduce results from them | Records the entity produced for the assessment, not summaries prepared only for the assessor | Conflicting records between the inventory, the roster and system exports, which weaken the whole test |
Implementing unique user identification in five steps
This sequence turns the requirement for a unique name or number per user into a working set of inventories, identifier rules, federated sign-in, documented exceptions and account reviews that an assessor can trace from a user back to a person.
Inventory every system that holds or reaches ePHI
Start by listing each application, database, server, workstation population, network device and administrative console that stores, processes or provides access to electronic protected health information. Include systems run by business associates and cloud services, and record who owns each one. The output is an ePHI system inventory with an owner and an access method for every entry. The step is done when the security official and system owners agree that no ePHI path is missing from the list, which is also the input the risk analysis needs.
Define the identifier standard
Write a short standard that sets the format of user identifiers, such as a naming pattern tied to the workforce member's legal or HR identity, and states that each identifier is unique across all ePHI systems. Include rules for reuse after a person leaves, handling of name changes, and which identifier is used for non-human accounts such as service accounts. The output is a signed identifier standard approved by the security official. The standard is complete when every system owner can point to the rule that governs their accounts.
Connect applications to one identity source
Map each ePHI system to a single authoritative identity source, such as a corporate directory, and configure sign-in so applications delegate authentication to it. Open-source options such as authentik, FreeIPA, Keycloak with directory federation, and midPoint for provisioning can each play a part, but the choice depends on your existing directory and applications, and should be confirmed in a proof of concept. The output is a federation map showing each application, its identity source and its sign-in method. The step is done when a test user's activity in each application can be traced to one account.
Eliminate or document shared and generic accounts
Find every shared, generic or group login that touches ePHI, including accounts used by clinical or front-desk teams and default administrator accounts. Replace each with individual accounts where the application allows it. Where a shared account cannot be removed, record it in an exception register with a named owner, the business reason, the users who know its credentials, and the compensating controls such as restricted workstations, session logging and credential rotation. The output is an exception register that the risk analysis and periodic review can reference. The step is done when no shared account remains without an approved entry.
Set up review of new, changed and removed accounts
Define a joiner-mover-leaver process that records every account creation, role change and removal, and assigns each action to a request, an approver and a completion date. Use provisioning tools where they fit, or a documented manual workflow where they do not. Schedule periodic reconciliation between the identity source and each ePHI system to catch accounts that drifted out of step. The output is a joiner-mover-leaver record for each event and a reconciliation report. The step is done when a sample of recent hires, transfers and departures can be traced from the request to the disabled or updated account in every connected system.
What evidence shows every ePHI user has a unique identifier
Assessors test unique user identification by tracing accounts from each system back to a named person, then checking that exceptions are controlled. The cards below are the artifacts that let you show that chain without rebuilding it during the audit. Your organization owns the control; the cadences shown are starting points to confirm against your own risk analysis.
Account exports matched to the HR roster
Export the user list from every system that stores or displays ePHI, including the EHR, billing, imaging viewers, file shares and admin consoles. Match each account to a current employee, contractor or authorized entity in the HR or contractor roster, and record accounts with no match. Assessors often start here because one orphaned account can undermine the whole control. Refresh the exports at least quarterly and before any assessment, and confirm the cadence against your risk analysis.
Written identifier naming standard
Document the rule that generates every user identifier, such as a pattern built from legal name or employee number, and state who may create identifiers and how duplicates are resolved. The standard shows the identifier is unique by design, not by accident. Include how identifiers are reused after a person leaves, since reuse can break attribution in old logs. Review the standard when the directory or identity provider changes, and at least annually.
Shared account exception register
List every account that more than one person uses, with its system, business justification, named owner and the compensating controls in place, such as individual sign-in to the shared account followed by logging of the session. Shared accounts are the main gap this specification is meant to close, so the register should be short and reviewed. Each entry needs a review date set by your risk analysis. Confirm with your security official that each exception has been assessed and documented.
Joiner, mover and leaver tickets
Keep tickets showing when each account was created, when access changed after a role move, and when it was disabled after departure. Each ticket should name the approver and the system changes made. Tickets prove that identifiers are issued through a controlled process and retired when a person no longer has authorized access. Sample a set of tickets each quarter and check that each account traces to one ticket, and confirm the sample size with your auditor or consultant.
Quarterly access reviews
Record a review in which the owner of each system confirms that every listed account and its rights are still needed. Reviews catch identifiers that survived a departure or that belong to accounts no one can explain. Keep the signed review, the list reviewed, and the removals made afterward. Quarterly is a common cadence, but your risk analysis sets the frequency, so confirm it there and document the reason for any longer interval.
Log sample tracing one identifier to one person
Pick several identifiers and show that each one appears in audit logs with activity that maps to a single named individual across systems. Include a sign-in event, a record access event and a logout, and confirm the same identifier resolves in the directory. This shows the identifier does its job of tying activity to a person. Run the trace before each assessment and after any identity system change, and keep the query and output so the result can be repeated.
What unique user identification costs in money and effort
This table breaks down the money and effort behind assigning unique user IDs under 164.312(a)(2)(i), showing who is paid, whether each cost is one-time or recurring, what drives it, and how to reduce it. Use it to frame a fixed-scope quote, since no figures are published here and the largest drivers are usually internal engineering and account cleanup rather than licenses.
| Cost component | One-time or recurring | What drives it | How to reduce it |
|---|---|---|---|
| Identity tooling and licenses | Recurring if commercial, one-time setup | Number of users, applications and directories connected; vendor support tier | Self-hosted open-source identity providers such as authentik, FreeIPA or Keycloak remove license fees but not operating or engineering cost |
| Engineering time to federate applications | One-time, with later changes | Count of ePHI applications, protocol support (OIDC, SAML, LDAP, RADIUS), custom or legacy apps without modern sign-in | Prioritize apps holding ePHI, reuse one provider for common protocols, and document each integration in writing |
| Inventory and cleanup of legacy and shared accounts | One-time, plus periodic reviews | Number of shared logins, generic service accounts, orphaned accounts and undocumented ePHI systems | Build an account inventory from the directory and application logs, then retire or re-assign shared accounts before federation |
| Directory and lifecycle automation | One-time build, recurring upkeep | Number of joiners, movers and leavers, and the rule set for inbound and outbound account changes | Use provisioning tools such as midPoint to create and remove accounts from role assignments, so manual steps shrink over time |
| Evidence upkeep | Recurring | Frequency of access reviews, log retention, and changes to user records and their approvals | Automate exports of user lists and access logs, and keep a dated record of each review and who signed it |
| External review or testing | Periodic, scope-dependent | Whether a third party tests identity flows, account enumeration or access paths, and how many applications are in scope | Agree a written test scope that covers the ePHI applications first, and ask for written findings and retest terms |
| Auditor or assessor sampling time | Recurring per assessment | Number of user IDs sampled, quality of the account inventory, and whether shared accounts exist | Keep one authoritative list of users and their identifiers so samples can be traced quickly without manual reconciliation |
Which self-hosted open-source tools can assign and synchronize unique identities
Unique user identification depends on where accounts are created, how applications sign users in, and how account lifecycles are kept aligned with the people who hold them. The four tools below cover different parts of that chain, so most organizations will pick one or two based on their directory and application estate.
authentik for delegated sign-in
authentik acts as an identity provider that applications delegate sign-in to, using OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers. Each user signs in with an individual identity, which lets you tie ePHI application activity to a named person rather than a shared login. Check which of its provider types your ePHI applications support, and confirm that every application is configured to require individual sign-in with no leftover shared credentials. Test this against your own applications before relying on it.
FreeIPA for Linux and UNIX sign-on
FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. For systems that hold or process ePHI, it gives each administrator and service user a unique principal rather than a shared root or generic account. The licence is GPL-3.0-or-later. Confirm that your server estate, hosts and clients can join the realm, and check how privileged accounts are created and retired.
Keycloak for directory federation
Keycloak's user federation connects to existing LDAP or Active Directory servers and synchronizes users from them into Keycloak. Accounts managed in the corporate directory are then used for application sign-in, so one identity record drives access across applications. The licence is Apache-2.0. Confirm that your directory holds a unique attribute for each person, and test how federated accounts behave when a user is disabled in the source directory.
midPoint for account lifecycle
midPoint creates, updates and deletes accounts on connected systems based on user changes and role assignments. It keeps them aligned through provisioning, live synchronization, scheduled reconciliation and discovery, using separately defined inbound and outbound rules. This matters because orphaned or duplicate accounts are the usual way unique identification breaks down over time. The licence is EUPL-1.2+. Confirm which target systems have connectors for your environment and how reconciliation reports exceptions.
Who owns unique user identification and what a partner can take on
Your organization owns the control. The Security Rule requires a covered entity or business associate to assign a unique name or number to each user with authorized access to ePHI, and that obligation sits with you, not with a vendor or consultant. Your team decides the identifier standard, approves any exception to it, and runs the access reviews that show each account still belongs to a person who needs it.
- Identifier standard: Define the format for user IDs, the rules for retiring them, and how a returning or renamed workforce member keeps or loses an identifier.
- Exception approval: Decide, in writing, whether any non-personal account, such as a service account or a legacy system login, may exist, who is accountable for it, and how its use is monitored.
- Access reviews: Schedule and perform reviews that compare active accounts against current staff and contractors, and record what was removed or changed.
- Policy and documentation: Keep the written policy and the risk analysis entries that explain how identification ties to the systems holding ePHI.
- Ownership of outcomes: Name the person accountable to leadership for the control, even when technical work is outsourced.
Confirm that your policies name a single accountable owner and that your HR offboarding process feeds directly into account deprovisioning.
An implementation partner prepares systems and evidence. It can inventory the applications and servers that hold ePHI, connect them to a central identity source, configure the open-source tools that issue and manage identifiers, and remove or convert shared accounts. The partner works inside your infrastructure and to a written scope. It does not attest to compliance, does not issue a report or certificate, and cannot decide on your behalf whether a risk is acceptable.
- System inventory: List every application, database, and administrative console that authenticates users to ePHI, and record which ones still use local or shared logins.
- Federation: Connect applications to a central identity provider, such as authentik, Keycloak with directory federation, or FreeIPA, so sign-in traces back to one identifier per person.
- Provisioning configuration: Set up tooling such as midPoint to create, change and remove accounts from role assignments and synchronization rules.
- Shared account cleanup: Work with application owners to replace shared logins with individual accounts and document any remaining exception for your team to approve.
- Evidence preparation: Produce configuration records, account exports and change logs that your team can review and that an assessor can sample.
Ask any partner to state in the written scope which items it configures and which items remain your responsibility, and confirm that it will not sign or present a compliance statement on your behalf.
An independent auditor, assessor or certification body tests the control and issues any report. Its role is to sample accounts, compare them against authoritative records, and judge whether the control operates as your organization describes it. An auditor cannot design the controls it tests, because doing so would remove the independence that makes its conclusion useful. HHS does not endorse or recognize private certifications, so any outside assurance is evidence for your own risk analysis, not a HIPAA certificate.
- Sampling: Select user accounts from the systems that hold ePHI and trace each one to a named person with a documented need for access.
- Shared account testing: Look for generic or group logins and check whether each has an approved exception with an accountable owner.
- Record comparison: Match active accounts against HR and contractor records to find orphaned or stale identifiers.
- Reporting: Issue any report or conclusion in its own name, describing what it tested, what it sampled and what it found.
- Independence: Keep the auditor separate from the team that configured the systems it is testing.
Before engaging an assessor, confirm its scope in writing, the sample method it will use, and whether it will test the operating effectiveness of the control over a period or only as of a single date.
Questions buyers ask about unique user identification before hiring help
Is a shared account ever allowed for accessing ePHI?
In practice, no. The unique user identification specification in 45 CFR 164.312(a)(2)(i) is a required implementation specification, and it asks that each user be assigned a unique name and or number so that identity can be tracked. A shared login such as a generic clinic account makes it impossible to tie a given action to a person. Where a break-glass or emergency pathway exists, it is handled under a separate emergency access procedure, and that procedure should still record who used it and when. Document any exception with a risk analysis, the approver and the compensating controls, and confirm the position with your privacy or compliance counsel, since the rule itself does not list permitted exceptions.
How long does it take to assign unique user IDs across our systems?
The duration depends on how many systems hold ePHI, how many accounts already exist and whether identities already come from a central directory. Work usually starts with an inventory of applications, shared accounts and service accounts, then moves to mapping each account to a named person and retiring or converting the shared ones. Organizations with Active Directory or LDAP often finish faster because an identity source already exists. No fixed duration applies to every environment, so ask for a timeline in the written scope after the inventory is complete, and confirm which systems are in it.
What does our staff need to provide for this work?
The work depends heavily on people who know the systems. Plan for named owners of each application and directory, someone who can approve account changes, and access to administrator accounts for the systems in scope. Compliance or privacy staff should confirm which workforce roles need ePHI access, since that determines who should hold a unique account. Clinical or operational leads usually need to validate that a shared workflow can be replaced without disrupting patient care. Ask your implementation partner to list these roles in the written scope before work begins.
Can our internal team do this without an outside partner?
Yes, many organizations do this in house, especially where the identity directory is already mature. The main questions are whether your team has time to inventory every ePHI system, whether it can change applications that still use shared credentials, and whether it can document decisions in a form an assessor will accept. An outside partner can prepare the identity architecture, integrate applications with a directory and produce the account evidence, but the organization still owns the policy, the risk decisions and the workforce records. A third-party assessment can test the result, but it does not replace internal responsibility.
What drives the cost of unique user identification work up?
Cost is driven by the number of ePHI systems, the number of shared or service accounts, the state of existing directories and the number of applications that must be reconfigured for individual sign-in. Integrations with legacy systems that lack modern authentication usually take the most effort. Costs are one-time for the initial inventory, mapping and integration, and recurring for access reviews, onboarding and offboarding. Ask any provider for a quote that separates these items, names the systems in scope and states which tasks the client's staff will perform. No cost figure is given here because none was supplied for this requirement.
Does HHS certify that we meet unique user identification?
No. There is no HIPAA certification. HHS has stated that no Security Rule standard requires an entity to certify compliance, that it does not endorse or recognize private certifications, and that such certifications do not prevent it from later finding a violation. Evidence that you assign unique user IDs comes from your own account records, access approvals and logs, and the Office for Civil Rights can review that evidence in an investigation or audit. Any third party that offers a HIPAA certificate should be asked which HHS guidance it relies on and what exactly it tested.
How DeployOpen scopes and prepares unique user identification evidence
DeployOpen plans and implements self-hosted open-source identity platforms inside your own infrastructure so each person and service account that touches ePHI has a unique identifier. We prepare the systems and the evidence, while your organization owns the control, its risk analysis and its policies.
How we scope
- The written scope lists every system that stores or displays ePHI and the account sources that feed each one.
- We inventory existing shared, generic and service accounts so the scope states which ones must be retired or re-assigned.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- We configure the identity provider, such as authentik, Keycloak or FreeIPA, so applications delegate sign-in rather than keeping local accounts.
- Where an existing corporate directory is the source of truth, we connect it through user federation so each person keeps one identifier.
- We test that duplicate and shared logins are blocked and that every ePHI session is traceable to a single named account.
How we hand over
- We document the naming rules, account lifecycle steps and the provisioning and deprovisioning workflow your staff will operate.
- We provide the evidence set: configuration exports, account listings, test results and sample logs tied to individual users.
- Your security official and independent assessor receive the materials, and the organization decides what to accept as sufficient.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can review account reconciliation reports on a recurring basis so new shared accounts are caught before they reach ePHI systems.
- Confirm with us in the scope which support tasks are included and how changes to the identity platform are handled.
