bsfm4465-loc7f605517

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.

Medical Group Ransomware Attack

Mon, 06 Jul 2026 15:15:00 GMT

Medical Practice Ransomware Attack Exposes 934,000 Patient Records

A multi-location medical group in Maryland had patient data for 934,326 individuals stolen in a January 2025 ransomware attack, leading to multiple class-action lawsuits over its cybersecurity practices and delayed notification .

What happened in this medical practice ransomware case?

On January 27, 2025, an unauthorized party gained access to the medical group's network and copied files from a shared file server. The organization, which operates more than 25 locations and employs nearly 4,000 staff, detected the unauthorized activity and took its IT systems offline to contain the threat.

The electronic medical records system itself was reportedly not the entry point. The attackers reached patient data through a shared drive — a far more common and far less defended target than the EHR platform most practices assume is their main point of exposure.

What patient information was exposed?

Stolen data included patient names, addresses, dates of birth, Social Security numbers, driver's license numbers, medical record numbers, health insurance details, and clinical information related to patient care. No ransomware group publicly claimed the attack and no stolen data surfaced publicly afterward, which security researchers say often indicates a ransom was paid quietly rather than negotiated in public.

Why did patients sue over this breach?

At least five class-action lawsuits were filed against the medical group. The suits allege the organization failed to implement reasonable cybersecurity safeguards, didn't follow industry-standard practices, and didn't disclose adequate detail in its breach notification letters — including what specific steps were being taken to prevent a repeat incident.

The lawsuits illustrate a pattern that extends well past large health systems: a breach notification that reads as vague or incomplete can generate legal exposure on its own, separate from the underlying security failure.

What would a managed IT provider have done differently?

A shared file server held highly sensitive data with apparently limited monitoring or access restriction. Network segmentation and least-privilege access mean files containing Social Security numbers and clinical data aren't sitting on a general-access shared drive in the first place — and if they must be, access is scoped and logged.

The intrusion wasn't detected until the attackers had already copied the data out. Continuous monitoring is built to catch unusual file access and large data transfers in progress, not after the fact, narrowing the window between intrusion and detection from weeks to minutes.

Breach notification letters were criticized as vague and incomplete, which became part of the basis for litigation. A documented incident response plan defines exactly what gets communicated, when, and in what level of detail — so notification meets both the legal requirement and the standard a reasonable patient would expect.

The practice had no way to quickly confirm what was actually impacted versus merely accessible. Clear documentation of where sensitive data lives and who can reach it means a practice can scope an incident accurately and quickly, instead of guessing under pressure while lawyers and regulators wait for an answer.

The bottom line

This wasn't an attack on a hardened core system — it was an attack on a shared drive that nobody had gotten around to locking down. That's a gap nearly every practice has somewhere, and it's the exact kind of gap proactive, documented IT management is built to close before it becomes a headline and a lawsuit.

Dental Practice Ransomware Settlement

Mon, 29 Jun 2026 15:18:23 GMT

A single-location dental practice in Indiana paid a $350,000 state settlement after a 2020 ransomware attack went unreported for two years — a case that shows how delayed disclosure can cost more than the breach itself.

What happened in this dental ransomware case?

Ransomware encrypted a server containing treatment plans, dental charts, and biometric data at the practice. The files could not be recovered internally, and the practice was locked out of its own patient records.

The breach was not reported to regulators until two years after it occurred. When investigators reviewed the case, they found the scope had been understated, and they uncovered separate HIPAA violations unrelated to the ransomware itself — including patient details disclosed in public social media and online review responses.

How much did the breach cost the practice?

The state settlement totaled $350,000. The terms also required mandatory staff HIPAA retraining and a court-ordered overhaul of the practice's data security protocols. These costs came on top of the original downtime and data loss from the ransomware event itself — they did not replace it.

Why did the two-year delay make this worse?

HIPAA requires breach notification within a defined window after discovery. A two-year gap between the incident and disclosure is itself a compliance violation, separate from the ransomware attack. Regulators treat delayed or downplayed disclosure as an aggravating factor, not a neutral one — it signals an absence of an incident response process, which increases both the fine and the scrutiny applied to everything else found during the investigation.

What would a managed IT provider have done differently?

No detection caught the attack until files were already encrypted. Around-the-clock monitoring flags ransomware behavior — mass file encryption, abnormal access patterns — before it spreads across the practice.

Server-side patient data was unrecoverable once encrypted. Encrypted, regularly tested off-site backups turn a ransomware event into a same-day restore, not a permanent loss.

A two-year gap passed before HIPAA notification went out. A documented incident response plan defines breach-assessment and notification timelines in advance, so disclosure happens within the legally required window instead of years later.

Unrelated privacy violations surfaced only because regulators went looking. Ongoing staff training on HIPAA-compliant communication closes that kind of gap before it ever becomes part of a regulatory finding.

The bottom line

This wasn't a sophisticated, unstoppable attack. It was one unmonitored server and a practice with no incident response plan — the exact gap a fixed-fee managed IT partnership is built to close.

Synology 4‑Bay NAS Recovery for GoodGardens

Thu, 16 Apr 2026 15:56:27 GMT

Vault Technologies Case Study — Synology 4‑Bay NAS Recovery for GoodGardens

Executive summary

On April 1, 2026 , Vault Technologies technician Michael Anderson performed an on‑site diagnostic and file‑recovery engagement for GoodGardens’ Synology 4‑bay NAS. A full diagnostic and access‑restoration procedure was completed on the Synology 4‑bay NAS. The team restored management access, exported all accessible files to an external drive, and delivered a clear remediation plan to prevent future data loss.

The challenge

GoodGardens requested verification of recorded video for several February date ranges; those files were missing.
The NAS was intermittently inaccessible and at risk of further data loss due to multiple failing drives.
Business operations depended on timely access to recorded footage for security and compliance.

What we did (solution and on‑site actions)

Immediate actions

Connected the Synology unit directly to a workstation to ensure stable access for evaluation.
Reset the administrator password to regain DSM management access.
Prepared and formatted an external drive for secure data export.
Initiated transfer of all accessible files to the external drive and instructed the client on monitoring and continuing transfers.

Recovery approach

Performed a full volume and directory review to locate requested video ranges.
Prioritized preservation: isolated the NAS, documented system state, and imaged drives when necessary.
Used snapshot exports and direct file copies (rsync/verified copies) to move recoverable data to external media.

Key technical findings

Most recent video files found: January 27 (no files dated February 1 or later were present).
Drive health:
Drive 1: functioning normally.
Drive 2: system partition failure.
Drive 3: system partition failure.
Drive 4: crashed and non‑operational.
With three of four drives failed or partially failed, the NAS could not reliably write new data—explaining the absence of February recordings.

Results and client impact

Access restored to the Synology management interface and to all accessible files; those files were exported to client‑provided external storage.
Root cause identified: multiple drive failures (system partition failures and a crashed drive) that prevented recording and retention during February.
Business impact mitigated: GoodGardens received a complete on‑site report, exported data, and a remediation plan to restore recording capability and prevent recurrence.

Recommendations (what we delivered and next steps)

Immediate: Replace failed drives and rebuild the array only after secure imaging and verification of recovered data.
Backup & retention: Implement regular snapshots and offsite Hyper Backup (or equivalent) with a clear retention policy.
Monitoring: Enable SMART and DSM alerts integrated with the client’s notification channels to detect drive degradation early.
DR testing: Schedule periodic restore tests to validate backups and recording continuity.
Documentation: Provide a runbook for recovery steps, contact escalation, and monitoring thresholds.

IT Setup & Support for a New Bookkeeping Business

Thu, 12 Mar 2026 17:29:19 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.

Emergency Data Recovery for a Time‑Sensitive Project

Thu, 12 Mar 2026 17:23:27 GMT

Case Study: Emergency Data Recovery for a Time‑Sensitive Project

�� Client Background

A local professional working on a major deadline‑driven project suddenly lost access to all files on their desktop. With no recent backups and no technical background, the client was unable to recover the missing data and risked missing an important submission deadline.

⚠️ The Challenge

All project files disappeared from the desktop without warning.
The client was under severe time pressure and needed immediate assistance.
The device showed signs of file system corruption, making recovery uncertain.
The client had no backup solution or recovery tools in place.

The situation required calm, fast, and precise technical work to prevent data loss.

��️ Vault Technologies’ Response

Vault Technologies responded immediately and provided last‑minute technical support. The approach focused on stabilizing the system, identifying the cause of the disappearance, and recovering the missing data without further damage.

Key actions included:

Performing a rapid diagnostic to identify file system issues.
Recovering all missing project files using safe, non‑destructive recovery methods.
Restoring the client’s desktop structure so they could resume work instantly.
Verifying file integrity to ensure nothing was corrupted or incomplete.

Throughout the process, communication remained calm, clear, and reassuring—critical for a client already under deadline stress.

✅ Results

100% of the client’s data was recovered.
The client was able to complete and submit their project on time.
System stability was restored without requiring a full rebuild.
The client expressed strong trust in Vault Technologies and stated they would not go anywhere else for laptop repairs or data issues.

�� Client Feedback

“Mike is a lifesaver! I had a major project due and suddenly everything disappeared from my desktop. I was in a total time crunch, but Mike stayed calm and recovered all my data in record time. Excellent last-minute technical support and great personnel. I won't go anywhere else for laptop repairs or data issues now.”

�� Impact

This case demonstrates Vault Technologies’ ability to:

Deliver rapid, reliable emergency support
Recover critical data under pressure
Maintain professionalism and calm in high‑stress situations
Provide trusted, ongoing IT support for local clients

The Future of Vault Technologies

Tue, 24 Feb 2026 02:50:39 GMT

Why Vault Technologies Is Becoming Oregon's Trusted IT Partner for Senior Care — and Beyond

In a crowded field of MSPs, most companies promise the same things: "fast support," "reliable service," "expert technicians." But the organizations we serve aren't looking for another generic IT provider. They're looking for a partner who understands the stakes of what they do — and shows up with the discipline, documentation, and clarity to match.

That's exactly why Vault Technologies was built.

As a Service-Disabled Veteran-Owned and Woman-Owned business, we built Vault on the values that shaped our careers: precision, integrity, and accountability. We don't believe in vague promises or confusing pricing. We believe in clear expectations, transparent processes, and IT support that feels like a partnership rather than a gamble.

That's what makes Vault different — and it's the thread running through everything we've built since.

Built on Discipline, Documentation, and Trust

Most MSPs operate behind the curtain. Clients rarely know what's happening, what's included, or what they're paying for. Vault Technologies takes the opposite approach.

We document everything. We communicate proactively. We set boundaries clearly. We price transparently — flat, per-seat, per-month, with no hourly billing surprises.

Our clients know exactly what we do, how we do it, and what to expect at every step. That clarity builds trust — and trust is the foundation of every long-term partnership we have.

A Rare Hybrid: IT Expertise and Clinical Understanding

One of the biggest gaps in healthcare IT is the divide between people who understand technology and people who understand care delivery. Most MSPs only know the former.

Vault closes that gap.

Our co-founder Kristina brings 15 years of nursing experience, including hospice and home care, to every conversation we have with assisted living, home health, and hospice clients. We don't just know what EHR downtime looks like on a dashboard — we know what it means for a med-pass window or a shift change when systems fail.

That's a hybrid skillset almost no other MSP in Oregon can offer, and it's why we built our service tiers — Foundation, Continuum, and Vigil — specifically around the realities of shift-based care, not a generic 9-to-5 business clock.

A Partner Built for Other MSPs, Too

Vault isn't just direct-to-client. We're also structured to support other MSPs who need additional capacity without the overhead of hiring.

Through our white-label and subcontracting model, we offer:

Overflow ticket capacity when an MSP's queue gets ahead of them
Standing capacity partnerships for MSPs ready to free up their senior techs
Full-scope backend delivery for MSPs that want to focus on sales and relationships while we run help desk, NOC, security, and M365 administration behind the scenes

Every tier comes with clear, published pricing and a transparent application process — because the same documentation-first approach we bring to direct clients applies to our MSP partners too.

Certified and Ready for Government and Prime Contracting

As a certified SDVOSB, VOSB, WOSB, and EDWOSB small business, Vault is also positioned to support federal, state, and local agencies, as well as prime contractors building out their subcontracting base. We're registered in SAM.gov and eligible for set-aside and sole-source opportunities — backed by the same audit-ready documentation and disciplined execution that defines how we operate everywhere else.

Veteran Values, Applied Everywhere We Work

Being veteran-owned isn't a marketing slogan for us — it's a mindset.

It shows up in how we communicate. It shows up in how we document. It shows up in how we treat clients and partners alike. It shows up in how we build systems that scale — whether that's a single assisted living facility or an MSP partner's entire book of business.

Why Organizations Choose Vault Technologies

Organizations across Oregon and beyond choose Vault because we offer:

Clear, transparent, per-seat pricing
Professional, jargon-free communication
Documented, audit-ready processes
Veteran-level discipline
Real clinical understanding for senior care and home health
A scalable model for MSP partnerships and government contracting
A modern, approachable brand built on substance, not slogans

We're not trying to be the biggest MSP in Oregon. We're becoming the most trusted — for the care organizations who depend on us, the MSPs who partner with us, and the agencies who need a certified, capable small business they can rely on.

The Future of Vault Technologies

Our mission is simple: become the most trusted IT partner for the organizations that value clarity, reliability, and professionalism — whether that's a senior care facility that can't afford technology failure, an MSP looking for a dependable subcontractor, or an agency seeking a certified small business partner.

This is the standard we hold ourselves to, and the standard our clients and partners have come to expect.