When the Caller ID Looks Right: Why Healthcare Security Has Become an Identity Problem

Healthcare organizations have spent years teaching employees to recognize suspicious emails.

That still matters.

But social engineering is not limited to email anymore.

Attackers can impersonate employees, spoof phone numbers, misuse trusted communication channels, and attempt to convince staff to provide access or approve changes that appear legitimate.

That creates a broader question for healthcare leaders:

What happens when the person asking for access looks and sounds legitimate?

In September 2026, Astrana Health disclosed a material cybersecurity incident involving social engineering attempts in which threat actors impersonated company personnel and spoofed the company's main corporate telephone number while contacting employees in an effort to gain unauthorized access to systems. Astrana said its response included resetting affected credentials, restricting remote-access tools, restoring certain systems from clean backups, and increasing monitoring, logging, and detection.

That incident is a useful reminder that cybersecurity is not only about detecting malicious software.

Sometimes the attack is aimed at trust itself.

Why Identity Has Become a Healthcare Cybersecurity Issue

Healthcare organizations depend on people being able to access information quickly.

Clinicians need patient information.

Billing teams need financial systems.

Administrative employees need business applications.

Remote employees need secure access.

Vendors may need controlled access to support systems.

IT teams need privileged accounts to maintain the environment.

All of that depends on a basic assumption:

The person requesting access is who they claim to be.

The HIPAA Security Rule directly addresses that issue. HHS states that regulated entities must implement procedures to verify that a person seeking access to electronic protected health information is who they say they are. The Security Rule also includes requirements around access controls and audit controls for information systems containing ePHI.

That makes identity management much more than an IT convenience.

It is part of protecting access to sensitive healthcare information.

Social Engineering Targets People Because People Can Grant Access

Social engineering is designed to manipulate a person into doing something the attacker wants.

HHS's Health Industry Cybersecurity Practices program identifies social engineering as one of the major threats affecting the healthcare and public health sector and specifically includes Identity and Access Management among its recommended cybersecurity practices.

The attack does not always need to involve someone giving away a password directly.

An attacker might try to convince an employee to:

• Reset an account
• Approve a login
• Change a phone number
• Install or enable remote-access software
• Provide a verification code
• Add a new user
• Change account permissions
• Bypass a normal process because something is "urgent"
• Trust a caller who appears to be an executive, coworker, vendor, or IT technician

That is why cybersecurity training alone cannot carry the entire burden.

Employees need education.

But the organization also needs processes and technical controls that make a single successful deception less likely to turn into broad system access.

Caller ID Is Not Identity Verification

A phone number appearing to come from a known organization does not prove who is on the other end.

The Astrana disclosure illustrates that distinction: the company reported that attackers spoofed its main corporate telephone number while impersonating personnel.

For healthcare organizations, that means identity verification procedures should not depend solely on information that can be presented or imitated.

A familiar:

• Caller ID
• Display name
• Email address
• Voice
• Job title
• Vendor name

should not automatically replace an established verification process.

When a request involves sensitive access or a security change, the organization should have a defined process for independently confirming the person's identity and authority.

Identity Verification Should Match the Risk of the Request

Not every interaction requires the same amount of verification.

Resetting a low-risk internal preference is different from:

• Resetting an administrator password
• Changing MFA settings
• Providing remote system access
• Granting access to ePHI
• Modifying privileged permissions
• Adding a new device
• Disabling a security control

The higher the potential impact, the stronger the verification process should be.

NIST's Digital Identity Guidelines address identity proofing, authentication, and federation as separate but related parts of establishing and verifying digital identity.

Healthcare organizations do not need to copy federal identity systems directly in order to take the lesson seriously.

The practical principle is simpler:

Do not let the urgency of the request determine the strength of the verification.

MFA Helps, but MFA Alone Is Not the Entire Identity Strategy

Multi-factor authentication is an important security control.

HHS has specifically noted that remote access can create higher risk and that regulated entities may consider stronger authentication, including MFA, based on their risk analysis.

But MFA should not be confused with a complete identity-management program.

Organizations still need to think about:

• How accounts are created
• How identities are initially verified
• How MFA factors are changed
• Who can reset an account
• How privileged accounts are managed
• How access is removed when employment changes
• How suspicious login activity is reviewed
• How remote-access requests are approved

An attacker who convinces someone to change an MFA method or approve a fraudulent request may be trying to bypass the very control designed to protect the account.

That is why strong processes need to surround the technology.

Phishing-Resistant Authentication Deserves Attention

Not all authentication methods provide the same protection against phishing.

NIST's current Digital Identity Guidelines distinguish phishing-resistant authentication from methods that require users to manually enter a one-time code. NIST notes that authenticator outputs entered manually are not considered phishing-resistant because an attacker may be able to relay the code during a fraudulent authentication attempt.

That does not mean every healthcare organization should replace every authentication method immediately.

It does mean identity strategy should evolve as risks and available technologies change.

Organizations should evaluate authentication based on:

• The sensitivity of the system
• The type of user
• Whether access is remote
• Whether the account is privileged
• The business impact of unauthorized access
• The organization's risk assessment

The most sensitive access may justify stronger controls than lower-risk systems.

Remote Access Should Be Treated as an Identity Decision

Remote access can be essential in healthcare.

Employees may work from multiple locations.

Providers may need access outside the main facility.

IT teams may support systems remotely.

Vendors may require limited remote access for legitimate support.

The risk comes when remote access is treated simply as a connectivity issue.

Before granting or changing remote access, organizations should understand:

Who is requesting it?

Why do they need it?

Which systems can they reach?

How long should the access remain active?

What authentication is required?

How is the activity logged?

Who reviews unusual behavior?

AvTek's Cybersecurity Services include VPN and remote-access security, MFA, privileged access management, role-based access controls, conditional access, identity monitoring, email security, and security assessments. These services can help healthcare organizations strengthen the identity and access layer around their broader security environment.

Unique User Accounts Matter Because Accountability Matters

Healthcare organizations also need to know which person performed which action.

The HIPAA Security Rule requires covered entities to assign a unique name or number for identifying and tracking user identity in systems that maintain ePHI. HHS explicitly states that shared login IDs do not satisfy that requirement.

Unique identities make it possible to:

• Trace activity to a specific user
• Investigate suspicious behavior
• Review system access
• Remove access when responsibilities change
• Apply role-based permissions
• Maintain meaningful audit records

If several users share one credential, those capabilities become much weaker.

Identity should therefore be managed throughout the entire user lifecycle.

Access Should Change When a Person's Role Changes

Identity management is not finished when an account is created.

Employees change roles.

Contractors leave.

Vendors complete projects.

Providers change responsibilities.

Administrative privileges may no longer be necessary.

Access that made sense six months ago may not make sense today.

That issue appeared directly in another recent HHS enforcement action.

On September 17, 2026, HHS's Office for Civil Rights announced a settlement following its investigation of a phishing incident involving Ambry Genetics. OCR identified potential HIPAA Security Rule issues including failure to conduct an accurate and thorough risk analysis, failure to implement procedures for terminating access when employment or another workforce arrangement ended or access was no longer appropriate, and failure to assign unique user identification in systems containing ePHI.

That does not mean every phishing incident involves the same weaknesses.

It does show why identity, access, and risk management belong in the same conversation.

Risk Analysis Should Include Identity and Access

The HIPAA Security Rule requires regulated entities to conduct risk analysis and implement appropriate safeguards for ePHI.

OCR's September Ambry settlement again emphasized risk analysis and risk management as foundational parts of cybersecurity.

For healthcare organizations, identity-related risk analysis should include questions such as:

• Where is ePHI stored?
• Who can access it?
• Which users have privileged access?
• How are users authenticated?
• How are remote users authenticated?
• How are accounts created?
• How are accounts disabled?
• How quickly can access be removed?
• How are vendors authenticated?
• How are suspicious access attempts detected?
• What logs are available after an incident?

The purpose is not to create paperwork for its own sake.

It is to understand where identity failure could create access to sensitive information.

For healthcare organizations that need cybersecurity leadership around these decisions, AvTek's vCISO Services include cybersecurity risk management, documentation review, incident response planning, governance, vendor-risk discussions, remediation planning, and ongoing reassessment of security priorities. AvTek specifically supports healthcare organizations with HIPAA-related cybersecurity and risk responsibilities.

Logging Matters After the Identity Check

Identity security has two sides:

Can we verify the person before granting access?

and

Can we determine what happened after access was granted?

HHS's Health Industry Cybersecurity Practices says healthcare organizations should clearly identify users and maintain audit trails that monitor each user's access to data, applications, systems, and endpoints.

The HIPAA Security Rule also requires audit controls that record and examine activity in information systems that contain or use ePHI.

Logging can help answer questions such as:

• Which user logged in?
• When did the login occur?
• Where did the activity originate?
• Which systems were accessed?
• Were permissions changed?
• Was data accessed unexpectedly?
• Was remote access used?
• What happened after a suspicious account event?

Those records become especially important when an organization needs to investigate whether a social-engineering attempt resulted in unauthorized activity.

Employee Training Still Matters, but It Needs a Process Behind It

Healthcare cybersecurity training should absolutely teach employees how to recognize manipulation.

HHS explicitly includes social engineering among the healthcare-sector cyber threats organizations should address.

But employees need more than warnings to "be careful."

They need to know exactly what to do when something feels wrong.

For example:

If someone claiming to be IT asks me to change a login setting, how do I verify them?

If an executive appears to call asking for urgent access, who do I contact?

If a vendor says they need remote access immediately, what is the approved process?

If I receive an MFA prompt I did not initiate, where do I report it?

If I suspect my account has been compromised, what should I do first?

Clear processes reduce the need for employees to make security decisions under pressure.

AvTek's Managed IT Services include cybersecurity support, proactive monitoring, identity and access management, security awareness, risk assessments, Microsoft 365 management, backup and disaster recovery, and strategic IT support for healthcare organizations.

Incident Response Should Assume an Identity Can Be Compromised

Even strong controls cannot guarantee that every social-engineering attempt will fail.

Healthcare organizations also need to be prepared for what happens when an account or access path may have been compromised.

Astrana Health's September disclosure describes several actions taken during its response, including credential resets, restricting remote-access tools, restoring systems from clean backups, and enhancing monitoring, logging, and detection.

Those actions highlight useful response questions for any organization:

• Can we quickly disable a compromised account?
• Can we revoke active sessions?
• Can we restrict remote access?
• Can we reset authentication methods?
• Can we identify what the account accessed?
• Can we determine whether permissions changed?
• Can we restore affected systems if necessary?
• Do we know who makes those decisions?

Incident response planning should account for identity-based incidents, not just malware.

Backups Still Matter in an Identity-Driven Attack

A social-engineering incident may begin with a person rather than malware, but recovery capabilities can still matter.

Astrana specifically reported restoring certain systems from clean backups as part of its response.

Healthcare organizations should therefore connect identity security with:

• Backup
• Recovery
• Incident response
• System isolation
• Monitoring
• Access revocation

AvTek provides Data Backup and Recovery Services as part of its broader technology-risk and resilience support.

The goal is not merely to have backup copies.

It is to know how systems can be restored when an incident affects normal operations.

Social Engineering Is a Layered-Control Problem

No single security measure solves social engineering.

Training helps.

MFA helps.

Identity verification helps.

Access controls help.

Logging helps.

Remote-access restrictions help.

Incident response helps.

Backup and recovery help.

The important part is how those controls work together.

A useful layered approach includes:

Identity Verification

Confirm that the person requesting sensitive access or changes is who they claim to be.

Authentication

Use authentication methods appropriate to the sensitivity and risk of the system.

Least-Privilege Access

Limit access to what each user or vendor actually needs.

Privileged Access Controls

Apply stronger oversight to accounts that can change systems, permissions, or security settings.

Remote-Access Governance

Define who can connect remotely, how they authenticate, and what they are permitted to reach.

Logging and Monitoring

Maintain records that make user and system activity reviewable.

Workforce Training

Teach employees how to recognize social engineering and how to verify unusual requests.

Incident Response

Define how the organization will disable accounts, restrict access, investigate activity, and recover systems.

This is why healthcare cybersecurity increasingly needs to be treated as risk management rather than a collection of individual tools.

Frequently Asked Questions About Healthcare Identity Security

When Trust Can Be Imitated, Verification Has to Be Intentional

Healthcare organizations need people to move quickly.

That creates a difficult balance.

Employees cannot treat every phone call, login request, vendor interaction, or internal message as malicious.

But they also cannot assume that a familiar name, phone number, voice, or sense of urgency proves identity.

That is why healthcare cybersecurity needs a layered approach.

Train the employee.

Verify the identity.

Limit the access.

Protect privileged accounts.

Monitor the activity.

Maintain the logs.

Prepare for the possibility that a trusted account is compromised.

The recent Astrana incident and HHS's Ambry enforcement action came from different circumstances, but together they reinforce a broader point: identity, access management, risk analysis, workforce processes, and monitoring all belong in the same cybersecurity conversation.

AvTek Solutions helps healthcare organizations strengthen that foundation through Managed IT Services, Cybersecurity Services, and vCISO Services. AvTek's healthcare-focused support includes cybersecurity risk management, identity and access controls, remote-access security, incident-response planning, monitoring, security assessments, and HIPAA-related cybersecurity leadership.

If your healthcare organization has focused heavily on phishing awareness but has not recently reviewed how identities are verified, how remote access is approved, or how privileged access is managed, that is a good place to start.

Talk with AvTek about your healthcare cybersecurity risk