Open source EDR for public sector: why keeping telemetry in-country changes the design
If endpoint telemetry must stay on government systems, a central SOC still needs feeds, and some Windows and Unix hosts cannot take a modern agent, then self-hosted Wazuh with Velociraptor fits best when data residency and evidence control matter more than SaaS convenience. Wazuh gives you continuous agent telemetry, alerting and compliance views on hosts it supports, while Velociraptor gives investigators targeted collection and hunting across the estate. Both run inside the agency's own cloud tenancy, data center or enclave, so the telemetry store, the alert history and the forensic artifacts never leave the jurisdiction that governs them. The first design decision is therefore not which tool to pick but where each component runs, who administers it, and which SOC receives which feed.
The scope question differs by level of government. Federal agencies work from NIST SP 800-53 Rev. 5, where the low, moderate and high baselines select 149, 287 and 370 controls and enhancements, and FISMA makes Inspectors General assess the results independently. Cloud-hosted monitoring for federal information can also fall under FedRAMP, although FedRAMP's scope excludes some systems used only for one agency's own operations, so confirm with your authorizing official whether the monitoring service is in scope. State and local bodies often inherit obligations through justice data: the FBI CJIS Security Policy version 6.1 took effect on 26 June 2026 and sets encryption and monitoring expectations for criminal justice information. EU public bodies are assessed under NIS2, which covers central government regardless of size, but excludes entities working in national security, public security, defense or law enforcement. Confirm early which of these regimes applies to each host group.
Write these answers down before you size the platform: which hosts hold regulated data, which can run an agent, which must stay air-gapped, and which retention period your records schedule and legal hold rules require. Ask your platform partner to confirm Wazuh agent support for each legacy operating system in your inventory, because coverage on old Windows and Unix builds is the most common gap. Confirm the license terms you will accept, since Wazuh is GPL-2.0 and Velociraptor is AGPL-3.0, and both affect how you modify and distribute them. Those answers determine the server footprint, the retention budget and the integration path to your central SOC.
Which public sector rules shape the EDR build
This table maps the federal, criminal justice, defense and EU rules most likely to affect a public sector endpoint build to what each means for agent coverage, data location, encryption and retention. Read each row as a question to settle with your assessor, inspector general or data protection office before selecting components.
| Rule or framework | What it means for the EDR build | Evidence to prepare |
|---|---|---|
| NIST SP 800-53 Rev. 5 baselines | Low, moderate and high baselines select 149, 287 and 370 controls and enhancements. The baseline you inherit sets how broadly agents must cover systems, how long logs are kept and how access to the EDR console is controlled. | System security plan mapping each audit, monitoring and access control to a specific Wazuh or Velociraptor configuration |
| FISMA and Inspector General review | Inspectors General assess agency system security independently and report to OMB. Expect them to test whether every in-scope endpoint reports, whether alerts are reviewed and whether response records exist. | Asset inventory reconciled to agent enrollment, alert triage records and retained telemetry for the review period |
| FedRAMP scope under M-24-15 | A cloud-hosted SaaS EDR or cloud-based log store that holds federal information on behalf of an agency falls within FedRAMP scope. A self-hosted deployment on agency-controlled infrastructure generally does not, but confirm the boundary with your authorizing official. | Written scope decision, data flow diagram showing where telemetry is stored and who can reach it |
| FBI CJIS Security Policy v6.1 | Where endpoints touch criminal justice information, encryption in transit and at rest outside physically secure locations must use FIPS 140-3 validated modules or AES with 256-bit keys. Vulnerability scanning must run at least monthly, so agent-based inventory and scanning needs a fixed schedule. | Cryptographic module validation certificates, scan schedule and results, key management procedure |
| 32 CFR 2002.14 and CUI on non-federal systems | Contractors and partners holding controlled unclassified information on their own systems inherit NIST SP 800-171 requirements through agency terms. Endpoint logs can themselves contain CUI, so the telemetry store often needs the same protections as the source system. | Agency requirements letter, CUI marking review of log content, access list for the EDR and SIEM stores |
| NIS2 scope for EU public administration | Central government entities are in scope regardless of size, and Member States may extend coverage to local administration. Entities working in national security, public security, defense or law enforcement are excluded, which changes which agents and telemetry fall under the directive. | Confirmed scope with the national competent authority, incident reporting workflow mapped to EDR alerts, retention periods set by national law |
Which open source platforms fit government endpoints
Wazuh is the usual starting point for continuous endpoint monitoring, detection and compliance reporting on government systems. Its core repository is licensed under GPL version 2, which agencies should confirm against their own procurement and redistribution rules. The platform has four components: the Wazuh indexer stores alerts and supports search and analytics, the Wazuh server analyzes agent data with decoders and rules, the Wazuh dashboard provides the web interface, and Wazuh agents run on the endpoints themselves.
- Broad agent coverage: Agents are documented for Linux, Windows, macOS, Solaris, AIX and HP-UX, which matters for legacy Unix estates.
- Agentless sources: Firewalls and other devices that cannot take an agent can send syslog, and the server can probe their APIs periodically.
- Compliance views: The dashboard includes prebuilt views for NIST 800-53, among other frameworks.
- Offline installation: An offline installation guide covers systems without internet connectivity, and vulnerability detection can use an offline repository instead of the Wazuh CTI platform.
- Clustered server: The server can run as a cluster for horizontal scaling and manages agent configuration remotely.
Confirm with the vendor and your own environment which operating system versions your agents must support and how the release cadence fits your change windows.
Velociraptor complements Wazuh by adding hunting, targeted collection and deep triage across many hosts. It is licensed under AGPL-3.0, which carries network-use obligations that legal teams should review before modifying the software. A deployment has a client on each endpoint, a frontend, a web GUI and a gRPC API. The server is only fully supported on Linux, and it stores its data in files on the filesystem rather than in a separate database.
- Artifacts instead of rebuilt agents: Collection logic lives in YAML artifacts that can be viewed and changed in the GUI.
- Offline collectors: Collectors built from the GUI can run hosts that cannot take a client, with results written to JSONL or CSV.
- Single binary client: The client ships as a statically compiled Go executable, which simplifies distribution to endpoints.
- Local triage: The velociraptor gui command starts a GUI, frontend and client on one machine for field work.
- Vendor ownership: Rapid7 acquired the project in April 2021 and stated it would continue supporting the open-source community.
Confirm the current release you will run, since the documentation asks users to move to 0.77.3 to address multiple CVEs, and confirm your Linux server hosting model with your security team.
Endpoint telemetry alone rarely explains lateral movement or command-and-control traffic. Security Onion bundles Suricata, Zeek, osquery and the Elastic stack into one platform for threat hunting and monitoring, and it is licensed under the Elastic License 2.0. Suricata, licensed under GPL-2.0, is a standalone intrusion detection and network monitoring engine that can feed alerts into the same SOC workflow. Sensor placement at agency boundaries and within segments decides what these tools can see.
- Security Onion as a bundle: It combines sensors and log management, which suits agencies that want one network monitoring product.
- Suricata as a component: It can run alone when an agency already has a log platform and needs signatures and network security monitoring.
- Sensor placement: Taps or mirror ports must reach the segments that carry government data, and this needs an architecture review.
- Licensing review: The Elastic License 2.0 and GPL-2.0 terms differ, so legal review should cover both before deployment.
- Correlation: Alerts should map to the same case identifiers used by the endpoint platform so analysts can pivot between them.
Confirm with the vendor and your network team which traffic you can legally and technically capture before you finalize sensor design.
The endpoint stack depends on identity for analyst access, role separation and evidence of who changed what. Keycloak, licensed under Apache-2.0, supports OpenID Connect, SAML 2.0, LDAP and Active Directory federation and clustering, which fits many agency directories. Evolveum midPoint, licensed under the European Union Public License 1.2 or later, handles identity governance, including access reviews that auditors often request. Both need to be planned as dependencies, not afterthoughts.
- Keycloak for sign-on: It can federate existing directories and provides SSO for the Wazuh dashboard and Velociraptor GUI where your version supports it.
- midPoint for governance: It supports joiner, mover and leaver processes that keep analyst access current.
- Secrets licensing: HashiCorp Vault version 1.15.0 and later uses the Business Source License 1.1 with IBM named as licensor, which is not an OSI-approved open source license. OpenBao, under MPL-2.0, is an alternative to evaluate.
- Certificates and keys: Agent enrollment and transport need certificates, so plan key management alongside the endpoint rollout.
- Lifecycle: Long-term support dates for midPoint, such as the 4.8 Curie release supported until October 17, 2028, should be checked against your planning horizon.
Confirm with the vendors which SSO integrations your exact versions support and whether your secrets platform license is acceptable to your procurement office.
How legacy Unix and Windows hosts get covered
Start by inventorying which agent platforms each host class can run, because the Wazuh agent list is the first filter. Wazuh agents are documented for Linux, Windows, macOS, Solaris, AIX and HP-UX. For a public sector estate, that means a Solaris or AIX server may be covered by an agent, but only if the exact OS version and architecture appear in the vendor's compatibility matrix for the Wazuh release you plan to deploy. Ask the vendor to confirm support per OS version, including end-of-life Windows builds and older Unix releases still running line-of-business applications, before you commit to a coverage target. Record any gap in the asset register as a named exception with an owner and a review date, not as an assumed yes.
Devices that cannot take an agent, such as network appliances, printers, embedded controllers and some legacy Unix hosts where the vendor forbids installs, fall back to agentless monitoring. Wazuh supports this through syslog collection and periodic API probing. Confirm with the application or device vendor which log formats and API endpoints are available, whether logging can be enabled without a change that breaks certification, and how much log volume the device generates. For Windows hosts that cannot be upgraded but accept a small utility, Velociraptor offline collectors can run any artifact and write results to JSONL or CSV, which gives investigators a point-in-time view without a resident client. Offline collection is evidence of a snapshot, so it does not replace continuous monitoring, and the collection schedule and chain-of-custody steps should be written into the operating procedure before the first hunt.
How an agency EDR rollout runs from scoping to handover
The sequence moves an agency from a defined set of endpoints and data rules to a self-hosted Wazuh and Velociraptor deployment that the agency's own staff can run, with each phase closing on a written output. The order matters because data classification sets retention and hosting, and the pilot shows what the rollout will need before any broad agent push.
Scope endpoints and classify the telemetry
The agency's security lead, system owners and DeployOpen agree which systems, operating systems and legacy Unix hosts fall in scope, and which hold data that drives hosting and access decisions. Each endpoint group is recorded with its operating system, owner, network zone and whether it can take an agent. The output is a signed scope register and a data classification note that states where telemetry may be stored, who may query it and how long it must be kept. Confirm the classification rules with your records and legal teams, since they set the design.
Design the deployment and accreditation inputs
DeployOpen drafts the architecture for the Wazuh indexer, server and dashboard, and the Velociraptor frontend and server, inside the agency's own data center or authorized cloud tenancy. The design records the hosting location, authentication path, encryption choices, backup scheme and the control mappings the agency's authorizing body will ask for, such as NIST SP 800-53 control families. The output is an approved design document and a set of accreditation inputs that the agency's assessors can review. Ask the authorizing official which baseline and evidence format they expect before this document is finalized.
Pilot on a representative host set
The team installs agents and an offline collector path on a small group that mirrors the real estate, including Windows, Linux, any legacy Unix hosts and at least one host that cannot take an agent. Staff test enrollment, alert volume, query performance, resource use on the endpoint and the response actions the agency has approved. The output is a pilot report that lists defects, noisy rules, unsupported platforms and any change to the design. Do not proceed to broad deployment until the agency signs off on the report.
Roll out agents in controlled phases
Agents are deployed in waves by business unit or network zone, using configuration management so that each wave is repeatable and recorded. After each wave, DeployOpen checks enrollment counts against the scope register, flags endpoints that did not report and logs exceptions with an owner and reason. The output is a deployment register that reconciles every in-scope host to either an active agent, an approved exception or an offline collector. The rollout continues only when unreconciled hosts are below the threshold the agency sets in advance.
Tune detections against agency baselines
The team reviews alerts from the pilot and each rollout wave, suppresses known benign activity with documented reasons and adds rules for behavior the agency cares about, such as privilege changes on administrative hosts. Velociraptor artifacts are used to confirm findings on individual hosts and to run baseline hunts. The output is a tuned rule set under version control, with a change log that names the approver for each change. Ask the vendor or partner how rule changes are tested before they reach production.
Connect to the central SOC and set retention
Wazuh alerts are forwarded to the agency's central SOC through the agreed transport, and escalation paths, severity mapping and ticket fields are tested with the SOC analysts who will receive them. Retention periods, index lifecycle settings and archive storage are configured to match the classification from the first step, and access to stored telemetry is restricted to named roles. The output is a tested integration with a documented data flow and a retention schedule signed by the records owner. Confirm the retention periods against the agency's own rules, since no general period applies across agencies.
Hand over runbooks and train the operators
DeployOpen writes runbooks for agent enrollment, upgrades, rule changes, Velociraptor hunts, offline collection, backup restore and evidence handling, then walks the agency's operators through each one on their own systems. Operators perform a supervised exercise that covers an alert, a host investigation and a restore test. The output is a handover pack containing the runbooks, the administrator register, the open issue list and a training record. Support after handover is governed by a separate written agreement, such as a retainer, so ownership is clear from the first day.
Evidence auditors and inspectors ask for from endpoint tooling
This table lists the evidence public sector assessors and inspectors commonly request from endpoint tooling, the Wazuh or Velociraptor component that produces each item, and what the agency should confirm before relying on it. Read it as a preparation checklist: DeployOpen prepares and organizes the evidence, while independent assessors and inspectors decide what it shows.
| Evidence type | Producing component | What to confirm before an assessment |
|---|---|---|
| Agent inventory and enrollment records | Wazuh server (agent registration) and Wazuh dashboard (agent views) | Every government endpoint in scope appears, including Linux, Windows and legacy Unix hosts, with unsupported systems documented separately |
| Configuration baselines and policy versions | Wazuh server (agent configuration managed remotely) and dashboard compliance views | Which baseline applies to each system class, and that the configuration history can be exported with dates |
| Vulnerability detection records | Wazuh server correlating agent software inventory with CTI or offline vulnerability data | Source of vulnerability data (online CTI or offline repository), its update date and how stale data is flagged |
| Alert and response logs | Wazuh indexer (stored alerts) and Wazuh server (rules and active response) | Retention period for alerts, who can alter rules, and whether response actions are logged with operator identity |
| Velociraptor collection records with hashes | Velociraptor GUI (collection history, artifacts run and results) | Hash algorithm used for collected files, chain of custody steps and where exported results are stored |
| Administrator and console access logs | Wazuh dashboard and Velociraptor GUI, plus the host logs of the server | Whether authentication to both consoles is centralized, and that administrator actions are recorded and reviewed |
| Retention and log protection settings | Wazuh indexer storage and Velociraptor server file storage | Retention periods agreed with records officers, backup coverage and access restrictions on stored telemetry |
| Compliance framework views | Wazuh dashboard prebuilt views for NIST 800-53 and other frameworks | Mapping of the agency's own control IDs to these views, since the dashboard output alone does not establish compliance |
What agencies ask before hiring an EDR implementation partner
What are the main cost drivers, and which costs are one-time versus recurring?
Cost depends on the number and type of endpoints, the server and storage footprint, and how much detection engineering the agency needs. One-time costs usually include design, installation, integration with the central SOC, custom rules and artifacts, hardening and handover documentation. Recurring costs include infrastructure hosting, storage for retained telemetry, staff time for triage and tuning, and any support or upgrade retainer. Wazuh and Velociraptor are open source, so license fees are not the main line item, but agencies should confirm the licensing terms of each component with counsel. Ask any partner for a quote that separates one-time implementation fees from recurring support and infrastructure, and that names who pays for each cloud or data center resource. Fixed-scope engagements are agreed in writing before work starts.
How long does a working EDR deployment take, and what drives the timeline?
The timeline is set by scope, not by a generic template. The main drivers are the number of operating systems to cover, whether the environment is connected or air-gapped, how many approval gates the agency has for changes to servers and endpoints, and how quickly the central SOC can accept alerts. Legacy Unix hosts and systems that cannot take an agent usually need a separate coverage plan, which adds analysis time. Agencies should ask the partner for a written schedule tied to milestones such as pilot endpoints, production rollout, integration testing and handover. A realistic plan also includes time for the agency's security authorization steps, which the partner cannot shorten. Confirm the schedule against your own change calendar before signing.
What does the agency team need to provide before implementation starts?
The agency needs to provide access and decisions, not just budget. Typical inputs include an endpoint inventory by operating system and version, network diagrams showing where the server, indexer and dashboard will sit, approved hosting locations, and named contacts in the SOC, network, and system owner groups. Agencies should also decide retention periods for alerts and forensic collections, who may view endpoint data, and which response actions are permitted without manual approval. Credentials for cloud or data center accounts, change windows, and a signed scope document are also needed. Ask the partner for a written list of inputs with owners and due dates so that delays are visible early.
Can our in-house staff run the EDR platform after handover?
Often yes, but only if the handover is planned as a skills transfer with documented runbooks. Running Wazuh and Velociraptor day to day requires people who can manage agent upgrades, review and tune detection rules, write or adjust Velociraptor artifacts in VQL, run hunts, and maintain the server, indexer and dashboard. Agencies should identify named staff early, assign them to the build, and require training on the operations they will own. Ask the partner what documentation is delivered, how upgrades are tested, and whether support is available after handover under a retainer. Staffing for 24x7 monitoring is a separate decision and should be sized in the agency's own operating model.
How do FedRAMP and CJIS requirements affect a SaaS EDR option?
Scope decides the outcome. FedRAMP covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency, under OMB memo M-24-15. A system used only for one agency's operations on cloud infrastructure and not offered as a shared service falls outside that scope, but many SaaS EDR offerings are shared services and must be assessed against the relevant baseline. The FBI CJIS Security Policy, version 6.1, requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for criminal justice information in transit and at rest outside physically secure locations, and requires vulnerability scanning at least monthly. Agencies should ask any SaaS vendor for its authorization status, where telemetry is stored, and how keys are managed. Self-hosted deployment keeps telemetry inside the agency's boundary, but the agency still owns the compliance evidence for it.
How are upgrades and CVE patches, such as the Velociraptor 0.77.3 update, handled?
Upgrades should follow a written patch process, and urgent security releases should follow an expedited path. Velociraptor's documentation asks users to update to release 0.77.3 to address multiple CVEs, which shows why an agency needs a tested patch route for the server and clients. A good process covers monitoring release notes, testing in a non-production environment, scheduling change windows, rolling client updates, and confirming the result in the console. Wazuh publishes 4.14 patch releases roughly every one to two months, so a recurring patch cadence is needed. Ask the partner who monitors releases, how long a critical patch takes to reach production in the agency's environment, and whether upgrades are included in a support retainer. Confirm these details against your own change authority rules.
Which evidence should a partner hand over for compliance reviews?
The partner should hand over evidence that shows how the system is configured, operated and monitored, not an audit opinion. Useful artifacts include the architecture and data flow diagrams, access control lists, logging and retention settings, patch records, change tickets, test results and runbooks. Frameworks such as NIST SP 800-53 control families for audit and accountability and system integrity map well to this kind of evidence. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the actual conclusions. Ask the partner which evidence it will produce, in what format, and who keeps it current after handover.
What happens to the EDR platform if a partner engagement ends?
The agency keeps ownership of the platform, data and documentation, so the engagement should end with a controlled handover. Because Wazuh, Velociraptor and related components are open source, the agency is not locked into a vendor product, but it still needs the configuration, rules, artifacts, credentials management and runbooks to operate the system. Ask the partner to deliver source configuration in a version-controlled repository, a list of accounts and roles, backup and restore procedures, and a plan for transferring any cloud or data center accounts. Also confirm how the agency can continue receiving security updates if it chooses not to renew support.
What to ask an implementation partner before signing
Start with the written scope, because it decides everything else. Ask the partner to name the exact Wazuh and Velociraptor versions they will deploy, the agent versions for each operating system, and the list of hosts in and out of scope. Wazuh's current line is 4.14, and Velociraptor's documentation asks users to move to 0.77.3 to address multiple CVEs, so a quote that says only "latest" is not a scope. Ask how version pinning, patch windows and the upgrade path will be handled after go-live, and who signs off each change.
Next, test the offline and data residency answers against your own enclave rules. Ask for the written offline update procedure: how rules, decoders, vulnerability data and Velociraptor artifacts reach the server by media transfer, who verifies the hashes, and how a failed transfer is rolled back. Confirm where the Wazuh indexer, the Wazuh dashboard and the Velociraptor server data files physically sit, which backup copies exist and where they are stored, and whether any component calls out to a vendor service. Ask about FIPS-validated cryptography too: for CJI or CUI, the partner should show which modules are FIPS 140-3 validated, how TLS and disk encryption are configured, and which AES key lengths are used. Ask which validation certificates they have checked, and state that the CJIS Security Policy version in force is your own determination to confirm with your state authority.
Finally, settle legacy coverage and handover before work starts. Ask which Unix platforms have an agent, which only receive syslog, and what the partner will do for hosts that cannot take one, such as offline Velociraptor collectors. Define acceptance criteria in writing: agent check-in counts against an asset list, alert delivery to your central SOC, a restore test of the indexer, and a documented hunt. Then ask who holds the Wazuh administrator and indexer credentials, the Velociraptor server admin and API keys, and the root or sudo access to the hosts after handover, and how those credentials are rotated and logged. The answers should appear in the contract, not only in a slide deck.
How DeployOpen scopes and supports public sector EDR
Public sector EDR depends on who installs it, who keeps it running and what evidence an assessor can review later. The cards below cover how DeployOpen scopes work inside your infrastructure, tests the result, and supports it after go-live.
Fixed-scope engagements in your environment
DeployOpen plans, deploys and hardens Wazuh and Velociraptor inside your own cloud accounts, data centers or enclaves, so telemetry stays under your control. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Before signing, confirm which operating systems, legacy Unix hosts and offline segments are in the written scope, who holds the administrator credentials, and where the Velociraptor server and Wazuh indexer will physically run.
Security testing of the deployed stack
DeployOpen runs security testing of applications, APIs, cloud and infrastructure, which can cover the EDR server, dashboard and agent update paths themselves. A monitoring platform is a high-value target, so its own exposure matters as much as the endpoints it watches. Ask for the test scope in writing, whether findings are retested after fixes, and how sensitive results are handled and stored.
Private cyber ranges for response rehearsal
DeployOpen operates private cyber ranges and security training, which let response teams practice Wazuh alert triage and Velociraptor collections against realistic scenarios before a live incident. For public agencies this is useful because staff rotate and an isolated range avoids touching production systems. Confirm that the range can mirror your agent versions and policies, and that exercises are recorded for after-action review.
Evidence preparation without audit opinions
DeployOpen prepares systems, controls and evidence for compliance assessments, such as configuration records, agent coverage reports and alert review logs. It does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Ask which evidence artifacts are in scope, who owns each one after handover, and which assessor or framework your agency must satisfy.
Retainers for upgrades and continuous testing
Ongoing support, upgrades and continuous testing are available as retainers after the initial build. Wazuh 4.14 patch releases arrive every one to two months, and Velociraptor needs updates when vulnerabilities are disclosed, so an agency needs a named process for patching agents and servers. Ask what the retainer covers, how emergency patches are handled, and how upgrade testing happens before production changes.
Handover and operator knowledge transfer
DeployOpen documents the deployment, including server configuration, agent groups, artifacts and retention settings, so the agency can run it without a permanent vendor dependency. Handover quality decides whether the platform survives staff turnover. Ask for the documentation set in the written scope, the training format for analysts and administrators, and the process for changing detection content after handover.
