📢 New post: The Light Switch Is on the KEV List: CVE-2023-4346 and Whether Your Building Is in the Boundary · 📝 Also fresh: The Security Appliance Nobody Drew on the Diagram: FortiSandbox CVE-2026-39808 · 🚦 Beacon — the FedRAMP 20x KSI emitter — design partners open ✨ · 🆕 20x Hub: program reference, kept current · 🧪 Free tool: KSI Quick Check — paste, run, get the verdict
← Blog
FedRAMPConMonCISAGRC

The Light Switch Is on the KEV List: CVE-2023-4346 and Whether Your Building Is in the Boundary

Most of the KEV items we've walked through have been recognizably IT — a PAN-OS GlobalProtect bypass, a UniFi OS chain, an AI orchestration takeover in Langflow. This week's is different in a way worth sitting with, because it points the same clock at gear most compliance programs never think about.

On July 15, CISA added CVE-2023-4346 to the Known Exploited Vulnerabilities catalog, with a federal remediation deadline of July 29. The affected thing is KNX Protocol Connection Authorization Option 1 — the authorization scheme in KNX, the open standard that runs building automation: lighting, HVAC, shades, and in a lot of installs, physical access control. NVD scores it CVSS 7.5 (HIGH) — vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, weakness CWE-645, Overly Restrictive Account Lockout Mechanism. CISA lists all versions of the affected configuration as in scope, and known ransomware use as unknown.

What the bug actually does

The name is the opposite of intuitive. "Overly restrictive account lockout" sounds like a login page being too strict. Here it's a weapon. Per NVD and CISA's ICS advisory, a KNX device using Connection Authorization Option 1 — without additional security options enabled — can be reached over the network, its devices purged, and a BCU key set to lock the device. Once that key is set, the legitimate operator can't get back in. That's the whole I:N/A:H shape of the CVSS vector: no confidentiality or integrity loss called out, but a clean, high-impact hit to availability. An attacker doesn't read your building; they lock you out of it.

The distinction that matters for a KEV clock: this isn't a "get root and exfiltrate" bug. It's a "brick the controllers that run the physical plant" bug, achievable by someone with network reach to the KNX bus. Physical access works too — but network exposure is what turns it from a facilities problem into a remote one.

The question that comes first

We keep landing on the same first move when a KEV item drops, and this one makes it unavoidable: before "patch," the honest question is "is this even ours — and is it inside the boundary we're accountable for?"

For most cloud service providers, KNX isn't in the authorized system at all. Building automation lives in the facility, not the product. It's the landlord's, or the colo operator's, or a facilities contractor's. So for a lot of readers the correct, defensible answer to CVE-2023-4346 is "not in our boundary" — and, as with PAN-OS, the interesting part is how fast and how defensibly you can say that.

But "not us" is a determination you document, not one you assert. A FedRAMP authorization boundary isn't only the customer-facing service — and this is exactly the class of thing that can pull building systems into scope:

  • Do you run your own facility? An agency data center or a provider with a facility-based authorization owns the physical and environmental layer. KNX-driven HVAC and access control can sit squarely inside the PE (Physical and Environmental Protection) control family — which means a KEV item on the automation protocol is your finding, not the landlord's.
  • Is the building network actually separate from the boundary? The comforting assumption is that facilities OT and the authorized system live on different worlds. The uncomfortable reality is a flat management VLAN, a shared jump host, or a "temporary" bridge nobody revisited. The CVSS AV:N says this is reachable over the network; whether it's reachable from your network is a scoping fact, not a hope.
  • What does availability of the physical plant support? If KNX runs the cooling for the racks that run the authorized system, then an availability hit to the building is an availability hit to the service. The boundary follows the dependency, not the org chart.

Get those right and "not applicable, and here's the inventory and network diagram that prove it" is a perfectly good answer. Get them wrong — assert "not us" because it feels like facilities — and you've scoped out an actively-cataloged, network-reachable availability bug that your cooling depends on.

Through the BOD 26-04 lens

CISA's required action here points straight at BOD 26-04: apply mitigations per vendor instructions, follow the risk-based patching guidance, evaluate each asset's internet exposure, and discontinue use if no mitigation exists. Run this one through the four questions:

  • Publicly exposed? KNX gear should never touch the internet — but the ones that do (remote facilities management, a misconfigured gateway) are exactly the assets this directive tells you to find and rank first.
  • Actively exploited? It's on the KEV catalog, which is the bar. Ransomware use is listed unknown, but availability-destroying access to physical infrastructure is precisely the kind of leverage that gets weaponized.
  • Automatable? Under FedRAMP's "assume it's automatable" default, you presume yes unless you can prove otherwise. Setting a BCU key over the network is not a hands-on-keyboard artisan exploit.
  • Full control? Not confidentiality or integrity here — but denial of the physical plant is as complete as an availability impact gets.

The remediation itself is the ordinary, unglamorous kind: enable the additional KNX security options so Connection Authorization Option 1 isn't standing alone, follow the vendor's hardening guidance, and — most of all — make sure the KNX bus isn't reachable from anywhere it doesn't need to be. Segmentation does more here than a patch, because the vulnerable behavior is baked into the authorization option itself.

What we keep coming back to

The technical fix is a weekend of facilities work. The thing that makes July 29 a calm date instead of a scramble is the same capability every one of these posts lands on: knowing what you run, at the resolution the CVE is written, before you're asked under a clock.

That's harder for building automation than for servers, precisely because nobody thinks of the light switch as an asset. The KNX controller doesn't show up in the software bill of materials. The person who knows its version may be a facilities contractor, not the security team. So when a KEV item lands on the protocol that runs the building, the first three days evaporate into figuring out whether you even have it, where it lives, and whether it can touch the boundary.

That's the work the Novaprospect audit engine is built around: infrastructure-native discovery that includes the OT and facility layer, not just the application stack — so a KEV listing on KNX surfaces the specific devices you run, their exposure, and whether they sit inside or outside the authorization boundary, with the network evidence to back the determination either way. The point isn't that every building system is in scope. It's that "in scope or not" should be a query you can answer in an afternoon, with the trail to prove it — not a meeting you convene because CISA started a clock on your light switch.

In a few weeks the actively-exploited thing will be something else again. The lesson holds the way it always does: know what you run — including the parts that don't look like IT — before someone else's timeline decides you have to.

Reference