CVE-2026-3611: Unauthenticated IQ4 Web HMI Exposes Critical BMS Risk

Honeywell’s widely deployed IQ4 building-management controllers can ship in a factory-default state that exposes the full web HMI without authentication, creating an immediate, high-severity risk for any installation where the device is reachable from untrusted networks.

Background​

The IQ4 family — marketed under Honeywell/Trend as IQ4E, IQ412, IQ422, IQ4NC, IQ41x, IQ3 and IQECO — is a line of building-management system (BMS) controllers used to manage HVAC, lighting, and other building automation functions across commercial, healthcare, government, and industrial facilities. These controllers run an embedded web-based HMI that operators normally use for monitoring and configuration. The controllers support standard building protocols such as BACnet/IP and expose Ethernet/TCP/IP networking for integration into modern building networks.
On March 2, 2026, researcher Gjoko Krstic of Zero Science published advisory ZSL-2026-5979 describing an unauthenticated web-HMI exposure in the IQ4 family. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) followed with an advisory on March 10, 2026 that cataloged the issue and assigned it the identifier CVE-2026-3611, giving the vulnerability a CVSS v3.1 base score of 10.0 — Critical. CISA’s advisory warns that successful exploitation could allow unauthorized access to management settings, control of field components, disclosure of sensitive information, or denial-of-service conditions.
Honeywell’s published product literature and datasheets confirm that IQ4 controllers are designed for on-premises building control and are typically installed and configured by specialist technicians. Honeywell’s public response to the researcher’s findings frames the vulnerability as a deployment/configuration issue — emphasizing that devices are delivered unconfigured and that security controls are applied during standard installation — while researchers and independent reporting indicate thousands of devices are reachable from the public internet in insecure states.

---

What the flaw actually is: technical summary​

At root, CVE-2026-3611 is a missing authentication for a critical function in the IQ4 web interface. The specific failure mode documented by researchers is:

• When an IQ4 controller is in its factory-default configuration and no user module is enabled, the embedded web HMI is available without authentication.
• In that default state the system runs under a privileged context (described by researchers as System User, level 100), granting read/write capabilities.
• Authentication enforcement is only enabled after a web user account is created through a web endpoint (U.htm) that dynamically activates the user module.
• Crucially, the endpoint used to create the first web user is accessible prior to authentication. This means a remote actor who can reach the HTTP interface can create an administrative account under attacker-controlled credentials — and thereby enable authentication under their own control.
• An attacker who creates such an account can take administrative control of the controller and potentially lock out legitimate operators, change operating setpoints, disable equipment, or disrupt building services.

Researchers also reported additional exposed endpoints (diagnostic pages, hidden overview paths) that expand the attack surface beyond the visible HMI.
This is not an authentication-bypass in the narrow sense of bypassing an existing login; it is a design decision and insecure default that allows administrative setup operations to be performed by any unauthenticated HTTP client with network access to the device.

---

Scope and affected firmware​

Affected product models include the IQ4 series variants named above. Impacted firmware releases were enumerated by researchers and reflected in vendor and CISA advisories; the vulnerable firmware window includes multiple v3.x and v4.x builds used across the IQ4 line. The vulnerability draws particular attention because the insecure state is the factory default for some firmware builds: devices straight out of the box, or those that have been reset to factory defaults, can present the full HMI without any initial login required.
Researchers reported finding thousands of IQ4 instances with their HMI exposed on the public internet and estimated a substantial proportion of those were accessible without authentication. Multiple industry outlets and CISA authenticated that internet exposure exists for many controllers, though the precise counts and percentages are researcher-supplied and have not been comprehensively validated by the vendor or by centralized scanning authorities.
Given that IQ4 controllers are deployed worldwide in buildings that control life-safety and environmental systems, even a conservative exposure — a few hundred internet-reachable units — is operationally significant.

---

Realistic attack scenarios and impacts​

The technical capability translates into several high-risk attack scenarios for organizations that allow management interfaces to be reachable from untrusted networks:

• Unauthorized administrative takeover: An unauthenticated user can create a web user with administrative privileges, then change control configurations, schedules, and setpoints. That can mean turning off chillers, disabling boilers, or altering fire-safety monitoring thresholds.
• Operator lockout: Because the first web user action enables the user module and defines credentials, an attacker can create credentials that lock legitimate technicians out of local and remote management paths.
• Manipulation of environmental controls: Attackers can raise or lower temperatures, switch off ventilation, or tamper with HVAC scheduling — actions that can harm occupant safety, damage equipment, or trigger costly outages.
• Information disclosure: Exposed HMIs may display system topology, passwords stored in configuration forms, or other operational details that help lateral movement.
• Denial-of-service: Malicious reconfiguration or deletion of critical control parameters can put plant systems into unsafe states or require extended recovery time.
• Supply-chain and long-game attacks: With administrative access, an attacker could create persistent backdoors (cron-like tasks, configuration changes, or hidden users) that survive reboots and are difficult to detect on typical building-operational procedures.

These are not theoretical: researchers reported successfully exercising write actions and controlling field components in at least one test installation, contradicting vendor claims that unconfigured devices cannot affect equipment until fully commissioned.

---

What vendors and authorities are saying​

• Researchers: The advisory from Zero Science (ZSL-2026-5979, published March 2, 2026) documents the unauthenticated HMI exposure, the pre-auth user-creation endpoint, and includes a proof-of-concept script demonstrating the issue. The researcher provided estimated exposure counts and categorized the issue as critical.
• Honeywell: Company responses emphasize that IQ4 devices are designed to be installed and configured by trained technicians, and that a typical installation process will enable security controls. Honeywell has characterized the insecure state as a brief installation-phase condition or an outcome of misconfiguration when installers deliberately disable defaults.
• CISA: The U.S. Cybersecurity and Infrastructure Security Agency issued an ICS advisory (recorded March 10, 2026) that classified the vulnerability as “Missing Authentication for Critical Function” and assigned a CVSS 3.1 score of 10.0. CISA’s guidance is precautionary; it notes Honeywell is aware and that no vendor patch had been released at the time of advisory publication. CISA also highlighted standard OT defensive measures, such as network segmentation and limiting internet exposure.

The public exchange includes a substantive disagreement: Honeywell argues the production footprint is secure when properly installed, while researchers and several independent news outlets point to practical deployments and scanning results that show many units connected in ways that make the insecure default exploitable.

---

What we can verify — and what remains uncertain​

Verified facts

• The vulnerability class is missing authentication for a critical function, and the pre-auth user-creation flow is the primary issue. This is documented by the original researcher advisory and echoed by CISA.
• Affected IQ4 models include IQ4E, IQ412, IQ422, IQ4NC, IQ41x, IQ3, and IQECO in certain firmware ranges.
• CISA issued an ICS advisory assigning the condition CVE-2026-3611 and rating it Critical (CVSS 10.0).
• Vendor guidance at time of public reporting encouraged limiting internet exposure and installing devices via trained personnel.

Unverified or disputed claims

• The researcher’s specific exposure counts (e.g., ~7,500 internet-reachable devices and ~20% unauthenticated) are researcher-provided and have not been independently validated by Honeywell or CISA. Independent reporting has confirmed that some devices are internet-exposed, but no single authoritative inventory confirms the exact numbers.
• Whether a particular field deployment will allow write operations in the unconfigured state depends on plant wiring, integration methods, and other local configuration — so blanket statements that unconfigured devices “cannot control equipment” are overstated without local testing.

Because of these uncertainties, organizations should treat any reachable IQ4 HMI as potentially exploitable until they can verify otherwise.

---

Immediate actions for defenders — a prioritized checklist​

If your organization uses IQ4 controllers, take the following steps immediately. These actions are ordered by speed and risk reduction impact.

• Identify and isolate
• Inventory existing IQ4 controllers, including model and firmware information.
• Block public access: ensure no IQ4 HTTP ports are reachable from the internet by checking firewall rules and external scans.
• If a publicly reachable device is discovered, immediately place it behind a firewall or network ACL.
• Confirm authentication state
• From a secure management workstation, attempt to reach the controller’s web HMI. If the HMI displays without login prompts, treat the device as vulnerable.
• Verify whether a web user account already exists. If none exists, be extremely cautious about creating the first account remotely — creating a user can enable authentication (and if an attacker can reach the same endpoint, that creates race conditions).
• Secure local physical access
• Ensure the device’s management port is accessible only from trusted subnets and management VLANs. If local engineers need to create the first account, perform these actions from a physically isolated management network or via a secured jump host.
• Create trusted web users safely
• Prefer to perform the initial user creation from the local network behind the controller’s management VLAN, using a console or isolated workstation that is not internet reachable.
• If in doubt, schedule a maintenance window and perform a factory reset + secure commissioning under controlled conditions to ensure the first user is created by authorized personnel.
• Network hardening
• Segment BMS and field devices into a dedicated OT VLAN, enforce strict firewalling between IT and OT, and implement allowlists for authorized management hosts.
• Disable unnecessary services on the controller (e.g., HTTP) and prefer secure management channels if supported (HTTPS, SSH).
• Where remote management is necessary, use secure, authenticated VPNs with certificate-based authentication and limit VPN client privileges.
• Monitoring and detection
• Add controller management IPs to monitoring and SIEM detection rules; log all web interface access.
• Hunt for signs of unauthorized account creation, suspicious changes to schedules or setpoints, or unexpected reboots.
• Contact vendor and support
• Open a support case with Honeywell PSIRT and request guidance and timelines for an official remediation or firmware fix.
• Follow vendor instructions for safe commissioning and hardening steps; retain audit trails and contact records.
• Plan for patching
• Establish patch/firmware testing and deployment processes for BMS devices. Do not apply untested firmware to production controllers without staging and rollback plans.

---

Step-by-step safe commissioning workflow (recommended)​

• Physically connect the controller to an isolated commissioning network that has no routable path to the wider enterprise or the internet.
• Access the controller’s web HMI from a dedicated local laptop or workstation that is on the isolated network.
• Create the initial web user account (the action that enables the user module) while capturing configuration snapshots and any baseline logs.
• Apply recommended security settings: change default credentials, disable unused protocols, enable HTTPS and cert validation where possible.
• Move the controller into its production VLAN only after verifying authentication is active and management paths are restricted to authorized hosts.
• Document the commissioning steps and store credentials securely in a secrets management tool or hardware-backed vault.

This workflow avoids the race condition where an external actor could create the first admin account during commissioning.

---

Detection and incident response playbook​

If you suspect an IQ4 controller has been compromised:

• Immediately isolate the controller from upstream network connections and put it into maintenance mode if possible.
• Record forensic data: capture memory images, configuration files, and system logs in a forensically-sound manner.
• Rotate related credentials (management consoles, supervisors, integrator accounts) and enforce password changes across any systems linked to the compromised controller.
• Identify and remediate any persistent changes: scheduled tasks, disabled alarms, user accounts, or new network services.
• Validate physical safety: confirm that HVAC, fire-safety, and other life-safety systems are operating as intended and switch to manual override if required.
• Engage third-party ICS/OT incident response specialists when available; these systems often require domain-specific expertise to restore to a safe state without causing further damage.
• Report incidents to national CERTs and regulatory bodies as required, and consider notifying insurers and legal counsel for compliance obligations.

---

Longer-term operational and procurement lessons​

This incident underscores several systemic challenges in the procurement and lifecycle management of OT devices:

• Secure-by-default is non-negotiable: Devices that ship in insecure default states dramatically increase risk, because even well-managed organizations can have missteps during commissioning.
• Vendor accountability and transparency: Enterprises should require vendors to document secure commissioning procedures and provide firmware update roadmaps and PSIRT contacts in contracting terms.
• Asset visibility: Building automation devices are often introduced by third-party contractors or integrators; procurement and security teams must integrate these devices into asset inventories before installation.
• Continuous validation: Security baselines for OT should include periodic re-validation that segmentation and allowlists remain intact, rather than one-time commissioning checks.
• Contractual security SLAs: Contracts with OT vendors and integrators should include security requirements such as secure-by-default configurations, regular security testing, and timelines for vulnerability remediation.

Organizations that purchase, operate, or maintain building automation systems should require proof of secure defaults and an ongoing vulnerability management commitment from suppliers.

---

Balancing vendor guidance and practical defenses​

Honeywell’s point — that IQ4 devices are meant to be configured by trained installers and are not designed for direct internet exposure — is technically valid. OT devices frequently rely on an assumption of an air-gapped or segmented management plane. However, that assumption is brittle in practice: integration needs, remote troubleshooting, contractor errors, and misconfigurations routinely place devices within reach of broader networks.
Therefore, while vendor guidance is part of the equation, defenders must act on practical realities:

• Assume misconfiguration happens. Harden the network perimeter and assume devices may be exposed inadvertently.
• Assume an attacker will test common device endpoints. Block direct access from public networks and log any inbound hits to management ports.
• Treat industrial and building systems as first-class security priorities. The potential business impact is real: disrupted HVAC, damaged equipment, and occupant safety consequences are all within the plausible outcome set of a successful exploit.

---

Final assessment and outlook​

CVE-2026-3611 is a clear example of the gap between design-time assumptions and operational reality in OT security. A device design that requires manual activation of authentication is, in principle, acceptable if commissioning workflows are tightly controlled. In practice, the existence of an unauthenticated path that enables administrative creation by any unauthenticated HTTP client creates a high-value target whenever that device is reachable.
Until Honeywell publishes and distributes an official fix or a firmware change that removes the pre-auth account-creation race condition, organizations must assume the highest reasonable risk level for any internet-exposed IQ4 HMI. The immediate and feasible defenses are straightforward: inventory, isolation, safe commissioning on a management-only network, restricted remote access, and monitoring. These are not glamorous controls, but they are effective at reducing the attack surface while waiting for vendor remediation.
For building owners and facilities managers, the takeaways are blunt: validate that BMS management interfaces are not internet-exposed; require secure commissioning from installers; and treat building-controller firmware and configuration audits as a recurring, prioritized security task. The intersection of legacy industrial expectations and modern network realities demands nothing less.

---

In the coming weeks and months, watch for vendor firmware advisories and PSIRT communications. Apply the safe commissioning workflow for any new or reset controllers, and assume compromise until you can prove a controller’s management plane is locked down under operator control. The risk is immediate, the fixes are procedural and network-based for now, and the consequences for inaction are operationally significant.

---

Source: CISA Honeywell IQ4x BMS Controller | CISA