HIPAA and Active Directory: auditing the technical safeguards

Healthcare organisations and their business associates run on Active Directory like everyone else — but with electronic protected health information flowing through the same mailboxes, Teams channels and SharePoint sites. The HIPAA Security Rule has specific things to say about who can reach that data and how you prove it.

Who this applies to

The HIPAA Security Rule applies to covered entities — health plans, clearinghouses and most healthcare providers — and to their business associates, meaning any vendor that handles electronic protected health information (ePHI) on their behalf. If you are a software company, an MSP or a consultancy serving healthcare clients, you are very likely a business associate with direct obligations, not just a contractual bystander.

The three safeguard families

The Security Rule organises requirements into administrative, physical and technical safeguards. A Microsoft configuration audit speaks to the technical safeguards and to parts of the administrative ones. Physical safeguards — facility access, workstation security, device disposal — are outside what any configuration tool can assess.

Access Control

Four things matter here, and each maps to a concrete Microsoft setting:

• Unique user identification. Every user gets their own account. Shared logins — the front-desk account, the generic clinical workstation login, the shared service mailbox with a password in a drawer — are a direct problem, and they are common. An audit surfaces accounts that look shared: no MFA, no recent interactive sign-in pattern, generic naming.
• Emergency access procedure. You need a documented way in when normal authentication fails. In Active Directory terms, that is a break-glass account: excluded from conditional access that could lock you out, credentials stored securely, and monitored. Getting this wrong means either being locked out of your own domain or running an unwatched super-account.
• Automatic logoff. Session timeout and inactivity settings, particularly relevant where clinical staff share workstations.
• Encryption and decryption. Both at rest and in transit across the collaboration stack.

Audit Controls

You must be able to record and examine activity in systems containing ePHI. In practice: the unified audit log actually enabled, sign-in and directory logs retained long enough to investigate, and mailbox auditing switched on. A surprising number of domains fail this because auditing was never turned on at the domain level — and you cannot retroactively produce logs you never collected.

Person or Entity Authentication

Verifying that whoever seeks access is who they claim to be. This is where MFA coverage lives, and where legacy authentication protocols cause the most damage: POP, IMAP and SMTP AUTH bypass modern authentication entirely, which undercuts whatever policy you have written down.

Transmission Security

Protecting ePHI in transit. For Active Directory, the practical risks are mail flow related: auto-forwarding rules to external mailboxes are a classic breach vector and a classic audit finding, along with external sharing settings in SharePoint and OneDrive that let a link to a document containing ePHI travel further than anyone intended.

The administrative overlap

Two administrative safeguards lean heavily on the same technical evidence:

• Information access management — authorising access based on role, and reviewing it. Privileged role assignments and group memberships are the evidence.
• Workforce security — including termination procedures. Accounts that remain enabled after someone leaves are the single most cited access-control failure across every framework, and HIPAA is no exception.

Why manual review keeps failing here

Healthcare IT teams are typically stretched, often supporting a mix of cloud services and on-premises systems, sometimes with clinical applications that authenticate against an on-premises domain. Checking every relevant setting by hand across a dozen admin portals is not a realistic recurring activity — so it happens once, badly, before an assessment, and then drifts.

Drift is the actual risk. A domain that was configured correctly eighteen months ago has since accumulated exclusions, new guest accounts, forwarding rules and an expanded set of administrators. Nobody decided to weaken the posture; it simply eroded.

What a read-only audit gives you

Running an automated audit across Active Directory and Active Directory produces a dated, repeatable measurement of the technical safeguards, with each finding ranked by severity and carrying a remediation step. That gives you three practical things:

1. A baseline — where you actually stand, rather than where the documentation says you stand.
2. Evidence for the technical safeguard conversation during a risk analysis or an assessment.
3. Drift detection — re-run quarterly and the delta tells you what changed without anyone deciding to change it.

Read-only matters especially in healthcare: an audit tool that could modify configuration in an environment handling ePHI is a risk in itself. Assessment should never carry the possibility of breaking clinical access.