ESET PROTECT Integration Beta: Endpoint Detections That Trigger WiFi Network Response

Your endpoint security knows a laptop is infected. Your network has no idea. The laptop keeps its WiFi session, keeps its VLAN, and keeps talking to everything else on the network until someone reads the alert and walks over.

The reverse is also true: the WiFi console shows a healthy, authenticated session. It cannot see that the machine behind that session is running ransomware.

Our new ESET PROTECT integration connects the two. ESET provides the detection, and IronWiFi WiFi ITDR provides the enforcement point the endpoint cannot tamper with: the network itself. The integration is available in beta starting today.

How It Works

1. Sync: IronWiFi connects to your ESET PROTECT instance through the ESET Connect API and continuously syncs endpoint detections.
2. Correlate: Each detection is checked against live RADIUS accounting. If the flagged device currently holds an active WiFi session, IronWiFi raises an infected endpoint on network detection with full network context: SSID, access point, NAS IP, session username, and session start time. Severity maps from ESET's own score.
3. Respond: A response playbook acts on the detection automatically - or just notifies, if you prefer a human in the loop.

What a Playbook Can Do in This Beta

• Disconnect the session with RADIUS CoA - the device is off the network in seconds.
• Block the MAC address so the device is rejected on its next authentication attempt, on every AP and every site.
• Move the device to a quarantine VLAN - contained, but still reachable for remediation.
• Block the client natively on Meraki networks through the Meraki API.
• Notify instead of enforce, for teams that want to validate before automating.
• Run in shadow mode first: every action is logged as "would have executed" so you can test triggers against real traffic before enabling enforcement.

Customers running their own RADIUS servers are covered too: response actions are dispatched to your infrastructure through a webhook instead of direct CoA. And because enforcement decisions ride on your existing cloud RADIUS authentication flow, there is nothing to install on the devices themselves.

Why Network-Side Enforcement Matters

ESET PROTECT already has host isolation, and it works well when the agent is healthy. But host isolation asks the compromised machine to police itself. Malware that gains admin rights and kills the endpoint agent also kills the containment.

Every detection, incident, and response action is persisted. For cyber insurance questionnaires and compliance audits, that means demonstrable evidence: compromised endpoints are automatically isolated from the network, with logs to prove it. If you are building toward policy-based access more broadly, this pairs naturally with conditional access rules on the same platform.

What Beta Means

The integration is feature-complete and available to IronWiFi customers on request. We are looking for early adopters running ESET PROTECT who want endpoint-triggered network response, and we will work directly with you during onboarding.

Getting Started

You will need an ESET PROTECT license with ESET Connect API access.

1. Create an API user in ESET PROTECT.
2. Add an ESET vendor connection in the IronWiFi console: the API username, password, and your ESET region (us / eu / de / ca - the region must match your ESET instance).
3. First sync anchors to now: historical detections are not replayed, so enabling the integration never floods you with old alerts.
4. Create a response playbook triggered on the infected-endpoint detection type. Start it in shadow mode.

The Bigger Picture

WiFi ITDR watches the authentication layer for identity threats: credential attacks, MAC spoofing, impossible travel, insider misuse. Endpoint detections are a new signal source in that same pipeline - the first of several security vendor integrations on the roadmap. If you want the background on the category, start with What Is WiFi ITDR?