For as long as health systems have had identity providers, the question they've been built to answer is who logged in. Multifactor authentication, single sign-on, and passwordless login all exist to answer that question well, and they've gotten good at it. But once that question is answered, the identity system's job is effectively done. Whoever is sitting in front of the screen an hour later is treated as the same person, because nothing in the architecture was built to check.
That's not an oversight. It's how the mechanics work. Authentication is a single event: a person proves who they are, and the identity provider issues a session, a token that tells every connected application "this is an authorized user, let them in." From that point forward, the applications trust the token, not the person. The token doesn't expire because someone walked away, and it doesn't know if someone else sat down. It expires on a timer, or when someone manually logs out, neither of which has anything to do with who's actually at the keyboard.
Consider a health information management coder working from home, authenticated by SSO into the medical record system to code charts for the day. A video call pulls her into another room, and the laptop stays open, unlocked, in a home office she shares with two roommates. Nothing about that session looks unusual to the identity provider. The token is valid, the login was legitimate, and the audit trail will show a clean, authorized session for as long as it stays open. It won't show who else was in the room.
The category HHS uses for exactly this kind of incident, unauthorized access and disclosure, grew 17.4% year over year in 2025, with the average incident affecting close to 10,000 individuals. That's not a category built primarily around outside attackers breaking in. It's built around situations where a session, a credential, or a record ends up being used by someone other than the person it was authorized for, which is precisely what "who logged in" can't detect and "who's using the session" is meant to catch.
Closing that gap by asking users to re-authenticate more often treats the symptom, not the mechanism. The problem isn't that MFA is too weak or that timeouts are too long. It's that both are built around the same underlying question, and no amount of tuning that question gets you an answer to a different one. A ten-minute timeout doesn't know that the person changed at minute two. A stronger MFA factor doesn't know that the credential is now sitting behind an unlocked screen in someone else's hands.
Answering "who's using the session" requires a signal that has nothing to do with the login event: something that keeps observing the person operating the session after authentication is already finished. The security industry has started calling that shift continuous identity, and it's a different category of tool than anything built to strengthen the login itself. Most of what gets marketed under that name today still assumes an answer to "who's using the session" instead of actually producing one. Getting a real answer is the shift health systems identity programs are going to need to make.
See how Twosense's Continuous Authentication Platform is built to answer that second question: Explore the solution.