74% of Shared Devices Are Left Signed In. Is Yours One of Them?

Why identity security cannot stop at login

14 min read

Login is only the start. What happens after it is a question of session security, and a February 2026 hospital breach shows exactly how it can go wrong.

On February 27, 2026, an employee at the 105 Kresowy Military Hospital in Żary, Poland, logged into the hospital’s AMMS medical system using individual credentials.

Then something changed.

The employee allowed a former employee, who was no longer authorized to use the system, to remain at the workstation and left the room. The authenticated session remained active while the unauthorized person was alone at the computer.

According to the hospital’s formal data protection notice, the incident occurred between 4:20 p.m. and 5:00 p.m. The active system contained patient information including names, addresses, national identification numbers, diagnoses, health information, and medical recommendations.

The hospital said that, based on the information available at the time, it had not established that individual patient records were actually viewed. But it could not rule out the possibility and treated the event as a data protection breach.

What is striking about this incident is what didn’t fail.

The security problem began after successful authentication.

The human operating the authenticated session changed. The system’s trust did not.

That distinction is becoming increasingly important. It is what session security is supposed to catch.

Authentication is an event. A session is a period of time.

We have spent decades improving the moment when someone first proves who they are. Passwords became stronger. Then came multifactor authentication. Biometrics, hardware security keys, FIDO2, passwordless authentication, and passkeys have made it significantly harder to steal or reuse credentials.

These are important advances, and organizations should continue adopting stronger authentication. But authentication solves a specific problem.

NIST defines authentication as the process through which a claimant proves possession and control of one or more authenticators associated with an account. In simpler terms:

Authentication asks: Can you prove that you are the user you claim to be?

Once that authentication event succeeds, however, something different usually happens. A session begins.

The application does not ask the user to completely authenticate again before every click, every medical record, every email, every financial transaction, or every action. It creates a mechanism that allows the authenticated state to continue.

NIST’s current Digital Identity Guidelines describe this explicitly. After authentication, a session can continue across subsequent interactions without requiring the subscriber to repeat the authentication event each time. In web applications, that continuity may be maintained through a session cookie or another session secret.

This is necessary for usability. Imagine completing MFA every time you opened another patient chart or moved between applications.

But it creates an important security question:

What evidence do we have that the human using the session now is still the human who authenticated earlier?

Traditional authentication is exceptionally good at answering the question at 9:00 a.m. It is not necessarily designed to answer it continuously at 9:17, 11:43, or 3:26.

That is why a strong login is not the same thing as a trustworthy session. We have gotten very good at building stronger doors. We need to pay more attention to who is still in the room after the door opens.

Four different questions that are often treated as one

Part of the problem is terminology. Authentication, authorization, session security, and continuous human verification are closely related, but they are not the same thing.

Security function	The question it answers
Authentication	Are you able to prove that you are the claimed user?
Authorization	What is this authenticated identity allowed to access or do?
Session security	Is the authenticated session itself still trustworthy?
Continuous human verification	Is the authorized human still the person operating the device?

NIST defines authorization as the decision to permit or deny a subject access to systems, applications, data, or services.

So authentication might establish that Sara is Sara. Authorization determines which applications, records, or functions Sara may access. A session allows Sara to continue working without proving her identity from scratch every few seconds.

But continuous human verification introduces another signal:

Is Sara still the human behind the active session?

That last question is frequently missing from the identity architecture.

The post-login attack surface is not one problem

When people hear “session security,” they often immediately think about stolen cookies or tokens. That is one important class of risk.

Microsoft explains that attackers can steal authentication tokens using techniques such as adversary-in-the-middle phishing or malware. Once a valid token is stolen, an attacker may be able to impersonate the authenticated user without defeating the original MFA event.

That is digital session takeover.

But there is another category: human substitution at the endpoint.

The token isn’t necessarily stolen. The application hasn’t necessarily been compromised. The authorized employee simply leaves an authenticated device, shares it, hands it to someone else, or fails to secure it before another human begins interacting with the session.

These two risks share a common principle:

Trust established at login can outlive the conditions that justified that trust.

But they require different controls. Token protection, phishing-resistant authentication, session binding, threat detection, and related technologies are important defenses against digital session hijacking.

They do not necessarily answer whether the person physically operating an already authenticated endpoint has changed. That distinction matters because “session security” is much broader than any single technology can solve.

Why MFA, passkeys and other controls don’t completely close the gap

The point is not that existing security controls are ineffective. They are effective at the jobs they were designed to do. The question is whether we are asking them to solve a problem outside those jobs.

Control	What it does well	What it does not inherently establish
MFA	Requires additional proof during authentication	That the same human remains at the device throughout the session
Passkeys / FIDO2	Provide strong, phishing-resistant authentication	Who is physically operating the endpoint later
SSO	Reduces authentication friction across applications	Continuous identity of the human behind the session
Conditional Access	Evaluates signals such as device, location, application and risk	Continuous physical identity of the endpoint user
Idle timeout / automatic lock	Locks a session after a defined period without activity	Whether the activity occurring before the timeout comes from the authorized user
Endpoint security / EDR	Detects malicious software, suspicious processes and device threats	Whether the authorized human has been replaced by another person
Behavioral analytics	Detects unusual patterns or changes in behavior	Direct confirmation that a particular human remains at the endpoint

Consider the ordinary inactivity timeout. It can be useful when an employee leaves a computer untouched. But if another person begins interacting with the computer before that timer expires, there may no longer be any inactivity to detect.

The problem is who is generating the activity. This is why relying exclusively on inactivity can create a subtle gap in shared-workstation environments.

At the same time, forcing users to manually lock, unlock, and repeatedly authenticate introduces its own operational problem. Hummingbirds AI has previously explored how repetitive authentication can create MFA fatigue and employee productivity friction.

Security has always involved balancing assurance with usability. The opportunity is to increase both.

Healthcare makes the problem easy to see

Shared devices are operationally valuable in healthcare because clinicians move constantly between patients, rooms, stations, and applications. But shared computing also exposes the difference between authenticating an account and continuously knowing which human is behind the account. That gap is a session security problem, not just an authentication one.

Imprivata’s 2025 research on shared mobile devices in healthcare found the following:

Those numbers are important because they expose a problem that cannot be solved simply by making the password more complicated.

Suppose a hospital deploys strong MFA. A clinician authenticates correctly. The EHR opens. The clinician responds to an emergency down the hall and walks away. Another person approaches the workstation.

At that moment, asking whether the original authentication was strong enough misses the point. The authentication may have been excellent. The context changed after authentication.

That is exactly what the February 2026 hospital incident demonstrates. The employee who authenticated was legitimate. The person later sitting at the workstation was not.

NIST is already treating session security as its own problem

This is not simply a new marketing category. NIST’s current Digital Identity Guidelines devote an entire section to session management and explicitly address the risk of a user walking away from an authenticated session.

NIST states that periodic reauthentication is intended to confirm the subscriber’s continued presence at an authenticated session, including situations where someone may have walked away without logging out.

Even more interestingly, NIST now describes session monitoring, sometimes called continuous authentication, as the ongoing evaluation of session characteristics to detect possible fraud during an active session.

Signals can include behavior, device characteristics, browser characteristics, geolocation, network information, and other contextual factors. NIST also notes that these signals can have privacy implications and should be considered within a privacy risk assessment.

This represents an important change in mindset. Identity is not only something to evaluate at the gate. It can be evaluated as the session evolves.

And Zero Trust points in the same direction. NIST’s Zero Trust Architecture rejects implicit trust based simply on network location, device ownership, or prior access. Authentication and authorization must be tied to access decisions rather than assumed because something sits inside a trusted perimeter.

If the central idea of Zero Trust is that trust should never become permanent simply because an earlier condition was satisfied, then the active user session deserves the same scrutiny.

But session monitoring still leaves an important identity question

Most session-risk systems evaluate context.

These are valuable signals. But there is another signal that becomes particularly important on physical endpoints:

Is the authorized human still the person in front of the computer?

That is different from simple presence detection. Knowing that someone is present is not the same as knowing that the authorized person is present.

A badge nearby is not necessarily enough. A device nearby is not necessarily enough. Continued keyboard activity is not enough.

Continuous human verification is about maintaining confidence in the relationship between the active session and the authorized human who is supposed to control it.

What continuous human verification adds

A useful continuous human verification layer should not force employees to repeatedly stop working and prove who they are. If every increase in security creates another interruption, users eventually find ways around the security.

Instead, the goal should be to make identity assurance more persistent while making authentication friction less visible. That means a continuous human verification system should ideally, in service of real session security:

Privacy is especially important here.

Continuous verification should not mean continuous surveillance. Those are not the same concept.

Hummingbirds AI’s approach to privacy-first authentication is built around performing facial processing locally on the endpoint rather than transmitting images or biometric information to the cloud.

The objective is not to watch what an employee is doing. It is to answer a narrow security question: is the authorized human still the human operating this device?

Where Guacamole™ fits

This is the problem Hummingbirds AI built Guacamole™ continuous authentication to address.

Guacamole is not designed to replace MFA, passkeys, SSO, identity providers, endpoint security, or Zero Trust architecture. Those technologies solve different parts of the security stack.

Guacamole adds a continuous human identity signal after login. Using on-device computer vision, Guacamole continually verifies the authorized user during the active session.

When the authorized user walks away, the session can be protected. When the authorized user returns, access can resume without introducing unnecessary manual authentication steps. If an unauthorized viewer is detected, screen privacy protections can also respond.

This model becomes particularly valuable in environments where people and devices move frequently: hospitals, clinics, manufacturing facilities, logistics operations, call centers, government environments, public safety, classrooms, labs, and other shared-workstation environments.

Hummingbirds AI has explored this issue previously in the context of unattended devices and CJIS access in public safety.

The common denominator is not the industry. It is the workflow. A sensitive session stays open while the humans around the device change.

The identity stack needs to evolve with the session

For years, the cybersecurity industry’s defining identity question was:

How do we make login harder to compromise?

That question produced enormous progress: MFA, hardware-backed credentials, biometrics, passkeys, conditional access, phishing-resistant authentication. We should keep investing in all of them.

But stronger authentication creates another question that becomes more important as sessions last longer and applications become more powerful:

Once someone has authenticated, how do we know they are still the person we authenticated?

This matters even more as AI moves from simply presenting information to taking actions on behalf of users. The consequences attached to an authenticated session are increasing. So the confidence behind that session must evolve too.

The February 2026 hospital incident gives us a remarkably simple illustration. Nothing was necessarily wrong with the employee’s credential. Nothing was necessarily wrong with the authentication mechanism. Nothing was necessarily wrong with the authorization assigned to the employee.

What changed was the human. And the computer did not know.

That is the gap continuous human verification is designed to close.

We have spent decades authenticating credentials. The next step is not to abandon everything we built. It is to extend it into real session security.

---

Sources and further reading

• 105 Kresowy Military Hospital: Official Notice of Personal Data Breach, 2026
• NIST SP 800-63B: Digital Identity Guidelines, Authentication and Lifecycle Management, Session Management
• NIST SP 800-207: Zero Trust Architecture
• NIST Cybersecurity Glossary: Authentication and Authorization
• Imprivata: 2025 State of Shared Mobile Devices in Healthcare findings
• Microsoft: Understanding Tokens in Microsoft Entra ID and Token Theft Attack Vectors
• Microsoft Security: Token Tactics and Adversary-in-the-Middle Attacks