Open source EDR for healthcare

Open source EDR for healthcare starts with where clinical systems can run agents

Start by sorting every clinical host into three groups: systems that can run a Wazuh agent, systems that can only send logs, and systems that can be examined only by an offline collector. A covered entity or business associate usually has clinical workstations, servers running EHR components, shared kiosks and medical devices that the vendor will not let you modify. A small security team cannot watch all of them equally, so the inventory decides what coverage is realistic before any tool is chosen. Confirm with each device vendor, in writing, whether an agent install affects support or certification, and record the answer per asset.

HIPAA shapes this design more than generic EDR features do. The technical safeguards in 45 CFR 164.312 require access control with unique user identification, audit controls that record and examine activity in systems holding ePHI, person or entity authentication, and transmission security. Those obligations point to evidence you must produce: who logged in, from where, what changed, and whether the traffic was protected. Wazuh fits the agent-covered hosts because it collects logs, file integrity data and inventory, and its dashboard includes a prebuilt HIPAA view. Velociraptor fits hunts and forensic collection across Windows, Linux and macOS endpoints. Logs forwarded from legacy hosts, network devices and medical device gateways, or offline Velociraptor collectors on hosts where a client cannot be installed, cover the remainder. Confirm each platform's supported operating systems against your own asset list.

HIPAA has no certification. HHS states that no Security Rule standard requires an entity to certify compliance, and the HHS Office for Civil Rights judges your program through complaints, compliance reviews and audits. The question an examiner will ask is whether you can show the monitoring, the access reviews and the response records for the period in question. Decide early which artifacts you will retain for each asset group, such as alert histories, agent status reports, log source inventories and documented exceptions for devices that cannot take agents, and who signs off on them. An implementation partner can prepare those controls and evidence, but the covered entity remains responsible for the risk decisions behind them.

Which HIPAA and sector requirements change the endpoint design

This table maps HIPAA technical safeguards, a business associate contract term, the NIS2 health listing and a CNIL enforcement case to what the endpoint layer must record or enforce. Read each row as a question the build must answer with evidence, not as a checklist of product features. The main takeaway is that endpoint telemetry alone does not satisfy these rules unless identity, access and incident reporting are designed around it.

Requirement	Source	What it means for the build
Unique user identification and access control	45 CFR 164.312(a)(1) and (a)(2)(i)	Endpoint events must tie to a named individual, not a shared clinical workstation login. Confirm how shared kiosks and badge sign-in map sessions to users in Wazuh and Velociraptor logs.
Emergency access procedure	45 CFR 164.312(a)(2)(ii), required specification	Break-glass accounts used during downtime still need logged activity. Define how emergency sessions are flagged and reviewed after the event.
Automatic logoff	45 CFR 164.312(a)(2)(iii), addressable specification	Record lock and logoff events on clinical endpoints so reviewers can show timeouts were enforced or why an alternative was chosen.
Audit controls over systems with ePHI	45 CFR 164.312(b)	Collect authentication, file access and administrative events from EHR component servers and workstations, and retain them long enough for periodic review. Document who reviews the logs and how often.
Person or entity authentication	45 CFR 164.312(d)	Monitor failed and unusual logons, privilege changes and credential use on endpoints. Confirm the identity provider logs are forwarded to the same case workflow.
Transmission security	45 CFR 164.312(e)	Verify that agent and server traffic, including syslog and API probing for agentless devices, is encrypted in transit. Record certificate and TLS configuration as evidence.
Business associate contract incident reporting	45 CFR 164.314(a)(2)(i)	Vendors and hosting partners that touch ePHI must report security incidents to the covered entity. Your alert triage and escalation timeline must support those contractual notice terms.
NIS2 health sector listing (EU entities)	Directive (EU) 2022/2555, Annex I	Healthcare providers and certain medical device manufacturers are listed as high criticality. Confirm with counsel whether your entity falls in scope and which national transposition applies.
Regulator focus on external access and MFA	CNIL fine on Hopital Prive de la Loire under GDPR Articles 32 and 34, 3 September 2026	Illustrative of what regulators examine: remote access paths, MFA and need-to-know limits. Endpoint logs should show remote sessions and privilege use so you can answer those questions.

How coverage differs across clinical workstations, EHR servers and devices

Shared clinical workstations in wards and clinics usually run Windows, with some macOS devices in imaging, research or administrative areas. Wazuh agents cover both platforms, so the main questions are whether your agent version, hardening baseline and logon model fit the clinical setting. Identity matters here because 45 CFR 164.312 requires unique user identification, and a shared account records activity under one name.

Wazuh agents on Windows and macOS: Agents on supported versions report logon events, process activity, file integrity and software inventory to the Wazuh server. Confirm the exact operating system builds in your fleet against the Wazuh compatibility documentation before rollout.
Velociraptor client: The client can run hunts and targeted artifacts on these machines, for example to find the same persistence entry across many workstations. Confirm client support for each macOS and Windows version you run.
Offline collectors for locked-down machines: Where change control blocks a new agent on a specific workstation, an offline collector built in the Velociraptor GUI can run during a maintenance window and write JSONL or CSV output.
Per-user attribution: Link session or badge identity to logon events so a shared workstation still produces a record of who was signed in, when and from which device.
Automatic logoff: Pair monitoring with the session timeout set through Group Policy or device management, since automatic logoff is an addressable specification under the technical safeguards.

Before you write the coverage list, confirm with clinical engineering which operating system builds, EHR client versions and endpoint protection products run on each workstation type.

Which open source platforms fit a healthcare endpoint program and why

A healthcare endpoint program needs one platform for continuous monitoring, one for deep investigation, and context from network and host telemetry. The cards below cover which open source tools take those roles, where their limits sit for clinical systems, and what to confirm before committing.

Wazuh agents, server and indexer

Wazuh is the core monitoring layer: agents on supported workstations and servers, a Wazuh server that decodes and applies rules, and an indexer that stores alerts. The core repository is licensed under GPL-2.0, so review the license terms with counsel alongside your own build. Check agent support for each clinical operating system, since many imaging and device hosts will fall outside it. Confirm whether the server cluster is needed for your alert volume and retention.

Wazuh dashboard HIPAA views

The Wazuh dashboard includes prebuilt views for HIPAA and other frameworks. These views map collected alerts and configuration checks to requirement areas, which helps assemble evidence for technical safeguard reviews. They do not make your organization compliant, and an auditor or your own risk analysis still decides whether controls are adequate. Ask your compliance lead which HIPAA requirements the team must evidence directly and which need policy or process records.

Velociraptor for hunts and collection

Velociraptor runs hunts across clinical endpoints and collects artifacts on demand, which supports investigations that need precise host evidence. It ships as a single Go binary, and its server is only fully supported on Linux, so plan the server host accordingly. Its AGPL-3.0 license has obligations for modified network-facing software, so confirm them with counsel before customizing the server. Pair it with Wazuh alerts so analysts can move from detection to targeted collection.

Velociraptor offline collectors

Some clinical devices cannot take an agent, and offline collectors let an administrator build a package from the GUI, run it locally and export results to JSONL or CSV. This covers legacy hosts for one-time triage without changing the device's configuration. Confirm with the device vendor that running a collector does not void support or affect clinical function. Record who ran each collection and when, because that log becomes part of the investigation record.

Security Onion and osquery for context

Security Onion bundles Suricata, Zeek, osquery and the Elastic stack, and it adds network and host context that an endpoint platform alone may miss. Its Elastic License 2.0 differs from the GPL and AGPL terms of the endpoint tools, so review it before distribution. Network sensors need clear placement on clinical VLANs, and some medical protocols may need tuning. Confirm the release you deploy, currently 3.3.0-20260911, against your change control process.

Shuffle for triage automation

Shuffle is a SOAR platform licensed under AGPL-3.0 that can enrich Wazuh alerts, open tickets and route cases to clinical IT or privacy staff. Small healthcare teams benefit from automated first-pass enrichment, but every automated action on a clinical host needs an approval step. Write playbooks that never isolate a device used for patient care without a named clinician or operations owner signing off. Confirm the current version, v2.3.0 as published September 28, 2026, before you build against it.

How small security teams keep alert handling manageable

A small team keeps alert volume workable by tuning Wazuh before the first clinical rollout, not after the queue fills. Start by suppressing or down-weighting rule matches that come from known clinical software behavior, such as scheduled EHR batch jobs, interface engine service accounts and imaging workstation updates, but only after the owning clinical engineering team confirms each pattern. Then rank alerts by where they land: anything on EHR application and database servers, any access to ePHI stores, and any change to logging or agent configuration goes to the top of the queue. Rules that fire on ePHI access should be reviewed against the unique user identification that HIPAA requires under 45 CFR 164.312, so each alert names a person or a service account the team can act on.

Escalation paths need named owners before an alert arrives. Define which alerts go to clinical engineering because they may affect a patient-care device or a clinical application, which go to the privacy officer because they may involve inappropriate access to patient records, and which the security team handles alone. Write down the decision points, including who can approve isolating a clinical workstation, since taking a ward system offline is a clinical decision as well as a security one. Velociraptor should be used as a targeted instrument: run a hunt only when a specific indicator, such as a hash, a suspicious scheduled task or a particular account, justifies a sweep across endpoints. Routine hunting across all hosts will consume analyst time that a small team cannot spare.

The staffing decision comes first and shapes everything above. Decide whether monitoring runs during business hours only or around the clock, and what response time the clinical operation expects for each alert class. Open-source tools do not provide people. A partner can help design tuning, write escalation runbooks, run an initial detection review and provide scoped support hours, but it cannot be on call for your hospital unless that service is contracted in writing. Ask any partner to state in the scope which alerts they triage, which they only forward, what hours they cover and who makes the containment call. Confirm those terms with your own clinical and legal teams before go-live.

Rollout phases for a healthcare endpoint deployment and their outputs

This sequence moves a clinical endpoint program from asset discovery to evidence-ready operations, with each phase closing on a named artifact so clinical engineering, security and compliance can sign off before the next step begins.

Inventory ePHI systems and clinical devices
Clinical engineering, IT operations and the security team build one inventory of clinical workstations, EHR component servers, medical devices and legacy hosts, marking which systems create, receive, maintain or transmit ePHI. Each entry records the operating system, the vendor's support position on installed software, whether an agent can run, and the owner who approves changes. The step closes when the inventory is signed by clinical engineering and the security lead, because every later decision about coverage and log-only monitoring depends on it.
Pilot on a clinical-safe subset
The team selects a small group of non-critical workstations and a test copy of an EHR-adjacent server, then installs Wazuh agents or confirms log forwarding with the application owner present. The pilot checks CPU and memory overhead, login behavior, printing, and any interaction with the clinical application, and it confirms rollback steps. The step closes with a pilot report listing each host, the result, and any vendor concern raised, which becomes the input to the change request.
Onboard agents and logs under approved change windows
Agent and log onboarding proceeds in waves, each tied to an approved change record that names the hosts, the window, the rollback plan and the clinical sign-off. Hosts that cannot take agents are routed to syslog or other log sources, and the change record documents which telemetry is missing for those systems. The step closes when every wave has a completed change record and the Wazuh server shows the expected agent count and log sources for each host group.
Build and tune detection content
Security engineers enable the prebuilt rules and compliance views that fit the environment, then suppress known clinical noise such as scheduled imaging jobs or service accounts used by medical devices. Each rule change is recorded with the reason, the author and the alert volume before and after the change. The step closes with a tuning log that shows which rules are enabled, which are suppressed and why, so reviewers can trace every alert decision during an audit or incident review.
Establish Velociraptor hunt and offline collector procedures
The team defines how Velociraptor is deployed on the server for hunts across supported endpoints, which artifacts are approved for clinical hosts, and how offline collectors are built, labeled, transported and returned for hosts that cannot take a client. The procedure states who may launch a hunt, how collection results are stored, and how chain of custody is recorded. The step closes with a runbook that has been exercised once on a non-production host, and the outputs of that exercise are retained as evidence.
Map controls to HIPAA evidence and review
Compliance and security staff map the Security Rule technical safeguards that the deployment supports, including unique user identification, audit controls and integrity monitoring, to the specific configurations, logs, reports and procedures that show each one operating. Gaps, such as devices without telemetry, are recorded with compensating controls and owners. The step closes with an evidence map and a scheduled review date set by the covered entity, because HIPAA has no certification, and the evidence must stand on its own during an HHS review or an independent assessment.

HIPAA audit evidence an endpoint program should be able to produce

This table lists the records an endpoint monitoring program should be able to produce for a HIPAA Security Rule review, the activity each one shows and the component that generates it. Read it as a checklist to confirm with your own compliance lead, since HHS does not certify compliance and DeployOpen prepares this evidence for assessors without issuing audit reports. The main takeaway is that most evidence depends on retention and change control settings that must be decided before an incident or audit, not after.

Evidence item	What it shows	Component that produces it
Unique user identification	Each workstation and server login tied to a named user rather than a shared account, supporting the unique user identification requirement in 45 CFR 164.312	Wazuh agent logs and endpoint authentication events forwarded to the Wazuh indexer
Authentication events	Successful and failed logons, privilege changes and session starts on clinical workstations and EHR servers, supporting person or entity authentication	Wazuh rules applied to Windows, Linux and macOS security logs
Audit records of ePHI system activity	Alerts and archived events showing who accessed systems containing ePHI and what security-relevant actions occurred, supporting audit controls	Wazuh alerts and archives, with archiving enabled and confirmed for the EHR component hosts
Log retention settings	The configured retention period for alerts, archives and indexed events, which the assessor can compare with your written retention policy	Wazuh indexer configuration and retention policy documentation maintained by the customer
Legacy host monitoring through logs	Evidence that devices without agents still send syslog or event data into the audit trail, with gaps documented	Wazuh syslog collection and agentless monitoring configuration for devices that cannot take agents
Incident collection records	Chain-of-custody notes, collection timestamps and artifacts gathered from affected hosts during an investigation	Velociraptor collection records and hunt results, including offline collector output
Agent configuration change records	Who changed which agent or rule configuration, when, and under what approval, supporting change control over security tooling	Wazuh configuration management records and version-controlled rule and config files kept by the customer

What do healthcare teams ask before an open source EDR project?

What drives the cost of a self-hosted Wazuh and Velociraptor build?

The cost depends on the size of the estate, the retention period and how much detection engineering the team needs, and the exact figures come from a written quote tied to your scope. The cost components are servers and storage for the Wazuh indexer, server and dashboard and for the Velociraptor frontend, engineering to deploy agents, write decoders and rules and tune alerts, and staffing to watch and act on alerts. Servers and storage are mostly recurring, while deployment and content work is largely one-time with ongoing tuning. Costs rise with the number of endpoints, log volume, clinical systems that need special handling and the hours your own staff must spend. Ask each quote to split these components so you can compare build, partner and SaaS options on the same basis.

How long does it take to get first endpoint coverage?

Time to first coverage depends on the asset inventory, the change approval process and how many clinical systems need testing before an agent is allowed. A first wave usually covers general-purpose Windows and Linux servers and a pilot group of workstations, and it can start once the deployment design is agreed in writing. Clinical workstations and servers running EHR components typically follow later, after vendor compatibility checks and maintenance windows. Ask any partner to show the phases, what each phase delivers and which dependencies sit with your team. Treat any single timeline you are given as an estimate that depends on your environment until it is confirmed in the scope.

What does our team need to supply before deployment starts?

Three inputs matter most: an accurate asset list, clinical change windows and a named owner for alerts. The asset list should cover workstations, servers, medical and legacy devices, and the systems that hold ePHI, with operating system versions and network segments. Clinical change windows define when agents can be installed or restarted without affecting patient care, and clinical engineering should approve them. An alert owner, usually a security analyst or a managed triage contact, must decide who acts on each alert and when. Without these three inputs, coverage stays partial and alerts pile up without a response path.

Can a small healthcare IT team run Wazuh and Velociraptor itself?

A small team can run the platform if it has someone who can operate Linux servers, manage agent configuration and review alerts on a set schedule. The harder part is detection tuning, incident handling and keeping up with releases. Wazuh has shipped 4.14 patch releases roughly every one to two months in 2026, and Velociraptor's documentation asks users to move to 0.77.3 to address multiple CVEs, so patching is a recurring duty. Velociraptor needs skilled staff to write and run artifacts during an investigation. Many teams keep the platform in-house and buy support or triage hours for nights and weekends. Confirm your staffing model against the alert volume you expect before committing.

Is there a HIPAA certification for endpoint monitoring tools?

No, there is no HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, and private certifications do not prevent HHS from later finding a violation. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits. The relevant question is whether your monitoring produces evidence for the Security Rule technical safeguards, including unique user identification, audit controls that record and examine activity in systems with ePHI, and person or entity authentication. Be cautious with any vendor or partner who claims a HIPAA certification for a product. Ask instead for the controls and logs they can show you.

How would the proposed HIPAA Security Rule change an open source EDR plan?

HHS proposed a major Security Rule revision on 6 January 2025, and as of October 2026 no final rule has been published. The Unified Agenda projects final action for July 2027, so the timing and final text may still change. The proposal is the signal to plan for, not a settled requirement. Keep your design flexible by documenting asset inventories, patch and vulnerability data, logging and retention settings, and response procedures in a form that can be extended. Ask your counsel and compliance lead to track the rulemaking, and review the design once a final rule exists. Do not treat a draft as current law when you set the scope.

What is the difference between monitoring legacy hosts through logs and installing agents?

Monitoring through logs means sending syslog or other event data from a device to the Wazuh server, which Wazuh supports for agentless sources such as firewalls. It adds visibility without installing software, but it sees only what the device logs, so detection depth is lower. Installing a Wazuh agent on a supported system gives file integrity monitoring, inventory and richer security events. Devices that cannot take agents need a clinical engineering review before any change, and Velociraptor offline collectors can help with point-in-time collection on some hosts. Confirm with the device vendor what it can export before you plan the coverage.

Which devices can run a Wazuh agent in a clinical environment?

Wazuh agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, but supported operating system does not mean supported clinical application. Each workstation or server running EHR components must be checked against the vendor's support statement before an agent is installed. Many clinical systems carry strict vendor rules about installed software, so confirm with the EHR and device vendors in writing. Use the asset list to mark each host as agent-capable, log-only or out of scope pending review. This keeps the coverage map honest and avoids surprises during a change window.

Questions to ask an implementation partner before signing

Start with clinical system coverage. Ask the partner which systems in your estate they will test against before go-live: the EHR application servers and database tiers, the interface engine, imaging and clinical workstations, and the Windows and Linux builds your clinical applications certify on. Ask how they will prove Wazuh agent coverage on each one, and what they do when a vendor says an agent is unsupported on a given build. Ask who writes the exception register for hosts that cannot take agents, and who signs off each entry. Request a sample test plan before signing, not a statement that coverage will be validated.

Next, ask how devices that cannot take agents will be monitored. Ask which log sources they will onboard through syslog, which hosts they will watch through periodic checks instead, and what they will do with medical devices that the manufacturer does not allow to be modified. Ask how offline and air-gapped procedures work: how rule and content updates arrive by media transfer, who records each transfer, and where the offline vulnerability repository is stored. Confirm that the partner has written procedures for these tasks and can show a sample change record.

Then cover the contract and the operating model. Ask for the business associate agreement terms the partner will sign, including subcontractor flow-down and incident reporting timelines under 45 CFR 164.314, and confirm whether they will access ePHI at all during deployment. Ask where logs, backups and support screenshots will be stored, which countries can reach them, and who at the partner can access them. Ask how alert triage is staffed, what hours are covered, and how escalation to your clinical operations and privacy officer works. Finally, ask how they will prepare evidence for assessors, which artifacts they produce, and how upgrades are scheduled around clinical downtime, including the maintenance windows they propose and how they handle emergency patches.

How DeployOpen scopes, builds and supports healthcare endpoint monitoring

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so endpoint telemetry from clinical systems stays under the client's control. For healthcare endpoint monitoring, we start from a written scope that covers which hosts, legacy devices and log sources are in and how alerts reach the people who will handle them.

How we scope

Inventory clinical workstations, EHR-adjacent servers and devices that cannot take agents, with the owners of each.
Agree which hosts get agents, which are monitored through logs, and which need offline collection.
Define the HIPAA technical safeguard evidence the written scope must produce, with your compliance lead.

How we build

Deploy the Wazuh server, indexer and dashboard in your environment, including cluster sizing for your agent count.
Configure agent policies, decoders and rules for supported endpoints, and document each tuning decision.
Set up Velociraptor for hunting and targeted collection, with offline collectors for hosts without agents.

How we hand over

Deliver architecture, runbooks, alert triage procedures and access control settings for the monitoring team.
Provide test results showing which hosts report, which log sources arrive and which alerts fire.
Train the staff who will triage alerts, so small teams can operate the platform after handover.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement ends.
Track Wazuh patch releases and apply updates under the change process you approve.
Review detection coverage and log source health with your security team on an agreed schedule.

Open source EDR for healthcare