bsfm4465-loc7f605517

Healthcare Employee Offboarding: A Practical IT Access Checklist

Mon, 26 Oct 2026 16:49:52 GMT

Employee offboarding is more than collecting a badge and disabling an email account.

A departing employee may have access to Microsoft 365, the EHR, billing systems, shared folders, remote-access tools, mobile devices, vendor portals, clinical applications, voicemail, and building systems.

If even one access path is overlooked, the organization may retain unnecessary security, privacy, and operational risk.

Quick Answer: What should a healthcare organization do when an employee leaves?

Use a documented offboarding checklist that identifies the employee’s last authorized working time, disables sign-in, revokes active sessions, removes application and vendor access, recovers organizational equipment, preserves required business records, and transfers unfinished responsibilities.

Do not immediately delete the employee’s Microsoft 365 account. First determine what email, files, contacts, calendars, and business records must be retained or transferred.

Why healthcare employee offboarding requires coordination

Healthcare employees rarely use only one account.

A nurse, medical assistant, scheduler, biller, administrator, therapist, contractor, or vendor technician may have separate identities across several systems.

Access may include:

EHR and practice-management systems
Microsoft 365, Outlook, Teams, SharePoint, and OneDrive
Windows computers and remote desktops
VPN and remote-support tools
Billing and revenue-cycle platforms
Electronic prescribing systems
Laboratory and imaging portals
Secure messaging and telehealth systems
Scheduling and payroll applications
Cloud storage and file-sharing services
Vendor support portals
Physical keys, badges, and alarm codes

The person coordinating the departure may not know every system the employee used. Management, human resources, IT, clinical leadership, and relevant vendors must work from the same checklist.

What does HIPAA say about terminating access?

The HIPAA Security Rule includes workforce-security and information-access-management requirements.

HHS guidance states that covered entities must implement procedures for terminating access to electronic protected health information when employment ends or when access is no longer appropriate.

How an organization applies these requirements depends on its size, risks, systems, and operating environment. This article provides an operational framework. It is not legal advice or a compliance certification.

Healthcare employee offboarding checklist

1. Establish the exact cutoff time

Document:

Employee or contractor name
Position and department
Supervisor
Last authorized working date and time
Whether the departure is routine or urgent
Locations and devices involved
Person authorized to initiate access removal
Person responsible for verifying completion

For routine departures, the technical work can be prepared before the employee’s final day.

For an immediate or higher-risk separation, leadership and IT should coordinate the cutoff so access is removed at the authorized time.

2. Disable the central identity

If Microsoft Entra ID, Active Directory, or another directory controls access, disable the employee’s primary organizational account.

In a Microsoft environment, blocking sign-in is only part of the process. Existing refresh tokens and browser sessions may also need to be revoked.

Confirm whether the employee has an identity in:

Microsoft Entra ID
On-premises Active Directory
A hybrid Microsoft environment
Local computer accounts
Remote-desktop platforms
VPN systems
Wireless or network-access services

Disabling one account may not disable separate accounts in other systems.

3. Remove clinical and business-system access

Review every application assigned to the employee.

This may include:

EHR and practice-management software
Electronic prescribing
Laboratory and imaging portals
Billing and payment platforms
Claims clearinghouses
Secure messaging
Telehealth systems
Scheduling applications
Document-management platforms
Accounting and payroll systems
Vendor support portals

When a vendor controls the account, submit a documented removal request and retain confirmation.

Do not assume that disabling Microsoft 365 automatically removes access to every application.

4. Remove groups, roles, and delegated permissions

Accounts may receive access through security groups, Microsoft Teams, shared mailboxes, SharePoint sites, EHR roles, or administrative groups.

Review:

Administrator roles
Departmental security groups
Distribution lists
Shared mailboxes
Microsoft Teams
SharePoint sites
Calendar delegation
Mailbox delegation
Application-specific roles
Vendor and contractor groups
Temporary or emergency access

Pay particular attention to prescribing, billing, reporting, data-export, and administrative privileges.

5. Recover equipment and physical access

Collect organizational property, including:

Laptop or desktop computer
Mobile phone
Tablet
Security token or smart card
Badge
Office keys
Removable storage
Remote-work equipment
Paper records
Backup media

Record the asset number and condition of every returned device.

If a device cannot be recovered immediately, determine whether it is enrolled in Microsoft Intune or another management platform. Remote lock, data removal, or wipe functions may be available.

Do not remotely wipe a device without confirming ownership, authorization, data-preservation requirements, and operational impact.

6. Preserve and transfer business information

A departed employee’s mailbox, calendar, contacts, and OneDrive folders may contain information needed for patient care, billing, scheduling, vendor coordination, or business operations.

Before deleting the account:

Identify the records that must be retained.
Transfer ownership of relevant files.
Assign approved mailbox or OneDrive access.
Decide how incoming messages will be handled.
Apply approved retention instructions.
Document who received access.
Remove delegated access when it is no longer needed.

Microsoft warns that removing a license can affect how long mailbox content remains available. Preservation and ownership decisions should be made before account deletion.

Retention decisions should follow the organization’s legal, privacy, records-management, and contractual requirements.

7. Review shared credentials

Shared accounts should be avoided when individual accounts are available. Individual identities provide clearer ownership and more useful activity records.

When a departing worker knew a shared password, review:

Vendor portals
Local administrator passwords
Alarm and door codes
Wi-Fi credentials
Shared voicemail PINs
Device-specific credentials
Emergency accounts
Website and social-media accounts

Changing a password may not end an existing session or remove a trusted device, recovery address, authentication application, or access token.

8. Check automations and integrations

A departing employee’s account may own an automated process or application connection.

Check for:

Scheduled tasks
Microsoft Power Automate workflows
Mail forwarding
Application passwords
Authentication tokens
Reporting subscriptions
Scanner-to-email configurations
Calendar integrations
Service accounts
Domain or website registrations
Vendor notification contacts

Move legitimate business processes to an approved service identity or responsible employee.

Critical workflows should not remain dependent on a former employee’s account.

9. Protect care continuity

Access removal should not prevent remaining staff from completing essential work.

Confirm who will assume responsibility for:

Patient messages
Test results
Referrals
Prescription requests
Scheduling changes
Billing follow-up
Vendor communication
Equipment or application support
After-hours escalation
Shared inboxes
Required documentation

Clinical and operational leaders should identify these responsibilities before the account is deleted.

10. Verify completion

The person performing the offboarding should not be the only person confirming that it is complete.

A second reviewer should verify that:

Sign-in is blocked.
Active sessions were addressed.
Clinical applications were reviewed.
Vendor access was removed.
Administrative privileges were removed.
Equipment was returned or accounted for.
Required records were preserved.
Shared credentials were reviewed.
Delegated access was documented.
Remaining exceptions have an owner and deadline.

Record the completion date, responsible person, available evidence, exceptions, and follow-up actions.

Disable first and delete later

Disabling an account and deleting an account are different actions.

Disabling access prevents ordinary sign-in while giving the organization time to preserve records, transfer responsibilities, review ownership, and investigate unresolved questions.

Deleting an account may affect:

Email delivery
Mailbox retention
OneDrive ownership
Calendar access
Microsoft Teams membership
Application dependencies
Audit information
Licensing
Automated processes

Microsoft’s former-employee process treats access blocking, record preservation, email handling, license removal, and account deletion as separate steps.

Can healthcare offboarding be automated?

Some technical steps can be automated when the organization has dependable identity information.

Microsoft Entra Lifecycle Workflows can perform tasks such as disabling accounts, revoking refresh tokens, removing group memberships, and running scheduled departure workflows when the required configuration and licensing are available.

Automation does not eliminate the need to review:

EHR accounts
Vendor-managed systems
Physical equipment
Shared credentials
Business-record ownership
Clinical responsibilities
Failed or incomplete tasks

A practical approach is to automate repeatable technical actions while keeping human approval and verification for clinical, legal, and operational decisions.

Why This Matters to Healthcare Organizations

Medical and dental practices

A departing employee may have access to scheduling, patient communications, insurance information, billing exports, and clinical applications.

Small practices may not have dedicated human-resources or security staff, making a written checklist especially important.

Hospice and home-health providers

Remote employees may use laptops, phones, mobile applications, secure messaging, and home internet connections.

Equipment recovery, mobile-device management, and timely removal of remote access are central to the process.

Assisted-living and senior-living organizations

Round-the-clock operations require careful timing.

Access should be removed promptly without disrupting medication workflows, nursing-station operations, staffing communications, or resident care.

Outpatient clinics

Clinics frequently depend on several vendors and portals. Each vendor-managed account must be tracked separately when centralized identity management is unavailable.

Organizations using contractors

Contractors, temporary workers, students, volunteers, and vendor technicians may have access to the same sensitive systems as employees.

Their access should have a defined owner, purpose, expiration date, and removal process.

Protect, Operate, Recover, and Grow

Protect

Require individual accounts.
Use multifactor authentication where supported.
Apply least-privilege access.
Separate administrative and ordinary accounts.
Establish an urgent access-removal procedure.
Review active sessions and shared credentials.

Operate

Maintain an application and account inventory.
Connect personnel notifications to IT tasks.
Define who approves access removal.
Track organizational devices.
Review failed or incomplete tasks.
Retain completion records and exceptions.

Recover

Preserve required email and files before deletion.
Recover or remotely secure organizational devices.
Transfer ownership of essential workflows.
Maintain access to operating procedures.
Escalate suspicious activity through the incident-management process.

Grow

Automate repeatable identity tasks where appropriate.
Replace shared accounts with individual identities.
Include vendors and contractors in the same process.
Review the checklist after major changes.
Track late or incomplete offboarding tasks.
Use lessons from departures to improve onboarding.

The Bottom Line

Healthcare employee offboarding is an access-control, records-management, and care-continuity process.

A reliable process disables access at the authorized time, addresses active sessions, reviews clinical and business applications, preserves required records, recovers equipment, transfers responsibilities, and documents completion.

The strongest checklist is one that staff can follow consistently during both routine and urgent departures.

Frequently Asked Questions

When should a departing healthcare employee’s access be disabled?

Access should be disabled at the time authorized by organizational leadership.

Routine departures can be prepared in advance. Immediate or higher-risk separations require coordinated timing among management, human resources, IT, and clinical leadership.

Is disabling Microsoft 365 enough to complete offboarding?

No.

The organization must also review the EHR, billing systems, vendor portals, remote access, local accounts, clinical applications, physical access, and organizational devices.

Should the Microsoft 365 account be deleted immediately?

Usually not before required email, files, calendars, contacts, application dependencies, and retention needs have been reviewed.

Disable access first. Then follow the organization’s approved preservation and deletion process.

Does changing the employee’s password revoke every session?

Not necessarily.

Existing browser sessions, refresh tokens, mobile applications, trusted devices, and third-party platforms may require separate action.

What if the former employee used a personal device?

Confirm what organizational information and access remain on the device.

Use approved mobile-device-management actions where available and authorized. Do not wipe personally owned equipment without confirming ownership, authority, and data-preservation requirements.

Should contractors follow the same offboarding process?

Yes.

Contractors, temporary employees, volunteers, students, and vendor technicians may have access to the same sensitive systems as regular employees.

How often should the offboarding checklist be reviewed?

Review it at least annually and after major changes to applications, vendors, locations, staffing models, or regulatory requirements.

It should also be reviewed after an offboarding failure or security incident.

Strengthen Your Healthcare Access-Management Process

Vault Technologies helps healthcare organizations improve Microsoft 365 and Entra ID administration, endpoint management, access controls, onboarding and offboarding procedures, vendor coordination, technical documentation, and care-continuity planning.

Our nurse-led clinical perspective helps keep technical controls connected to actual workflows, shift coverage, and patient or resident care.

Request a complimentary Technology Health Assessment to identify practical gaps in identity management, endpoint operations, documentation, backup planning, and care-continuity readiness.

The assessment is a planning tool. It is not a legal opinion, compliance certification, penetration test, forensic investigation, or guarantee against cyber incidents.

Authoritative Sources

HHS: Summary of the HIPAA Security Rule — updated August 7, 2026.

HHS: Security Standards—Administrative Safeguards — revised March 2007.

Microsoft: Remove a Former Employee — updated June 15, 2026.

Microsoft: Revoke User Access in Microsoft Entra ID — updated June 19, 2026.

Microsoft: Lifecycle Workflows Tasks and Definitions — updated July 29, 2026.

Microsoft: Execute Employee Termination Tasks Using Lifecycle Workflows — updated March 12, 2026.

Actively Exploited Windows Shell Flaw: What Healthcare Organizations Should Verify

Mon, 19 Oct 2026 22:32:53 GMT

Microsoft released its October security updates on October 13, 2026, addressing an actively exploited Windows Shell vulnerability.

The vulnerability is rated High, with a CVSS score of 8.8.

For healthcare organizations, the immediate priority is verifying that supported Windows devices received the applicable update.

QUICK ANSWER

Ask your IT provider to verify successful installation, identify failed or offline devices, complete required restarts, and document unresolved exceptions.

What Dental Practices Can Learn from a $350,000 Ransomware Settlement

Mon, 19 Oct 2026 15:18:23 GMT

Updated October 19, 2026

A $350,000 settlement involving an Indiana dental group shows why ransomware response cannot end when computers return to service.

The settlement addressed allegations involving a 2020 ransomware incident, delayed breach reporting, patient-record access, privacy practices, and compliance with federal and Indiana law.

The case does not prove that every ransomware incident will result in a penalty. It does show how an incomplete investigation, unclear reporting process, and unresolved privacy issues can expand the consequences of an already disruptive event.

Quick Answer: What should dental practices learn from this settlement?

A dental practice should treat ransomware as a business, patient-care, privacy, and legal event—not merely a computer problem.

The response should include:

Containing the incident without destroying evidence
Determining which systems and information may be affected
Preserving available alerts, logs, and vendor communications
Engaging appropriate technical, legal, privacy, insurance, and leadership resources
Restoring systems through tested procedures
Evaluating applicable notification obligations
Documenting decisions, findings, exceptions, and follow-up work

No security product guarantees that ransomware will be stopped. No backup system guarantees immediate recovery without data loss. The goal is to establish multiple safeguards and a documented response process before an incident occurs.

What happened in the Indiana dental case?

According to a complaint filed by the Indiana Attorney General on December 23, 2024, a ransomware attack occurred around October 20, 2020, and involved a server at an Indiana dental location.

The state alleged that the server contained information that included dental records, images, treatment information, insurance information, and biometric data.

The complaint also alleged that the incident was not reported to the Indiana Attorney General until October 28, 2022—approximately two years later.

A federal court entered a consent judgment on January 2, 2025. The dental entities agreed to pay $350,000 and complete corrective measures addressing data protection, patient privacy, policies, and employee training.

The consent judgment resolved the state’s allegations. The dental entities denied the allegations and did not admit wrongdoing.

That distinction matters. Public discussion of the case should not present every allegation as an independently proven fact.

Was this a $350,000 HIPAA settlement?

Calling it only a “HIPAA settlement” leaves out important context.

The State of Indiana brought the case, and the complaint included alleged violations of HIPAA and multiple Indiana laws. The settlement resolved those allegations without an admission of liability.

The payment should therefore be described as a $350,000 state settlement involving alleged federal and state privacy, security, notification, and consumer-protection violations.

This article provides general technical and operational information. It is not legal advice, and organizations should consult qualified legal and privacy professionals about their specific obligations.

Why the reporting timeline matters

The HIPAA Breach Notification Rule generally requires covered entities to provide required notifications following a breach of unsecured protected health information without unreasonable delay and no later than 60 calendar days after discovering the breach.

The exact obligations depend on the facts, the information involved, the organization’s role, the results of the required assessment, and other applicable federal or state laws.

A cybersecurity incident does not become less important because systems appear to be working again.

After containment, leadership still needs answers:

Was protected health information accessed, acquired, altered, or unavailable?
What evidence is available?
Which patients or employees may be affected?
When was the incident discovered?
Who is responsible for the breach assessment?
Which federal and state notification rules may apply?
What deadlines must be tracked?
Who has authority to approve notifications?
What corrective actions remain unresolved?

These decisions should be coordinated with appropriate legal and privacy professionals. An IT provider can support the technical investigation, preservation, restoration, documentation, and coordination process, but should not make legal determinations outside its role.

What dental practices should review before an incident

1. System and data inventory

A practice should know which systems store or process patient information.

The inventory may include:

Practice-management systems
Electronic dental or health records
Digital imaging systems
Intraoral camera workstations
Insurance and billing applications
Scheduling systems
Email and Microsoft 365
File servers
Cloud-storage platforms
Backup systems
Patient communication tools
Third-party vendor portals

The inventory should identify the responsible owner, support vendor, location, authentication method, backup status, and recovery priority for each system.

2. Vendor responsibilities

Dental practices frequently rely on several technology vendors.

One company may support the network. Another may host the practice-management application. A separate vendor may manage imaging equipment, billing, backups, email, or patient communications.

Leadership should know:

Who receives security alerts
Who can access systems remotely
Who preserves technical evidence
Who contacts the cyber-insurance carrier
Who coordinates with legal counsel
Who restores each system
Who communicates with affected employees or patients
Who tracks unresolved actions

“Contact the IT company” is not a complete incident-response plan.

3. Backup coverage

A backup strategy should identify what is protected, how frequently it is copied, where the copies are stored, and how restoration will be performed.

Practices should verify:

Critical servers and applications are included
Backup failures are monitored
Appropriate copies are isolated or otherwise protected
Backup administration uses controlled access
Retention periods support operational needs
Restoration procedures are documented
Recovery tests are performed periodically

Backups can reduce operational harm, but they do not determine whether information was accessed or whether notification obligations exist.

Restoration time also depends on the damage, available equipment, application dependencies, backup integrity, vendor availability, and the amount of data involved.

4. Access controls

Practices should review:

Multifactor authentication
Shared accounts
Local administrator privileges
Former employee access
Vendor accounts
Remote-support tools
Service accounts
Password and credential practices
Access to backup consoles

Every person and vendor should have only the access required for their role.

5. Logging and endpoint visibility

Endpoint protection, device management, security alerts, and system logs can help an organization identify suspicious activity and reconstruct events.

However, monitoring does not guarantee that every attack will be detected before damage occurs.

The practice should know:

Which devices are monitored
Which systems generate alerts
Who reviews the alerts
How long relevant records are retained
What happens when a device stops checking in
How urgent alerts are escalated
Whether vendor-controlled systems are included

A tool that is installed but not monitored, updated, or assigned to an owner provides limited protection.

What should a dental practice do during suspected ransomware?

Protect people, systems, and evidence

Employees should use the approved emergency contact process immediately.

When technically and clinically appropriate:

Disconnect affected devices from the network.
Avoid continuing to open suspicious files.
Do not delete ransom notes or security alerts.
Do not wipe or rebuild devices without authorization.
Preserve screenshots, timestamps, alerts, and vendor communications.
Prevent additional users from accessing affected systems.

Actions should be coordinated carefully. Abruptly shutting down systems or deleting files can destroy evidence or interfere with recovery.

Activate the response team

The response may require coordination among:

Practice leadership
The responsible IT provider
Cyber-insurance contacts
Qualified legal counsel
Privacy or compliance personnel
Application and equipment vendors
Communications support
Other specialized professionals when warranted

The appropriate team depends on the incident and the organization’s existing agreements.

Maintain patient-care operations

The practice should activate documented downtime procedures when important systems are unavailable.

That may include:

Alternate scheduling procedures
Paper documentation
Manual patient check-in
Alternate methods for viewing essential information
Procedures for urgent referrals
Communication with laboratories and pharmacies
Rescheduling criteria
Manual payment or billing procedures
A method for entering information after systems return

Downtime procedures should be prepared and tested before they are needed.

Why this matters to dental practices

Dental practices may be small businesses, but they maintain valuable information and depend on specialized technology.

A single server or workstation may support:

Patient charts
Diagnostic images
Treatment plans
Insurance information
Scheduling
Billing
Prescriptions
Referrals
Patient communications

Many practices also rely on outside vendors to maintain equipment and applications. That can make responsibility unclear unless access, support, backup, and escalation duties are documented.

A ransomware response must therefore address more than malware removal. It must account for patient-record availability, vendor coordination, evidence preservation, recovery, communication, and applicable reporting obligations.

Protect, Operate, Recover, and Grow

Protect

Maintain an accurate inventory of systems, devices, data, and vendors.
Require multifactor authentication where supported.
Limit administrative privileges.
Remove inactive employee and vendor accounts.
Maintain managed endpoint protection.
Keep supported systems updated.
Protect backup administration separately from everyday user access.

Operate

Establish one approved process for reporting suspected incidents.
Document technical, leadership, legal, privacy, and insurance contacts.
Assign responsibility for monitoring security alerts.
Review remote vendor access.
Maintain accessible downtime procedures.
Train employees to recognize and report unusual computer behavior.
Document unresolved risks and exceptions.

Recover

Preserve available evidence before rebuilding systems.
Verify backup integrity before restoration.
Prioritize systems based on patient-care and operational needs.
Coordinate restoration with application vendors.
Validate critical applications before normal use resumes.
Reset credentials or revoke sessions when evidence supports that action.
Record what was restored, what remains unavailable, and who owns each follow-up task.

Grow

Test restoration procedures periodically.
Review incident-response and downtime plans annually.
Include security and notification responsibilities in vendor agreements.
Replace unsupported systems.
Review cyber-insurance requirements before an incident.
Conduct a technology assessment before expanding locations or adopting new clinical systems.
Use lessons from incidents and exercises to improve documentation.

The bottom line

The most important lesson from the Indiana dental settlement is not that one security product would have prevented every consequence.

The lesson is that an organization needs a coordinated process for investigation, documentation, restoration, communication, and legal review.

A practice should know which systems matter, where its information resides, who receives alerts, who has decision-making authority, how recovery will work, and how possible notification obligations will be evaluated.

Technology controls reduce risk. Clear responsibility and documented response procedures prevent confusion from becoming another incident.

Frequently asked questions

Was the dental practice fined $350,000 solely for a HIPAA violation?

No. The Indiana settlement resolved state allegations involving HIPAA and several Indiana laws. The dental entities denied the allegations and admitted no wrongdoing under the consent judgment.

When did the reported ransomware incident occur?

The Indiana Attorney General alleged that the incident occurred around October 20, 2020. The state’s complaint said a breach notification was submitted to the Indiana Attorney General on October 28, 2022.

Does every ransomware incident constitute a reportable HIPAA breach?

The answer depends on the facts and the applicable legal analysis. A regulated organization should promptly involve qualified legal and privacy professionals rather than assume an incident is or is not reportable.

How quickly must a HIPAA breach be reported?

The HIPAA Breach Notification Rule generally requires applicable notifications without unreasonable delay and no later than 60 calendar days after discovery. Other deadlines and state laws may also apply.

Do backups eliminate the need for a breach investigation?

No. Backups may help restore unavailable information, but they do not establish whether information was accessed, acquired, altered, or disclosed.

Can endpoint monitoring guarantee that ransomware will be stopped?

No. Monitoring and endpoint protection can improve visibility and may help detect suspicious activity, but no tool guarantees prevention or detection before damage occurs.

What should a small dental practice do first?

Start by documenting critical systems, vendors, administrative access, backup responsibilities, incident contacts, notification decision-makers, and downtime procedures.

Strengthen your dental practice’s technology readiness

Vault Technologies helps medical and dental practices improve endpoint administration, Microsoft environments, access controls, vendor coordination, backup planning, incident procedures, technical documentation, and care-continuity readiness.

Our nurse-led perspective keeps technical planning connected to patient care, employee workflows, scheduling, and the safe operation of the practice.

Request a complimentary Technology Health Assessment to establish a practical baseline and identify which technology issues should be addressed now, next, or later.

The assessment is a planning tool. It is not legal advice, a compliance certification, a penetration test, a forensic investigation, or a guarantee against cybersecurity incidents.

Authoritative sources

Federal court docket—State of Indiana v. Westend Dental and related entities , complaint filed December 23, 2024; consent judgment entered January 2, 2025.
Indiana Attorney General’s filed complaint , filed December 23, 2024.
HHS Office for Civil Rights—Breach Notification Rule , current federal guidance accessed October 19, 2026.
Indianapolis Business Journal—Dental office agrees to pay state $350K after data breach, privacy investigation , published December 31, 2024.
Becker’s Dental Review—Indiana dental practice agrees to pay $350K after data breach: 8 things to know , published January 2, 2025.

Medical Practice Ransomware Attack Exposes 934,000 Patient Records

Mon, 19 Oct 2026 15:15:00 GMT

Medical Practice Ransomware Attack Exposes 934,000 Patient Records

Updated October 19, 2026

A ransomware attack against a multi-location Maryland healthcare organization exposed information belonging to 934,326 people. The incident shows why medical practices must protect shared file servers—not only their electronic health record systems.

Quick Answer: What can medical practices learn from this ransomware attack?

Medical practices should inventory every location where patient information is stored, restrict access to shared files, monitor unusual activity, maintain tested backups, and document how the organization will continue operating during an outage.

Protecting the EHR alone is not enough. Patient information may also exist in shared drives, scanned documents, billing folders, email, exported reports, employee computers, and vendor-managed systems.

What happened in the ransomware attack?

The healthcare organization detected a ransomware event on January 27, 2025, and took affected information systems offline.

Its investigation found that an unauthorized person accessed the network and copied files from a shared file server. The organization reported the incident to the U.S. Department of Health and Human Services Office for Civil Rights on March 28, 2025.

The federal breach listing identified 934,326 affected individuals.

The organization stated that the electronic medical record system was not compromised. However, files outside the EHR contained sensitive patient information.

This distinction matters. A secure or unaffected EHR does not mean every copy of patient information is equally protected.

What patient information was involved?

The information varied by individual and reportedly included combinations of:

Names
Mailing addresses
Dates of birth
Social Security numbers
Driver’s license numbers
Medical record numbers
Health insurance information
Clinical information related to patient care

The incident demonstrates how a shared file server can contain information just as sensitive as data stored inside an EHR.

Did the ransomware attack interrupt patient care?

The organization took systems offline and reported service delays while it investigated and restored operations. Most facilities remained open, using established backup and downtime procedures.

This is an important care-continuity lesson.

A healthcare cybersecurity incident is not only a privacy or technology problem. It may affect scheduling, prescription processing, documentation, referrals, billing, communications, and access to information needed for patient care.

Were lawsuits filed after the breach?

Yes. Public reporting identified multiple proposed class-action lawsuits following the breach.

The plaintiffs alleged that the organization failed to use reasonable cybersecurity safeguards and did not provide adequate information in its breach notifications. These are allegations presented in civil litigation; they are not the same as final findings by a court or regulator.

As of the sources reviewed for this article, the litigation should not be described as a confirmed regulatory violation or final settlement.

Why shared file servers create healthcare risk

Shared drives are common in medical and dental practices. They may hold referral documents, scanned identification, insurance records, billing exports, employee files, clinical forms, or information temporarily downloaded from another system.

Over time, these folders can become difficult to manage.

Common problems include:

Too many employees having access
Former employees retaining permissions
Sensitive files being stored without a defined owner
Copies remaining after their original purpose has ended
Limited monitoring of file access
Inconsistent retention and deletion practices
Backups that have never been tested
Patient information being exported from the EHR and forgotten

A shared drive is not automatically insecure. The risk increases when the organization does not know what it contains, who can access it, or how activity is monitored.

What should healthcare organizations review now?

1. Identify where patient information is stored

Create an inventory that includes more than the EHR.

Review:

Shared network drives
Microsoft 365 and SharePoint
OneDrive accounts
Local computer folders
Scanned-document repositories
Billing and accounting systems
Email mailboxes
Backup systems
Vendor portals
Removable storage devices

The inventory does not need to contain patient information. It should identify the system, data owner, business purpose, responsible vendor, backup method, and access requirements.

2. Review access to shared files

Employees should have access only to the information required for their responsibilities.

Review access when:

An employee joins the organization
A job role changes
An employee leaves
A contractor’s assignment ends
A vendor relationship changes
A new office or department is added

Administrative accounts should be separate from ordinary user accounts whenever practical. Multifactor authentication should be used where the system supports it.

3. Reduce unnecessary copies

Staff may download reports or patient lists to complete a task and then leave those files on a desktop, shared drive, or downloads folder.

Create a defined process for:

Approving data exports
Selecting an appropriate storage location
Restricting access
Setting retention periods
Securely removing files when they are no longer needed

The goal is not to disrupt legitimate work. It is to prevent temporary files from becoming permanent, unmanaged records.

4. Monitor important systems

Monitoring can help identify unusual logins, unexpected administrative changes, suspicious file activity, security-agent failures, and other warning signs.

No monitoring system guarantees immediate detection. Its effectiveness depends on the systems covered, the quality of available logs, alert configuration, retention settings, and who is responsible for responding.

Healthcare organizations should document:

Which systems are monitored
Which events generate alerts
Who receives each alert
How quickly alerts are reviewed
What happens when the primary contact is unavailable
How actions and decisions are recorded

5. Test backups and restoration

A successful backup notification does not prove that systems can be restored within the time patient care requires.

Testing should answer:

Which systems are included?
Is another protected copy available?
How often are backups completed?
Who receives failure alerts?
How long would restoration take?
Which system must be restored first?
Can the organization continue working during restoration?
When was the last successful recovery test?

Backup planning should be tied to clinical and operational priorities—not merely storage capacity.

6. Maintain a practical downtime plan

A downtime plan should explain how staff will continue essential work when technology is unavailable.

Depending on the organization, this may include:

Accessing current schedules
Documenting care
Processing urgent prescriptions
Contacting clinicians and caregivers
Receiving laboratory or imaging results
Verifying patient information
Handling referrals
Communicating with vendors
Restoring data to the correct systems afterward

The plan should identify decision-makers, approved communication channels, printed resources, vendor contacts, and the conditions for returning systems to service.

7. Prepare incident documentation before an emergency

An incident response plan should establish who coordinates technical work, leadership decisions, patient-care operations, vendor communication, legal review, insurance notification, and regulatory reporting.

Healthcare organizations should not improvise breach notifications or make legal conclusions without qualified guidance.

Vault Technologies can support technical coordination, system documentation, access review, recovery planning, and care-continuity preparation. Legal determinations, breach-notification obligations, and forensic conclusions should be handled by the appropriate legal, compliance, insurance, and specialized investigative professionals.

Why this matters to healthcare organizations

Independent medical and dental practices

Small practices may rely on one shared drive for scanned forms, insurance documents, reports, and administrative files. A single compromised account or device may therefore reach a large collection of sensitive information.

Hospice and home-health providers

Patient information may move among office staff, clinicians, mobile devices, email, cloud storage, and vendor platforms. Clear ownership and access controls are essential when employees work across many locations.

Assisted-living and senior-living organizations

Technology disruptions can affect nursing stations, medication-related workflows, resident documentation, staffing communications, and family coordination. Recovery priorities should reflect care needs and shift operations.

Outpatient clinics

Clinics often depend on multiple connected systems and vendors. A working EHR does not eliminate risks involving file storage, Microsoft 365, billing platforms, imaging systems, or local endpoints.

A practical Protect, Operate, Recover, and Grow plan

Protect

Require multifactor authentication where supported.
Apply least-privilege access to shared files.
Remove inactive accounts promptly.
Keep operating systems and applications current.
Protect endpoints with centrally managed security controls.
Separate administrative access from routine user activity.

Operate

Maintain an inventory of systems and data locations.
Assign an owner to every shared repository.
Document onboarding, role changes, and offboarding.
Review important security alerts.
Coordinate access with EHR, billing, cloud, and other vendors.
Keep technical procedures current and usable.

Recover

Maintain protected backups appropriate to the organization’s risk.
Test recovery procedures.
Establish system-restoration priorities.
Maintain EHR and communications downtime procedures.
Preserve relevant records when an incident occurs.
Document technical actions, decisions, and unresolved risks.

Grow

Include security and recovery requirements in vendor reviews.
Reassess technology when locations or services change.
Reduce duplicate and outdated data repositories.
Use incident exercises to improve procedures.
Connect technology planning to clinical operations and care continuity.

The bottom line

This incident did not require attackers to compromise the organization’s EHR to expose patient information. A shared file server contained enough sensitive data to affect more than 934,000 people.

Healthcare organizations should know where patient information exists, limit who can reach it, monitor important systems, test recovery, and prepare for clinical downtime.

The objective is not to promise that every incident can be prevented. It is to reduce avoidable exposure, identify problems sooner, and keep patient care moving when technology fails.

Frequently Asked Questions

Can ransomware expose patient information without compromising the EHR?

Yes. Patient information may exist in shared drives, email, scanned documents, billing exports, local folders, backups, and vendor systems. Each location requires appropriate access controls and oversight.

Should medical practices stop using shared drives?

Not necessarily. Shared drives can support legitimate workflows. They should have a defined purpose, responsible owner, limited permissions, appropriate monitoring, backup coverage, and retention rules.

Does multifactor authentication prevent ransomware?

MFA can reduce the risk associated with stolen passwords, but it cannot prevent every ransomware incident. It should be combined with patching, endpoint security, access controls, monitoring, backups, staff awareness, and incident planning.

Are backups enough to recover from ransomware?

No. Backups are essential, but organizations must also verify that backups are protected, complete, and recoverable. Recovery procedures should be tested before an emergency.

What is least-privilege access?

Least privilege means giving each employee, contractor, or vendor only the access required for their responsibilities. Permissions should be updated when roles or relationships change.

How often should healthcare organizations test recovery?

The appropriate schedule depends on operational risk, system changes, contractual requirements, and care-continuity needs. Critical systems should be tested on a documented schedule and after significant changes.

Can an IT provider determine whether a HIPAA breach occurred?

An IT provider can help establish technical facts and preserve relevant documentation. Legal counsel and qualified privacy or compliance professionals should determine notification and regulatory obligations.

Strengthen your healthcare technology readiness

Vault Technologies helps healthcare organizations improve endpoint administration, Microsoft environments, access controls, technical documentation, backup planning, vendor coordination, and care-continuity readiness.

Our nurse-led clinical perspective keeps technology decisions connected to patient care and real healthcare workflows.

Request a complimentary Technology Health Assessment to identify practical technology risks and priorities.

The assessment is a planning tool. It is not a legal opinion, compliance certification, penetration test, forensic investigation, or guarantee against cyber incidents.

Sources

HHS Office for Civil Rights Breach Portal , breach reported March 28, 2025.
BleepingComputer: Frederick Health data breach impacts nearly 1 million patients , published April 24, 2025.
HIPAA Journal: Ransomware Attack on Frederick Health Medical Group Affects 934,000 Patients , published April 28, 2025.
Becker’s Hospital Review: Maryland hospital faces four lawsuits over ransomware breach , published April 22, 2025.
Becker’s Hospital Review: Ransomware attack prompts Maryland hospital to take systems offline , published January 27, 2025.

Healthcare IT and Care Continuity | Vault Technologies

Mon, 19 Oct 2026 02:50:39 GMT

Updated October 19, 2026

Healthcare organizations depend on technology for scheduling, documentation, communication, billing, medication workflows, and access to patient information.

When technology fails, the effect isn’t limited to computers. Staff lose time, clinical workflows slow down, and patient or resident care may be disrupted.

Vault Technologies focuses on reducing that risk. We provide healthcare-focused managed IT, cybersecurity, Microsoft administration, endpoint support, backup planning, documentation, and technology guidance for small-to-midsize organizations.

Quick Answer: What makes Vault Technologies different?

Vault combines practical IT experience with a nurse-led understanding of healthcare operations.

That means technology decisions are evaluated against the realities of patient care, shared workstations, remote staff, shift changes, vendor dependencies, limited budgets, and systems that cannot simply be taken offline without planning.

Our goal is straightforward: reduce technology risk, disruption, and uncertainty so healthcare teams can focus on the people they serve.

Why Vault focuses on healthcare IT

Healthcare organizations have many of the same technology needs as other businesses, but the operational consequences are different.

A failed workstation in an ordinary office may delay an administrative task. In a medical practice, hospice agency, or senior-living organization, that same failure may interfere with documentation, medication workflows, care coordination, scheduling, or access to important information.

Healthcare organizations also operate within a complex environment of privacy obligations, outside vendors, electronic health record systems, mobile workers, shared devices, and limited maintenance windows.

Vault’s approach keeps those operational realities in view. Security matters, but security controls must be implemented in a way that also supports safe and dependable daily operations.

A nurse-led clinical perspective

Vault’s co-founder, Kristina Anderson, brings 15 years of nursing experience, including hospice and home-health care.

That clinical background helps connect technology planning to the way care is actually delivered.

For example:

A workstation restart may need to be coordinated around medication administration or patient appointments.
A home-health device may remain offline long enough to miss an important update.
An EHR outage may require documented downtime procedures that employees can find without accessing the unavailable system.
A shared nursing-station computer may support several shifts and require carefully planned maintenance.
A vendor-controlled clinical system may need coordination between the healthcare organization, its IT provider, and the application vendor.

Technical recommendations are more useful when they account for these circumstances from the beginning.

Who Vault Technologies serves

Vault primarily supports small-to-midsize healthcare and regulated organizations, including:

Independent medical practices
Dental practices
Assisted-living organizations
Senior-living communities
Hospice providers
Home-health agencies
Outpatient clinics
Other organizations that depend on secure and reliable access to sensitive information

These organizations may not have a large internal IT department, but they still need clear ownership, dependable support, secure systems, and documented recovery plans.

What does healthcare-focused managed IT include?

The exact service plan depends on the organization’s size, systems, risks, operating hours, and existing vendor relationships.

Vault’s supported capabilities include:

Responsive remote help-desk and clinical IT support
Windows endpoint administration
Microsoft 365 support
Microsoft Entra ID and Active Directory administration
Microsoft Intune and device-management support
User onboarding and offboarding
Multifactor authentication and access-control support
Network and systems administration
Patch and update coordination
Secure endpoint support
Backup and recovery planning
EHR access troubleshooting
Vendor coordination
Incident-management support
Technology assessments and planning
Standard operating procedures and knowledge documentation
HIPAA-aware and compliance-aligned technical operations

Vault does not present these services as a guarantee that an incident will never occur. The purpose is to reduce avoidable risk, improve visibility, respond consistently, and strengthen the organization’s ability to continue operating.

Why documentation matters

Healthcare technology often involves several responsible parties.

An internal employee may manage one system. An EHR vendor may control another. A managed service provider may support the computers and network. A copier, imaging, laboratory, pharmacy, or specialty-application vendor may maintain additional equipment.

Without clear documentation, important questions can go unanswered:

Which company supports each system?
Who can access it remotely?
Which devices are still under warranty?
When was the last successful backup?
Who receives security alerts?
What should staff do during an outage?
Who removes access when an employee leaves?
Which vendor should be contacted first?

Vault emphasizes practical documentation because it supports daily operations, employee transitions, incident response, vendor coordination, audits, and recovery.

Good documentation should be understandable, current, and available when the primary system is not.

Care continuity should guide technology planning

Healthcare technology planning should not stop at preventing an outage.

Organizations also need to consider how care will continue when a system, vendor, internet connection, or device becomes unavailable.

A useful continuity plan identifies:

The systems that support critical workflows
The maximum tolerable interruption for each workflow
Available alternate devices or procedures
Vendor and escalation contacts
Backup and restoration responsibilities
Communication procedures
Paper or offline alternatives when appropriate
The process for safely returning to normal operations

These plans should be reviewed and tested before an actual disruption.

Protect, Operate, Recover, and Grow

Vault organizes technology planning around four practical goals.

Protect

Protection begins with understanding what exists and controlling access to it.

Healthcare organizations should:

Maintain an accurate inventory of devices, systems, applications, and vendors.
Require multifactor authentication where supported.
Remove access promptly when employees or vendors no longer need it.
Keep supported systems updated.
Limit administrative privileges.
Maintain appropriate endpoint protection.
Establish clear rules for approved applications and AI tools.

Operate

Reliable operations require more than responding when something breaks.

Organizations should:

Provide employees with an approved support channel.
Document ownership of important systems.
Track unresolved technology issues.
Coordinate updates around clinical workflows.
Maintain onboarding and offboarding procedures.
Review vendor access periodically.
Keep recovery and downtime instructions accessible.

Recover

A backup is useful only if the required information can be restored when needed.

Organizations should:

Identify which systems and data require backup.
Confirm who is responsible for each backup.
Monitor backup completion.
Protect backup access.
Maintain an appropriate offsite or isolated copy.
Test restoration procedures.
Document who makes recovery decisions during an incident.

Grow

Technology should support the organization’s plans rather than become an obstacle to them.

Organizations should:

Review technology before opening a new location.
Include IT requirements when selecting a new vendor.
Budget for aging devices and unsupported software.
Standardize equipment and configurations where practical.
Review licensing before adding employees.
Evaluate security and continuity risks before adopting new applications.
Maintain a written technology roadmap.

What should a healthcare organization expect from an IT partner?

A dependable IT partner should be able to explain:

What systems it manages
What is excluded from its responsibility
How employees request support
How urgent issues are escalated
How updates are deployed and verified
How administrative access is controlled
How vendors are coordinated
How documentation is maintained
How unresolved risks are communicated
How technology decisions support operational continuity

Leadership should not have to rely on vague assurances that everything is being handled.

Clear scope, written responsibilities, visible exceptions, and regular communication create a stronger working relationship.

Remote-first support with local accountability

Vault provides remote-first services that allow many support and administrative issues to be addressed without waiting for an onsite visit.

Direct service is available in Cottage Grove, Eugene, Springfield, and the broader Lane County area. Scheduled onsite service is limited to Vault’s Eugene-area service region when included in the applicable scope of work.

This approach provides practical support while keeping service boundaries and expectations clear.

Veteran-owned and built around accountability

Vault Technologies is a veteran-owned small business.

That identity is reflected in how we approach service: establish clear responsibilities, document the work, communicate directly, and follow through on unresolved issues.

Accountability does not mean promising that technology will never fail. It means making the environment easier to understand, operate, support, and recover.

The bottom line

Healthcare organizations need more than someone who can repair a computer.

They need technology support that accounts for clinical workflows, sensitive information, outside vendors, shared devices, remote staff, care continuity, and limited operating margins.

Vault Technologies brings together managed IT, cybersecurity, Microsoft administration, endpoint support, documentation, recovery planning, and a nurse-led clinical perspective.

The goal is not to add unnecessary complexity. It is to create a dependable technology foundation that supports employees and protects the organization’s ability to serve patients and residents.

Frequently asked questions

What types of healthcare organizations does Vault support?

Vault focuses on small-to-midsize medical and dental practices, assisted-living and senior-living organizations, hospice and home-health providers, outpatient clinics, and other regulated organizations.

Does Vault provide remote IT support?

Yes. Vault uses a remote-first service model for help-desk support, endpoint administration, Microsoft services, access issues, vendor coordination, and many other technology needs.

Does Vault provide onsite service?

Scheduled onsite service may be available within Vault’s Eugene-area service region when included in the applicable scope of work. Remote service may be available more broadly.

Can Vault help with Microsoft 365 and Entra ID?

Yes. Vault supports Microsoft 365, Entra ID, Active Directory, Intune, identity administration, access controls, multifactor authentication, and related endpoint operations.

Can Vault help with HIPAA?

Vault provides HIPAA-aware and compliance-aligned technical operations, documentation, access controls, endpoint support, and technology planning. Vault does not provide legal opinions or guarantee that an organization is compliant.

Can Vault help prepare for an IT outage?

Yes. Vault can help identify critical systems, clarify responsibilities, document downtime procedures, review backup and recovery planning, and connect technology decisions to care-continuity needs.

What is a Technology Health Assessment?

A Technology Health Assessment provides a practical review of areas such as endpoint management, Microsoft services, access controls, vendor responsibilities, backup readiness, documentation, security, and operational continuity.

Start with a practical technology baseline

Organizations do not need to replace every system or solve every risk at once.

The first step is understanding what exists, identifying the most important gaps, and deciding what should be addressed now, next, or later.

Request a complimentary Technology Health Assessment to establish a practical baseline for your organization.

The assessment is a planning tool. It is not a legal opinion, compliance certification, penetration test, forensic investigation, or guarantee against technology or cybersecurity incidents

Healthcare IT Documentation Starter Kit: 12 Records Every Practice Should Maintain

Mon, 12 Oct 2026 18:41:00 GMT

Healthcare technology documentation should tell authorized staff what the organization uses, who supports it, how it is protected, and what to do when something fails.

It does not have to begin as a complex policy library. A small practice can start with a controlled set of accurate records covering its systems, devices, vendors, access, backups, downtime procedures, and technology priorities.

Quick Answer: What IT documentation should a healthcare organization maintain?

At minimum, maintain these 12 records:

Technology ownership and contact list
System and application inventory
Device and asset inventory
User and access register
Vendor and business-associate register
Network and connectivity diagram
Backup and recovery record
Downtime and emergency-mode procedures
Employee onboarding and offboarding checklist
Technology change and maintenance log
Incident-response contact and action sheet
Technology lifecycle and improvement roadmap

Give every record an owner, storage location, last-reviewed date, and next-review date. Update it after material technology or organizational changes.

This starter kit supports orderly, HIPAA-aware technical operations. It is not a legal opinion, compliance certification, or substitute for an organization-specific risk analysis.

Why healthcare IT documentation becomes unreliable

Documentation commonly becomes unusable because it is:

Stored in personal email or on one employee’s computer
Written once and never reviewed
Mixed with obsolete versions
Missing an identified owner
Filled with unexplained abbreviations
Inaccessible during an internet or identity-system outage
Overloaded with passwords that should be stored elsewhere
Maintained entirely by a vendor without an accessible customer copy

Good documentation should help an authorized person answer an operational question quickly.

For each record, include:

Document owner
Approved storage location
Information classification
Date last reviewed
Date or event triggering the next review
Approver, when appropriate
Related vendor, system, or procedure
Version or change history

The 12 essential healthcare IT records

1. Technology ownership and contact list

Start with a short directory identifying who owns important technology decisions and whom staff should contact when something goes wrong.

Include:

Internal technology decision-maker
Privacy and security contacts
Practice manager or administrator
Approved help-desk number and email address
EHR and practice-management support contacts
Internet, telephone, imaging, laboratory, pharmacy, billing, and medical-device contacts
Cyber-insurance reporting contact
After-hours escalation instructions
Alternate contacts if the primary person is unavailable

Clearly distinguish ordinary support requests from outage, privacy, safety, and security escalation paths.

Review this record whenever staff, vendors, contracts, or telephone numbers change.

2. System and application inventory

List the applications and services the organization depends on to provide care and conduct business.

For every system, record:

Product and vendor name
Business or clinical purpose
Internal owner
Vendor support contact
Web address or access method
Information handled by the system
Operational criticality
Authentication method and MFA availability
Important integrations
Contract or renewal date
Downtime alternative
Data export or termination procedure
Responsible IT provider

Include cloud services, EHR platforms, Microsoft 365, scheduling tools, billing applications, e-prescribing services, imaging software, secure messaging, backup platforms, and specialty clinical systems.

Do not assume a cloud application is automatically documented, recoverable, or owned by the IT provider.

3. Device and asset inventory

A device inventory shows what equipment exists, where it is, who uses it, and whether it is still supportable.

Recommended fields include:

Asset name or tag
Manufacturer, model, and serial number
Device type
Assigned person or department
Physical location
Operating system
Encryption status
Endpoint-management status
Security-software status
Warranty expiration
Purchase or deployment date
Expected replacement date
Disposal status

Include servers, workstations, laptops, tablets, smartphones, firewalls, switches, wireless access points, scanners, printers, backup devices, and shared clinical equipment when the organization is responsible for them.

CISA includes logical and physical asset inventory among its ransomware-risk reduction recommendations. CISA

4. User and access register

The access register documents who can reach important systems and why.

Record:

User name
Employment or contractor status
Department and role
Systems assigned
Access level
Administrative privileges
MFA status
Access approver
Date access was granted
Last access review
Expected removal date for temporary access

Prioritize privileged accounts, shared devices, vendor identities, service accounts, remote access, and users with access to sensitive information.

Do not place passwords, recovery codes, private keys, or reusable MFA secrets in the register. Store secrets in an approved password-management system with restricted access.

5. Vendor and business-associate register

Healthcare organizations frequently depend on vendors that store information, support systems, or connect remotely to their environment.

For each vendor, record:

Legal business name
Service provided
Internal owner
Primary and emergency contacts
Systems or devices accessed
Information received, created, maintained, or transmitted
Remote-access method
Business associate agreement status, when applicable
Security-notification requirements
Contract and renewal dates
Data return or destruction terms
Account and access-removal process
Replacement or continuity considerations

The register is an operational tool, not a legal determination that a particular vendor is—or is not—a business associate. Contract and regulatory questions should be reviewed by qualified legal or compliance professionals.

6. Network and connectivity diagram

A current network diagram helps a support provider understand how offices, internet connections, wireless networks, and critical devices relate to one another.

It should identify:

Internet provider and circuit
Firewall and router
Network switches
Wireless access points and network names
Servers and storage devices
Major network segments or VLANs
Site-to-site and remote connectivity
Voice and telephone services
Backup internet connection
Network closets and power protection
Critical systems that depend on the connection

Keep the diagram understandable. A one-page overview plus a restricted technical appendix is often more useful than an enormous engineering diagram.

Do not place passwords, private keys, or other reusable secrets directly on the diagram.

7. Backup and recovery record

A backup record should explain what is protected and demonstrate whether recovery has been tested.

For each system or data set, record:

Data or workload being protected
Backup owner
Backup destination
Backup frequency
Retention period
Encryption status
Latest successful backup
Failed-backup escalation process
Last restore test
Restore-test result
Recovery dependencies
Recovery time and recovery point objectives, if established
Vendor contact and contract details

A successful backup notification does not prove that an organization can restore a usable system. Restoration should be tested at a scale and frequency appropriate to the organization’s risk.

HHS identifies data backup, disaster recovery, and emergency-mode operations as elements of Security Rule contingency planning for regulated entities. HHS.gov

8. Downtime and emergency-mode procedures

Downtime procedures connect technology recovery to patient care.

Document:

Events that activate the procedure
Person authorized to declare downtime
Internal notification method
Paper or alternate workflows
Patient registration and scheduling process
Medication and clinical-information safeguards
Laboratory, imaging, and referral alternatives
Vendor escalation contacts
Staff assignment and shift handoff
Safe return-to-service process
Reconciliation of information created during downtime
Date of the last drill or review

Keep essential instructions available even when Microsoft 365, the EHR, internet service, or ordinary identity systems cannot be reached.

Avoid placing unnecessary patient information in the downtime plan itself.

9. Employee onboarding and offboarding checklist

Use one controlled checklist to coordinate managers, HR, IT, and application owners.

An onboarding checklist can cover:

Approved role and start date
Device assignment
Account creation
Required applications
MFA enrollment
Role-based access approval
Security and privacy training
Support contact information
Completion confirmation

An offboarding checklist can cover:

Confirmed departure time
Account disabling
Active-session revocation
Administrative-access removal
Device and key return
Data ownership transfer
Vendor and remote-access removal
Email or file-retention decision
Completion evidence
Exception approval

The checklist should document completion without exposing credentials.

10. Technology change and maintenance log

A simple log helps the organization reconstruct what changed before an outage or unexpected behavior began.

For meaningful changes, record:

Date and time
Affected system
Reason for the change
Requester and approver
Person performing the work
Planned impact
Backup or rollback preparation
Validation performed
Outcome
Follow-up actions

Include major software updates, network changes, device replacements, permission changes, vendor integrations, backup changes, and security-policy adjustments.

The log does not need to capture every routine help-desk action. Define which changes require documentation based on their risk and operational impact.

11. Incident-response contact and action sheet

An incident guide should help the first person receiving a report take safe initial actions.

Include:

Events employees should report
Approved reporting channel
Internal incident coordinator
IT escalation contact
Privacy, compliance, leadership, legal, and insurance contacts
Authority to isolate a device or disable an account
Instructions for preserving messages, logs, and other records
Communication and status-update method
Decision owners for external notifications
Post-incident documentation requirements

Keep the first page short enough to use under pressure. Detailed procedures can sit behind it.

Do not ask employees to investigate suspicious activity on their own or continue interacting with a suspected attacker.

12. Technology lifecycle and improvement roadmap

The roadmap turns documentation into planning.

Track:

Unsupported or aging systems
Warranty expirations
Software and contract renewals
Capacity concerns
Repeated support problems
Security improvements
Recovery and continuity gaps
Planned technology projects
Estimated budget range
Business owner
Target date
Dependencies and risks

Review the roadmap during budgeting, annual planning, leadership changes, mergers, office moves, and major vendor renewals.

Where should healthcare IT documentation be stored?

Use an approved, access-controlled location with:

Role-based access
MFA
Version history
Backup or retention protection
Clear ownership
Periodic access review
A controlled emergency-access method

Maintain an offline or otherwise independently accessible copy of essential contact and downtime information. The copy should be protected, reviewed, and replaced when it becomes obsolete.

Avoid unmanaged personal drives, personal cloud accounts, unencrypted USB devices, and email threads as the authoritative repository.

How often should the records be reviewed?

Update documentation after a material change, including:

New or departing employee
New vendor or terminated contract
Application implementation
Device replacement
Office move
Network change
Backup redesign
Security incident
Merger, acquisition, or ownership change
Downtime exercise
Changed legal or contractual requirement

Also establish a scheduled review. Critical contact, recovery, and downtime documents may need more frequent review than long-range planning records.

NIST’s Cybersecurity Framework 2.0 emphasizes managing cybersecurity as an ongoing organizational activity across Govern, Identify, Protect, Detect, Respond, and Recover. NIST

A practical documentation standard

Every document should pass five tests.

Is it accurate?

Confirm that names, numbers, devices, vendors, and procedures reflect the current environment.

Is it owned?

Assign a person or role responsible for keeping it current.

Is it accessible?

Authorized personnel must be able to retrieve it during ordinary operations and foreseeable outages.

Is it protected?

Limit access according to the sensitivity of the information. Documentation can reveal systems, vendors, network design, and response processes.

Has it been tested?

Use the record during a support request, access review, restore test, downtime exercise, or tabletop discussion. Correct anything that creates confusion.

What should a small practice document first?

If creating all 12 records at once is unrealistic, begin with:

Technology contacts
Critical systems and applications
Vendors and remote access
Backups and restore-test status
Downtime and emergency procedures

Add the remaining records through normal work rather than waiting for a perfect documentation project.

For example, update the device inventory during endpoint-management deployment, update the access register during a user review, and update the network diagram after the next approved network change.

HIPAA documentation caveat

Some documentation is specifically required under the HIPAA Security Rule; other records in this guide are operational practices that may help an organization manage technology and support its safeguards.

HHS states that documentation required by the Security Rule must generally be retained for six years after the later of its creation date or the date it was last in effect. HHS also calls for periodic review and updates in response to environmental or organizational changes affecting the security of electronic protected health information. HHS.gov

That rule should not be interpreted to mean that every field in every operational spreadsheet automatically has the same retention requirement. Organizations should determine what applies to each record with qualified legal or compliance guidance and their approved retention policies.

Why this matters to healthcare organizations

Independent medical and dental practices

One administrator may coordinate the EHR, billing system, imaging equipment, Microsoft 365, internet service, and outside IT support. Documentation reduces dependence on personal memory and provides a clearer handoff when staff or vendors change.

Hospice and home-health providers

Distributed employees, mobile devices, cellular connections, and after-hours care make ownership and escalation paths particularly important. Documentation helps teams identify which devices, accounts, and vendors support field operations.

Assisted-living and senior-living organizations

Technology supports 24-hour operations across shifts. Current contacts, downtime procedures, network records, and recovery responsibilities help staff coordinate when ordinary support personnel are unavailable.

Outpatient clinics

Clinics may depend on numerous cloud platforms and specialty vendors. A system and vendor inventory helps identify dependencies before a contract change, outage, or security event.

Organizations with multiple technology vendors

An organization may have separate providers for managed IT, EHR support, imaging, laboratory interfaces, telephones, internet service, billing, and medical devices. Documentation clarifies who owns each issue and which access paths should exist.

Protect, Operate, Recover, and Grow

Protect

Inventory systems, devices, accounts, and vendor access.
Restrict documentation according to sensitivity.
Keep passwords and reusable secrets in an approved password manager.
Review privileged and remote access.
Document security ownership and escalation paths.

Operate

Give each record an owner and review date.
Keep one authoritative version.
Update documentation as part of approved changes.
Use clear language that nontechnical leaders can understand.
Verify vendor contacts and support procedures.

Recover

Document backups and restoration responsibilities.
Record the date and result of restore tests.
Maintain accessible downtime and emergency instructions.
Define incident roles before an event.
Preserve essential contacts outside systems that may become unavailable.

Grow

Track aging technology and renewal dates.
Connect recurring problems to improvement projects.
Budget for replacements before support ends.
Use documentation during technology assessments.
Review whether systems still meet clinical and business needs.

The bottom line

Healthcare IT documentation is useful when an authorized person can find it, understand it, and act on it during a real operational problem.

Begin with contacts, critical systems, vendors, backups, and downtime procedures. Assign owners, protect sensitive details, and improve the records through routine support, testing, and technology planning.

The goal is not a shelf full of documents. It is safer, more consistent decision-making when patient care and business operations depend on technology.

Frequently asked questions

What is healthcare IT documentation?

Healthcare IT documentation is the controlled information an organization maintains about its technology, including systems, devices, users, vendors, networks, backups, downtime procedures, incidents, and future plans.

Does HIPAA require an IT asset inventory?

The Security Rule requires regulated entities to identify and manage risks to electronic protected health information, but applicability and the required form of documentation depend on the organization and the safeguard involved. An asset inventory is a widely recommended operational foundation, not by itself proof of HIPAA compliance.

Should IT documentation contain passwords?

Ordinary inventories, diagrams, and procedures should not contain passwords, recovery codes, private keys, or reusable MFA secrets. Store those items in an approved, access-controlled password-management system.

How often should healthcare IT documentation be updated?

Update it whenever a relevant system, user, vendor, location, process, or risk changes. Add scheduled reviews based on the document’s importance; contact, access, backup, and downtime records usually deserve frequent attention.

Where should downtime instructions be stored?

Keep the authoritative copy in a secure, access-controlled repository and maintain a protected emergency copy that remains available when normal internet, EHR, or identity services are unavailable.

What documentation should a small medical practice create first?

Start with technology contacts, a critical-system inventory, a vendor register, a backup record, and downtime procedures. These five records address common questions during outages, staffing changes, and vendor escalations.

Can a managed IT provider maintain the documentation?

Yes, a provider can help build and maintain technical records. The healthcare organization should still know where its documentation is stored, retain appropriate access, assign internal ownership, and verify that records remain usable if the provider relationship changes.

Build a usable technology baseline

Vault Technologies helps healthcare organizations organize system inventories, endpoint information, vendor access, backup responsibilities, downtime readiness, and technical operating procedures.

Our nurse-led perspective keeps documentation connected to clinical workflows, shift coverage, patient care, and practical recovery—not paperwork for its own sake.

Request a complimentary Technology Health Assessment to identify documentation gaps and establish practical priorities for safer, more supportable operations.

The assessment is a planning tool. It is not a legal opinion, compliance certification, penetration test, forensic investigation, or guarantee against technology or security incidents.

Authoritative sources

HHS — Summary of the HIPAA Security Rule , originally published October 17, 2008; current HHS summary reviewed for this article October 12, 2026.
HHS Office for Civil Rights — HIPAA Audit Protocol , updated July 2018.
HHS Office for Civil Rights — August 2024 Cybersecurity Newsletter , published August 2024.
NIST — Cybersecurity Framework 2.0 , published February 26, 2024.
NIST — Cybersecurity Framework 2.0 Resource and Overview Guide , published February 26, 2024.
CISA — Cross-Sector Cybersecurity Performance Goals , initial goals announced December 8, 2022; current guidance reviewed October 12, 2026.
CISA — StopRansomware Guide , current guidance reviewed October 12, 2026.

Healthcare Employee Offboarding: Remove Access Without Losing Critical Information

Mon, 05 Oct 2026 18:03:41 GMT

When an employee leaves a healthcare organization, disabling one email account is not enough.

The departing person may have access to an EHR, Microsoft 365, shared mailboxes, cloud files, clinical applications, scheduling systems, billing platforms, remote-support tools, mobile devices, door controls, vendor portals, and locally stored information.

At the same time, immediately deleting every account can remove email, documents, contacts, calendars, workflow knowledge, or files another employee needs to continue patient care and business operations.

Effective offboarding must accomplish two goals together:

End the departing person’s access.
Preserve the organization’s information and responsibilities.

Quick Answer: How should a healthcare organization offboard an employee?

Use a coordinated checklist owned by an authorized manager and completed by HR, IT, and relevant application owners.

At the approved departure time:

Disable sign-in through the authoritative identity system.
Revoke active sessions and authentication tokens.
Remove access from the EHR and other applications that do not deactivate automatically.
Recover or secure organization-owned devices, badges, keys, and authentication methods.
Preserve and transfer business records before deleting accounts or licenses.
Redirect necessary communications to an approved employee or shared mailbox.
Document every completed action, exception, owner, and timestamp.
Verify that access is actually unavailable.

Microsoft explains that disabling a user does not necessarily end every active application session immediately. Applications can maintain their own session tokens, and those sessions may require separate deprovisioning.

Why healthcare offboarding is more than an HR task

A departure changes several kinds of access at once.

Identity access

This includes:

Microsoft 365
Microsoft Entra ID
Active Directory
Workstation sign-in
VPN access
Remote desktop
Password-management systems
Multifactor-authentication methods
Single sign-on
Administrative accounts

Clinical and operational access

This may include:

EHR and practice-management systems
Electronic prescribing
Clinical messaging
Laboratory and imaging portals
Pharmacy platforms
Scheduling systems
Telehealth and remote-patient-monitoring tools
Billing and claims systems
Medical-device portals
Hospice or home-health applications
Resident or care-management platforms

Physical access

This may include:

Building keys
Access cards
Alarm codes
Medication-area access
Server or network closets
Records rooms
Organization vehicles
Storage areas

Information ownership

The departing employee may control or possess:

Email conversations
Patient-service communications
Calendars
OneDrive files
Shared documents
Vendor contacts
Procedures and checklists
Device passcodes
Project files
Records stored outside approved shared locations

A reliable process must address all four areas.

What does HIPAA say about terminating access?

The HIPAA Security Rule requires regulated organizations to maintain policies and procedures so workforce members have access appropriate to their roles.

HHS’s audit protocol specifically addresses procedures for terminating access to electronic protected health information when employment or another workforce arrangement ends. It also examines access-control devices, contractors, role changes, termination timeframes, exit procedures, and documentation showing that access was removed in a timely manner.

The exact safeguards appropriate for an organization depend on its size, structure, systems, risks, and circumstances. HHS describes the Security Rule as flexible, scalable, and technology-neutral.

This article provides operational guidance, not a legal conclusion or compliance certification.

Start before the employee’s final day

Good offboarding begins during onboarding.

An organization cannot reliably remove access it never documented.

Each workforce member should have an access record showing:

Legal name and preferred name
Job title and department
Manager
Work location
Start date
Organization-owned devices
Primary identity account
Email addresses and aliases
EHR role
Application access
Shared mailboxes
Shared drives and cloud libraries
Security groups
Distribution lists
Vendor portals
Administrative privileges
Mobile-device enrollment
MFA methods
Physical-access items
Access approvals
Training status

This record should be updated when the person changes roles, locations, departments, or responsibilities.

Planned and urgent departures require different timing

Planned departure

A resignation, retirement, contract completion, or scheduled transfer allows time to:

Identify responsibilities that need reassignment
Move files into approved shared locations
Transfer vendor relationships
Review shared mailboxes and calendars
Document recurring work
Recover equipment
Schedule access removal
Prepare an internal communication plan

The employee should not be asked to share passwords. Access should be transferred through administrative controls.

Immediate or high-risk departure

An involuntary termination, suspected account compromise, policy violation, or credible insider-risk concern may require access to be removed before or during the separation meeting.

Coordinate the exact timing among authorized leadership, HR, IT, security, and legal or compliance resources as appropriate.

Do not place termination details, allegations, medical information, or unnecessary personal information into an ordinary help-desk ticket. Record only what authorized technical personnel need to perform the approved actions.

The healthcare employee-offboarding process

Step 1: Establish the authorized request

The request should identify:

Employee or contractor
Manager
Last working date
Exact access-removal time
Planned or immediate departure
Systems known to be used
Equipment assigned
Business records requiring transfer
Approved mailbox or communication handling
Authorized decision-maker
Special legal, compliance, or safety instructions

IT should not guess whether a departure is voluntary, immediate, or delayed.

A specific cutoff time is safer than “sometime Friday.”

Step 2: Identify the authoritative identity source

Determine where the user account originates.

Common configurations include:

Microsoft Entra ID only
On-premises Active Directory only
Active Directory synchronized to Microsoft Entra ID
A separate identity provider
Independent accounts in each application

In a synchronized environment, disabling an account in the wrong location may be ineffective or later overwritten.

Microsoft advises organizations with synchronized identities to

Step 3: Block sign-in and revoke sessions

For Microsoft environments, the required actions may include:

Disable the user in Active Directory or Microsoft Entra ID.
Block new sign-ins.
Revoke active sessions and refresh tokens.
Disable or secure registered devices.
Review authentication methods.
Remove privileged roles.
Remove application assignments.
Remove group memberships where appropriate.
Review recent sign-in activity when the circumstances justify it.

Revoking sessions matters because an employee may already be signed in on a browser, mobile application, or workstation.

Microsoft notes that applications can issue and control their own session cookies. Disabling the Entra account may not directly terminate a session maintained by another application.

Step 4: Disable independent application accounts

Not every healthcare application uses Microsoft Entra ID or Active Directory.

Review the access list and disable the user directly in:

EHR and practice-management systems
Electronic-prescribing services
Clinical messaging
Laboratory and imaging portals
Billing and clearinghouse platforms
Telehealth systems
Scheduling applications
Vendor support portals
Remote-access tools
Backup consoles
Security-camera systems
Medical-device portals
Password managers
Cloud-storage services
Website administration
Social-media and marketing systems

For each system, record:

Action taken
Date and time
Administrator
Account status
Sessions terminated
Access reassigned
Exceptions
Verification result

Step 5: Address shared credentials safely

Shared credentials make offboarding more difficult because the organization may not know who still possesses the password.

When shared credentials cannot yet be eliminated:

Change the password.
Update approved password-management records.
Revoke active sessions where possible.
Replace shared MFA destinations.
Review recovery email addresses and phone numbers.
Notify only authorized users of the new access method.
Record why the shared account still exists.
Create a plan to replace it with named accounts.

Do not email or text a new shared password to a large group.

Step 6: Secure devices and locally stored information

Identify every organization-owned or organization-managed device assigned to the person:

Desktop
Laptop
Tablet
Smartphone
External drive
USB storage
Security token
Smart card
Printer or scanner storage
Home-health or field device
Medical device with local user access

Record the asset tag, serial number, condition, return date, and responsible custodian.

Before wiping or reassigning a device:

Confirm that necessary files have been preserved.
Confirm whether a legal or investigative hold applies.
Check for locally stored business information.
Remove the former user’s access.
Validate encryption and device-management status.
Follow the organization’s approved reset and redeployment process.

Microsoft notes that a remote wipe requires the device to connect to the internet; an offline device may retain locally stored information until the command can run. Wiping also makes device data unrecoverable, so preservation decisions must come first.

Step 7: Preserve email and cloud files before deletion

Disabling access and deleting an account are separate decisions.

Microsoft’s former-employee workflow recommends considering:

Preserving mailbox contents
Wiping or blocking mobile devices
Forwarding necessary email
Converting the mailbox to a shared mailbox where appropriate
Assigning access to Outlook and OneDrive information
Removing licenses
Deleting the account only after required information has been handled

Microsoft reports that deleting an account ordinarily begins a limited restoration period, but retention behavior depends on the account, licensing, configuration, workload, and applicable retention policies.

Before deleting anything, determine:

Who owns the business information?
Who needs continuing access?
Which records must be retained?
Is a legal, compliance, or investigation hold required?
Should email be forwarded?
Should the mailbox become a shared mailbox?
Where should OneDrive documents be moved?
Are patient-care or billing tasks still pending?
Are personal files mixed with organizational records?
When will the account become eligible for deletion?

Avoid relying on a temporary default-recovery period as the organization’s retention plan.

Step 8: Reassign responsibilities

Access removal is only half the process. Work must also continue.

Reassign:

Patient callbacks
Referral coordination
Prior authorizations
Billing follow-up
Vendor communication
Shared calendars
Scheduled reports
Recurring meetings
Equipment maintenance
Domain or certificate renewals
Subscription ownership
Purchasing approvals
Documentation ownership
Emergency contacts
After-hours duties

Confirm that the replacement employee has appropriate access based on their role. Do not copy every permission from the departing employee without review.

Step 9: Recover physical access

Collect or deactivate:

Building keys
Access cards
Alarm credentials
Office keys
Records-room access
Server-room access
Parking or gate credentials
Organization identification
Physical security tokens
Organization payment cards

If a shared physical code was known to the departing person, determine whether it must be changed.

Step 10: Verify the result

The technician who completed the checklist should verify that:

The former user cannot sign in.
Active sessions were addressed.
EHR and clinical-system accounts are inactive.
Administrative roles were removed.
Remote access is unavailable.
Mobile-device actions are complete or pending.
Email and files are assigned correctly.
Equipment is returned or listed as outstanding.
Physical access is removed.
Exceptions have owners and deadlines.
Completion evidence is retained.

For higher-risk departures, consider having a second authorized person review the completed checklist.

Why deleting the Microsoft 365 license first can cause problems

License removal may appear to be the fastest way to stop access, but it should not be the first or only step.

Removing a license does not replace:

Blocking sign-in
Revoking sessions
Disabling other applications
Preserving email
Moving OneDrive files
Reviewing shared mailboxes
Securing devices
Removing physical access
Documenting completion

It may also change how email, files, applications, and retention features behave.

The safer sequence is generally:

Disable access.
Revoke sessions.
Preserve and transfer required information.
Reassign communications and responsibilities.
Remove licenses when appropriate.
Delete the account only after retention and operational requirements are resolved.

The exact sequence should reflect the organization’s Microsoft configuration and approved policy.

Common offboarding failures

HR tells IT too late

If IT learns about the departure after the employee has left, accounts and sessions may remain available longer than intended.

Correction: Require a standard request with an exact cutoff time.

The Microsoft account is disabled, but the EHR remains active

Independent healthcare applications may not receive identity changes automatically.

Correction: Maintain an application-access list and assign an owner to each system.

The account is deleted before records are transferred

Email, files, contacts, calendars, or workflow history can become difficult to recover.

Correction: Separate immediate access removal from later account deletion.

Shared passwords are not changed

A former employee may retain access to a shared portal even after their named accounts are disabled.

Correction: Replace shared accounts where possible; otherwise rotate credentials and authentication methods.

The employee’s mobile device remains connected

Email, documents, messages, or application data may remain available through cached sessions or locally stored data.

Correction: Use approved device-management and application-protection controls, and verify their status.

No one takes ownership of ongoing work

Patient callbacks, referrals, billing questions, or vendor renewals may be missed.

Correction: Include operational reassignment in the offboarding checklist.

Contractors are excluded

Temporary staff, consultants, students, volunteers, agency personnel, vendors, and former owners may possess sensitive access.

Correction: Apply the process whenever any workforce or business arrangement ends—not only when a payroll employee leaves.

Why this matters to healthcare organizations

Independent medical and dental practices

One employee may manage scheduling, billing, vendor communication, and shared mailboxes. Deleting that account without transferring information can disrupt several workflows simultaneously.

A short, repeatable checklist is more reliable than depending on one office manager’s memory.

Hospice and home-health providers

Remote staff may use mobile devices, home networks, cloud applications, and locally cached information. Offboarding must account for equipment return, remote sessions, mobile applications, and documentation needed by continuing care teams.

Assisted-living and senior-living organizations

Departing staff may have access to resident records, medication-related systems, scheduling, communications, door controls, and shared nursing-station devices.

Clinical and physical access should be coordinated.

Outpatient clinics

EHR access is only one part of the environment. Laboratory, imaging, referral, prescribing, billing, and patient-communication portals may each require separate action.

Small organizations using outside IT providers

Leadership must communicate departures to the IT provider early enough to coordinate access removal. The organization should receive written confirmation showing which systems were addressed and which actions remain pending.

Protect / Operate / Recover / Grow

Protect

Give each workforce member a named account.
Require MFA where supported.
Limit access according to job responsibilities.
Separate ordinary and administrative accounts.
Record assigned devices and applications.
Eliminate unnecessary shared credentials.
Review recovery emails, phone numbers, and authentication methods.
Define urgent and routine departure procedures.

Operate

Maintain one access list for each workforce member.
Require an authorized offboarding request.
Include contractors, temporary staff, students, volunteers, and vendors.
Coordinate HR, management, application owners, and IT.
Use an exact access-removal time.
Separate access suspension from account deletion.
Record completion evidence and exceptions.
Test the process with a tabletop exercise.

Recover

Preserve required email, files, and operational records.
Maintain an approved method for restoring mistakenly deleted accounts or data.
Document mailbox and OneDrive ownership.
Escalate missing devices or unexpected access.
Review sign-in activity when circumstances warrant it.
Preserve relevant logs and records during an investigation.
Confirm that patient-service responsibilities were reassigned.

Grow

Automate provisioning and deprovisioning where practical.
Connect approved applications to centralized identity management.
Reduce manually maintained accounts.
Review access when employees change roles.
Track offboarding completion time.
Review recurring exceptions.
Include access removal in vendor and contract requirements.
Update the process when new systems are adopted.

Microsoft recommends automated deprovisioning where possible and a documented manual process for applications that cannot be deactivated automatically.

A simple offboarding record

For each departure, retain:

Person’s name
Employment or relationship type
Manager
Approved cutoff date and time
Request authorization
Identity system disabled
Sessions revoked
EHR access removed
Other applications removed
Administrative privileges removed
MFA methods addressed
Device status
Email disposition
File disposition
Physical-access status
Responsibilities reassigned
Exceptions
Exception owners and deadlines
Technician
Completion date and time
Reviewer, when required

Do not place unnecessary private employment details in the technical record.

The bottom line

Healthcare employee offboarding is successful when the former worker can no longer access organizational systems, while the organization retains the information and operational continuity it still needs.

The essential sequence is:

Authorize.
Disable.
Revoke.
Preserve.
Transfer.
Verify.
Document.

Do not confuse disabling an account with completing the entire process—and do not confuse deleting an account with securing it.

Frequently asked questions

When should a departing healthcare employee’s access be removed?

Remove access at the time authorized by leadership, HR, or the organization’s approved procedure. Immediate or high-risk departures may require coordinated removal before or during the separation meeting. Planned departures should still have an exact cutoff time.

Is disabling a Microsoft 365 account enough?

No. Active sessions, independent applications, EHR accounts, mobile devices, shared credentials, physical access, and locally stored information may require separate action.

Should the former employee’s account be deleted immediately?

Usually not before required email, files, contacts, calendars, and business records are preserved or transferred. Immediate sign-in blocking and eventual account deletion are different actions.

What happens to a former employee’s email?

The organization may preserve the mailbox, grant authorized access, forward necessary messages, or convert it to a shared mailbox, depending on operational, privacy, legal, licensing, and retention requirements.

Does changing the employee’s password end every session?

Not necessarily. Tokens, application sessions, mobile applications, and independently managed systems may continue to operate. Administrators should disable access and revoke sessions using the appropriate identity and application controls.

Does the process apply to contractors and temporary workers?

Yes. Anyone with organizational access should have that access reviewed and removed when their employment, contract, placement, volunteer role, student rotation, or vendor relationship ends.

How can a small healthcare practice manage offboarding without a large IT department?

Use a short checklist, maintain an employee-access list, assign an owner to every application, notify the IT provider in advance, and require written completion confirmation. The process matters more than the organization’s size.

Strengthen your access-management process

Vault Technologies helps healthcare organizations document user access, coordinate Microsoft 365 and endpoint administration, improve onboarding and offboarding, reduce shared-account dependence, and create practical procedures that support both security and care continuity.

Our nurse-led perspective helps keep technical decisions connected to patient workflows, staffing transitions, and reliable operations. Our veteran-owned team emphasizes accountability, clear documentation, and security-first support.

A complimentary Technology Health Assessment can help identify gaps across identity management, endpoints, vendor access, documentation, backup planning, and continuity readiness.

The assessment is a planning tool. It is not a legal opinion, compliance certification, penetration test, forensic investigation, or guarantee against a security incident.

Authoritative sources

HHS Office for Civil Rights — HIPAA Audit Protocol , updated July 2018. The workforce-security section addresses access authorization, role changes, termination procedures, access-control devices, contractors, and documentation. HHS.gov
HHS — Summary of the HIPAA Security Rule , current version reviewed October 5, 2026. HHS.gov
Microsoft Learn — Revoke User Access in Microsoft Entra ID , updated June 19, 2026. Microsoft Learn
Microsoft Learn — Remove a Former Employee and Secure Data , updated June 15, 2026. Microsoft Learn
CISA and NSA — Identity and Access Management Recommended Best Practices for Administrators , published March 2023.

ScreenConnect Flaw: What Healthcare Organizations Should Verify

Mon, 14 Sep 2026 15:44:38 GMT

Published September 14, 2026

Featured image

Concept: A healthcare administrator and an authorized IT technician reviewing remote-support access on a clinic workstation. Display a generic device-management screen without real company names, passwords, patient information, or recognizable software interfaces. Keep the mood calm, professional, and verification-focused.

Filename: screenconnect-vulnerability-healthcare-remote-support.jpg

Alt text: Healthcare administrator verifies remote-support software and vendor access with an IT technician inside a clinic

Remote-support software allows an authorized technician to view or control a computer without being physically present.

That capability is valuable to medical practices, dental offices, hospice and home-health providers, outpatient clinics, and senior-care organizations. It allows technology problems to be addressed quickly across offices, clinical areas, and remote work locations.

It is also a privileged access path that must be managed carefully.

ConnectWise released a security update for a critical ScreenConnect client vulnerability on September 8, 2026. The U.S. Cybersecurity and Infrastructure Security Agency added the vulnerability to its Known Exploited Vulnerabilities Catalog on September 11 after finding evidence of active exploitation.

The vulnerability is identified as CVE-2026-84869 .

Quick Answer: What should healthcare organizations do about the ScreenConnect vulnerability?

Ask the organization’s IT provider whether ScreenConnect is installed or used anywhere in the environment.

If it is, obtain written confirmation that affected clients and access agents have been updated to ScreenConnect 26.6.5 or later , that exposed permissions and active sessions were reviewed, and that relevant remote-access activity was checked for unauthorized file transfers or execution.

Do not remove remote-support software from clinical systems without coordinating with the responsible technology provider. An unplanned removal could interfere with support, monitoring, or patient-care operations.

Organizations that do not use ScreenConnect should still use the event to review every remote-support tool with access to their computers.

What happened?

On September 8, ConnectWise published a security bulletin addressing a condition in the ScreenConnect client.

According to the company, the vulnerability could allow files to be transferred and executed through an active remote session without the expected authorization or host confirmation in certain circumstances.

ConnectWise released ScreenConnect client version 26.6.5 to address the issue.

On September 11, CISA added CVE-2026-84869 to its Known Exploited Vulnerabilities Catalog. CISA adds vulnerabilities to this catalog when there is reliable evidence that attackers have exploited them.

That changes the issue from a theoretical software weakness to a confirmed, active threat.

What systems are affected?

The vulnerability concerns the ScreenConnect client used during support and access sessions. ConnectWise’s bulletin states that ScreenConnect servers are not affected by this specific vulnerability.

The required response depends on how ScreenConnect is deployed.

ConnectWise-hosted cloud environments

ConnectWise reports that its cloud service was updated. The company also recommends reinstalling host clients and updating access agents so endpoints receive the corrected client.

A cloud console being updated does not necessarily prove that every installed endpoint component has completed its update.

Self-hosted ScreenConnect environments

Organizations or providers operating an on-premises ScreenConnect installation should upgrade to version 26.6.5 or later and verify that connected clients and agents are current.

ScreenConnect integrated with ConnectWise Automate

ConnectWise Automate partners were instructed to apply the ScreenConnect 26.6.5 update through Automate Product Updates when eligible.

Healthcare customers may not know which deployment model their provider uses. That is precisely why written verification is appropriate.

Why this vulnerability matters

Remote-support tools are designed to perform sensitive actions.

Depending on their configuration and the permissions assigned, they may allow technicians to:

View a user’s screen
Control the keyboard and mouse
Transfer files
Run commands
Install or remove software
Work with elevated privileges
Access systems outside normal office hours
Connect without a user physically present

These functions make remote support efficient. They also mean that weak authorization, excessive permissions, stolen credentials, or an unpatched client may create significant risk.

The concern is not that all ScreenConnect sessions were compromised. Public guidance does not establish that every organization using the product was affected.

The correct question is whether a particular organization had an exposed version, whether the affected function was available, and whether activity during the relevant period shows anything requiring further investigation.

What healthcare leaders should ask their IT provider

Send the following questions to the person or company responsible for remote support.

1. Do we use ScreenConnect?

Ask whether it is used:

Directly by the organization
By its managed service provider
Through another ConnectWise product
By an EHR or application vendor
By a billing or revenue-cycle vendor
By a copier, imaging, laboratory, or medical-device vendor
For unattended after-hours access
On employee-owned or mobile devices

A product may appear under names such as ScreenConnect , ConnectWise Control , or a provider’s white-labeled support application.

2. Which devices have the client or access agent installed?

Request an inventory identifying:

Device name
Location
Responsible department
Installed version
Last successful connection
Whether unattended access is enabled
Current update status
Assigned access group
Responsible vendor or administrator

Include clinical workstations, servers, laptops, home-health devices, reception computers, and administrative systems.

3. Are all affected components running version 26.6.5 or later?

Request the answer in writing.

The response should explain:

Current server or service version
Current client version
Current access-agent version
Date the update was applied
Number of devices successfully updated
Number of devices offline or pending
How exceptions will be resolved

“ConnectWise handles updates” is not sufficient if local clients or agents still need to reconnect, reinstall, or complete an upgrade.

4. Were permissions reviewed?

Before the corrected version was available, ConnectWise reportedly advised administrators to restrict the TransferFiles permission for users with open sessions.

Ask whether the provider reviewed:

File-transfer permission
Command-execution capabilities
Unattended-access permissions
Administrator roles
Technician groups
Temporary accounts
Former employees
Vendor accounts
Open or unusually long sessions

Permissions should be restored only when they are necessary and appropriately controlled.

5. Was relevant activity reviewed?

Ask whether the provider examined available records for:

Unexpected remote sessions
Unrecognized technician accounts
Unusual connection times
File transfers
File execution
Permission changes
New accounts
Modified access groups
Connections to high-value systems
Sessions originating from unexpected locations

The availability and detail of these records will depend on the deployment, licensing, retention settings, and logging configuration.

A lack of obvious alerts does not prove that the environment was unaffected. The provider should explain what records were available, what period was reviewed, and what the review found.

6. Were credentials or sessions reset where appropriate?

The provider should determine whether any accounts, tokens, active sessions, API connections, or authentication methods require revocation or replacement.

This decision should be based on actual exposure and evidence. Broad credential resets performed without planning can interrupt clinical operations and may not address an already active session.

7. What is the written conclusion?

Request a short statement covering:

Whether ScreenConnect is present
Whether vulnerable components were found
Whether all components were updated
Whether suspicious activity was identified
Which devices remain pending
Which temporary restrictions were applied
Whether further investigation is recommended
Who owns each remaining action
When the next update will be provided

Avoid settling for a verbal “you should be fine.” It is a splendidly reassuring phrase and a rather poor audit record.

What should employees do?

Employees should not attempt to update, disable, or remove remote-support agents themselves unless specifically instructed.

They should report:

Unexpected remote-control prompts
A cursor moving without explanation
Unapproved file-transfer notices
New support applications
Unusual pop-ups
Requests to leave a computer unlocked
Technicians they cannot verify
Remote sessions outside expected times
Security warnings involving support software

Employees should end or refuse an unexpected support session when safe to do so and contact the approved support channel independently.

A legitimate technician should be willing to let the employee verify the request.

Do not confuse this flaw with fake remote-support software

This event involves a vulnerability in a legitimate ScreenConnect client.

Attackers also abuse legitimate remote-support products in other ways. They may:

Trick an employee into installing an unauthorized agent
Use a trial account
Steal a technician’s credentials
Impersonate the help desk
Send a fake software-update notice
Rename a remote-access tool
Install more than one persistence tool

Updating ScreenConnect addresses this specific vulnerability. It does not replace controls for technician identity, software installation, MFA, access approval, logging, or vendor oversight.

Why this matters to healthcare organizations

Independent medical and dental practices

A remote-support agent may exist on every workstation while technology is managed by one outside provider. Practice leadership may never see the management console and must rely on its provider for accurate verification.

Hospice and home-health providers

Remote employees and mobile devices can be difficult to update consistently. Devices that have been offline may remain pending until they reconnect.

Assisted-living and senior-living organizations

Unattended remote access may be used to support nursing stations, medication-related systems, administrative computers, and after-hours operations. Access should be limited without making legitimate support unavailable during a care disruption.

Outpatient clinics

Remote-support software may reach EHR-connected computers, Microsoft 365, imaging workstations, billing systems, and shared clinical devices. A current device inventory is essential for verifying coverage.

Healthcare organizations using multiple vendors

Separate vendors may install separate support agents. An organization may have tools from its MSP, EHR vendor, copier provider, imaging company, and specialty application vendors on the same device.

Without an inventory, leadership may not know how many outside access paths exist.

What if the organization does not use ScreenConnect?

Use this incident as a reason to review other remote-support tools.

Ask:

Which products are installed?
Which company owns each installation?
Which employees or vendors can connect?
Is unattended access enabled?
Is MFA required for technicians?
Are sessions logged?
Are clients and agents updated automatically?
How are former technicians removed?
Can file transfer or command execution be restricted?
Who reviews remote-access activity?

The goal is not to ban remote support. The goal is to make every access path known, owned, current, restricted, and reviewable.

A practical response checklist

Protect

Identify every remote-support product.
Update ScreenConnect clients and agents to 26.6.5 or later.
Require MFA for technician accounts.
Remove inactive accounts.
Limit unattended access.
Restrict file transfer and command execution to authorized roles.
Separate ordinary and administrative identities.

Operate

Maintain a device and remote-access inventory.
Record the owner and purpose of every agent.
Establish a verification procedure for support sessions.
Review vendor access periodically.
Define expected support hours.
Retain appropriate session and administrative logs.
Document the update and exception process.

Recover

Revoke suspicious sessions and credentials.
Preserve relevant logs and vendor communications.
Isolate affected devices when technically and clinically appropriate.
Coordinate specialized investigation if evidence warrants it.
Validate systems before returning them to ordinary use.
Document restoration and unresolved risks.

Grow

Add remote-support requirements to vendor contracts.
Review access during employee and vendor offboarding.
Reduce duplicate or abandoned support agents.
Test how support will work during an outage.
Include privileged vendor access in technology assessments.
Require written security notices and remediation confirmation.

The bottom line

CISA’s confirmation of active exploitation makes CVE-2026-84869 an issue that ScreenConnect users should address promptly.

Healthcare organizations do not need to perform the technical work themselves. They should obtain clear answers from the person or company responsible for remote support.

Start with four questions:

Is ScreenConnect installed anywhere?
Are all clients and agents running version 26.6.5 or later?
Were permissions, sessions, and relevant logs reviewed?
Can the provider document the result?

Remote support should make healthcare technology easier to operate. It should not become an undocumented doorway whose owner, version, and permissions are unknown.

Frequently asked questions

What is ScreenConnect?

ScreenConnect is a remote-support and remote-access product from ConnectWise. Authorized technicians can use it to view or control computers, transfer files, run support tools, and maintain systems from another location.

What is CVE-2026-84869?

It is a vulnerability in the ScreenConnect client that may allow unauthorized file transfer and execution through an active remote session under certain conditions.

Is the ScreenConnect vulnerability being actively exploited?

Yes. CISA added CVE-2026-84869 to its Known Exploited Vulnerabilities Catalog on September 11, 2026, based on evidence of active exploitation.

Which ScreenConnect version contains the fix?

ConnectWise released the fix in ScreenConnect client version 26.6.5 . Organizations should use version 26.6.5 or a later vendor-supported release.

Are ConnectWise-hosted cloud customers protected automatically?

ConnectWise reports that its cloud service was updated. However, customers and providers should still verify that installed host clients and access agents have been reinstalled or updated as recommended.

Should employees uninstall ScreenConnect?

Not without authorization. Removing a legitimate support agent may interrupt monitoring or technical assistance. The responsible IT provider should verify the version and determine the appropriate action.

What if a healthcare organization uses another remote-support product?

The specific ScreenConnect patch does not apply, but the broader lesson does. Inventory the tool, confirm ownership, review privileged access, require strong authentication, verify updates, and retain appropriate activity records.

Strengthen your healthcare technology readiness

Vault Technologies helps healthcare organizations improve endpoint administration, remote-support governance, access controls, vendor documentation, patch coordination, and incident-management readiness.

Our nurse-led perspective keeps security decisions connected to patient care, clinical workflows, shift coverage, and safe technology operations.

Request a complimentary Technology Health Assessment to establish a practical baseline across endpoint management, vendor access, Microsoft environments, documentation, backup planning, and care-continuity readiness.

The assessment is a planning tool. It is not a legal opinion, compliance certification, penetration test, forensic investigation, or guarantee against cyber incidents.

Authoritative sources

ConnectWise — September 8, 2026 ScreenConnect security bulletin , published September 8, 2026.
CVE Program — CVE-2026-84869 record , published September 8, 2026.
CISA — Known Exploited Vulnerabilities Catalog , ScreenConnect entry added September 11, 2026.
ConnectWise — public disclosure repository for CVE-2026-84869 , published September 8, 2026.
NHS England Digital — “ConnectWise Releases Security Update for ScreenConnect” , published September 9, 2026.
Computerworld — “ConnectWise patches critical ScreenConnect authentication failure after five days” , published September 11, 2026.

The First 60 Minutes of a Healthcare IT Outage

Mon, 07 Sep 2026 17:10:27 GMT

When a healthcare system stops wo rking, the first question is not always, “How do we fix the computer?”

The first questions are:

Can employees continue caring for patients safely?
Which services are affected?
Who is coordinating the response?
Could this be a cybersecurity incident?
What information must be preserved?
How will staff receive reliable instructions?

A short outage can affect scheduling, medication information, clinical documentation, laboratory orders, referrals, billing, communications, and access to patient records.

The first hour should be organized around care continuity, controlled technical response, clear communication, and accurate documentation.

Quick Answer: What should a healthcare organization do during the first hour of an IT outage?

Confirm the scope, protect urgent patient-care functions, appoint one response leader, contact the approved IT or vendor representative, activate the appropriate downtime procedures, preserve relevant information, and issue one clear internal update.

Do not let every employee troubleshoot independently. Avoid unnecessary reboots, password changes, software removal, or disconnected equipment until someone has determined whether the event is an ordinary failure, vendor outage, network problem, or possible security incident.

This guide is a practical starting point. Each organization should adapt it to its systems, clinical responsibilities, staffing, vendors, contracts, and emergency procedures.

Before using this guide

If the disruption creates an immediate threat to life or patient safety, follow the organization’s emergency clinical procedures and contact emergency services when appropriate. Technology troubleshooting must not delay urgent care.

An IT outage does not automatically mean a cyberattack. Possible causes include:

Internet or power failure
Vendor service disruption
Equipment malfunction
Expired certificate or license
Failed update
Authentication problem
Network configuration error
Accidental change
Malicious activity

Treat the cause as unknown until it is reasonably established.

Minutes 0–10: Recognize, protect, and report

1. Confirm what employees are seeing

Ask for observable facts:

Which system is unavailable?
When was the problem first noticed?
Is it affecting one user, one location, or everyone?
Is the internet working?
Are telephones working?
Are users receiving an error message?
Are files missing or renamed?
Did anyone receive a suspicious prompt, email, call, or login request?
Did a vendor announce an outage?
Are medical devices or medication workflows affected?

Record the exact wording of error messages when possible. A photograph may be useful if it does not expose patient information.

Avoid declaring the event “ransomware,” “a breach,” or “just an internet problem” without evidence.

2. Protect immediate patient-care functions

The clinical or operational leader should determine whether staff can safely continue normal work.

Check critical functions such as:

Patient identification
Current medications and allergies
Urgent orders and results
Prescription handling
Clinical documentation
Scheduling and patient contact
Laboratory and imaging workflows
Communication between care teams
Access to emergency information

If required information is unavailable, activate the applicable clinical escalation or emergency procedure.

3. Report through the approved support channel

Employees should contact the organization’s established IT representative, managed service provider, internal support contact, or affected vendor.

Use a known telephone number or support portal. Do not rely on contact information supplied in an unexpected email, text message, pop-up, or telephone call.

The initial report should include:

Reporter’s name and callback number
Affected location
System or device
Time first noticed
Number of affected users
Patient-care impact
Exact symptoms
Actions already taken
Suspicious activity, if any

Minutes 10–20: Establish control

4. Appoint one incident coordinator

One person should coordinate the organization’s response.

Depending on the organization, this may be:

Practice administrator
Executive director
Clinical supervisor
Privacy or security representative
Internal IT lead
Designated continuity coordinator

This person does not need to repair the system. The role is to coordinate decisions, communications, priorities, and documentation.

Identify backups in case the primary coordinator is unavailable.

5. Open an incident record

Start a written record immediately. Paper may be necessary if normal systems are unavailable.

Record:

Date and time
Person reporting
Systems and locations affected
Known operational impact
People contacted
Instructions received
Decisions made
Temporary procedures activated
Changes performed
Time of each update
Unanswered questions

Separate confirmed facts from assumptions.

A clean timeline is valuable for technical recovery, leadership review, insurance coordination, vendor follow-up, and any later privacy or legal assessment.

6. Establish a trusted communication method

Choose one approved method for staff updates.

Possible options include:

Telephone tree
Approved text-notification system
Alternate email service
Printed instructions
In-person unit or department briefings
Predefined emergency communication platform

Do not discuss patient details in an unapproved communication channel.

Employees should know:

Where updates will come from
Who is authorized to issue instructions
When the next update is expected
Where questions should be directed
Which temporary procedures are active

Minutes 20–30: Stabilize and preserve

7. Prevent uncontrolled troubleshooting

Ask employees to stop taking independent corrective actions unless directed by the response lead or technical representative.

Uncoordinated actions may:

Erase useful evidence
Spread malicious activity
Interrupt working systems
Complicate restoration
Create conflicting configuration changes
Delay diagnosis
Disconnect equipment needed for patient care

Do not broadly instruct employees to unplug everything. Isolation decisions should consider both technical risk and clinical impact.

8. Preserve relevant information

Where safe and practical, retain:

Error messages
Alert emails
Suspicious messages or telephone details
Login notifications
Screenshots without unnecessary patient information
Device names
Usernames involved
IP or network information supplied by IT
Vendor notices
Support-ticket numbers
Times of observed events
Names of people who performed technical actions

Do not forward suspicious attachments or links to coworkers. Use the organization’s approved reporting method.

9. Determine whether specialized escalation is needed

Technical personnel should assess whether signs point to:

A local device failure
Network or internet outage
Microsoft 365 or identity disruption
EHR or vendor outage
Account compromise
Malware or ransomware
Unauthorized administrative change
Data loss
Power or facility problem

If malicious activity is suspected, activate the organization’s security-incident process. Appropriate leadership, cyber-insurance, privacy, legal, law-enforcement, or regulatory contacts may need to become involved based on the facts and established procedures.

Vault can support operational coordination and technical incident management, but legal determinations, breach-notification decisions, forensic investigations, and law-enforcement matters require the appropriate qualified resources.

Minutes 30–45: Activate downtime operations

10. Move staff to approved temporary procedures

A healthcare downtime plan should identify how essential work continues when normal systems are unavailable.

Procedures may cover:

Patient check-in
Identity verification
Appointment lists
Medication and allergy information
Clinical notes
Orders and referrals
Prescription requests
Laboratory and imaging work
Billing and payment collection
Patient communications
Care-team handoffs
Home-health schedules
Hospice coordination
Assisted-living or senior-care documentation

Use approved forms and procedures. Improvised notes on loose paper can create privacy, accuracy, and reconciliation problems.

11. Identify the most critical systems

Not every system should receive equal restoration priority.

Consider:

Immediate patient-safety functions
Clinical communications
Identity and access services
EHR and medication-related systems
Network and internet connectivity
Laboratory, imaging, and prescribing connections
Scheduling and patient communications
Billing and administrative services

The correct order depends on the organization.

HHS contingency-planning guidance addresses application and data criticality analysis—determining which applications and information are most important to patient care and business operations so recovery can be prioritized appropriately.

12. Coordinate with affected vendors

If a hosted platform or external service may be involved, contact the vendor through a verified channel.

Ask:

Is there a confirmed service disruption?
Which products, locations, or customers are affected?
When did the disruption begin?
Is the event operational or security-related?
Are customer actions required?
Should credentials or integrations be changed?
Is there a temporary workaround?
When is the next update?
What ticket or incident number should be recorded?

Do not accept “everything is fine” or “we are investigating” as the final record. Request written follow-up as facts become available.

Minutes 45–60: Brief leadership and set the next checkpoint

13. Prepare a short situation report

The response coordinator should provide leadership with a concise update:

What happened: Confirmed symptoms and start time
What is affected: Systems, locations, and users
Patient-care impact: Current clinical and operational consequences
What is working: Available systems and workarounds
What has been done: Contacts, containment, and downtime actions
What remains unknown: Cause, duration, data impact, or restoration time
What is needed: Decisions, resources, or external support
Next update: Specific time or triggering event

Avoid filling gaps with guesses.

14. Confirm responsibility for the next phase

Before the first hour ends, assign owners for:

Technical diagnosis
Clinical operations
Staff communications
Vendor coordination
Incident documentation
Leadership updates
Privacy and legal escalation, if needed
Insurance notification, if applicable
Recovery validation
Reconciliation of temporary records

One person may hold several roles in a small organization, but the responsibilities should still be named.

15. Set a firm update schedule

Even if there is no resolution, staff should receive updates at predictable intervals.

A useful message answers:

Is the system still unavailable?
Are current downtime procedures unchanged?
Has the affected scope changed?
Is there a new safety or security instruction?
When will the next update arrive?

Silence encourages rumors and independent troubleshooting—two commodities rarely in short supply during an outage.

What employees should not do

Unless specifically directed by an authorized responder, employees should not:

Repeatedly restart computers or network equipment
Delete suspicious messages
Run unapproved cleanup tools
Install software
Change settings
Reset passwords across the organization
Use personal email or consumer file-sharing services
Photograph patient information
Post outage details on social media
Contact unverified “support” numbers
Reconnect isolated equipment
Discard temporary clinical records after service returns

A password reset may be appropriate in some incidents, but indiscriminate resets can disrupt response work and may not revoke an attacker’s existing session.

Why this matters to healthcare organizations

Independent medical and dental practices

A small practice may have only one administrator and one outside technology provider. A one-page first-hour checklist can prevent the response from depending entirely on one person’s memory.

Hospice and home-health providers

Employees may be dispersed across homes and care locations. The plan must explain how schedules, patient contacts, documentation, and clinical escalation continue when cloud or mobile systems fail.

Assisted-living and senior-living organizations

Technology outages may cross shifts and affect medication-related workflows, documentation, communication, and resident support. Handoffs must include the outage status and temporary procedures.

Outpatient clinics

An EHR, internet, identity, or telephone disruption can affect nearly every patient encounter. Front-desk, clinical, administrative, and technical personnel need coordinated instructions.

Small healthcare organizations

Smaller organizations may not have separate security, privacy, legal, clinical-operations, and IT teams. That makes clearly assigned roles more important, not less.

Build the first-hour kit before an outage

Keep a protected printed or offline kit containing:

One-page first-hour checklist
Incident-record form
Current IT and vendor contacts
Leadership call tree
Cyber-insurance contact and policy number
Approved downtime forms
Critical-system priority list
System and application owners
Alternate communication instructions
Emergency-access procedure
Locations of backups and recovery documentation
Instructions for reconciling temporary records
Date the kit was last reviewed and tested

Do not place passwords, recovery keys, or sensitive configuration details in an openly accessible binder.

Protect, Operate, Recover, and Grow

Protect

Maintain MFA and individual accounts.
Separate administrative access from ordinary work.
Keep systems patched and supported.
Protect backups from routine user access.
Monitor critical systems and vendor services.
Train employees to report unusual activity quickly.

Operate

Maintain current support contacts.
Document system dependencies.
Rank applications by clinical and operational importance.
Keep approved downtime forms accessible.
Define response authority and communication channels.
Review vendor notification procedures.

Recover

Validate systems before returning them to normal use.
Confirm that restored information is complete and usable.
Reconcile paper or temporary records.
Preserve the incident timeline and vendor communications.
Monitor for recurring errors or suspicious activity.
Communicate clearly when normal operations resume.

Grow

Conduct a short after-action review.
Record what worked and what failed.
Assign owners and deadlines for improvements.
Update the downtime plan and contact list.
Test the revised procedure.
Include continuity gaps in technology planning and budgeting.

The bottom line

The first hour of a healthcare IT outage should not be improvised.

A strong response protects patient care, establishes one decision structure, brings in verified technical support, preserves useful information, activates documented downtime workflows, and keeps employees informed.

Prepare four things now:

A named response coordinator
A verified contact list
A one-page first-hour checklist
Usable clinical downtime procedures

The technology may still fail. The organization’s ability to respond does not have to fail with it.

Frequently asked questions

What is the first action during a healthcare IT outage?

etermine whether patient care is immediately affected, then report the outage through the approved technical-support channel. Urgent clinical and safety procedures take priority over routine troubleshooting.

Does every IT outage indicate a cyberattack?

No. Outages can result from equipment, power, internet, software, configuration, identity, or vendor failures. Treat the cause as unknown until it is reasonably established.

Should employees unplug computers during a suspected cyber incident?

Not automatically. Disconnecting a device may sometimes be appropriate, but it can also affect patient care or remove useful technical information. Employees should follow the approved incident procedure or directions from an authorized responder.

Should a healthcare practice call its cyber-insurance carrier?

Follow the policy’s notification requirements and the organization’s incident procedure. Some policies require early contact or approval before engaging certain vendors. Keep the current policy number and contact instructions in the protected response kit.

What should be documented during an outage?

Record times, symptoms, affected systems, patient-care impact, people contacted, instructions received, actions taken, temporary procedures, vendor statements, decisions, and unresolved questions.

When can staff return to normal systems?

Return only after the responsible technical and operational leaders confirm that the systems are available, safe to use, and ready for clinical operations. Temporary records must then be reconciled through an approved process.

How often should a healthcare downtime plan be tested?

Use a risk-based schedule and test often enough to keep contacts, roles, forms, and procedures workable. Testing should also occur after significant system, vendor, staffing, or workflow changes and after an actual disruption.

Strengthen your healthcare technology readiness

Vault Technologies helps healthcare organizations document critical systems, organize vendor dependencies, improve Microsoft 365 and endpoint administration, develop practical downtime procedures, plan backup and recovery, and strengthen incident-management readiness.

Our nurse-led perspective keeps the response focused on the essential outcome: maintaining safe, reliable patient care while technology is restored.

Request a complimentary Technology Health Assessment to establish a practical baseline across systems, access controls, vendor dependencies, documentation, backup planning, and care-continuity readiness.

The assessment is a planning tool. It is not a legal opinion, compliance certification, penetration test, forensic investigation, or guarantee against cyber incidents.

Authoritative sources

NIST — SP 800-61 Revision 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management , published April 3, 2025.
NIST — Announcement of revised incident-response guidance , published April 3, 2025.
HHS — Summary of the HIPAA Security Rule , updated August 7, 2026.
HHS — HIPAA Security Series: Administrative Safeguards , published May 2005 and revised March 2007.
HHS 405(d) — Health Industry Cybersecurity Practices: Managing Threats and Protecting Patients , 2023 edition.
HHS 405(d) — Patient Safety , published June 28, 2023.

Shared Healthcare Workstations Without Shared Accounts

Mon, 31 Aug 2026 16:02:59 GMT

Published August 31, 2026

Featured image

Concept: A healthcare employee signing into a shared clinical workstation with an individual account or identification badge. Show a realistic outpatient or senior-care environment without visible patient information, passwords, warning graphics, or hacker imagery.
Filename: shared-healthcare-workstations-individual-accounts.jpg
Alt text: Healthcare employee signs into a shared clinical workstation using an individual account and secure badge at a clinic

Healthcare employees often share computers. A workstation may be used by several nurses, medical assistants, front-desk employees, clinicians, or caregivers during the same day.

Sharing the device can be practical. Sharing one username and password is a different matter.

When several people use the same account, the organization may be unable to determine who opened a record, changed a setting, downloaded information, sent a message, or approved an action. It also becomes harder to remove access when an employee leaves or changes roles.

Quick Answer: Can healthcare employees share a workstation?

Yes. Employees can share a properly configured workstation while still signing in with individual accounts.

Each workforce member should use an identity assigned to that person. The device can remain shared, but access permissions, authentication, activity records, and account termination should follow the individual user.

A general account such as FrontDesk , NurseStation , or ClinicUser should not replace individual identification when people access systems containing electronic protected health information.

A shared device is not the same as a shared account

These two arrangements are often mistaken for one another.

Shared workstation

A shared workstation is one computer used by several authorized people. Each person signs in using an individual account, badge, passkey, security key, or another approved authentication method.

This arrangement can support:

Individual accountability
Role-based access
Reliable activity records
Prompt access removal
Different permissions for different jobs
Investigation of suspicious activity

Shared user account

A shared account uses one set of credentials for multiple people.

Examples include:

Everyone at reception using FrontDesk
Every caregiver using CareTeam
A password taped near a nursing-station computer
Several administrators using one Microsoft 365 administrator account
Former and current employees knowing the same vendor password

The computer may be convenient to use, but the organization loses an important connection between the activity and the person who performed it.

HHS states that covered entities must assign a unique name or number to each workforce member who uses a system containing electronic protected health information so that access and activity can be identified and tracked.

That does not mean every healthcare application has identical technical capabilities. It does mean limitations and exceptions should be identified, assessed, documented, and addressed appropriately.

Why shared accounts create practical problems

Activity becomes difficult to attribute

Suppose a patient record is opened unexpectedly, an email-forwarding rule appears, or a large report is downloaded.

If ten people use one account, the activity log may identify the shared username but not the person responsible. Leadership may then have to rely on schedules, interviews, camera footage, or assumptions.

Individual accounts provide a much clearer starting point.

Passwords spread beyond their intended audience

Shared passwords tend to be:

Written down
Sent by text or email
Reused
Changed infrequently
Known by former employees
Disclosed to temporary personnel or vendors

Changing the password can disrupt everyone using the account, which encourages organizations to postpone the change.

Access removal becomes unreliable

When an employee leaves, disabling an individual account is straightforward. With a shared account, the organization must identify every person and device using it before changing the password.

That delay can leave former employees with continued access.

Permissions become too broad

A shared account usually receives enough permission for everyone who uses it. This often means some employees receive more access than their work requires.

Individual accounts allow permissions to follow job responsibilities more closely.

Multifactor authentication becomes awkward

MFA is difficult to manage when approval prompts are sent to one employee’s phone or several people share one authentication method.

Staff may begin approving prompts without knowing who initiated them. They may also create unsafe workarounds to avoid disrupting care.

The answer is not to abandon MFA. It is to design authentication around shared-device workflows.

Why this matters to healthcare organizations

Independent medical and dental practices

A front-desk workstation may connect to scheduling, insurance, billing, email, payment, and patient-record systems. One shared login can obscure activity across several sensitive workflows.

Hospice and home-health providers

Employees work from offices, homes, client locations, and mobile devices. Individual identities help the organization manage remote access and remove it when assignments change.

Assisted-living and senior-living organizations

Computers at nursing stations may be used across shifts. Fast access is important, but so is knowing which employee accessed or changed information.

Outpatient clinics

Clinicians and support personnel may move between rooms throughout the day. Authentication must be quick enough to support care while preserving individual accountability.

Small organizations with limited IT staff

Smaller organizations may believe shared accounts are necessary because account administration takes time. In practice, shared accounts often create more work during employee departures, access reviews, investigations, and password changes.

How to configure a safer shared-workstation workflow

1. Inventory shared computers

Create a list of computers used by more than one person.

For each device, record:

Location
Device owner
Primary users or departments
Applications accessed
Whether ePHI may be displayed or stored
Current sign-in method
Automatic-lock setting
Local administrator access
Support responsibility

Include reception desks, nursing stations, treatment rooms, medication areas, back offices, and shared laptops.

2. Identify shared accounts

Look beyond the Windows login. Shared credentials may exist in:

Electronic health records
Microsoft 365
Billing platforms
Imaging systems
Patient portals
Laboratory services
Pharmacy and prescribing platforms
Vendor-support portals
Network devices
Backup systems
Remote-access tools

Do not immediately disable an account simply because it is shared. First determine what depends on it and whether changing it could interrupt patient care.

3. Classify each account correctly

Not every non-person account serves the same purpose.

Account typeAppropriate general treatmentIndividual workforce accountAssigned to one person and tied to that person’s responsibilitiesShared human loginReplace where reasonably possible with individual accessService accountRestrict to a defined system function; do not use for routine human activityShared mailboxGive named users delegated access instead of sharing its passwordEmergency-access accountReserve for documented emergencies and monitor closelyVendor accountAssign named access where possible; restrict, review, and expire itKiosk accountLimit to a narrowly defined application and prevent broader access

A service account or kiosk identity should not quietly become a convenient staff login.

4. Give each employee an individual identity

Provision access using a repeatable onboarding process.

The account record should identify:

Employee name
Job or role
Department or location
Manager
Approved systems
Required permissions
Authentication method
Account owner
Start date
Review date

Permissions should reflect current responsibilities, not simply copy everything another employee has.

5. Choose authentication that fits the workflow

A busy clinical area needs a sign-in process that employees will actually use.

Depending on the environment and licensing, suitable options may include:

Individual username and password with MFA
Windows Hello for Business
FIDO2 security keys
Passkeys
Badge-based authentication
Microsoft-supported frontline-worker authentication
Single sign-on with controlled session behavior

Microsoft recommends phishing-resistant methods such as Windows Hello for Business, passkeys, FIDO2 security keys, and certificate-based authentication where appropriate.

Microsoft also provides specialized shared-device and frontline-worker options. These require careful planning, licensing review, pilot testing, and configuration. They should not be enabled across an organization merely because they appear convenient.

6. Configure automatic locking

Shared workstations should lock after an appropriate period of inactivity.

The exact timing should reflect:

Workstation location
Likelihood of public or patient access
Clinical urgency
Application behavior
Reauthentication time
Care-continuity requirements
Results of the organization’s risk analysis

An aggressive timeout that repeatedly interrupts documentation may encourage unsafe workarounds. A timeout that is too long may leave patient information exposed.

Test the setting with actual users and workflows.

7. Separate administrator access

Employees should not perform ordinary email, browsing, or clinical work while signed in with an administrator account.

Administrators should use:

An individual everyday account
A separate named administrative account
MFA appropriate to the account’s risk
Only the privileges needed for the task
A documented procedure for elevated access

Microsoft recommends least privilege, MFA for administrators, and time-limited privileged access through Privileged Identity Management when licensing and operational needs support it.

8. Maintain emergency access separately

An emergency-access account—sometimes called a break-glass account—is not an ordinary shared staff login.

Microsoft recommends two cloud-only emergency-access accounts for Microsoft Entra environments. These accounts require deliberate configuration, protected credentials, strong authentication, monitoring, testing, and documented authorization.

They should:

Be used only for defined emergencies
Remain separate from normal staff activity
Avoid dependencies likely to fail during the same emergency
Generate alerts when used or changed
Be reviewed and tested on a documented schedule
Have credentials stored securely and accessibly to authorized personnel

Creating an emergency account and forgetting about it is not an emergency-access strategy. It is merely an unattended privileged account wearing a dramatic name.

9. Document exceptions and legacy limitations

Some clinical or vendor systems may not support individual accounts properly.

When replacement is not immediately feasible:

Record the affected system and account.
Identify who is authorized to use it.
Document the operational reason.
Restrict access by device, network, location, or schedule where possible.
Limit permissions.
Monitor relevant activity.
Protect and rotate credentials.
Establish a review date.
Plan remediation, replacement, or compensating safeguards.

An unsupported application does not make the risk disappear. It makes documentation and risk management more important.

10. Test the complete employee lifecycle

A sound access process covers more than initial account creation.

Test what happens when an employee:

Is hired
Changes roles
Transfers locations
Takes extended leave
Loses an authentication device
Needs temporary elevated access
Leaves unexpectedly
Returns as a contractor
Requires urgent access during an outage

The organization should be able to remove or change access without guessing which shared passwords the person may know.

What should healthcare leaders ask their IT provider?

Leadership does not need to configure every technical control. It should receive clear answers to these questions:

Which shared user accounts exist?
Which systems containing ePHI use them?
Can activity be traced to an individual?
How quickly is access removed after a departure?
Who reviews administrator, vendor, and service accounts?
How are shared clinical workstations secured?
Which legacy systems prevent individual sign-in?
What compensating measures are documented?
When were emergency-access accounts last tested?
Who owns each unresolved access risk?

A report consisting only of usernames is not enough. Leadership needs ownership, risk, status, and next actions.

Protect, Operate, Recover, and Grow

Protect

Use individual workforce identities.
Apply least privilege.
Require appropriate MFA.
Separate administrator accounts.
Lock unattended workstations.
Restrict service, kiosk, vendor, and emergency accounts.

Operate

Maintain an account and device inventory.
Use documented onboarding and offboarding.
Review access after role changes.
Give employees a quick, workable sign-in method.
Document application owners and support contacts.
Test shared-workstation settings in real workflows.

Recover

Preserve sign-in and administrative records.
Document how compromised sessions are revoked.
Maintain emergency-access procedures.
Know how staff will work during identity or Microsoft 365 outages.
Record temporary access changes made during an incident.

Grow

Replace shared human accounts systematically.
Add individual authentication requirements to vendor evaluations.
Retire applications that cannot meet operational and security needs.
Improve role-based access as the organization expands.
Use access-review findings to guide technology planning.

The bottom line

Healthcare organizations do not need to assign one computer to every employee. They do need to distinguish the device from the identity.

A shared workstation can support efficient care when each user signs in individually, permissions match job responsibilities, unattended sessions lock, and access is removed promptly.

Start with three actions:

List the shared workstations.
Find the shared human accounts.
Prioritize the accounts that reach patient information, email, administration, billing, or remote access.

That creates a practical path forward without disrupting every workflow at once.

Frequently asked questions

Can two healthcare employees use the same computer?

Yes. A properly configured workstation can be used by multiple employees. Each employee should sign in with an individual identity so permissions and activity can be attributed appropriately.

Can employees share an EHR username?

HHS states that workforce members using systems containing ePHI must receive unique identification so activity can be identified and tracked. If a legacy system cannot support this, the organization should assess and document the limitation, apply safeguards, and establish a remediation plan.

Is a shared mailbox the same as a shared account?

No. A Microsoft 365 shared mailbox can provide several named users with delegated access. Employees should use their own accounts instead of sharing the mailbox password.

What is wrong with a nursing-station login?

A generic nursing-station account may prevent the organization from knowing which employee performed an action. The workstation can remain shared while staff use individual identities and a sign-in method designed for quick clinical access.

Should every Microsoft 365 administrator have a separate account?

Yes. Routine work and privileged administration should be separated. Each administrator should have an individual everyday identity and a separate named administrative account with appropriate protection.

Are service accounts allowed?

Service accounts can be necessary for applications, integrations, and automated processes. They should have a defined owner and purpose, limited permissions, protected credentials, monitoring, and a review process. Staff should not use them for ordinary work.

What is an emergency-access account?

It is a highly privileged account reserved for situations in which normal administrative access is unavailable. It requires special protection, monitoring, testing, and documentation and should never be used as a routine shared administrator login.

Strengthen your healthcare technology readiness

Vault Technologies helps healthcare organizations improve account administration, Microsoft 365 and endpoint management, shared-workstation configuration, access documentation, employee lifecycle procedures, and care-continuity planning.

Our nurse-led perspective keeps technical decisions connected to the realities of patient care, shift changes, mobile work, and busy clinical environments.

Request a complimentary Technology Health Assessment to establish a practical baseline across access controls, endpoint management, vendor dependencies, documentation, and recovery readiness.

The assessment is a planning tool. It is not a legal opinion, compliance certification, penetration test, forensic investigation, or guarantee against cyber incidents.

Authoritative sources

HHS — “Does the Security Rule permit a covered entity to assign the same log-on ID to multiple employees?” , published April 8, 2010.
HHS — Summary of the HIPAA Security Rule , updated August 7, 2026.
HHS — Guidance on HIPAA and Cloud Computing , updated December 23, 2022.
Microsoft — Manage emergency-access accounts in Microsoft Entra ID , updated June 5, 2026.
Microsoft — Best practices for Microsoft Entra roles , updated June 1, 2026.
Microsoft — Authentication methods in Microsoft Entra ID , updated May 7, 2026.
Microsoft — Device management for frontline workers , updated October 24, 2025.

CareCloud Breach Affects 3.75 Million People: What Healthcare Practices Should Review

Thu, 27 Aug 2026 15:36:08 GMT

An electronic health record system can feel like one part of a medical practice’s technology. In reality, it may connect patient records, scheduling, billing, insurance information, clinical documentation, and payment workflows.

That concentration makes healthcare technology vendors valuable targets.

CareCloud, a provider of electronic health records, practice-management, billing, and related healthcare technology, has reported a breach affecting 3,756,469 people . The newly confirmed total makes this more than a story about one software company. It is a reminder that healthcare organizations need to understand what information their vendors hold, how those systems connect to daily care, and what happens when a vendor is compromised.

Quick Answer: What should healthcare organizations do about the CareCloud breach?

Healthcare organizations should first determine whether they use CareCloud directly or through a related service, integration, billing provider, or technology partner.

If they are potentially affected, they should obtain written information from the vendor, identify the systems and patient populations involved, review connected accounts and integrations, preserve relevant documentation, and confirm that downtime and patient-notification responsibilities are understood.

Organizations that do not use CareCloud can still apply the lesson by reviewing their most important EHR, billing, cloud, and practice-management vendors.

What happened in the CareCloud breach?

CareCloud detected a network disruption in its CareCloud Health division on March 16, 2026. The disruption affected functionality and data access in one of the company’s six electronic health record environments for approximately eight hours.

CareCloud restored the affected environment that evening.

Its later investigation found that an unauthorized third party had accessed one of its Amazon Web Services environments between March 10 and March 16. CareCloud reported that the attacker claimed to have removed data from databases in that environment.

On March 24, CareCloud determined that the incident was material because of the sensitivity of the potentially affected information and the possible consequences for patients, customers, operations, regulatory matters, and the company’s reputation. It filed a cybersecurity disclosure with the Securities and Exchange Commission on March 27.

The company completed its review of the affected data on June 24. Breach notifications followed in July, and the Department of Health and Human Services breach portal now lists 3,756,469 affected individuals .

What information may have been involved?

The information varies by person. CareCloud’s regulatory notices say the affected data may include a person’s name together with one or more of the following:

Home address
Date of birth
Social Security number
Driver’s-license or other government identification number
Financial-account information
Credit or debit card information
Medical information
Health-insurance information

An individual notification letter should identify the categories associated with that person.

This combination is particularly sensitive because it can support several forms of misuse. Medical and insurance information may be used to make phishing messages more convincing, while identity and financial details may increase the risk of fraud or account impersonation.

CareCloud has said it found no evidence of additional unauthorized activity in the affected environment after March 16. That does not establish whether stolen information will be misused later.

What remains unknown?

Several important questions have not been answered publicly:

How the attacker first entered the CareCloud environment
Whether stolen or compromised credentials were involved
Whether a vulnerability was exploited
Who conducted the attack
Whether the incident involved ransomware or an extortion payment
Which CareCloud customers were affected
Whether the federal total may change again

No known criminal group has publicly taken responsibility for the incident.

There is also no public evidence that Amazon Web Services itself was breached. The confirmed facts concern unauthorized access to an AWS environment operated by CareCloud.

Why this matters to healthcare organizations

Smaller healthcare organizations often rely on outside vendors for systems they could not reasonably build or manage internally. That includes electronic health records, billing, prescription services, patient communications, imaging, backups, payment processing, and cloud applications.

This is normal and often necessary. It also creates dependencies that must be understood before something goes wrong.

The lesson is especially relevant to:

Independent medical and dental practices with limited internal IT staff
Hospice and home-health providers whose employees need remote access
Assisted-living and senior-living organizations using several clinical and administrative platforms
Outpatient clinics that depend on hosted records, scheduling, and billing
Organizations working with outside billing companies or managed service providers

A healthcare organization may not operate a vendor’s cloud environment, but it still needs enough information to manage its own access, integrations, documentation, communications, and continuity planning.

Five questions to ask about an EHR or healthcare-technology vendor

1. What data does the vendor hold?

Document the types of information shared with the vendor.

This may include patient demographics, clinical notes, insurance information, billing records, payment details, employee information, scanned documents, and system logs.

The organization should also know whether the vendor retains information after a patient relationship ends or after a contract is terminated.

2. Which systems connect to the vendor?

An EHR rarely stands alone. It may connect to:

Microsoft 365
Patient portals
Billing and payment platforms
Laboratories
Imaging systems
Pharmacies and prescribing services
Insurance and claims systems
Medical devices
Document repositories
Third-party reporting tools

Maintain a current integration list that identifies the system owner, purpose, connection method, responsible vendor, and procedure for disabling access.

3. Who can access the platform?

Review users, administrators, service accounts, vendor-support identities, and integration credentials.

Remove accounts that are no longer required. Verify that multifactor authentication is enabled where available, administrative access is limited, and shared accounts are avoided.

Vendor access should also be reviewed. A support account that is rarely used may still have broad access to patient and operational information.

4. What happens if the system becomes unavailable?

CareCloud reported an approximately eight-hour disruption to the affected EHR environment. Even a shorter interruption can create problems during a busy clinic day.

A practical downtime plan should explain:

How staff verify patient identity
Where appointments and contact information can be accessed
How clinical notes are recorded temporarily
How medication and allergy information is handled
How orders, referrals, and prescriptions are managed
Who can authorize urgent technical changes
How temporary records are entered after service returns
How staff and patients receive reliable updates

The procedure must be usable by the people delivering care—not only by the IT team.

5. What will the vendor provide after an incident?

The organization should know who its vendor contact is and what information will be requested after a security event.

Useful written answers include:

Whether the organization was affected
Which systems and dates are involved
What information was accessed
Which patients or employees may be affected
Whether integrations or credentials must be changed
What containment and remediation occurred
What monitoring the vendor is offering
Who is responsible for notifications
When the next update will be provided

A vague statement that an incident is “under investigation” may be appropriate at first, but it should not be the final documentation.

What should an affected CareCloud customer do?

A CareCloud customer should avoid making assumptions based only on public reporting. Its own vendor notice and contractual relationship will determine the appropriate response.

A reasonable technical and operational review should include these steps:

Obtain written confirmation of impact. Ask whether the organization, its systems, or its patients are included in the reported breach.
Identify the affected population and data. Determine which patients, employees, locations, and information categories are involved.
Review connected access. Examine administrator accounts, service accounts, integrations, remote-access methods, application secrets, and support identities.
Coordinate required assessments. Leadership should involve the appropriate privacy, legal, insurance, clinical, and technical personnel. Vault does not provide legal determinations.
Preserve documentation. Retain notices, vendor communications, decisions, system records, investigation notes, and completed actions.
Prepare staff for impersonation attempts. Attackers may use real medical, insurance, or billing details to make fraudulent messages sound legitimate.
Review continuity procedures. Confirm that staff know what to do if the EHR, billing system, portal, or connected application becomes unavailable.

Do not rotate credentials or disconnect an integration without understanding its clinical and business impact. Technical changes should follow a documented sequence that protects patient care.

Applying Protect, Operate, Recover, and Grow

Protect

Use multifactor authentication wherever supported.
Separate administrative accounts from everyday user accounts.
Apply least privilege to staff, vendor, and integration access.
Remove inactive accounts promptly.
Protect exported reports and locally stored patient files.

Operate

Maintain an inventory of healthcare applications and vendors.
Document data types, system owners, integrations, and support contacts.
Review privileged and vendor access regularly.
Track vendor notices, updates, and unresolved security questions.
Confirm where sensitive downloads and scheduled reports are stored.

Recover

Maintain usable EHR and communications downtime procedures.
Document how integrations and compromised accounts can be isolated.
Preserve vendor communications and technical records.
Test how temporary clinical records will be reconciled after restoration.
Confirm that backup and recovery plans cover systems the organization controls.

Grow

Include vendor dependencies in technology planning.
Replace unsupported systems and undocumented integrations.
Use contract renewals to request clearer security, notification, and recovery terms.
Prioritize improvements based on care-continuity risk.
Use a Technology Health Assessment to establish a practical baseline.

The bottom line

The CareCloud breach did not begin inside 3.75 million individual medical practices. It occurred inside a widely used healthcare-technology environment where information from many people was concentrated.

That is the central lesson.

Healthcare organizations cannot directly manage every vendor’s security. They can control which vendors they use, what access they grant, what information they retain locally, how well their dependencies are documented, and whether staff are prepared to continue care during a disruption.

Start with three questions:

Which vendors hold our most sensitive information?
Which daily services would stop if one of those vendors became unavailable?
Do we have current, written procedures for responding?

Frequently asked questions

What is CareCloud?

CareCloud provides electronic health records, practice-management, revenue-cycle, billing, and other technology services to healthcare organizations. It handles patient and operational information for providers across the United States.

How many people were affected by the CareCloud breach?

The HHS Office for Civil Rights breach portal lists 3,756,469 affected individuals . The entry remains under investigation, so organizations should use their direct CareCloud notices for organization-specific information.

When did the CareCloud breach happen?

CareCloud’s investigation found unauthorized access to an AWS environment between March 10 and March 16, 2026. The company detected a network disruption on March 16.

What information was involved?

Depending on the person, the information may include names, addresses, dates of birth, Social Security numbers, government identification, financial information, payment-card information, medical information, and health-insurance information.

Was Amazon Web Services breached?

There is no public evidence that AWS itself was breached. The incident involved unauthorized access to an AWS environment operated by CareCloud.

Does every CareCloud customer need to notify patients?

Not necessarily. A healthcare organization should obtain written, organization-specific information from CareCloud and coordinate with its appropriate privacy and legal resources. Public reporting alone does not determine an organization’s notification obligations.

What should a practice do if it does not use CareCloud?

Use the incident as a reason to review other EHR, billing, cloud, and healthcare-technology vendors. Document what data they hold, who can access their platforms, what systems connect to them, and how the organization would operate during an outage.

Strengthen your healthcare technology readiness

Vault Technologies helps healthcare organizations improve the reliability, security, and documentation of the technology supporting patient care.

Our work includes managed IT, endpoint and Microsoft environment administration, access and configuration reviews, network and systems support, backup and recovery planning, technology assessments, and audit-ready technical documentation.

Our nurse-led perspective keeps the focus on a practical goal: technology should support patient care, not interrupt it.

Request a complimentary Technology Health Assessment to review vendor dependencies, access controls, documentation, endpoint management, and recovery readiness.

The assessment provides a practical baseline and prioritized next steps. It is not a legal opinion, compliance certification, penetration test, forensic investigation, or guarantee against cyber incidents.

Authoritative sources

HHS Office for Civil Rights Breach Portal — CareCloud entry submitted July 24, 2026; federal total verified August 24, 2026.
CareCloud Form 8-K filed with the SEC — March 27, 2026.
CareCloud consumer breach notice published by the California Attorney General — July 2026.
CareCloud notification filed with Massachusetts — July 2026.
TechCrunch independent reporting — August 19, 2026.

Fake IT Support Calls Are Targeting Healthcare: What Your Team Should Verify

Tue, 11 Aug 2026 00:26:19 GMT

Fake IT Support Calls Are Targeting Healthcare: What Your Team Should Verify

Published August 10, 2026

An unexpected call from “IT” may not seem suspicious. Healthcare employees speak with support vendors, software companies, and internal IT teams every day.

That normal interaction is exactly what makes this attack effective.

Google Threat Intelligence Group, or GTIG, recently reported that attackers are calling employees while pretending to be IT-support personnel. The caller creates an urgent reason to update multifactor authentication, register a passkey, or complete a security migration. The employee is then sent to a convincing but fraudulent login portal.

Healthcare was among the industries targeted by infrastructure connected to this campaign.

Quick Answer: What Should an Employee Do During an Unexpected IT Call?

Do not provide a password, read back an authentication code, approve an unexpected MFA prompt, or register a passkey based only on an incoming call.

End the conversation and contact IT through the telephone number, support portal, or internal contact your organization already has on file. Verify the request before changing anything.

If you already followed the caller’s instructions, report it immediately. The sooner IT knows what happened, the sooner it can revoke sessions, review account activity, and determine what needs to be secured.

What Is Happening?

GTIG tracks the group behind this activity as UNC6671. Its attacks have been connected to several public extortion brands, including BlackFile, Redact, Pink, Helix, and Falcon.

The names may change, but the approach is consistent:

Research an organization and its employees.
Call an employee while pretending to represent the IT help desk.
Create urgency around an MFA, passkey, or security update.
Send the employee to a fake portal using the organization’s name.
Capture credentials and authentication information.
Use the access to enter cloud services such as Microsoft 365 or Okta.
Find valuable information and remove it from the environment.
Use the stolen information for extortion.

In some cases, the attackers called employees on their personal mobile phones. GTIG also observed spoofing of legitimate help-desk numbers, meaning the caller ID could appear familiar.

A familiar number is not proof that the caller is legitimate.

Why This Matters to Healthcare Organizations

Healthcare employees are accustomed to outside support.

A nurse may speak with the EHR vendor. A practice manager may work with the billing company. A dental office may need help with imaging software. A home-health employee may contact IT from the field. Staff in a senior-living community may depend on remote support outside normal business hours.

Attackers take advantage of that trust.

If an attacker gains access to an employee’s Microsoft 365 or another cloud account, the attacker may be able to reach whatever that employee is authorized to use. Depending on the person’s role, that could include email, shared documents, schedules, operational records, billing information, or vendor communications.

This does not mean every targeted healthcare organization was breached or that patient information was stolen. GTIG identified healthcare among the sectors targeted by campaign infrastructure, but it did not publicly identify every organization or report the outcome of every attempt.

The practical lesson is simpler: employees need an easy way to verify IT, and IT needs a reliable way to verify employees.

Why These Calls Work

The Request Sounds Routine

Password resets, MFA changes, software updates, and new-device enrollment are normal IT activities. The attacker disguises the request as something employees already expect.

The Caller Creates Urgency

The employee may be told that an account will be disabled or that a security update must be completed immediately. That pressure makes it less likely that the person will stop and verify the request.

The Caller May Know Real Information

An attacker may know the employee’s job title, supervisor, telephone number, vendor, or email address. Real information makes a false story sound credible.

The Website Looks Professional

The fake portal may include the organization’s name and familiar terms such as “MFA,” “SSO,” “passkey,” or “help desk.” A professional-looking page can still be fraudulent.

MFA Is Not All the Same

MFA remains an important security control. However, attackers may convince an employee to disclose a code, approve a prompt, or complete authentication through a fraudulent website.

Phishing-resistant methods provide stronger protection, but technology alone cannot replace a clear verification process.

Five Rules for Unexpected IT Calls

1. Pause Before Acting

A legitimate support professional should understand why an employee wants to verify a security-sensitive request.

Urgency should never eliminate verification.

2. Never Share Authentication Information

Employees should not disclose their password, MFA code, password-reset code, recovery code, or the contents of an unexpected authentication prompt.

They should never approve an MFA request they did not initiate.

3. Use the Official Support Channel

Do not use a link or callback number supplied by the caller.

End the call and contact IT using the support number, portal, or internal contact already documented by the organization.

4. Verify the Ticket

Ask for a ticket number, then verify it through the normal support system. A ticket number by itself is not proof, but it gives the real IT team something to confirm.

5. Report Suspicious Calls

Even an unsuccessful attempt may show that the organization is being targeted. Record the time, telephone number, domain name, text messages, and other available details.

Do not revisit a suspicious website merely to collect more information.

What If Someone Already Followed the Instructions?

Treat the situation as time-sensitive, but avoid blame.

Employees sometimes hesitate to report a mistake because they are embarrassed or worried about getting in trouble. That delay gives the attacker more time.

The employee should stop communicating with the caller and contact the established IT or security representative immediately. They should explain:

What information they entered or disclosed
Whether they approved an MFA prompt
Whether they registered a passkey or authentication method
Which website they visited
Which device they used
Whether they downloaded anything
When the interaction occurred

Depending on what happened, the technical response may include resetting credentials, revoking active sessions, reviewing authentication methods, checking Microsoft 365 and email activity, examining the managed device, and preserving relevant logs.

Changing the password may not be enough if the attacker already obtained an authenticated session or registered another authentication method.

How Healthcare Leaders Can Reduce the Risk

Healthcare administrators do not need to become security analysts. They do need written answers to a few practical questions.

Do Employees Know How to Verify IT?

Publish one official support number and one approved support portal. Explain how technicians identify themselves, what they will never request, and how employees should report suspicious contact.

Keep those instructions somewhere staff can access during an outage.

Is There a Callback Rule?

Employees should be expected to end unsolicited calls involving passwords, MFA, passkeys, remote access, or security settings. They can then reconnect through the official support channel.

Leadership should support this behavior. Employees should never feel that verifying an IT request will get them in trouble.

How Are Password and MFA Resets Approved?

Help-desk personnel should not rely only on information that can be researched or purchased, such as birth dates, job titles, addresses, or supervisor names.

Password resets, MFA resets, new-device enrollment, passkey registration, and recovery-method changes should follow a documented identity-verification process.

Privileged and administrative accounts should receive additional scrutiny.

Are Important Accounts Adequately Protected?

GTIG recommends phishing-resistant authentication such as FIDO2 security keys, passkeys, and Windows Hello for Business.

Healthcare organizations should introduce stronger authentication carefully, starting with administrators and other high-risk accounts. Changes must be planned and tested so they do not interrupt clinical workflows.

Is Anyone Reviewing the Activity?

Organizations should be able to review password resets, MFA changes, unusual sign-ins, new authentication methods, unexpected inbox rules, privileged-account changes, and other suspicious activity.

Collecting logs is not enough. Someone must know when to review them, what requires escalation, and how the organization will document its response.

Protect, Operate, Recover, and Grow

Protect

Use strong authentication, separate administrative accounts from everyday accounts, apply least privilege, and require documented verification for password and MFA resets.

Operate

Maintain current support contacts, escalation paths, account procedures, and instructions for remote or after-hours employees.

Recover

Document how the organization will revoke affected sessions, secure accounts, preserve relevant information, examine managed devices, and continue essential workflows during a disruption.

Grow

Use exercises and real incidents to improve employee education, vendor oversight, technical documentation, and technology planning.

The Bottom Line

Fake IT-support calls work because employees are accustomed to trusting the people who maintain their technology.

The answer is not to make staff distrust every support interaction. The answer is to give them a simple verification process that works during a busy clinic day, an after-hours shift, or a home-health visit.

Every employee should remember three things:

Never disclose a password or authentication code during an unsolicited call.
Verify the request through the organization’s established support channel.
Report a suspected mistake immediately.

A calm, documented process protects the organization without making legitimate support harder to use.

Frequently Asked Questions

What Is an IT Help-Desk Voice-Phishing Attack?

It is a social-engineering attack in which someone calls an employee while pretending to be an authorized IT-support professional. The caller tries to obtain credentials, authentication approval, remote access, or control of an account.

Will a Legitimate IT Technician Ask for My Password or MFA Code?

A properly designed support process should not require an employee to disclose a password or one-time MFA code. Verify unusual requests through the organization’s official support channel.

Can Caller ID Prove the Call Came From Our Help Desk?

No. Telephone numbers can be spoofed. End the call and reconnect through a known support number or approved portal.

Does MFA Stop Fake IT-Support Attacks?

MFA reduces risk, but some methods can be socially engineered or intercepted. Phishing-resistant authentication offers stronger protection against fraudulent websites.

What Should I Do if I Approved an Unexpected MFA Request?

Contact your established IT or security representative immediately. Provide the time, account, device, prompt, website, and any other available details.

Why Would Attackers Target a Small Healthcare Organization?

Small healthcare organizations still rely on valuable email, scheduling, billing, vendor, and clinical-support systems. They may also have informal support procedures that are easier to impersonate.

How Can We Verify a Passkey-Enrollment Request?

Start the process through an approved internal procedure, known support portal, or independently verified technician. Do not register a passkey through a link supplied during an unexpected call or text message.

Strengthen Your Healthcare Technology Readiness

Vault Technologies helps healthcare organizations improve Microsoft 365 and endpoint administration, help-desk processes, technical documentation, backup and recovery planning, and care-continuity readiness.

Our nurse-led perspective keeps the focus where it belongs: technology should support patient care, not interrupt it.

A complimentary Technology Health Assessment can help establish a practical baseline across access controls, endpoint management, vendor dependencies, support procedures, documentation, and recovery readiness.

Know where your organization stands. Request a complimentary Technology Health Assessment and identify the technology risks that deserve attention first.

The assessment is a practical planning tool. It is not a legal opinion, compliance certification, penetration test, forensic investigation, or guarantee against cyber incidents.

Authoritative Sources

Amgen Confirms Patient PHI Theft From Cloud Systems: Five Checks for Healthcare Organizations

Mon, 03 Aug 2026 20:20:50 GMT

A major biotechnology company has confirmed that protected health information was taken from data stored in third-party cloud environments. The incident is a timely reminder for healthcare organizations of every size: moving data to the cloud does not move away your responsibility to understand where sensitive information lives, who can access it, and how suspicious activity will be detected and handled.

What Amgen confirmed

In a Form 8-K filed with the U.S. Securities and Exchange Commission on July 31, 2026, Amgen said it identified unauthorized activity in July involving data stored in cloud environments hosted by third-party cloud service providers.

Amgen reported that data exfiltrated from those environments included proprietary information, patient protected health information, and other data. The company activated its cybersecurity response plan, implemented containment measures, and engaged independent forensic experts. It determined the incident was material on July 29 based on the apparent volume of affected files and the potential sensitivity of the information.

The investigation remains ongoing. At the time of the filing, Amgen had not identified an impact on its products, manufacturing operations, financial reporting systems, or ability to meet patient needs.

What has not been disclosed

Several important details were still unknown or unavailable in Amgen’s filing, including:

• The identity or motive of the attacker.
• The initial access method.
• The cloud provider or providers involved.
• The number or location of affected patients.
• The specific PHI fields that were taken.
• The full extent of any affected intellectual property or research and development information.

Those gaps matter. They also mean healthcare leaders should avoid turning this disclosure into speculation about a particular vendor, attack technique, or number of victims.

The larger lesson: cloud security is a shared responsibility

Cloud platforms can provide strong security capabilities, but those capabilities still have to be configured, monitored, and governed. HHS guidance says healthcare organizations using cloud services for electronic PHI should understand the cloud environment, conduct their own risk analysis, establish appropriate risk-management policies, and maintain appropriate business associate agreements.

For a small medical office, dental practice, hospice provider, home-health agency, or senior-living organization, the practical question is not simply, “Is our data in the cloud?” The better questions are: “Which cloud systems contain PHI? Who can get into them? What evidence would show us that something went wrong? And what would we do next?”

Five checks healthcare organizations should make now

1. Locate PHI across every cloud platform

Create a current inventory of systems that store, process, or transmit patient information. Include the EHR, email, file-sharing platforms, backup services, billing systems, patient portals, collaboration tools, and vendor-managed applications. Assign an owner to each system and document what information it contains.

2. Review identities and privileged access

Confirm that multifactor authentication is enforced, especially for administrators and remote access. Remove stale accounts, separate daily-use and administrative identities, and review vendor and contractor access. Access should match each person’s actual role—not simply remain in place because it was granted years ago.

3. Confirm that useful logging is enabled

Logs should help answer who signed in, from where, what they accessed, and what changed. Verify that important audit logs are enabled, retained long enough to support an investigation, and reviewed through alerts or routine monitoring. A log that exists but is never checked provides limited protection.

4. Revisit vendor agreements and escalation contacts

Confirm which vendors are business associates, where the applicable agreements are stored, and who must be contacted during an incident. Review notification expectations, security responsibilities, data return or destruction terms, backup and recovery commitments, and the process for obtaining relevant records during an investigation.

5. Practice the first day of a cloud incident

Document the first actions your team would take if cloud data might have been accessed: preserve evidence, disable or restrict affected access, rotate credentials where appropriate, contact the right internal and external parties, maintain patient-care workflows, and begin the required legal and regulatory assessment. Test the plan before an emergency exposes missing contacts or unclear authority.

What this means for your practice

Amgen’s disclosure does not prove that every cloud system is unsafe. It shows why “the vendor handles security” is not a complete operating model. Healthcare organizations need visibility into their own users, data, configurations, contracts, logs, and response procedures—even when a third party hosts the technology.

A practical review does not have to begin with a massive project. Start with the systems holding the most sensitive information and supporting the most important patient-care processes. Identify the highest-risk gaps, assign owners, and build a realistic improvement plan.

A sensible next step

Vault Technologies helps healthcare organizations understand where technology risk may affect privacy, operations, and care continuity. A Technology Health Assessment can help establish a clear starting point for reviewing access, cloud governance, documentation, vendor dependencies, and recovery readiness.

Ready to see where your organization stands? Start your Technology Health Assessment or contact Vault Technologies to discuss your environment.

Sources:

Amgen Form 8-K, filed July 31, 2026

HHS Guidance on HIPAA and Cloud Computing

When the Network Goes Down: Lessons for Healthcare Practices From Angola’s Nationwide Cyberattack

Mon, 03 Aug 2026 19:38:14 GMT

This is a subtitle for your new post

The body content of your post goes here. To edit this text, click on it and delete this default text and start typing your own or paste your own from a different source.

N-central Cyberattacks Reached Managed Devices

Mon, 03 Aug 2026 18:48:45 GMT

Attackers are actively exploiting a security vulnerability in N-able N-central, a remote monitoring and management platform used by managed service providers and internal IT teams. The vulnerability, CVE-2026-18577, can allow remote administrative access to vulnerable N-central servers.

N-able confirmed that attackers used this access to connect to downstream managed devices through N-central’s legitimate Take Control feature. On some endpoints, the attackers installed Cloudflare tunnels as Windows services, creating a way to retain access even after access through the N-central server was revoked.

For healthcare organizations, the central lesson is straightforward: updating the management server is essential, but it may not remove persistence already established on managed devices.

QUICK ANSWER

Organizations using N-central should verify that build 2026.3.1.7 has been applied, determine whether their environment shows evidence of exploitation, and confirm that managed endpoints were examined for unauthorized Take Control activity, suspicious files, and Cloudflare tunnel services.

What Happened in the N-central Cyberattack?

N-able observed an unusual increase in licensing problems among N-central customers on July 31, 2026. During its investigation, the company identified another way to exploit a vulnerability that it had previously attempted to address.

The earlier vulnerability, CVE-2026-18556, was addressed in N-central 2026.2. N-able later determined that the correction was incomplete and assigned the newly identified issue CVE-2026-18577 .

According to N-able, attackers were able to:

Obtain remote administrative access to vulnerable N-central servers.
Use N-central’s legitimate Take Control function to reach managed customer devices.
Register a service named Cloudflared on some Windows endpoints.
Maintain access through a Cloudflare tunnel after access through N-central was revoked.

N-able says it identified a limited number of affected customers and contacted them directly. The company has not publicly disclosed the total number of managed service providers, downstream organizations, endpoints, industries, or countries involved.

The attacker and motive remain unknown. There is currently no confirmed public evidence that the incident involved ransomware, patient-data theft, or a compromise of Cloudflare. Attackers abused Cloudflare’s legitimate tunneling functionality; Cloudflare itself was not reported breached.

Why Is CVE-2026-18577 Especially Concerning?

Remote monitoring and management tools are designed to provide broad, efficient administrative access. Authorized IT teams use them to troubleshoot devices, deploy software, run scripts, change settings, and support users remotely.

Those capabilities are valuable, but they also make an RMM platform a high-impact target. If an attacker gains administrative control , the platform’s trusted functions can become a pathway to numerous endpoints and potentially multiple customer organizations.

For healthcare organizations, affected devices could support:

Electronic health record access
Medication, scheduling, billing, and imaging workflows
Microsoft 365 and shared clinical documentation
Remote and mobile care teams
Domain controllers, file servers, and identity systems
Workstations used during patient care

There is no public evidence that every type of system listed above was affected in this incident. The list illustrates why healthcare organizations should treat privileged remote-management platforms as part of their critical operational infrastructure.

Does Installing the N-central Hotfix Completely Resolve the Risk?

No . Installing the hotfix closes the known N-central vulnerability, but it does not automatically prove that managed endpoints are clean.

N-able released N-central 2026.3 Hotfix 1, build 2026.3.1.7 , on August 2, 2026. The vendor identifies this as the first unaffected build and recommends urgent installation.

N-able-hosted N-central : N-able says the upgrade will be applied automatically according to the customer’s communicated schedule.
Self-hosted N-central : The organization or its IT provider must download and install the hotfix.

However, attackers installed persistent services on downstream devices in confirmed cases. Once that occurs, patching the N-central server or disabling a compromised administrator account may not terminate the connection established on an endpoint.

A complete response therefore requires answers to two separate questions:

Has the N-central server been updated to build 2026.3.1.7 or later?
Have managed devices been investigated for suspicious activity that occurred before the update?

What Should Healthcare Organizations Ask Their MSP or IT Provider?

Healthcare leaders do not need to become vulnerability analysts. They do need clear, written confirmation that their technology environment was evaluated appropriately. Ask your managed service provider or internal IT team the following questions.

1. Do We Use N-able N-central Anywhere in Our IT Environment?

Confirm whether N-central is operated internally, hosted by N-able, or used by an outside managed service provider to support your devices. A healthcare organization may be affected by its IT provider’s management tools even when it does not own or directly access the platform.

2. What Exact N-central Build Manages Our Systems?

Request written confirmation that the relevant N-central server is running build 2026.3.1.7 or later . If the platform is hosted, ask whether the upgrade has been completed—not merely scheduled .

3. Was Our Environment Checked for Evidence of Exploitation?

The review should include N-central administrator activity, access-control events, Take Control sessions, scripts, jobs, and unexpected changes to accounts or roles.

N-able also published network indicators associated with the attacks. However, an IP-address match should be evaluated alongside the account involved, the time of the connection, the affected device, and session records. Some published addresses are commercial VPN exit nodes, so an IP match alone is not proof of compromise .

4. Were Managed Windows Devices Examined for Persistent Access?

N-able recommends examining managed endpoints—not only the N-central server . The investigation should include unauthorized Take Control activity, unexplained remote sessions, suspicious files, and unexpected services named Cloudflared.

Sensitive systems such as domain controllers, file servers, administrative workstations, and devices supporting patient-care workflows should receive appropriate priority. Installing the hotfix does not automatically remove access that may already have been established on an endpoint.

5. Do Any Credentials, Tokens, or Accounts Need to Be Rotated?

If exploitation is suspected or confirmed, the organization and its IT provider should determine which administrator credentials, service accounts, access tokens, and remote-access secrets may have been exposed.

Credential rotation should follow a documented sequence to avoid disrupting essential applications or patient-care services. Simply changing one N-central administrator password may not address credentials accessed elsewhere in the environment.

6. What Findings and Decisions Are Being Documented?

Request a written record of the affected N-central deployment, installed build, investigation scope, systems reviewed, evidence found, remediation performed, credentials rotated, and remaining follow-up actions.

Clear technical documentation supports operational continuity, leadership oversight, insurance communications, and any required legal or regulatory assessment. It also helps prevent critical decisions from being lost when several vendors or internal teams participate in the response.

What Should You Do if Your IT Provider Cannot Confirm the Update?

Escalate the request to the provider’s technical or security leadership and ask for written confirmation of the N-central version, update status, and investigation performed.

A vulnerable self-hosted instance that cannot be promptly updated should not remain openly exposed without a documented risk decision and protective controls. Appropriate interim measures may include:

Restricting console access through a VPN or firewall allowlist
Limiting administrative access to authorized personnel
Increasing monitoring for unusual administrative or endpoint activity
Temporarily disabling an unsafe instance when doing so will not create a greater operational risk

These decisions should be made by qualified personnel who understand the organization’s clinical and business dependencies.

Healthcare leaders should avoid making abrupt changes to remote-management systems during patient-care hours without a continuity plan. The goal is prompt risk reduction without creating an unmanaged outage that interferes with care delivery.

What This Incident Teaches Healthcare Organizations

The N-central incident is a lesson about vendor access and privileged technology —not simply a patching story. Healthcare organizations can use the event to evaluate security and operational readiness across four areas.

Protect

Restrict access to privileged management platforms, use strong multifactor authentication where supported, separate administrative accounts from everyday user accounts, apply least privilege, and reduce unnecessary internet exposure.

Operate

Maintain an accurate inventory of remote-management tools, responsible vendors, installed versions, integrations, privileged identities, and the devices each platform can reach. Require technology providers to communicate material vulnerabilities and remediation status clearly.

Recover

Document how the organization would isolate a compromised management platform, rotate affected access, examine managed endpoints, preserve relevant evidence, restore trusted administration, and continue essential care workflows during disruption.

Grow

Use lessons from real incidents to improve vendor oversight, technical documentation, technology lifecycle planning, and leadership visibility. A Technology Health Assessment can help establish an objective baseline and prioritize improvements according to operational and care-continuity impact.

The Bottom Line

CVE-2026-18577 demonstrates why trusted IT-management tools require the same disciplined oversight as other critical systems. N-able has released a hotfix, but healthcare organizations must also consider what attackers may have done through the platform before it was updated.

Healthcare organizations should obtain documented answers to three questions:

Was our N-central environment vulnerable?
Was the correct hotfix applied?
Were managed devices and privileged activity reviewed for persistence or misuse?

Those answers provide far more assurance than a simple statement that “the patch was installed.”

Strengthen Your Healthcare Technology Readiness

Vault Technologies helps healthcare organizations improve the reliability, security, and documentation of the technology supporting care. Our work includes managed IT, endpoint and Microsoft environment administration, network and systems support, access and configuration reviews, backup and recovery planning, technology assessments, and audit-ready technical documentation.

Our nurse-led perspective keeps the focus where it belongs: technology should support patient care, not interrupt it.

Know where your organization stands. Request a complimentary Technology Health Assessment to review privileged access, endpoint management, vendor dependencies, documentation, and recovery readiness across the Protect, Operate, Recover, and Grow framework.

The assessment provides a practical baseline and prioritized next steps. It is not a legal opinion, compliance certification, penetration test, or guarantee against cyber incidents.

Frequently Asked Questions

What Is CVE-2026-18577?

CVE-2026-18577 is an authentication-bypass and account-takeover vulnerability caused by an incomplete correction for the earlier CVE-2026-18556 vulnerability. It affects N-central versions before build 2026.3.1.7 and has been actively exploited.

Which N-central Version Fixes CVE-2026-18577?

N-able identifies N-central 2026.3 Hotfix 1, build 2026.3.1.7 , as the first unaffected version. Organizations should confirm the exact installed build rather than relying only on an assurance that N-central was updated.

Are Hosted N-central Deployments Affected?

The vulnerability applied to vulnerable N-central deployments. N-able says upgrades for its hosted service are applied automatically according to a communicated schedule. Customers should confirm that the upgrade was completed and determine whether activity before the update requires investigation.

Does Patching N-central Remove a Cloudflare Tunnel From an Endpoint?

Not necessarily. N-able reported that attackers registered Cloudflare tunnels as services on managed devices, allowing access to persist after N-central access was revoked. Affected endpoints must be examined and remediated separately.

Was Cloudflare Breached?

No public evidence indicates that Cloudflare was breached. Attackers used Cloudflare’s legitimate tunneling technology to create persistent connections on affected managed devices.

Was Patient Information Stolen?

N-able has not publicly confirmed patient-data theft in this incident. The confirmed facts establish exploitation of vulnerable N-central systems, administrative access, downstream endpoint access in affected environments, and the installation of persistent tunnels on some devices.

How Can a Healthcare Organization Determine Whether Its MSP Uses N-central?

Ask the provider to identify the remote-monitoring, endpoint-management, and remote-support platforms used to administer the organization’s systems. The answer should include the platform owner, hosting model, current version, responsible administrator, and systems the platform can reach.

Sources

Update — August 3, 2026: Hosted N-central Deployments Are Also Affected

New findings from Huntress materially expand the scope of this incident. The vulnerability is not limited to self-hosted or on-premises N-central servers. Both hosted and on-premises deployments are affected, and every currently supported version requires the N-central 2026.3.1.7 hotfix.

At the time of Huntress’s August 3 update, 55.6% of the reachable N-central cloud servers associated with its partners and customers remained unpatched. This figure does not represent every N-central deployment worldwide, but it demonstrates why healthcare organizations should obtain explicit confirmation that their environment is running build 2026.3.1.7—even when N-central is hosted or managed by an outside IT provider.

Installing the hotfix is essential, but it does not automatically remove access that attackers may have already established on managed devices. Confirm that your IT provider has reviewed downstream endpoints for unauthorized Take Control sessions, suspicious services, and Cloudflare tunnels—not simply updated the central N-central server.

N-able’s published IP indicators should also be interpreted carefully. Several are commercial VPN exit nodes associated with Mullvad or NordVPN. A matching IP address is a reason to investigate the related account, time, device, remote session, and support ticket; it is not proof of compromise by itself.

Healthcare organizations should ask their IT provider to confirm, in writing:

Whether every hosted and on-premises N-central instance is running build 2026.3.1.7.
Whether administrative accounts, access logs, and remote-control sessions were reviewed.
Whether managed endpoints—including domain controllers and file servers—were examined for suspicious Take Control activity and unauthorized Cloudflare tunnel services.
Whether any unexplained activity was found and, if so, what containment and recovery actions were taken.

The central lesson remains the same: “hosted” does not necessarily mean “already patched,” and updating the management server is not a substitute for investigating the devices it controlled.

Synology NAS Data Recovery: A Four-Drive Failure Case Study

Thu, 16 Apr 2026 15:56:27 GMT

A four-bay Synology network-attached storage device had become intermittently inaccessible after multiple drives developed serious problems. The system stored security video, but recordings requested from February could not be found.

Vault Technologies evaluated the NAS, restored administrative access, preserved the files that remained accessible, and documented the steps needed to rebuild the organization’s storage and backup process.

Quick Answer: What did Vault recover from the Synology NAS?

Vault Technologies restored access to the Synology DiskStation Manager interface and exported all accessible files to client-provided external storage.

The requested February recordings were not present on the NAS and could not be recovered. The evaluation found that three of the four installed drives had failed or developed system-partition problems, preventing the NAS from reliably recording and retaining new video.

The Synology NAS Problem

The organization depended on its Synology four-bay NAS to store security recordings. When specific February recordings were requested, employees discovered that the files were missing.

The NAS was also intermittently inaccessible, creating a risk that additional files could become unavailable.

The initial priorities were to:

Stabilize access to the device
Determine which files remained available
Preserve recoverable data
Identify why new recordings were missing
Document a practical recovery plan

Because continued changes to a degraded storage array can increase risk, the work required a careful and controlled approach.

How Vault Technologies Responded

Restored administrative access

Vault connected the Synology NAS directly to a workstation to establish stable access for evaluation. Administrative access to Synology DiskStation Manager was then restored so the storage volumes, directories, and drive status could be reviewed.

Prepared external storage

A client-provided external drive was prepared for the data export. This provided a separate destination for accessible files and reduced dependence on the degraded NAS.

Preserved accessible files

Vault reviewed the available volumes and directories, then transferred accessible files to external storage using direct and verified copy methods.

The client also received instructions for monitoring and continuing the transfer process where appropriate.

Reviewed the missing recording dates

The storage directories were examined for the requested video ranges. The most recent recordings found were dated January 27. No files dated February 1 or later were present on the NAS.

This distinction is important: the engagement preserved files that were still accessible, but it could not recover recordings that the system had apparently failed to create or retain.

What the Technical Review Found

The drive review identified the following conditions:

Drive 1 was functioning normally.
Drive 2 had a system-partition failure.
Drive 3 had a system-partition failure.
Drive 4 had crashed and was no longer operational.

With only one of the four drives functioning normally, the NAS could not be considered reliable for ongoing recording or data retention.

The multiple drive problems provided a reasonable technical explanation for the missing February recordings. However, the assessment did not establish the precise date on which every failure occurred.

Results of the NAS Recovery

Vault Technologies completed the engagement with the following results:

Administrative access to the Synology NAS was restored.
All accessible files were exported to client-provided external storage.
The missing recording period was identified and documented.
Multiple drive failures were identified as the underlying storage problem.
The organization received a written remediation plan.
Immediate risks and recommended next steps were clearly explained.

The NAS was not represented as fully repaired or ready for continued production use. Replacing failed drives, rebuilding the storage environment, and validating the recording process remained necessary.

Recommended Next Steps

Replace the failed drives carefully

Failed drives should be replaced only after accessible data has been preserved and verified. Rebuilding an array without a recovery plan can overwrite information or place additional stress on the remaining drives.

Maintain a separate backup

RAID can help maintain availability after certain drive failures, but it is not a backup. Important files should also be copied to separate storage that is not dependent on the same NAS enclosure or disk array.

Enable storage-health alerts

Synology DSM notifications and drive-health monitoring should be configured to alert the appropriate person when a drive degrades, a storage pool changes status, or a backup fails.

Alerts are useful only when they reach someone responsible for acting on them.

Define recording and retention requirements

Organizations using a NAS for security video should document:

How many days of recordings must be retained
Which cameras and locations are covered
How storage capacity is calculated
Who reviews recording failures
How missing footage is escalated
Whether critical recordings require a second copy

Test recovery periodically

A backup process should be tested by restoring selected files. Successful backup notifications do not prove that the required files can be recovered when needed.

Document the environment

The organization should maintain current records covering:

NAS model and serial number
Drive models, capacities, and installation dates
Storage-pool and RAID configuration
Administrator ownership
Alert recipients
Backup destinations
Retention settings
Recovery and escalation procedures

Why This Matters to Small Organizations

A NAS often operates quietly in the background until a file is missing or a drive fails. Small organizations may not have an employee routinely reviewing storage health, backup results, available capacity, or recording continuity.

That creates several common risks:

Drive warnings remain unnoticed.
Storage fills without warning.
Video stops recording.
Backups fail silently.
Administrative credentials become unavailable.
Recovery procedures remain untested.
Employees assume RAID protects against every form of data loss.

Regular monitoring and documented ownership can expose these problems before several drives fail or critical information is requested.

The Bottom Line

Vault Technologies restored access to a degraded Synology NAS and preserved all files that remained accessible. The assessment also established that the requested February recordings were not present and that multiple drive failures had disrupted reliable recording and retention.

The most important lesson is straightforward: a NAS requires monitoring, independent backups, tested recovery procedures, and a clearly assigned owner. RAID alone is not a complete data-protection strategy.

Frequently Asked Questions

Can data be recovered from a Synology NAS with failed drives?

Sometimes. Recovery depends on the RAID configuration, number and type of drive failures, condition of the remaining disks, and whether new data has overwritten recoverable information. The safest response is to stop unnecessary changes and have the system evaluated before rebuilding it.

Does RAID count as a backup?

No. RAID can provide resilience against certain drive failures, but it does not protect against accidental deletion, corruption, malware, theft, fire, equipment failure, or every multiple-drive failure. Important data needs a separate backup.

Why might security recordings be missing from a NAS?

Possible causes include failed drives, a degraded storage pool, insufficient capacity, camera or application errors, incorrect retention settings, network problems, permissions issues, or interrupted recording services. The cause must be determined from the specific system.

Should a degraded Synology array be rebuilt immediately?

Not always. Rebuilding can place additional stress on the remaining drives and may create further data loss. Important files should be preserved first, and the condition of the storage pool and disks should be evaluated before changes are made.

How can an organization detect NAS drive failures earlier?

Enable DSM notifications, configure drive-health and storage-pool alerts, identify responsible recipients, and periodically review whether alerts are being received and acted upon.

How often should NAS backups be tested?

Testing frequency should reflect the importance of the data and how quickly it changes. At minimum, organizations should perform scheduled restore tests and test again after significant storage, backup, or configuration changes.

Can Vault Technologies guarantee that missing files will be recovered?

No responsible provider can guarantee data recovery before evaluating the device. Vault can assess the system, preserve accessible information, document findings, and recommend appropriate recovery or remediation steps.

Strengthen Your Data-Protection Plan

Vault Technologies helps organizations improve storage administration, backup and recovery planning, system monitoring, technical documentation, and business-continuity readiness.

Request a complimentary Technology Health Assessment to identify gaps in storage, backups, endpoint management, access controls, vendor dependencies, and recovery planning.

The assessment is a planning tool. It is not a forensic investigation, data-recovery guarantee, legal opinion, or compliance certification.

IT Setup for a New Bookkeeping Business in Cottage Grove

Thu, 12 Mar 2026 17:29:19 GMT

A new bookkeeping business needs more than accounting software. It needs reliable equipment, protected document storage, properly configured applications, and a support resource who can explain the technology clearly.

A bookkeeping professional in Cottage Grove, Oregon, asked Vault Technologies to create a dependable technology foundation before client work began.

Quick Answer: How did Vault prepare the bookkeeping business for launch?

Vault Technologies configured the client’s accounting software, cloud document storage, laptop, printer, and scanner as one practical working environment. The completed setup allowed the client to begin serving customers with reliable equipment, organized information, and greater confidence using the technology.

What the Client Needed

The client was establishing a bookkeeping business and needed technology that was secure, reliable, and straightforward to use. The setup had to support accounting work, protect sensitive financial documents, and connect the laptop, printer, and scanner into one dependable daily workflow. Because the client had limited technical experience, clear guidance and ongoing support were also important.

Technology Challenges Before Launch

Before the business could begin serving clients efficiently, several technology needs had to be addressed:

Accounting software: The application needed to be installed, updated, and configured for the client’s workflow.
Document storage: The client needed an organized cloud-storage structure for sensitive business and customer files.
Equipment setup: The new laptop, printer, and scanner needed to be configured and tested together.
Ease of use: The completed system needed to be understandable and manageable for someone without a technical background.
Ongoing support: The client needed a trusted resource for questions and future technology problems.

Without a coordinated setup, these issues could have caused delays, inconsistent document handling, equipment problems, and unnecessary interruptions after the business opened.

Vault Technologies’ Solution

Vault Technologies provided a guided technology setup designed around the client’s daily bookkeeping workflow.

1. Accounting Software Configuration

Vault installed and configured the accounting software, applied available updates, and adjusted the basic settings and user preferences needed for client work.

2. Organized Cloud Document Storage

Vault established a structured cloud-storage environment so the client could organize and access business and customer documents more consistently. The setup focused on practical access, clear organization, and reducing dependence on files stored only on one device.

3. Laptop and Office-Equipment Setup

The client’s laptop, printer, and scanner were configured and tested together. This helped ensure the equipment supported everyday tasks such as creating documents, printing records, and scanning paperwork.

4. Clear User Guidance

Vault explained the completed setup in plain language and answered the client’s questions. The goal was not merely to install technology, but to leave the client comfortable using it.

5. Ongoing Support

The engagement also gave the client a trusted resource for future technical questions, system changes, and troubleshooting.

Results

The client launched the bookkeeping business with a functioning, organized technology environment ready to support daily work.

Key outcomes included:

Accounting software configured and ready for client work
Cloud document storage organized for practical daily use
Laptop, printer, and scanner connected and tested
Less dependence on files stored only on one device
Greater confidence using the completed system
An established relationship for future IT support

The project reduced the uncertainty of setting up several technologies independently and allowed the client to concentrate on building the new business.

Client Testimonial

“I’m a bookkeeper starting my business, and Vault Technologies helped me with all the tech stuff I didn’t understand. They set up my accounting software, helped me pick a secure cloud storage option for client documents, and got my new laptop and printer working the way they should. They were patient, professional, and made everything simple. I feel a lot more confident now thanks to Vault Technologies IT support and plan to work with them again.”

The client’s identity has been withheld for privacy.

Impact

This project demonstrates how a coordinated technology setup can reduce delays and uncertainty when launching a small business.

Vault Technologies helped the client:

Begin operations with properly configured equipment and software
Organize important documents more consistently
Reduce dependence on a single device for file storage
Understand how the new technology worked
Establish a trusted source for ongoing support

For small businesses in Cottage Grove and the Eugene–Springfield area, practical IT support can provide a stronger foundation without requiring the owner to become a technology expert.

The Bottom Line

New businesses often acquire software, computers, printers, and cloud services separately. Without coordinated setup, those tools may not work together effectively.

Vault Technologies helps organizations reduce technology risk, disruption, and uncertainty—so their people can focus on the work that matters.

Request a complimentary Technology Health Assessment to review your technology, access controls, documentation, backup planning, and operational readiness.

The assessment is a practical planning tool. It is not a legal opinion, compliance certification, penetration test, or guarantee against technology failures or cyber incidents.