By Des Moloney, Principal Consultant, Fortified Health Security
LinkedIn: Des Moloney
LinkedIn: Fortified Health Security
Most healthcare organizations already know they have an identity problem, because it surfaces in every risk assessment they commission. The findings come back, the IT team nods, and then comes the question: what are we supposed to do about it?
I’ve spent years inside those environments, cleaning up identity and access management (IAM) risk after the assessment is over, and the hardest part is often authority: Who owns the identities? Who decides on those identities that can be decommissioned, and more critically those that will remain active in an environment.
In my experience, the person who is responsible for fixing an identity is almost never the person who can decide what it’s for.
As a result, the work stalls. A service account nobody claims keeps running in the lab, a vendor account outlives the contract that created it, and a clinical group’s permissions grow across acquisitions.
Here’s why identity cleanup stalls, and the five questions that help turn it from an IT task into an organizational decision.
Access Risk Is Rising Faster Than Programs
Access, one of the least interesting controls in security yet one of the most consequential, has a way of ranking near the top of every framework and every finding list.
Across more than 150 healthcare assessments a year, our teams are finding four times as many identity and access issues as they were a year ago, and 64% of those findings are rated critical or high risk.
None of this is news to the teams living inside it.
From Inventory to Identity Risk Assessment
If a system runs on infrastructure, IT gets handed the keys, so IT ends up owning identities for systems the business asked for. But IT can’t name an owner, because that isn’t an IT function. That process belongs, or should belong, to the organization.
As you begin your inventory, the most common answers you will receive are, ‘I’m not the owner’ or ‘I don’t have time’. Both are honest answers from people who are already at capacity, and enough of both can be a death sentence for the project.
I’ve seen firsthand an identity inventory that ultimately failed. Not descoped. Not delayed. It died because nobody outside my team had a reason to care about it.
I soon realized the fatal flaw in my approach, and that it was a single word: inventory. “Inventory” sounds like an asset list of serial numbers, asset tags, and hostnames, a spreadsheet somebody else maintains for reasons that directly impact your day-to-day operations. Nothing in that world obligates a department head to take a meeting.
Call it an IT project, and it competes with every other technology initiative. Call it an Identity Risk Assessment, and it gets the attention it deserves. Identity risk is an organizational issue, not just an IT problem. Leaders speak the language of risk, and they are responsible for assigning ownership, managing exposure, and ensuring accountability for outcomes.
What an Identity Risk Assessment Must Answer
There are two groups of identities. On one side you have workforce, contractors, vendors and privileged admins – human identities. On the other you have service accounts, application programming interfaces (APIs), automations and AI agents – non-human identities. No matter which group it falls into, every identity in your environment needs five questions answered, documented, and reported to leadership.
- A Named, Accountable Owner
Think of the owner as the primary key: without it, nothing else in the record resolves. The owner doesn’t have to know the technical detail themselves, department heads often do not, but they must know, and name, those individuals who do know those details.
- A Documented, Specific Purpose
Purpose is the hardest field to backfill and the most valuable. One service account may run a single application, or it may hold four API connections that go into a data warehouse. Usually each does something different, and, more commonly than we would like, each was created at a different time by someone who has since left. You need to know the purpose in order to scope the privileges.
- Privileges Scoped to That Purpose
Least privilege is easy to say and hard to maintain when the business needs something working today. Document why the permissions are what they are. A line in the account description or the password vault costs you thirty seconds, and it’s what lets the next person judge whether the access is still justified.
- Mapped Dependencies Before Any Change
Identities form a web, and pulling one strand moves the others.
Years ago, I found a database administrator’s service account sitting in the Domain Admins security group. The reason was mundane: it couldn’t write backups to a file share, and elevating it solved that in an afternoon. That made the SQL server admin a domain admin, and that put a fair amount of gray hair on my head. The account ran that way for years, and nothing broke, so nobody looked. By the time my team found it, it was in the center of a web that had to be undone carefully as to not break anything else.
Most over-provisioning starts with someone solving a legitimate business problem as quickly as possible. The risk emerges when dependencies, ownership, and downstream impacts aren’t understood. Skip the mapping effort, and you’ll likely discover those dependencies the hard way, through outages, access issues, or compliance findings.
- A Defined End of Life
Name the event that retires the identity, whether that’s a termination, a contract close, or a finished project, because without it your record stays accurate for exactly one day. Directory services have been around for twenty-five-plus years, and I’ve seen user accounts created in the 1990s that nobody could account for. With a defined end of life you have a clear trigger to retire unused and unneeded identities.
What a Sustainable Identity Program Looks Like
In broad strokes, a sustainable identity program has three essential components: (1) governance, which sets the boundaries, (2) operations, which executes on those boundaries, and (3) the identity review that confirms that reality still matches what is written down.
There is also a pattern of healthy habits across successful programs:
- Weekly reviews of created and removed accounts. Your help desk can do it in fifteen minutes.
- Re-certifying access on a cadence tied to privilege levels, from annual down to quarterly for the highest.
- Requiring multi-factor authentication (MFA) with no standing exceptions, including at every electronic health record (EHR) login.
- Ticketing every change, so that it can be reverted or defended later.
You don’t need to over-engineer the process. One of the cleanest lifecycles I’ve seen for human identities was really straightforward: human resources emailed IT, the account was disabled for thirty days, then it was deleted.
Even with such a simple process, it took almost a year to get the organization to align behind it due to ownership and authority challenges.
Bring IAM to Leadership as a Risk
Leadership doesn’t need to understand directory services, human versus non-human identities, or other technical complexities. What matters is understanding the organization’s exposure to identity-related risk. Risk is a language leaders understand, and it’s what drives accountability, ownership, and action.
You don’t need a budget line or a new platform to start reducing exposure from your identities, but you do need buy-in. Next time you bring IAM to your leadership, bring it as an identity risk assessment built around owner, purpose, privilege, dependencies, and end-of-life.