Who Still Has Access?

Consider a routine access review. An organization has 296 workforce members, but one clinical system lists 427 active accounts. Some belong to current employees. Others belong to former interns, vendors, old software, test profiles, and service accounts that no one immediately recognizes.

The report does not prove that a breach occurred. It reveals something more basic: the organization cannot quickly explain who or what still has access.

That question sits at the center of the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Security Rule. Access control is not simply the login screen that appears before someone enters a system. It is the full process for deciding who may reach electronic protected health information (ePHI), what they may do with it, how their identity is verified, and when that access must change or end.

A password can help keep an outsider out. It cannot tell the organization whether an insider still needs every permission attached to the account.

Access control is a living process

Two related HIPAA Security Rule standards work together to govern access to ePHI.

Information access management is the administrative side. It establishes how access is requested, approved, documented, reviewed, and modified. Access control is the technical side. It uses system controls to allow access only to people or software programs that have been granted access rights.^{1, 2, 3}

One decides who should receive the key. The other determines which doors that key can open.

Problems arise when the two no longer match. A manager may approve a narrow level of access, but a system template may grant something broader. A staff member may move to another department, yet retain permissions from the previous role. A vendor's assignment may end while its remote account remains active. A service account may survive long after the software that created it has been removed.

For that reason, access should be treated as a continuing decision, not a one-time event completed during onboarding.

Permission begins before the account is created

A strong access process begins with a business decision, not a technical request that simply says, "Please give this person access."

Before an account is created, the organization should be able to answer:

• Who is requesting the access?
• Who is authorized to approve it?
• Which systems, applications, and information are needed?
• What actions should the user be allowed to perform?
• Is the access permanent, temporary, emergency-based, or vendor-related?
• When should it be reviewed or automatically expire?
• Does the request involve elevated or administrative privileges?

The answers should connect to the person's current responsibilities. Job title alone may not be enough. Two employees with similar titles may work in different locations, support different services, or need different functions within the same electronic health record.

Role-based access can provide a useful starting point, but a standard role should not become an excuse to grant every person the same broad permissions. The template should reflect real work, and exceptions should be approved and documented.

Follow the account through the workforce lifecycle

Access management is often described as a joiner, mover, and leaver process. In healthcare, the lifecycle may also include students, volunteers, temporary workers, contractors, vendors, and workforce members who take extended leave.

The handoff matters. Managers know when responsibilities change. Human resources personnel know when employment status changes. Information technology (IT) personnel manage many of the accounts. Compliance and security personnel help define and monitor the controls. If any part of that chain receives information late, access can remain active longer than intended.

A dependable process therefore needs named owners, defined timing, and a way to confirm completion. "Someone submitted a ticket" is not the same as knowing that access was removed from every relevant system.

Not every account belongs to a person

An access review that looks only at employee names will miss some of the most powerful accounts in the environment.

Privileged accounts may configure systems, create users, change permissions, or bypass ordinary restrictions. Vendor accounts may support maintenance or troubleshooting. Service accounts allow software and automated processes to communicate. Emergency accounts may support access when normal procedures are unavailable.

These accounts may be necessary. They also require deliberate control.

The U.S. Department of Health and Human Services (HHS) warned in a January 2026 cybersecurity newsletter that software may create generic or service accounts with elevated privileges and default passwords. HHS also described how such an account may remain after the software that created it has been removed, leaving behind a pathway that an attacker or malicious insider could exploit.⁴

Organizations should know which nonhuman and privileged accounts exist, why each one is needed, who owns it, what it can reach, how its credentials are protected, and when it was last reviewed. An account without a clear owner is an access-control question waiting for an answer.

Authentication is the front door, not the whole building

Authorization and authentication sound similar, but they answer different questions.

Authorization asks: What is this person or system permitted to access?

Authentication asks: Is the person or system attempting to enter really the identity it claims to be?

The current HIPAA Security Rule requires procedures to verify the identity of a person or entity seeking access to ePHI. Passwords are one method, but passwords can be reused, guessed, stolen through phishing, or exposed in an unrelated breach.

Multifactor authentication (MFA) strengthens the process by requiring more than one form of verification. HHS guidance explains that an organization's risk analysis may determine that MFA is needed to reduce unauthorized-access risk for particular systems. That is different from saying the current Security Rule contains a blanket MFA mandate for every system and situation.^{3, 4}

Even strong authentication cannot correct excessive authorization. MFA may help confirm that the correct employee entered the account, but it does not determine whether that employee should still have access to an old department, an administrative function, or a folder unrelated to current work.

The organization needs both: confidence in the identity and confidence in the permissions attached to it.

What the current technical standard includes

The HIPAA access-control standard contains four implementation specifications.^{1, 3}

Under the current rule, "addressable" does not mean "optional." A regulated organization must assess whether the specification is reasonable and appropriate in its environment. If it is, the organization must implement it. If it is not, the organization must document why and implement an equivalent alternative measure when reasonable and appropriate.¹

That distinction is important. A decision not to use a particular control requires analysis and documentation, not silence.

Review access before an incident reviews it for you

Access reviews should compare what the system permits with what the work currently requires. This is sometimes called access recertification. The name matters less than the discipline behind it.

A useful review examines more than a list of usernames. It considers:

• Active accounts that do not match the current workforce or vendor roster
• Permissions that remain after transfers, promotions, or reorganizations
• Temporary access that passed its intended expiration date
• Privileged accounts and unexplained exceptions
• Shared, generic, default, emergency, and service accounts
• Accounts with long periods of inactivity
• Remote access that is no longer needed
• Repeated failed logins, unexpected locations, unusual access times, or other activity that deserves investigation

The HIPAA Security Rule also requires audit controls capable of recording and examining system activity and requires procedures for regularly reviewing records such as audit logs, access reports, and security-incident tracking reports.^{2, 3}

Logs do not protect information simply because they exist. Someone must know what is being reviewed, how often, what should trigger escalation, who investigates, and how the organization documents the result.

What 2026 enforcement is telling healthcare organizations

On April 23, 2026, HHS's Office for Civil Rights (OCR) announced four settlements following separate ransomware investigations. Together, the breaches affected more than 427,000 individuals. The regulated entities paid a combined $1,165,000 and agreed to corrective action plans monitored by OCR for two years.⁵

Accuracy matters here. OCR's findings largely centered on inadequate risk analyses. In some cases, OCR also identified impermissible disclosures or a failure to provide timely breach notification. The announcement did not characterize all four matters as access-control violations.

However, OCR's accompanying cybersecurity recommendations have direct access-control relevance. HHS advised regulated organizations to use authentication mechanisms designed to ensure that only authorized users access ePHI, maintain audit controls, regularly review system activity, and encrypt ePHI in transit and at rest when appropriate.

The lesson is not that every ransomware event proves an access-control violation. The lesson is that organizations need to understand who and what can reach ePHI, watch for activity that does not belong, and reduce unnecessary pathways before an attacker finds them.

In December 2024, HHS proposed changes that would remove most of the current distinction between required and addressable specifications and would require MFA with limited exceptions, among many other changes.

As of August 25, 2026, HHS still identifies these changes as a proposed rule. They are not part of the current HIPAA Security Rule. HHS expressly states that the existing Security Rule remains in effect while rulemaking continues.^{6, 7}

Organizations may consider the proposal when planning future improvements, but they should not present proposed provisions to employees or customers as current legal requirements.

A practical access review for managers

Managers and compliance leaders can begin with a focused review:

1. Reconcile the accounts. Compare active system accounts with current employee, contractor, student, volunteer, and vendor records.
2. Confirm the owner. Identify the person responsible for approving and periodically reviewing each role, privileged account, service account, and vendor connection.
3. Test a role change. Select a recent transfer or promotion and confirm that access from the former role was removed, not merely supplemented.
4. Test an offboarding event. Verify that a recent departure was removed from every relevant application, remote-access method, physical credential, and third-party platform.
5. Review exceptions. Examine permissions that exceed the normal role and confirm the business reason, approval, and review date.
6. Find forgotten access. Look for inactive, expired, shared, generic, default, test, and emergency accounts.
7. Examine activity. Confirm that access reports and audit logs are reviewed under a defined schedule and that unusual activity reaches the right person.
8. Document the decision. Record what was reviewed, what changed, who approved it, and when the next review is due.

The goal is not to produce a perfect spreadsheet. It is to create a repeatable process that can explain access clearly and correct it promptly.

Access should move at the speed of the work

Healthcare organizations cannot protect ePHI by making information impossible to reach. Clinicians, billing teams, support staff, and approved partners need dependable access to perform legitimate work and support patient care.

Good access control makes that access timely, traceable, and appropriate. It also recognizes that permission has an expiration date, even when the account does not display one.

The most useful question is not simply, "Can this account get in?"

It is, "Should this account still be able to get here, do this, and see this today?"

When an organization can answer that question consistently, access control becomes more than a technical safeguard. It becomes part of how the organization understands its people, systems, and responsibility for patient information.

Support Resources