This gives us an idea: we *might* ask our visitors to create an account when they take their ticket at the reception, so we can then monitor their machines, with a perfect inventory of IP, os, machine description, etc, so, during periodical checks, all the machines not on the list will be easy to be labelled as "suspicious".
You definitely need the inventory, in some form of another.
You could do what e.g. coffee shops and such do, and redirect all traffic from unknown devices to a registration page, where they type in their information, and a short key they obtain from any authorized lab worker. (The keys might be sorted in "untrusted visitor, external web access only" and "student"; "three hours", "today", "this week"; and preprinted and put in some jar not trivially accessible to guests. Anything else the admin handles.)
Again, this is just the combined two first steps in the security scheme. The unknown device users have to talk to a human to get a key, and the humans have very simple and friendly criteria how to behave. Any lab worker can hand off those "guest" keys for a day, they just need to help the guest fill in the web form. (That is to ensure the guests won't just fill in asdfgfgfds. It is easy to describe/frame it as "courtesy and helping" instead of "we're suspicious of you". Trust but verify.)
armored cabinets
Standard racks, with doors you can close and lock on all sides (even though you can pick the lock using a twig), should suffice if in-campus.
For wireless routers, don't bother; just have a piece of security cable tied to keep it in place if human reachable, so it is not just trivially swipable. (Same applies to video projectors and such, by the way.)
All access problems I've observed have been caused by students letting in complete strangers through locked doors (naïve, don't want to look prejudiced), or by personnel or students with an obvious drug/gambling/kleptomania problem looking for wallets to swipe. Again, the first step is making it look like it is not worth the effort of trying to obtain access without permission. So, not so much making it look impossible, just make it look too noisy and too obvious trying to break them.
If you make security practices cumbersome, people will just work around it. It is important to try and make it easier to do it right, than bypass it. This is the major reason why I tend to implement home-brew scripts for monitoring and such, not NIH. There just aren't modular security component services that one could combine to fit very different needs; they all want to be the overarching framework that stuff happens under. (Yes, I am one of those who are disgusted by the awful design and implementation of the pile of crap called systemd. I don't like the approach at all.)
Again, if I were to write the identifying service, I'd make it trivial to install and configure, even for embedded devices; and as simple as humanly possible. Have it just do that one thing, reliably identify the machine based on Ethernet/WiFi queries. The server side would similarly have to be modular.
I very definitely subscribe to
Unix philosophy and the
KISS principle. I do choose the paranoid approach and overengineer the code I write, but I don't see any contradiction or real NIH symptoms in that.