The Accounts Nobody in Your Practice Remembers Creating

I got a question from a practice administrator a while back that I still think about. She asked me, plainly, how many accounts had access to her patient records. Not a trick question. Just a number. And the honest answer, once we actually looked, was that nobody knew.

That is not a knock on her. It is the normal state of almost every healthcare organization I talk to. You buy an EHR. Then a scheduling tool. Then a patient portal, a billing platform, a lab integration, a telehealth vendor. Each one creates accounts. Each one gets a service login so the systems can talk to each other. Somewhere in there, a former MA still has a login nobody disabled, a vendor has a standing account from a project that wrapped two years ago, and an automated integration is authenticating every night with credentials nobody has looked at since the day it was set up.

That pile of forgotten access is the thing I want to talk about, because it is where a lot of breaches actually start.

Credentials are the front door, not the window

There is a mental picture a lot of people carry around: the hacker breaking in, some malware, an alarm going off. Real intrusions are quieter than that. According to The Hacker News, stolen and misused credentials are among the most frequently reported initial access vectors in breach research, including Verizon’s annual Data Breach Investigations Report. In plain terms, attackers do not usually pick the lock. They log in with a key that already works.

That matters more in healthcare than almost anywhere, because a login that already works does not trip the alarms your team is watching. As The Hacker News put it, when an attacker uses compromised legitimate credentials within the permissions those credentials already hold, the resulting activity can closely resemble normal operational behavior. A stolen account browsing patient charts looks a lot like a clinician browsing patient charts. That is the whole problem.

The accounts you cannot see

The Hacker News has a phrase for the hidden layer of access that never made it into your central system: identity dark matter. It describes it as local application accounts, embedded service credentials, legacy authentication flows, and integrations that were never onboarded into a central identity provider.

Read that list again with your own practice in mind. The lab interface that logs in with its own credentials. The old imaging system that has its own local accounts and never talked to your single sign-on. The billing vendor’s standing login. None of those show up when someone runs an access review inside your main identity platform, because they were never part of it. The Hacker News makes a point that stuck with me: governance reports tend to describe the applications connected to them, so if an application was never integrated, it does not appear in the report, and absence can be mistaken for compliance. An empty line in a report is not proof of safety. It is often proof that nobody is looking.

The machine accounts deserve their own paragraph. The Hacker News notes that service accounts, API keys, and workload credentials frequently outnumber employee accounts in cloud-heavy environments and often have no expiration. Think about what that means for a practice running a dozen integrated systems. The credentials doing the most work, moving the most data, are frequently the ones with no owner, no expiration, and no MFA. They just run. Forever. Until someone finds them.

Why the standard reports do not save you

Here is the uncomfortable part. Most IAM reporting, as The Hacker News describes it, answers what access was granted, but not whether the account still has a human owner or whether the permission has been used in the last year. Your access review can come back clean and still miss the thing that gets you.

There is also a compounding effect the article calls out that I see constantly. A user assigned a modest role can inherit far broader capability through a nested group, a shared service account, or a trust relationship between accounts. The Hacker News calls the real result effective access, and effective access is often broader than intended. Someone who looks like they can only read one system may, through a chain nobody drew on a whiteboard, actually reach much more. Those chained paths, the article notes, are exactly what attackers traverse during lateral movement.

What identity visibility actually means

So when The Hacker News defines identity visibility as the ability to see every identity in an environment, what it can access, and how that access is actually used at runtime, that is not abstract to me. It is the answer to the practice administrator’s question. It is being able to say, with confidence and not a guess: here is every account, human and machine, that can touch patient data. Here is what each one can actually reach. Here is which ones have not been used in a year, which ones have no owner, and which ones have write access to something that matters and no MFA in front of them.

The article draws a line I find useful between what your systems are supposed to do and what they actually do. IAM platforms express intent, who should have access and under what conditions. The applications themselves reveal execution, which credentials actually authenticated and which permissions actually got used. Identity visibility is the practice of closing the gap between those two. For a healthcare organization, that gap is not an administrative annoyance. It is patient data sitting behind accounts nobody is accounting for.

Where I would start

If I were sitting across from you with a coffee, I would not tell you to buy a platform this week. I would tell you to answer four questions honestly, because the answers usually reveal how much work there is:

How many accounts can reach your patient records, and can you produce that list without guessing? If the answer is a shrug, that is your starting point.

Which of your systems authenticate outside your main sign-on? Those are the ones your access reviews are silently skipping.

How many service and integration accounts do you have, who owns each one, and when do they expire? If the honest answer to the last part is never, that is a finding.

When was the last time anyone checked which granted permissions are actually being used, versus just granted on paper? Unused access is risk with no upside.

None of that requires a big budget to begin. It requires someone willing to look at the accounts nobody remembers creating, and to keep looking, because this is not a one-time cleanup. It is a picture that has to stay current.

The practice administrator who asked me how many accounts had access to her records was not behind. She was ahead, because she asked the question at all. Most people never do.