What Wazuh agentless monitoring covers for network devices
Many routers, firewalls, switches and locked-down servers cannot take an agent. The vendor may not allow one, the operating system may be frozen, or change control may keep third-party software off the device. Wazuh supports agentless monitoring of devices like these through syslog collection and periodic API probing, according to its documentation. For regulated teams, this matters because the network edge is where many access and configuration events happen, and a gap there leaves the audit trail with holes in it. The practical question is which documented method each device can support.
Wazuh's documentation is the basis for what is supported, so treat it as the reference for your release line, which is currently 4.14. Confirm the exact syslog formats and API probing options for each device model and firmware version you run, because support described for a device family may not cover every model in your estate. Where a device can neither send syslog nor expose an API that Wazuh can query, it stays outside the agentless scope and needs a compensating control or a different event source. Write that decision down so auditors can see which assets are covered and which are not.
The Wazuh deployment has four components. The Wazuh indexer is a full-text search and analytics engine that stores alerts. The Wazuh server analyzes incoming data with decoders and rules. The Wazuh dashboard is the web interface where analysts review alerts and compliance views. Wazuh agents are installed on endpoints and remain the main collection path wherever a device can take one, because they supply richer host data, such as the software inventory that vulnerability detection correlates with vulnerability data. Agentless sources feed the same server and indexer, so their alerts appear alongside agent alerts in the dashboard.
Agentless monitoring gives you visibility into what a device reports, but host-level depth stays limited. A device that sends syslog or answers an API probe reports only what its own software chooses to record and expose, so expect narrower coverage than an agent on a host you control. Before scoping, list each device with its model and firmware, whether it can forward syslog, whether it offers an API that Wazuh can query, and who owns its credentials. Devices that can do neither need a decision on whether they stay in scope at all.
Ask your team and each device vendor to confirm three things before you commit: the event types the device emits, the transport and format used for forwarding, and the permissions a read-only API account needs. Store API credentials in a managed secrets store with a named owner and a rotation process, and limit the account to the reads Wazuh needs. Plan for silent failure as well, since a syslog sender can stop without any error on the Wazuh side. The dashboard should show when expected devices go quiet, so that a dropped feed is caught before an audit or an incident exposes it.
Agentless collection options and when each fits
This table compares four ways to bring data from a network device into Wazuh without installing a full agent on it. Read each row for how data reaches the manager, what the device must expose, who holds the credentials and the situations where that option is the sensible choice. The main takeaway is that agentless options trade visibility depth for reduced change on the device, so the choice usually follows what the device owner permits.
| Option | How data reaches Wazuh | What the device must expose | Who owns the credentials | When it fits |
|---|---|---|---|---|
| Syslog from the device | The device sends syslog messages to a Wazuh manager listener, which decodes and analyzes them | Syslog forwarding enabled and a route to the manager's listening port, with the log levels the team needs turned on | Usually none, since the device pushes events without stored login data (confirm transport and format options for your model) | Firewalls, switches and routers where the owner allows log forwarding but no inbound access or agents |
| Periodic API probing | The Wazuh manager polls a device API on a schedule and processes the responses as events | A management API that is reachable from the manager and returns the data the team needs | The team that manages the API account, stored in Wazuh configuration (confirm the supported authentication methods for your platform) | Devices with a documented read-only API where polling at a set interval gives enough visibility |
| SSH-based checks | The manager connects over SSH and runs defined commands, then evaluates the output and file integrity results | SSH access for a dedicated account, and a command set the device permits and that returns parseable output | The security team holds a restricted, rotated account, with keys or secrets kept in a managed store (confirm credential handling in current documentation) | Locked-down servers or appliances where SSH is allowed. Confirm supported command coverage and integrity-check behavior with current Wazuh documentation and a test device before rollout |
| Lightweight agent on a host beside the device | A Wazuh agent on a separate host reads the device through its management interface and forwards results | A reachable management interface from that host, and no software on the device itself | The team that operates the helper host, which holds the device access (confirm the collection method your version supports) | Devices that cannot run software or accept SSH, where a nearby Linux host can reach them on a segregated network |
How credentials and device access shape the design
Agentless collection is only as capable as the access the device grants, so that access sets the design before any rule is written. For network devices, the access usually takes one of three forms: syslog forwarding settings on the device that send events to the Wazuh server, API accounts that Wazuh probes on a schedule, or SSH accounts that Wazuh uses to run commands and check file integrity. Each path needs different credentials, exposes a different amount of the device, and carries a different risk if it is compromised. Decide the path for each device class first, then choose the accounts that path requires.
Give each monitoring path its own least-privilege account. Avoid shared administrator logins and avoid reusing an operator's personal account. Where the vendor offers a read-only role for API access, use it and confirm in the vendor documentation which endpoints that role can read. For SSH checks, limit the account to the commands the check actually runs, and confirm whether those commands need privilege escalation. Test the account by attempting a configuration change and confirming it fails. Record the account owner, the purpose and the approval for each account so that access reviews can verify it later.
For SSH, key-based access is the stronger default for a monitoring account because the private key can be held on the Wazuh side with restricted file permissions and the public key can be limited on the device to the specific command set. Password access is sometimes the only option on older or locked-down devices, and in that case the password needs a documented owner, a strong unique value and a defined rotation schedule. Confirm with your Wazuh version's documentation whether each check type supports key-based authentication, and confirm whether passwords are stored in configuration files, a keystore or another location before you commit to either method.
Rotation is where agentless monitoring most often fails silently. When a device password or key changes and the Wazuh side is not updated, checks stop returning data, and the gap may not be obvious until someone looks for an event. Plan a rotation procedure that updates the device, updates Wazuh, runs a test check and logs the change. Confirm where Wazuh stores these credentials, which accounts on the Wazuh server can read them, whether they appear in the dashboard or in logs, and how file permissions are set. Test this on a non-production device, and include the Wazuh server itself in your access review.
Setting up Wazuh agentless monitoring for a device
This sequence takes one network device from unmonitored to a verified event stream in the Wazuh dashboard. Each step ends with a check you can repeat, so a gap shows up at the step that caused it and the team can fix it before the next device is added.
Inventory target devices and interfaces
Your team lists each device with its model, firmware version, management interfaces and the protocols it exposes, such as SSH, an HTTPS management API or syslog. Record the device owner and whether the network path allows the Wazuh server to reach it. Confirm the interfaces on the device itself, and confirm firmware-specific log formats with the vendor's documentation before assuming anything. The step is done when every device has a row in the inventory with each interface checked on the device.
Choose a collection method per device
For each device, decide whether it will send events by syslog, be checked through periodic API probing, or be reviewed through SSH-based command and integrity checks. Devices that can forward logs are usually simpler to monitor than devices that must be polled. Record which checks the chosen method can and cannot provide, because agentless collection does not give the same endpoint visibility as an installed agent. Confirm the supported options for your Wazuh version in the Wazuh documentation. The step is done when each device has a written method and an owner who accepts its limits.
Create a read-only or forwarding-only account
Create a dedicated account on the device that can only read the data Wazuh needs, or only forward logs if the device supports that role. Do not reuse administrator or shared credentials. Use key-based authentication where the device supports it, and store the secret in your approved secrets manager. Test the account by logging in and confirming it can read the required data but cannot change configuration. Then run a deliberate failed login and confirm the failure appears in the device's own log. The step is done when both tests pass.
Configure the device to send events
On the device, enable syslog forwarding or the API or SSH access that the chosen method requires, and point it at the Wazuh server address. Set the device clock to a time source that the Wazuh server also uses, so timestamps line up across sources. Restrict management and forwarding access to the Wazuh server and the admin network. Generate a known test event, such as a failed login from step 3, and confirm the device's local log records it. The step is done when the test event exists on the device with the correct timestamp.
Point the Wazuh server at the device
On the Wazuh server, open the listener for syslog from the device, or add the device to the server configuration for API or SSH collection, using the account from step 3. Keep the credentials in the secure store and reference them from the configuration rather than writing them into plain files. Check the server logs for a successful connection and for any authentication or certificate errors. Confirm that only the expected ports and source addresses are open. The step is done when the server reports a clean connection to the device and no errors for the test period you set.
Add decoders and rules for the log format
Wazuh uses decoders to pull fields out of a log line and rules to decide which events matter. Start with the built-in decoders for the vendor if they exist for your firmware. Write custom decoders only for lines the built-in set does not parse. Test each decoder with sample lines from the device, including the failed-login line from step 3, using the log testing tool in your Wazuh version. Check that each sample decodes to the expected fields and triggers the expected rule and severity. The step is done when every sample line decodes as planned.
Confirm events reach the dashboard
Search the Wazuh indexer for the test events from steps 4 and 6, and confirm the source device name, timestamp, decoded fields and rule match. Then trigger a new failed login on the device and confirm the alert appears in the dashboard within the window your team has agreed. Repeat the check for each device in the inventory. Keep the test record with the device inventory so an auditor or the next engineer can see how monitoring was verified. The step is done when a fresh event from every device is indexed and visible in the dashboard.
Security risks of agentless access to network devices
Agentless monitoring trades an installed agent for network paths, stored credentials and remote interfaces on devices you may not fully control. The cards below cover the risks that most often appear when Wazuh receives syslog or probes device APIs and SSH, each paired with the control to verify before go-live.
Plaintext syslog transport
Syslog from a firewall or switch may travel over UDP or TCP without encryption, so log content can be read or altered in transit between the device and the Wazuh server. Confirm for each device model whether it supports a protected transport such as TLS-wrapped syslog, and check the vendor documentation for the exact configuration. Where the device cannot protect the stream, restrict the path to a dedicated management VLAN and document the residual risk.
Over-privileged device accounts
The API or SSH account Wazuh uses to probe a device often inherits administrator rights because a read-only role is harder to define. An account that can change configuration can also make the integrity checks meaningless. Create a dedicated account limited to the read and show commands the checks need, and verify its permissions by attempting a write on a lab device before rollout.
Credential sprawl across the server
Device passwords, keys and tokens tend to spread into Wazuh configuration files, shell history, scripts and backups, which makes rotation slow and incomplete. Record every location where a device credential is stored and decide which of them the Wazuh server must hold. Restrict file permissions on those locations, and plan a rotation procedure that updates the device and the monitoring configuration in one change.
Wazuh server reachable from device management
A Wazuh server that can reach every device management interface becomes a privileged path into the network, and a compromise of the server exposes every device it can log into. Place the server and the probing components in a segment that reaches only the management ports and syslog ports the checks require. Test the firewall rules from the server side and confirm that no other destinations are reachable.
Silent devices and missing logs
When a device stops sending syslog or a probe starts failing, nothing in the alert flow announces the gap, and a silent device can look the same as a quiet one. Define the device inventory Wazuh should expect, and alert on the absence of events from each source over a window you set for that device. Check the behavior by disabling forwarding on a lab device and confirming the alert fires.
Operating agentless monitoring after go-live
The first ongoing job after go-live is keeping decoders and rules matched to what the devices actually send. Network device firmware changes log formats, adds message types and renames fields, and a decoder written for one version can stop matching the next without raising any error. Assign an owner for each device class, record the firmware version each decoder was validated against, and review alert volume for each rule after every firmware change on an in-scope device. Keep custom decoders and rules in version control, and change them only after testing against sample messages captured from that firmware.
A silent source is the most common failure in agentless monitoring, because a device that stops sending syslog or fails an API probe produces no alert by default. Build a check that compares the last event time from each device against its expected reporting pattern, and alert when a source stays quiet longer than a threshold you set for that device class. Confirm that the check surfaces in the dashboard your analysts use. Apply the same logic to periodic probes: an authentication failure or timeout should appear as a monitoring health event, not as a line in a log file on the server nobody reads.
Duplicated and noisy events usually originate in the collection path, so fix them there before tuning rules to hide the symptom. Duplicates appear when the same syslog stream reaches the server through two relays, or when a probe interval overlaps a retry. Noise comes from routine events such as session openings, scheduled jobs or repeated interface flaps that matter in aggregate but not one by one. Suppress or aggregate these with documented rule changes, keep the raw events archived so an investigator can reconstruct what happened, and measure alert counts over a fixed period before and after each change.
Review credential rotation on a fixed schedule and whenever staff with access change. Each agentless check depends on an account on the device or an API token, so inventory those accounts, their permissions and where their secrets are stored. After each rotation, confirm that monitoring still authenticates and that a failure raises the health alert described above. Plan regular version checks as well. The Wazuh release notes list 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, including 4.14.8 and 4.14.9. These dates show the line is still being maintained, but they do not set a schedule you can rely on. Read each release note for changes to agentless components, test the upgrade on a non-production server first, and record the result before applying it to production.
Limits of Wazuh agentless monitoring to confirm in your environment
Agentless monitoring can fall short of agent-based monitoring in the areas below. Each card names one limit and the check to run before you commit to a design. The answers come from the Wazuh vendor documentation and a proof of concept in your own environment, and this page does not settle them.
Device models and firmware
Agentless monitoring depends on each device sending syslog or exposing an API that Wazuh can read. Support varies by model and firmware, so list every device class in scope and record its exact model and version. Confirm which log formats and API endpoints each version exposes, whether logging levels must be changed on the device, and whether a vendor firmware upgrade would remove the data your decoders and rules expect.
Shell command access on devices
Integrity and command checks over SSH run commands on the device's shell. Many routers, firewalls and switches offer only a restricted command-line interface, and some block the commands you need entirely. For each device, confirm that the monitoring account can run the specific commands your checks require, that the output is parseable by Wazuh, and that the commands change no state on the device.
Event volume at the server and indexer
Syslog from network devices can be verbose, and each event passes through the Wazuh server for decoding and rule matching before it reaches the Wazuh indexer. Measure events per second per device during the proof of concept, then size the server and indexer for the peak bursts you observe. Confirm how decoders handle your vendor's log format and whether high-volume facilities need filtering before indexing.
Probing frequency and device load
Periodic API probing asks the device for data on a fixed schedule. Each probe adds load to the device's management plane, and aggressive intervals can affect devices with limited CPU or strict session limits. Confirm the vendor's guidance on API rate limits and concurrent sessions, choose intervals per device class, and test during a maintenance window to see whether the device's own performance changes under monitoring.
Visibility lost compared with an agent
An agent reads local files, running processes and system state directly on the host. Agentless monitoring sees only what the device logs, what its API exposes and what the commands you run return. Confirm which local file changes, process activity and user session details your detection rules depend on, then document each gap with a compensating control such as central log forwarding or a separate control on the device.
Questions buyers ask before hiring help with agentless monitoring
How much does agentless Wazuh monitoring setup cost?
The cost follows from a fixed scope agreed in writing before work starts. DeployOpen does not publish a price list, so a quote is built from the scope itself. The main drivers are the number and types of devices, the collection methods (syslog, periodic API probing or SSH-based checks, each configured differently), the decoder and rule work needed for devices whose logs are not parsed out of the box, the credential model, and the number of environments. One-time costs cover design, deployment, decoder work, testing and handover. Recurring costs are ongoing support or a retainer, if you choose one, plus the infrastructure you run. Ask every bidder to itemize device types, collection methods, credential handling and documentation so quotes can be compared line by line.
How long does an agentless network device monitoring project take?
The timeline depends on device variety, decoder work, change windows and how quickly access is provided. Devices that already send standard syslog are typically simpler to onboard than devices that need custom parsing. Change windows on firewalls and core switches often set the pace, because changes to collection on those systems usually need approval. Ask for the schedule to show milestones: access confirmed, a test device validated, decoders accepted, production rollout and handover. Confirm the dates in the written scope, and confirm any dependency on your change calendar before the project starts.
What must we provide before network device monitoring work begins?
You provide access, approvals and owners. Expect to supply network paths from the Wazuh server to each device, accounts with the permissions the chosen collection method requires, and a named owner for each credential who can approve rotation. You also need a test device that can be changed safely, scheduled change windows for production devices, and a contact who can confirm device configuration details such as log formats and management addresses. Finally, provide a place to store the documentation, such as your internal wiki or change system. Name these items in the scope so responsibilities are clear on both sides.
Can our own team set up agentless Wazuh monitoring?
Yes, if your team already has the skills and time to do the work. The work needs someone who can run and tune a Wazuh server, understands decoders and rules, administers the network devices involved, and can manage credentials and change control. Teams without one of these areas often find that the device configuration or decoder work takes longer than expected. A practical test is to run one pilot device end to end, from access through alerts, and measure the effort before committing to the full estate. A partner can take on the whole build or only the parts your team cannot cover.
Does the open-source Wazuh software have a license fee?
The self-hosted Wazuh software has no license fee, according to the vendor. Wazuh is distributed under the GNU General Public License version 2, with an exception that permits linking with the OpenSSL library. Wazuh Cloud is a separate, managed cloud-delivered XDR and SIEM service with its own plans, sold in Small, Medium, Large and Custom tiers, and every paid plan includes at least Standard support. Wazuh Cloud offers a 14-day free trial that needs no credit card. Your costs for self-hosting still include infrastructure, storage, implementation labor and ongoing operations, so budget for those separately. Confirm current terms with the vendor before you decide.
Does agentless monitoring replace agents on our servers?
No. Agentless monitoring covers devices that cannot run an agent, and it does not replace agents where they are supported. Agents on servers and endpoints provide telemetry that agentless collection cannot, such as host-level file integrity, process activity and the system inventory that vulnerability detection correlates against vulnerability data. Agentless collection also does not replace a log retention policy, network detection tools or a dedicated runtime security product. Keep agents on every system that supports them, and use agentless monitoring for the locked-down devices and servers where an agent is not allowed or not practical.
How are network device credentials handled in agentless monitoring?
Use dedicated, least-privilege service accounts stored in a controlled secrets store, with a named owner and a rotation process. Each collection method needs a specific level of access, so grant only what that method requires, and confirm that the device supports the authentication method you plan to use, including key-based access where available. Keep credentials out of configuration files that are copied between environments, log access to the secrets store, and test rotation on the pilot device before production. Document who can approve a change, who receives alerts about failed logins, and how a credential is revoked when a person leaves. Confirm each device's authentication options with its vendor before design starts.
How DeployOpen scopes and delivers Wazuh agentless monitoring
DeployOpen plans, builds and documents Wazuh agentless monitoring for network devices inside your own infrastructure, starting from a written scope that names each device class, its checks and its credential model. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer.
How we scope
- Inventory of routers, firewalls, switches and locked-down servers, with the role of each and whether it can accept an agent.
- Which SSH-based integrity and command checks run on each device class, and which need confirmation against the vendor's platform.
- Credential model written into scope: accounts used, key or password handling, where secrets are stored and who rotates them.
How we build
- Agentless collection set up on your Wazuh server, with network paths, firewall rules and access accounts documented as built.
- Check definitions, schedules, decoders and rules configured per device class and tested against sample output from each device type.
- Alert thresholds and suppressions tuned with your operations team before monitoring goes live, so noisy checks are caught early.
How we hand over
- Runbook covering how each check works, its schedule, expected output and the limits of agentless monitoring compared with agents.
- Test evidence showing each check detected a controlled configuration change and reported a known-good state correctly.
- Credential and access records, plus a checklist of items your team reviews at each Wazuh upgrade and each device change.
How we support
- Ongoing support and continuous testing are available as a retainer, with scope agreed in writing after handover.
- Review after each Wazuh patch release, which the vendor ships roughly every one to two months, to confirm agentless checks still behave as documented.
- Retainer work can cover device inventory changes, new check definitions and periodic credential and access reviews for your environment.
