All your points have contradicted my most important one. We should never allow the situation in which someone who has been given access to the network (a guest

All your points have contradicted my most important one. We should never allow the situation in which someone who has been given access to the network (a guest, a child, ...) can be allowed to either control the BACnet components themselves, or install a trojan that can. By having no security built in, BACnet can be controlled by any device that has unrestricted access to the network - whether it be a compromised computer, a guest, etc. You can say that giving someone access to your wifi is some cardinal error, but people do it every day, and ignoring it would just give Apple a headache. In an enterprise this is manageable, in a home it is not - because Apple will have bad pr from people getting their central heating hacked, but will not be able to supervise the installation themselves. My phone is not particularly secure, no. But good sandboxing means that I can ignore the majority of network threats. If Apple programmed this in their computers as a system level program, then it would be at least as secure as (say) the keychain, which already contains enough to leave me in big trouble if it got leaked. BACnet can use all of the network architecture around, but generally needs it to be supported in some way. For example, had BACnet used TCP - it would have been fairly trivial to get BACnet to use TLS as well, and then the security issue would have gone away. I'm sure that all of the critical flaws with BACnet (and don't be confused, they are critical flaws) can be fixed with addendums to the standard. The problem is that then we have much BACnet compatible software that doesn't support BACnet as implemented by Apple. Again, were I Apple, I'd - Refuse to use any BACnet device that didn't provide a minimum level of security, because it could lead to bad PR. - Refuse to use any BACnet device that didn't operate on top of TCP at a minimum (because using TCP allows me to use (say) TLS). - Refuse to use any BACnet device that wouldn't support both IPv4 and IPv6. - Have to work with all the BACnet stakeholders. - Have to make all of my software backwards compatible. - Have to find some way of agreeing with all the stakeholders to market their Apple-compatible devices in such a way that Apple customers won't have to spend days poring over spec sheets to find out which BACnet devices are compatible with the Apple software. BACnet is just a protocol, and a complex, bloated one - if it's flawed such that to fix it we must change it drastically, it's probably easier to just replace it. It's already clear that almost all of the devices on the market currently would not be compatible with whatever a reasonable Apple might do. Given that this might require many changes to the standard, why should they bother with all the politics when they can just do it themselves? These flaws (believe it or not) actually negate the rest of the BACnet standard. It's a standard, yes, but it's an old one, and we can do better with the benefit of both hindsight and modern hardware. From a hardware point of view, it's probably better to use the standard - from a software or UX point of view, the standard adds nothing, but takes many things away. As a pure point of history, BACnet became an ISO standard in 2003, work having started in 1987. TCP has been a standard since 1974, and a new standard was published in 1989. The problem for BACnet is obviously that every time a new physical transport is announced, BACnet as a standard has to add support - much effort on the part of anyone who wants to get things moving faster. Addendums to a standard don't really hold much water, by the way. If you can just add something to a standard whenever the standard doesn't do what you want, then you lose the standardisation. Indeed, if you add anything to a standard, it ceases to be that standard (it becomes a new standard).