CVE-2023-4346 isn't just another denial-of-service vulnerability. It's a case study in how security features can become destruction vectors, permanently disabling a device in a way that no legitimate recovery procedure can reverse. The KNX BCU key feature allows an attacker who obtains device access to set a new password, and the device then accepts only that new credential — leaving the original operator locked out permanently. The device isn't temporarily unavailable; it's functionally bricked unless the attacker provides the key they just set.
This violates a foundational principle that the aerospace and medical device industries learned decades ago: security controls must not create irrecoverable states. MIL-STD-1553 and IEC 61508 codify this explicitly. The same failure pattern has appeared in BIOS passwords that brick ThinkPads, TPM initialization locks, and iCloud activation lock repurposed for coercion. The KNX vulnerability isn't a novel attack — it's the same genetic defect wearing different hardware. The building automation sector simply never absorbed the lessons other safety-critical industries were forced to learn.
What makes this particularly dangerous is the blast radius. KNX devices don't operate in isolation — they coordinate HVAC, lighting, access control, and potentially life-safety systems. A permanently locked controller in an interconnected building system can cascade into physical consequences: elevators stranded with occupants, buildings without climate control, evacuation systems that can't coordinate. The exposure window doesn't close when the attacker leaves; it stays open for the device's lifetime unless someone physically replaces it.
For defenders managing deployed KNX devices: inventory your BCU key configurations immediately. Identify any devices where BCU key protection is enabled without a documented, secured backup of the key. Treat any device where you cannot retrieve the original BCU key as potentially vulnerable to permanent lockout by anyone who gains any form of access — network-adjacent or physical. The vulnerability requires no special privileges; the exploit is identical from either attack vector, which indicates the authorization layer was never properly threat-modeled. Given that firmware updates for OT devices often never reach deployed hardware, treat this as a long-term operational risk that demands compensating controls until vendor patches become available.