IT made them do it for good reasons though. Managing a large number of users and workstations in an enterprise environment is one of the things that Microsoft stack stands out.
Pull the boundaries in. Provide all of the enterprise services through the web. Provide hardened VMs for those services that can't be migrated. Suddenly your workstations are thin clients, and it doesn't really matter anymore if someone decides they want BYOD.
Now you can get after the actual interesting problem of intellectual property theft and corporate espionage. Things which the firewalls of old did nothing to prevent but provide a layer of obfuscation.
It's naive to think that just because your production critical software is web based, you can just have everyone BYOD. That is asking for rampant malware on the company network, and targeted attacks that steals company secrets.
You're completely missing the point. The internal network I'm describing should be nothing more than server metal and virtual workstations. Your border is miniscule at that point. You no longer have to fret about network ports in conference rooms. You no longer have to worry about testing your OS and software patches on the 20 iterations of lifecycle replacement hardware that is floating out in your company. You don't even need to invest heavily in workstations, as thin clients will suffice for most situations. Business continuity becomes a piece of cake because you're no longer factoring in the physical workstation beyond ensuring your cold site has a box of laptops in the corner.
Your concern about rampant malware won't even matter because the only way people can access the web services is through the VMs. The thin clients and physical workstations won't even be able to access most of those services that are mission critical.
In the situation where a company provided physical workstation is necessary, that machine would be just as isolated from the internal network as anyone else. Developers can use one of those, or use VMs that are VLAN'd off. And if your developers are automating their builds and containerizing, then your developers are going through layers of services and automation before their code goes out to production, so even they won't need access to production environments from their relatively insecure dev laptops.
From the lens of a programmer it's definitely possible to do BYOD without any real danger to the domain.
They need access to a few webfrontends and be able to use their SCM server...
But in order to do that, they'll have to be able to test locally or have a really hardened access to their servers. Significantly harder than just forcing everyone on company hardware without root/admin access
Developers get special treatment, because the nature of their work often require them to have local admin access. But the majority of people do not need that, and if I'm in charge of company network and security, I would not allow anything but approved machines on the internal network.
Each and every organization I've heard of that did that, reverted to give developers local admin pretty quickly because the requests to the IT administrators for every time a developer needed admin to install a required dependency, start whatever at admin to debug, change reg settings, test installations, ect.
Senior scientists in corporate R&D often require local admin access as well. The image analysis and spectum simulation programs I needed to run and keep updated were not on the radar for our corporate IT folks. They were very good at what they did and were cooperative when we explained our needs and showed that we were competent to manage our own systems and were willing to reach out and ask questions before doing something unfamiliar. Even in R&D, most chemists could use a standard workstation. It was mainly analytical chemists/material scientists working with specialized instruments and doing custom software development that needed local admin access.
