Person or entity authentication: the rule does not name a method

Ask whether a clinic requires multi-factor authentication and the honest answer often doubles as an excuse: “the rule doesn’t require it.” That sentence is true and does almost nothing to help the clinic, because it treats the absence of a named method as the end of the analysis instead of the beginning of it.

What the rule actually requires

Person or entity authentication is a Required standard: implement procedures to verify that a person or entity seeking access to ePHI is the one claimed (45 CFR 164.312(d)).

There are no implementation specifications listed. The rule states the outcome and leaves the method to the flexibility built into 164.306(b), which lets a covered entity choose reasonable and appropriate measures given its own size, complexity, and risk.

How this differs from access control

Access control (164.312(a)) and authentication (164.312(d)) sit next to each other and answer different questions. Access control governs what an identity is permitted to do once it is recognized. Authentication asks whether the identity presenting itself is real in the first place. A system can enforce access rules perfectly and still fail authentication, if the credential proving the identity is trivial to steal, share, or guess.

A password alone authenticates a string of characters, not a person. Anyone holding the string passes the check, whether or not they are who the password claims.

“Access control governs what an identity is permitted to do. Authentication asks whether the identity is real in the first place.”

The honest answer on MFA

Here is the honest answer, stated plainly because it gets muddied often: the current Security Rule does not require multi-factor authentication. The word does not appear in 164.312(d). It requires you to verify that a person is who they claim to be, and it leaves the method to you.

But that sentence does not end where people want it to end. Read 164.312(d) alongside the two Required standards that govern the assessment itself, risk analysis (164.308(a)(1)(ii)(A)) and risk management (164.308(a)(1)(ii)(B)). Those require you to identify the actual threats your systems face and respond to them reasonably. In 2026, on an internet-facing system holding children’s clinical records, phishing and credential-stuffing are not hypothetical threats, they are the dominant ones. A risk analysis that identifies credential-based compromise as a real threat, and a risk management response that does not include MFA, is a document that has to explain its own gap. That explanation is difficult to write honestly.

So: MFA is not required by the letter of 164.312(d). It is very hard to justify skipping once 164.308(a)(1) is taken seriously, which is exactly the point, no single Security Rule standard sits in isolation.

What a real answer looks like, next to what most clinics have

	What the rule requires	What most clinics actually have
Method named in the rule	None, left to reasonable judgment	Often cited as “not required” and left there
Verification strength	Matched to the actual risk of the system	A single password, no second factor
Justification	A risk-based decision, documented	No documented reasoning either way
Password reality	Verifies the identity, not just the string	Anyone with the password passes as that person

The gap in the last row is where this standard actually fails in practice. It is rarely a clinic that assessed the risk and made a reasoned call against MFA. It is a clinic that never made the assessment at all, and is relying on the absence of a named method as if that were the same as a decision.