I think the developers of stuff like this come in two primary flavours: people who know enough to realize that it's not totally trivial, who rapidly fall down a

I think the developers of stuff like this come in two primary flavours: people who know enough to realize that it's not totally trivial, who rapidly fall down a security rabbit hole once they get going... and people who just churn out the minimum that meets the superficial description of the product ASAP. Because of the aformentioned rabbit hole, the fomer group doesn't tend to ship many products compared to the latter. The latter group's design gets compromised by a magnet or a magic packet because the description didn't say anything about those. :) I think if you think hard about it for a while and do some research you'll find that it's actually more complicated than you might think. ... two way communications between the 'key' and the lock, non-volatile counters in each to prevent replay, secure crypto that is too slow and power hungry when run on the 8-bit microcontroller that fits in the space/power/cost budget... etc. Of course, you can work around these challenges-- but that's the rabbit hole. :) There are various kinds of pretty secure electronic locks. Because of the extremely poor track record of cryptography in embedded devices I'd be inclined to find designs that rely less on crypto more trustworthy. I'm fond of the kaba mas x-10. :)